All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	mturquette@ti.com
Subject: Re: [PATCH v2 5/6] OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
Date: Fri, 7 Oct 2011 17:16:22 -0500	[thread overview]
Message-ID: <4E8F7A36.3030408@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1110061938210.4611@utopia.booyaka.com>

Hi Paul,

On 10/6/2011 20:40, Paul Walmsley wrote:
> On Fri, 16 Sep 2011, Jon Hunter wrote:
>
>> From: Jon Hunter<jon-hunter@ti.com>
>>
>> The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
>> clock frequency (fint) operating range than OMAP3430. Update the
>> dpll_test_fint() function to check for the correct frequency ranges
>> for OMAP36xx and OMAP4xxx.
>>
>> For OMAP36xx and OMAP4xxx devices, DPLLs fint range is 0.5MHz to
>> 2.5MHz for j-type DPLLs and otherwise it is 32KHz to 52MHz for all
>> other DPLLs.
>>
>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>
> This looks okay to me for now - queued for 3.2.  Ideally we would move the
> Fint DPLL data to the struct dpll_data, but this would be a fairly
> significant undertaking, since we don't have a clean way to use different
> dpll_data for different OMAP3 variants.  Something good to keep in mind
> for the common clock conversion.

You know at first I was thinking about adding this to the dpll_data 
struct, but then I thought these ranges only change for a couple dplls 
and so adding a few more members to each dpll struct was bloating the 
struct and making this a massive change. So I went the other path and 
just added a couple defines to minimise the changes. However, we could 
definitely do that if it is preferred and if with next-gen devices (such 
as omap5) more dplls have different ranges then this would make more 
sense too.

Cheers
Jon


WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/6] OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
Date: Fri, 7 Oct 2011 17:16:22 -0500	[thread overview]
Message-ID: <4E8F7A36.3030408@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1110061938210.4611@utopia.booyaka.com>

Hi Paul,

On 10/6/2011 20:40, Paul Walmsley wrote:
> On Fri, 16 Sep 2011, Jon Hunter wrote:
>
>> From: Jon Hunter<jon-hunter@ti.com>
>>
>> The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
>> clock frequency (fint) operating range than OMAP3430. Update the
>> dpll_test_fint() function to check for the correct frequency ranges
>> for OMAP36xx and OMAP4xxx.
>>
>> For OMAP36xx and OMAP4xxx devices, DPLLs fint range is 0.5MHz to
>> 2.5MHz for j-type DPLLs and otherwise it is 32KHz to 52MHz for all
>> other DPLLs.
>>
>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>
> This looks okay to me for now - queued for 3.2.  Ideally we would move the
> Fint DPLL data to the struct dpll_data, but this would be a fairly
> significant undertaking, since we don't have a clean way to use different
> dpll_data for different OMAP3 variants.  Something good to keep in mind
> for the common clock conversion.

You know at first I was thinking about adding this to the dpll_data 
struct, but then I thought these ranges only change for a couple dplls 
and so adding a few more members to each dpll struct was bloating the 
struct and making this a massive change. So I went the other path and 
just added a couple defines to minimise the changes. However, we could 
definitely do that if it is preferred and if with next-gen devices (such 
as omap5) more dplls have different ranges then this would make more 
sense too.

Cheers
Jon

  reply	other threads:[~2011-10-07 22:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-16 17:48 [PATCH v2 5/6] OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices Jon Hunter
2011-09-16 17:48 ` Jon Hunter
2011-10-07  1:40 ` Paul Walmsley
2011-10-07  1:40   ` Paul Walmsley
2011-10-07 22:16   ` Jon Hunter [this message]
2011-10-07 22:16     ` Jon Hunter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E8F7A36.3030408@ti.com \
    --to=jon-hunter@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mturquette@ti.com \
    --cc=paul@pwsan.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.