All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [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

  reply	other threads:[~2012-06-05 13:11 UTC|newest]

Thread overview: 96+ 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 ` 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   ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 02/24] ARM: omap4: cm: add bitfield width values Rajendra Nayak
2012-06-01 12:07   ` 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   ` 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   ` 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-01 12:07   ` Rajendra Nayak
2012-06-04 13:57   ` Jon Hunter
2012-06-04 13:57     ` Jon Hunter
2012-06-04 14:16     ` Rajendra Nayak
2012-06-04 14:16       ` Rajendra Nayak
2012-06-04 14:25       ` Jon Hunter
2012-06-04 14:25         ` Jon Hunter
2012-06-05  4:58         ` Rajendra Nayak
2012-06-05  4:58           ` Rajendra Nayak
2012-06-05 13:11           ` Jon Hunter [this message]
2012-06-05 13:11             ` Jon Hunter
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   ` 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   ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 08/24] ARM: omap4: clk: Convert to common clk Rajendra Nayak
2012-06-01 12:07   ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 09/24] ARM: omap3: " Rajendra Nayak
2012-06-01 12:07   ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 10/24] ARM: omap2: " Rajendra Nayak
2012-06-01 12:07   ` 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-01 12:07   ` Rajendra Nayak
2012-06-04  5:44   ` Tony Lindgren
2012-06-04  5:44     ` Tony Lindgren
2012-06-04  8:53     ` Rajendra Nayak
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   ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk Rajendra Nayak
2012-06-01 12:07   ` Rajendra Nayak
2012-06-04 22:14   ` Jon Hunter
2012-06-04 22:14     ` Jon Hunter
2012-06-05  4:35     ` Rajendra Nayak
2012-06-05  4:35       ` Rajendra Nayak
2012-06-05  6:42   ` Tony Lindgren
2012-06-05  6:42     ` Tony Lindgren
2012-06-05  6:44     ` Tony Lindgren
2012-06-05  6:44       ` Tony Lindgren
2012-06-07  5:29     ` Rajendra Nayak
2012-06-07  5:29       ` Rajendra Nayak
2012-06-20 11:39       ` Tony Lindgren
2012-06-20 11:39         ` Tony Lindgren
2012-06-21  6:28         ` Rajendra Nayak
2012-06-21  6:28           ` Rajendra Nayak
2012-06-21  7:00           ` Tony Lindgren
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   ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 15/24] ARM: omap2: clk: Add 24xx " Rajendra Nayak
2012-06-01 12:07   ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 16/24] ARM: omap: clk: Switch to COMMON clk Rajendra Nayak
2012-06-01 12:07   ` 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   ` Rajendra Nayak
2012-06-01 12:07 ` [RFC 18/24] ARM: omap: hwmod: Cleanup !CONFIG_COMMON_CLK parts Rajendra Nayak
2012-06-01 12:07   ` Rajendra Nayak
2012-06-01 12:08 ` [RFC 19/24] ARM: omap4: clk: " Rajendra Nayak
2012-06-01 12:08   ` Rajendra Nayak
2012-06-01 12:08 ` [RFC 20/24] ARM: omap3: " Rajendra Nayak
2012-06-01 12:08   ` Rajendra Nayak
2012-06-01 12:08 ` [RFC 21/24] ARM: omap2: " Rajendra Nayak
2012-06-01 12:08   ` 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   ` Rajendra Nayak
2012-06-01 12:08 ` [RFC 23/24] ARM: omap3: " Rajendra Nayak
2012-06-01 12:08   ` Rajendra Nayak
2012-06-01 12:08 ` [RFC 24/24] ARM: omap2: " Rajendra Nayak
2012-06-01 12:08   ` Rajendra Nayak
2012-06-01 13:37 ` [RFC 00/24] Move OMAP2+ over to use COMMON clock Paul Walmsley
2012-06-01 13:37   ` Paul Walmsley
2012-06-04  8:38   ` Rajendra Nayak
2012-06-04  8:38     ` Rajendra Nayak
2012-06-01 17:58 ` Mike Turquette
2012-06-01 17:58   ` Mike Turquette
2012-06-01 20:37 ` Jon Hunter
2012-06-01 20:37   ` Jon Hunter
2012-06-01 23:27 ` Jon Hunter
2012-06-01 23:27   ` Jon Hunter
2012-06-04  8:52   ` Rajendra Nayak
2012-06-04  8:52     ` Rajendra Nayak
2012-06-04 13:51     ` Jon Hunter
2012-06-04 13:51       ` Jon Hunter
2012-06-04 14:04       ` Rajendra Nayak
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 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.