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
next prev parent 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.