From: Rajendra Nayak <rnayak@ti.com>
To: Jon Hunter <jon-hunter@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: Mon, 04 Jun 2012 19:46:07 +0530 [thread overview]
Message-ID: <4FCCC327.7070100@ti.com> (raw)
In-Reply-To: <4FCCBECA.6010905@ti.com>
>> +/* 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)
>
>> +/**
>> + * 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.
>> +
>> +struct clk_hw_omap_ops;
>> +
>> +struct clk_hw_omap {
>> + struct clk_hw hw;
>> + struct list_head node;
>> + unsigned long fixed_rate;
>> + u8 fixed_div;
>> + void __iomem *enable_reg;
>> + u8 enable_bit;
>> + u8 flags;
>> +#ifdef CONFIG_ARCH_OMAP2PLUS
>> + void __iomem *clksel_reg;
>> + u32 clksel_mask;
>> + const struct clksel *clksel;
>> + struct dpll_data *dpll_data;
>> + const char *clkdm_name;
>> + struct clockdomain *clkdm;
>> +#else
>> + u8 rate_offset;
>> + u8 src_offset;
>> +#endif
>> + const struct clk_hw_omap_ops *ops;
>> +};
>> +
>> +struct clk_hw_omap_ops {
>> + void (*find_idlest)(struct clk_hw_omap *oclk,
>> + void __iomem **idlest_reg,
>> + u8 *idlest_bit, u8 *idlest_val);
>> + void (*find_companion)(struct clk_hw_omap *oclk,
>> + void __iomem **other_reg,
>> + u8 *other_bit);
>> + void (*allow_idle)(struct clk_hw_omap *oclk);
>> + void (*deny_idle)(struct clk_hw_omap *oclk);
>> +};
>
> The above clk_hw_xxx would also be needed for omap1 too, right?
Yes, when OMAP1 moves to common clk *and* if we find enough
commonalities in clk_hw_xxxx accross OMAP1 and OMAP2+.
Else it would make sense to keep them in separate mach folders.
>
> Cheers
> Jon
WARNING: multiple messages have this Message-ID (diff)
From: rnayak@ti.com (Rajendra Nayak)
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: Mon, 04 Jun 2012 19:46:07 +0530 [thread overview]
Message-ID: <4FCCC327.7070100@ti.com> (raw)
In-Reply-To: <4FCCBECA.6010905@ti.com>
>> +/* 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)
>
>> +/**
>> + * 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.
>> +
>> +struct clk_hw_omap_ops;
>> +
>> +struct clk_hw_omap {
>> + struct clk_hw hw;
>> + struct list_head node;
>> + unsigned long fixed_rate;
>> + u8 fixed_div;
>> + void __iomem *enable_reg;
>> + u8 enable_bit;
>> + u8 flags;
>> +#ifdef CONFIG_ARCH_OMAP2PLUS
>> + void __iomem *clksel_reg;
>> + u32 clksel_mask;
>> + const struct clksel *clksel;
>> + struct dpll_data *dpll_data;
>> + const char *clkdm_name;
>> + struct clockdomain *clkdm;
>> +#else
>> + u8 rate_offset;
>> + u8 src_offset;
>> +#endif
>> + const struct clk_hw_omap_ops *ops;
>> +};
>> +
>> +struct clk_hw_omap_ops {
>> + void (*find_idlest)(struct clk_hw_omap *oclk,
>> + void __iomem **idlest_reg,
>> + u8 *idlest_bit, u8 *idlest_val);
>> + void (*find_companion)(struct clk_hw_omap *oclk,
>> + void __iomem **other_reg,
>> + u8 *other_bit);
>> + void (*allow_idle)(struct clk_hw_omap *oclk);
>> + void (*deny_idle)(struct clk_hw_omap *oclk);
>> +};
>
> The above clk_hw_xxx would also be needed for omap1 too, right?
Yes, when OMAP1 moves to common clk *and* if we find enough
commonalities in clk_hw_xxxx accross OMAP1 and OMAP2+.
Else it would make sense to keep them in separate mach folders.
>
> Cheers
> Jon
next prev parent reply other threads:[~2012-06-04 14:16 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 [this message]
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
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=4FCCC327.7070100@ti.com \
--to=rnayak@ti.com \
--cc=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.