From: Jon Hunter <jon-hunter@ti.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: mturquette@ti.com, paul@pwsan.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 05/24] ARM: omap: clk: Nuke plat clock.c & clock.h if CONFIG_COMMON_CLK
Date: Tue, 5 Jun 2012 08:11:39 -0500 [thread overview]
Message-ID: <4FCE058B.3060407@ti.com> (raw)
In-Reply-To: <4FCD91DD.8050704@ti.com>
Hi Rajendra,
On 06/04/2012 11:58 PM, Rajendra Nayak wrote:
> Hi Jon,
>
>> On 06/04/2012 09:16 AM, Rajendra Nayak wrote:
>>>
>>>>> +/* struct clksel_rate.flags possibilities */
>>>>> +#define RATE_IN_242X (1<< 0)
>>>>> +#define RATE_IN_243X (1<< 1)
>>>>> +#define RATE_IN_3430ES1 (1<< 2) /* 3430ES1 rates only */
>>>>> +#define RATE_IN_3430ES2PLUS (1<< 3) /* 3430 ES>= 2 rates
>>>>> only */
>>>>> +#define RATE_IN_36XX (1<< 4)
>>>>> +#define RATE_IN_4430 (1<< 5)
>>>>> +#define RATE_IN_TI816X (1<< 6)
>>>>> +#define RATE_IN_4460 (1<< 7)
>>>>> +#define RATE_IN_AM33XX (1<< 8)
>>>>> +#define RATE_IN_TI814X (1<< 9)
>>>>> +
>>>>> +#define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X)
>>>>> +#define RATE_IN_34XX (RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS)
>>>>> +#define RATE_IN_3XXX (RATE_IN_34XX | RATE_IN_36XX)
>>>>> +#define RATE_IN_44XX (RATE_IN_4430 | RATE_IN_4460)
>>>>> +
>>>>> +/* RATE_IN_3430ES2PLUS_36XX includes 34xx/35xx with ES>=2, and all
>>>>> 36xx/37xx */
>>>>> +#define RATE_IN_3430ES2PLUS_36XX (RATE_IN_3430ES2PLUS |
>>>>> RATE_IN_36XX)
>>>>> +
>>>>> +/* Platform flags for the clkdev-OMAP integration code */
>>>>> +#define CK_242X (1<< 4)
>>>>> +#define CK_243X (1<< 5) /* 243x, 253x */
>>>>> +#define CK_3430ES1 (1<< 6) /* 34xxES1 only */
>>>>> +#define CK_3430ES2PLUS (1<< 7) /* 34xxES2, ES3,
>>>>> non-Sitara 35xx only */
>>>>> +#define CK_3505 (1<< 8)
>>>>> +#define CK_3517 (1<< 9)
>>>>> +#define CK_36XX (1<< 10) /* 36xx/37xx-specific
>>>>> clocks */
>>>>> +#define CK_443X (1<< 11)
>>>>> +#define CK_TI816X (1<< 12)
>>>>> +#define CK_446X (1<< 13)
>>>>> +
>>>>> +#define CK_34XX (CK_3430ES1 | CK_3430ES2PLUS)
>>>>> +#define CK_AM35XX (CK_3505 | CK_3517) /* all Sitara AM35xx */
>>>>> +#define CK_3XXX (CK_34XX | CK_AM35XX | CK_36XX)
>>>>
>>>> I am not sure why we should duplicate these defines in an OMAP2
>>>> specific
>>>> header. What not just leave in plat clock.h where we have all the
>>>> RATE_IN_xxx and CK_xxx for all OMAP devices?
>>>
>>> These get removed from the file which is used for OMAP1 in a later
>>> patch. Like I said the idea was to separate out whats needed for OMAP1
>>> (using legacy struct clk) and OMAP2+ (using common struct clk) with
>>> both headers residing in respective mach-omap folders. (The RFC I posted
>>> still had the OMAP1 file in plat-omap)
>>
>> But these definitions are unrelated to whether you use common clock or
>> legacy. So why move them?
>
> I am really fine either way, I don;t see a big issue in keeping these
> in plat clock.h and some others with ifdefs around for COMMON_CLK.
> The bigger issue is moving OMAP1 to common clk and I don't plan to do
> it as part of this series.
Ok, thanks. I guess ultimately it is Paul's decision but you know my
preference ;-)
As for omap1, I was not expecting you/we convert this at this point.
That is not my goal either. However, just to make sure that if and when
we do it will not be such a massive churn.
>>
>>>>
>>>>> +/**
>>>>> + * struct clksel_rate - register bitfield values corresponding to
>>>>> clk divisors
>>>>> + * @val: register bitfield value (shifted to bit 0)
>>>>> + * @div: clock divisor corresponding to @val
>>>>> + * @flags: (see "struct clksel_rate.flags possibilities" above)
>>>>> + *
>>>>> + * @val should match the value of a read from struct clk.clksel_reg
>>>>> + * AND'ed with struct clk.clksel_mask, shifted right to bit 0.
>>>>> + *
>>>>> + * @div is the divisor that should be applied to the parent clock's
>>>>> rate
>>>>> + * to produce the current clock's rate.
>>>>> + */
>>>>> +struct clksel_rate {
>>>>> + u32 val;
>>>>> + u8 div;
>>>>> + u8 flags;
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct clksel - available parent clocks, and a pointer to their
>>>>> divisors
>>>>> + * @parent: struct clk * to a possible parent clock
>>>>> + * @rates: available divisors for this parent clock
>>>>> + *
>>>>> + * A struct clksel is always associated with one or more struct clks
>>>>> + * and one or more struct clksel_rates.
>>>>> + */
>>>>> +struct clksel {
>>>>> + struct clk *parent;
>>>>> + const struct clksel_rate *rates;
>>>>> +};
>>>>
>>>> These above clksel structures would be need for omap1 devices so
>>>> that we
>>>> could use the clock framework to set the parent clock. So why not keep
>>>> in plat clock.h?
>>>
>>> We could, but that alone wouldn't be enough if we move OMAP2+ alone to
>>> common clk, it would mean we duplicate the clksel handling code too,
>>> and if we do that, maybe its not that bad to just duplicate a couple
>>> more struct definitions.
>>
>> So I have tested the legacy clksel code on omap1 and it works. So I
>> would hope that the common clock version of clksel would work too for
>> omap1 (if we move omap1 to the common clock framework).
>
> Yes, *if we move omap1 to common clock* :-)
Agree :-)
Thanks
Jon
next prev parent reply other threads:[~2012-06-05 13:11 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-01 12:07 [RFC 00/24] Move OMAP2+ over to use COMMON clock Rajendra Nayak
2012-06-01 12:07 ` [RFC 01/24] clk: Add CLK_IS_BASIC flag to identify basic clocks Rajendra Nayak
2012-06-01 12:07 ` [RFC 02/24] ARM: omap4: cm: add bitfield width values Rajendra Nayak
2012-06-01 12:07 ` [RFC 03/24] ARM: omap: clk: convert all clk_enable to clk_prepare_enable Rajendra Nayak
2012-06-01 12:07 ` [RFC 04/24] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage Rajendra Nayak
2012-06-01 12:07 ` [RFC 05/24] ARM: omap: clk: Nuke plat clock.c & clock.h if CONFIG_COMMON_CLK Rajendra Nayak
2012-06-04 13:57 ` Jon Hunter
2012-06-04 14:16 ` Rajendra Nayak
2012-06-04 14:25 ` Jon Hunter
2012-06-05 4:58 ` Rajendra Nayak
2012-06-05 13:11 ` Jon Hunter [this message]
2012-06-01 12:07 ` [RFC 06/24] ARM: omap: clk: Remove all direct dereferncing of struct clk Rajendra Nayak
2012-06-01 12:07 ` [RFC 07/24] ARM: omap: hwmod: Fix up hwmod based clkdm accesses Rajendra Nayak
2012-06-01 12:07 ` [RFC 08/24] ARM: omap4: clk: Convert to common clk Rajendra Nayak
2012-06-01 12:07 ` [RFC 09/24] ARM: omap3: " Rajendra Nayak
2012-06-01 12:07 ` [RFC 10/24] ARM: omap2: " Rajendra Nayak
2012-06-01 12:07 ` [RFC 11/24] ARM: omap: clk: list all clk_hw_omap clks to enable/disable autoidle Rajendra Nayak
2012-06-04 5:44 ` Tony Lindgren
2012-06-04 8:53 ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 12/24] ARM: omap: clk: Define a function to enable clocks at init Rajendra Nayak
2012-06-01 12:07 ` [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk Rajendra Nayak
2012-06-04 22:14 ` Jon Hunter
2012-06-05 4:35 ` Rajendra Nayak
2012-06-05 6:42 ` Tony Lindgren
2012-06-05 6:44 ` Tony Lindgren
2012-06-07 5:29 ` Rajendra Nayak
2012-06-20 11:39 ` Tony Lindgren
2012-06-21 6:28 ` Rajendra Nayak
2012-06-21 7:00 ` Tony Lindgren
2012-06-01 12:07 ` [RFC 14/24] ARM: omap3: clk: Add 3xxx " Rajendra Nayak
2012-06-01 12:07 ` [RFC 15/24] ARM: omap2: clk: Add 24xx " Rajendra Nayak
2012-06-01 12:07 ` [RFC 16/24] ARM: omap: clk: Switch to COMMON clk Rajendra Nayak
2012-06-01 12:07 ` [RFC 17/24] ARM: omap: clk: Use plat clock.c & clock.h only for OMAP1 Rajendra Nayak
2012-06-01 12:07 ` [RFC 18/24] ARM: omap: hwmod: Cleanup !CONFIG_COMMON_CLK parts Rajendra Nayak
2012-06-01 12:08 ` [RFC 19/24] ARM: omap4: clk: " Rajendra Nayak
2012-06-01 12:08 ` [RFC 20/24] ARM: omap3: " Rajendra Nayak
2012-06-01 12:08 ` [RFC 21/24] ARM: omap2: " Rajendra Nayak
2012-06-01 12:08 ` [RFC 22/24] ARM: omap4: clk: Delete old OMAP clock data Rajendra Nayak
2012-06-01 12:08 ` [RFC 23/24] ARM: omap3: " Rajendra Nayak
2012-06-01 12:08 ` [RFC 24/24] ARM: omap2: " Rajendra Nayak
2012-06-01 13:37 ` [RFC 00/24] Move OMAP2+ over to use COMMON clock Paul Walmsley
2012-06-04 8:38 ` Rajendra Nayak
2012-06-01 17:58 ` Mike Turquette
2012-06-01 20:37 ` Jon Hunter
2012-06-01 23:27 ` Jon Hunter
2012-06-04 8:52 ` Rajendra Nayak
2012-06-04 13:51 ` Jon Hunter
2012-06-04 14:04 ` Rajendra Nayak
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=4FCE058B.3060407@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 \
--cc=rnayak@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).