Re: [PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver
On 07/31/2013 04:59 AM, Tero Kristo wrote: On 07/30/2013 09:22 PM, Nishanth Menon wrote: this patch should be 3/33 to allow dpll.c to build. On 07/23/2013 02:19 AM, Tero Kristo wrote: Some of the clock.h contents are needed by the new OMAP clock driver, including dpll_data and clk_hw_omap. Thus, move these to the generic omap header file which can be accessed by the driver. Looking at the change, I wonder what the rules are for the movement? commit message was not clear. This is kind of a merge of almost everything that is needed by clock drivers at some point. I can move the changes along to the patches that actually need the exports for clarity and to keep compilation clean. I think it is better to do in stages (while ensuring compilation is clean) - it is a bit hard to understand need and context of movement when a singular movement is done :( [..] @@ -356,28 +230,13 @@ unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw, /* DPLL Type and DCO Selection Flags */ #define DPLL_J_TYPE0x1 -long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate, -unsigned long *parent_rate); -unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate); -int omap3_noncore_dpll_enable(struct clk_hw *hw); -void omap3_noncore_dpll_disable(struct clk_hw *hw); -int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate, -unsigned long parent_rate); Why are these being moved to generic? These are used from the dpll.c by the ops. The ops should probably move as well from mach-omap2. No reason to keep it around in mach-omap2 then. [...] diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h index 647f02f..cba892a 100644 --- a/include/linux/clk/omap.h +++ b/include/linux/clk/omap.h @@ -19,6 +19,161 @@ #ifndef __LINUX_CLK_OMAP_H_ #define __LINUX_CLK_OMAP_H_ -int __init dt_omap_clk_init(void); +/** + * struct dpll_data - DPLL registers and integration data + * @mult_div1_reg: register containing the DPLL M and N bitfields + * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg + * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg + * @clk_bypass: struct clk pointer to the clock's bypass clock input + * @clk_ref: struct clk pointer to the clock's reference clock input + * @control_reg: register containing the DPLL mode bitfield + * @enable_mask: mask of the DPLL mode bitfield in @control_reg + * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate() + * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate() + * @last_rounded_m4xen: cache of the last M4X result of + * omap4_dpll_regm4xen_round_rate() + * @last_rounded_lpmode: cache of the last lpmode result of + * omap4_dpll_lpmode_recalc() + * @max_multiplier: maximum valid non-bypass multiplier value (actual) + * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate() + * @min_divider: minimum valid non-bypass divider value (actual) + * @max_divider: maximum valid non-bypass divider value (actual) + * @modes: possible values of @enable_mask + * @autoidle_reg: register containing the DPLL autoidle mode bitfield + * @idlest_reg: register containing the DPLL idle status bitfield + * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg + * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg + * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg + * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg + * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg + * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg + * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs + * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs + * @flags: DPLL type/features (see below) + * + * Possible values for @flags: + * DPLL_J_TYPE: J-type DPLL (only some 36xx, 4xxx DPLLs) but the flag is in arch/arm/mach-omap2/clock.h ? I'll look at this and probably move the flag also. + * + * @freqsel_mask is only used on the OMAP34xx family and AM35xx. + * + * XXX Some DPLLs have multiple bypass inputs, so it's not technically + * correct to only have one @clk_bypass pointer. + * + * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m, + * @last_rounded_n) should be separated from the runtime-fixed fields + * and placed into a different structure, so that the runtime-fixed data + * can be placed into read-only space. + */ +struct dpll_data { is it necessary to export this? usage is limited to dpll.c and could be made private to it alone, no? No, unfortunately dpll_data is used both by the dpll.c and the support code under mach-omap2. This is some sort of intermediate solution, so get DT clocks working first, then move the support code also under drivers/clk/omap. looks like a case for omap_dpll.h
Re: [PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver
On 08/01/2013 05:04 PM, Nishanth Menon wrote: On 07/31/2013 04:59 AM, Tero Kristo wrote: On 07/30/2013 09:22 PM, Nishanth Menon wrote: this patch should be 3/33 to allow dpll.c to build. On 07/23/2013 02:19 AM, Tero Kristo wrote: Some of the clock.h contents are needed by the new OMAP clock driver, including dpll_data and clk_hw_omap. Thus, move these to the generic omap header file which can be accessed by the driver. Looking at the change, I wonder what the rules are for the movement? commit message was not clear. This is kind of a merge of almost everything that is needed by clock drivers at some point. I can move the changes along to the patches that actually need the exports for clarity and to keep compilation clean. I think it is better to do in stages (while ensuring compilation is clean) - it is a bit hard to understand need and context of movement when a singular movement is done :( Yep, will do the change for this. [..] @@ -356,28 +230,13 @@ unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw, /* DPLL Type and DCO Selection Flags */ #define DPLL_J_TYPE0x1 -long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate, -unsigned long *parent_rate); -unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate); -int omap3_noncore_dpll_enable(struct clk_hw *hw); -void omap3_noncore_dpll_disable(struct clk_hw *hw); -int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate, -unsigned long parent_rate); Why are these being moved to generic? These are used from the dpll.c by the ops. The ops should probably move as well from mach-omap2. No reason to keep it around in mach-omap2 then. There is reason I don't want to move _everything_ from mach-omap2 in the first phase. But after initial support is in, yes, they can be moved. [...] diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h index 647f02f..cba892a 100644 --- a/include/linux/clk/omap.h +++ b/include/linux/clk/omap.h @@ -19,6 +19,161 @@ #ifndef __LINUX_CLK_OMAP_H_ #define __LINUX_CLK_OMAP_H_ -int __init dt_omap_clk_init(void); +/** + * struct dpll_data - DPLL registers and integration data + * @mult_div1_reg: register containing the DPLL M and N bitfields + * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg + * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg + * @clk_bypass: struct clk pointer to the clock's bypass clock input + * @clk_ref: struct clk pointer to the clock's reference clock input + * @control_reg: register containing the DPLL mode bitfield + * @enable_mask: mask of the DPLL mode bitfield in @control_reg + * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate() + * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate() + * @last_rounded_m4xen: cache of the last M4X result of + * omap4_dpll_regm4xen_round_rate() + * @last_rounded_lpmode: cache of the last lpmode result of + * omap4_dpll_lpmode_recalc() + * @max_multiplier: maximum valid non-bypass multiplier value (actual) + * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate() + * @min_divider: minimum valid non-bypass divider value (actual) + * @max_divider: maximum valid non-bypass divider value (actual) + * @modes: possible values of @enable_mask + * @autoidle_reg: register containing the DPLL autoidle mode bitfield + * @idlest_reg: register containing the DPLL idle status bitfield + * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg + * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg + * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg + * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg + * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg + * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg + * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs + * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs + * @flags: DPLL type/features (see below) + * + * Possible values for @flags: + * DPLL_J_TYPE: J-type DPLL (only some 36xx, 4xxx DPLLs) but the flag is in arch/arm/mach-omap2/clock.h ? I'll look at this and probably move the flag also. + * + * @freqsel_mask is only used on the OMAP34xx family and AM35xx. + * + * XXX Some DPLLs have multiple bypass inputs, so it's not technically + * correct to only have one @clk_bypass pointer. + * + * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m, + * @last_rounded_n) should be separated from the runtime-fixed fields + * and placed into a different structure, so that the runtime-fixed data + * can be placed into read-only space. + */ +struct dpll_data { is it necessary to export this? usage is limited to dpll.c and could be made private to it alone, no? No, unfortunately dpll_data is
Re: [PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver
On 08/01/2013 10:12 AM, Tero Kristo wrote: On 08/01/2013 05:04 PM, Nishanth Menon wrote: On 07/31/2013 04:59 AM, Tero Kristo wrote: On 07/30/2013 09:22 PM, Nishanth Menon wrote: this patch should be 3/33 to allow dpll.c to build. On 07/23/2013 02:19 AM, Tero Kristo wrote: Some of the clock.h contents are needed by the new OMAP clock driver, including dpll_data and clk_hw_omap. Thus, move these to the generic omap header file which can be accessed by the driver. Looking at the change, I wonder what the rules are for the movement? commit message was not clear. This is kind of a merge of almost everything that is needed by clock drivers at some point. I can move the changes along to the patches that actually need the exports for clarity and to keep compilation clean. I think it is better to do in stages (while ensuring compilation is clean) - it is a bit hard to understand need and context of movement when a singular movement is done :( Yep, will do the change for this. [..] @@ -356,28 +230,13 @@ unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw, /* DPLL Type and DCO Selection Flags */ #define DPLL_J_TYPE0x1 -long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate, -unsigned long *parent_rate); -unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate); -int omap3_noncore_dpll_enable(struct clk_hw *hw); -void omap3_noncore_dpll_disable(struct clk_hw *hw); -int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate, -unsigned long parent_rate); Why are these being moved to generic? These are used from the dpll.c by the ops. The ops should probably move as well from mach-omap2. No reason to keep it around in mach-omap2 then. There is reason I don't want to move _everything_ from mach-omap2 in the first phase. But after initial support is in, yes, they can be moved. I will re-iterate my suggestion again - DPLL enable/disable stuff is going to be a series of steps, which would not change if we do DT or non-DT. currently those steps reside inside mach-omap2. having a driver call into mach-omap2 is counter-intutive, at least to me. if we want to have a cleanup in the future, mach-omap2 should depend on drivers/clk rather than the other way around. This is the reason of requesting files in drivers/clk to be as isolated as possible - dpll operations (the actual steps) of doing dpll configuration does sound isolated enough to move into drivers/clk and not have reverse dependencies. Any reverse dependencies should be clearly mentioned with reasoning why it cannot be moved in the respective patches, it was a little hard for me to indicate precisely which functions make absolutely no sense and which not. I am not saying this is an easy step to do, but for our future cleanups, it does sound reasonable to expect from this series. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver
On 07/30/2013 09:22 PM, Nishanth Menon wrote: this patch should be 3/33 to allow dpll.c to build. On 07/23/2013 02:19 AM, Tero Kristo wrote: Some of the clock.h contents are needed by the new OMAP clock driver, including dpll_data and clk_hw_omap. Thus, move these to the generic omap header file which can be accessed by the driver. Looking at the change, I wonder what the rules are for the movement? commit message was not clear. This is kind of a merge of almost everything that is needed by clock drivers at some point. I can move the changes along to the patches that actually need the exports for clarity and to keep compilation clean. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/clock.h | 151 + include/linux/clk/omap.h| 157 ++- 2 files changed, 157 insertions(+), 151 deletions(-) diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h index 7aa32cd..d1a3125 100644 --- a/arch/arm/mach-omap2/clock.h +++ b/arch/arm/mach-omap2/clock.h @@ -21,6 +21,7 @@ #include linux/clkdev.h #include linux/clk-provider.h +#include linux/clk/omap.h struct omap_clk { u16cpu; @@ -178,83 +179,6 @@ struct clksel { const struct clksel_rate *rates; }; -/** - * struct dpll_data - DPLL registers and integration data - * @mult_div1_reg: register containing the DPLL M and N bitfields - * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg - * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg - * @clk_bypass: struct clk pointer to the clock's bypass clock input - * @clk_ref: struct clk pointer to the clock's reference clock input - * @control_reg: register containing the DPLL mode bitfield - * @enable_mask: mask of the DPLL mode bitfield in @control_reg - * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate() - * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate() - * @last_rounded_m4xen: cache of the last M4X result of - *omap4_dpll_regm4xen_round_rate() - * @last_rounded_lpmode: cache of the last lpmode result of - * omap4_dpll_lpmode_recalc() - * @max_multiplier: maximum valid non-bypass multiplier value (actual) - * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate() - * @min_divider: minimum valid non-bypass divider value (actual) - * @max_divider: maximum valid non-bypass divider value (actual) - * @modes: possible values of @enable_mask - * @autoidle_reg: register containing the DPLL autoidle mode bitfield - * @idlest_reg: register containing the DPLL idle status bitfield - * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg - * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg - * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg - * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg - * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg - * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg - * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs - * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs - * @flags: DPLL type/features (see below) - * - * Possible values for @flags: - * DPLL_J_TYPE: J-type DPLL (only some 36xx, 4xxx DPLLs) - * - * @freqsel_mask is only used on the OMAP34xx family and AM35xx. - * - * XXX Some DPLLs have multiple bypass inputs, so it's not technically - * correct to only have one @clk_bypass pointer. - * - * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m, - * @last_rounded_n) should be separated from the runtime-fixed fields - * and placed into a different structure, so that the runtime-fixed data - * can be placed into read-only space. - */ -struct dpll_data { -void __iomem*mult_div1_reg; -u32mult_mask; -u32div1_mask; -struct clk*clk_bypass; -struct clk*clk_ref; -void __iomem*control_reg; -u32enable_mask; -unsigned longlast_rounded_rate; -u16last_rounded_m; -u8last_rounded_m4xen; -u8last_rounded_lpmode; -u16max_multiplier; -u8last_rounded_n; -u8min_divider; -u16max_divider; -u8modes; -void __iomem*autoidle_reg; -void __iomem*idlest_reg; -u32autoidle_mask; -u32freqsel_mask; -u32idlest_mask; -u32dco_mask; -u32sddiv_mask; -u32lpmode_mask; -u32m4xen_mask; -u8auto_recal_bit; -u8recal_en_bit; -u8recal_st_bit; -u8flags; -}; - /* * struct clk.flags possibilities * @@ -274,56 +198,6 @@ struct dpll_data {
Re: [PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver
this patch should be 3/33 to allow dpll.c to build. On 07/23/2013 02:19 AM, Tero Kristo wrote: Some of the clock.h contents are needed by the new OMAP clock driver, including dpll_data and clk_hw_omap. Thus, move these to the generic omap header file which can be accessed by the driver. Looking at the change, I wonder what the rules are for the movement? commit message was not clear. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/clock.h | 151 + include/linux/clk/omap.h| 157 ++- 2 files changed, 157 insertions(+), 151 deletions(-) diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h index 7aa32cd..d1a3125 100644 --- a/arch/arm/mach-omap2/clock.h +++ b/arch/arm/mach-omap2/clock.h @@ -21,6 +21,7 @@ #include linux/clkdev.h #include linux/clk-provider.h +#include linux/clk/omap.h struct omap_clk { u16 cpu; @@ -178,83 +179,6 @@ struct clksel { const struct clksel_rate *rates; }; -/** - * struct dpll_data - DPLL registers and integration data - * @mult_div1_reg: register containing the DPLL M and N bitfields - * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg - * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg - * @clk_bypass: struct clk pointer to the clock's bypass clock input - * @clk_ref: struct clk pointer to the clock's reference clock input - * @control_reg: register containing the DPLL mode bitfield - * @enable_mask: mask of the DPLL mode bitfield in @control_reg - * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate() - * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate() - * @last_rounded_m4xen: cache of the last M4X result of - * omap4_dpll_regm4xen_round_rate() - * @last_rounded_lpmode: cache of the last lpmode result of - * omap4_dpll_lpmode_recalc() - * @max_multiplier: maximum valid non-bypass multiplier value (actual) - * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate() - * @min_divider: minimum valid non-bypass divider value (actual) - * @max_divider: maximum valid non-bypass divider value (actual) - * @modes: possible values of @enable_mask - * @autoidle_reg: register containing the DPLL autoidle mode bitfield - * @idlest_reg: register containing the DPLL idle status bitfield - * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg - * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg - * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg - * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg - * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg - * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg - * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs - * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs - * @flags: DPLL type/features (see below) - * - * Possible values for @flags: - * DPLL_J_TYPE: J-type DPLL (only some 36xx, 4xxx DPLLs) - * - * @freqsel_mask is only used on the OMAP34xx family and AM35xx. - * - * XXX Some DPLLs have multiple bypass inputs, so it's not technically - * correct to only have one @clk_bypass pointer. - * - * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m, - * @last_rounded_n) should be separated from the runtime-fixed fields - * and placed into a different structure, so that the runtime-fixed data - * can be placed into read-only space. - */ -struct dpll_data { - void __iomem*mult_div1_reg; - u32 mult_mask; - u32 div1_mask; - struct clk *clk_bypass; - struct clk *clk_ref; - void __iomem*control_reg; - u32 enable_mask; - unsigned long last_rounded_rate; - u16 last_rounded_m; - u8 last_rounded_m4xen; - u8 last_rounded_lpmode; - u16 max_multiplier; - u8 last_rounded_n; - u8 min_divider; - u16 max_divider; - u8 modes; - void __iomem*autoidle_reg; - void __iomem*idlest_reg; - u32 autoidle_mask; - u32 freqsel_mask; - u32 idlest_mask; - u32 dco_mask; - u32 sddiv_mask; - u32 lpmode_mask; - u32 m4xen_mask; - u8 auto_recal_bit; - u8 recal_en_bit; - u8 recal_st_bit; - u8 flags;
[PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver
Some of the clock.h contents are needed by the new OMAP clock driver, including dpll_data and clk_hw_omap. Thus, move these to the generic omap header file which can be accessed by the driver. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/clock.h | 151 + include/linux/clk/omap.h| 157 ++- 2 files changed, 157 insertions(+), 151 deletions(-) diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h index 7aa32cd..d1a3125 100644 --- a/arch/arm/mach-omap2/clock.h +++ b/arch/arm/mach-omap2/clock.h @@ -21,6 +21,7 @@ #include linux/clkdev.h #include linux/clk-provider.h +#include linux/clk/omap.h struct omap_clk { u16 cpu; @@ -178,83 +179,6 @@ struct clksel { const struct clksel_rate *rates; }; -/** - * struct dpll_data - DPLL registers and integration data - * @mult_div1_reg: register containing the DPLL M and N bitfields - * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg - * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg - * @clk_bypass: struct clk pointer to the clock's bypass clock input - * @clk_ref: struct clk pointer to the clock's reference clock input - * @control_reg: register containing the DPLL mode bitfield - * @enable_mask: mask of the DPLL mode bitfield in @control_reg - * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate() - * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate() - * @last_rounded_m4xen: cache of the last M4X result of - * omap4_dpll_regm4xen_round_rate() - * @last_rounded_lpmode: cache of the last lpmode result of - * omap4_dpll_lpmode_recalc() - * @max_multiplier: maximum valid non-bypass multiplier value (actual) - * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate() - * @min_divider: minimum valid non-bypass divider value (actual) - * @max_divider: maximum valid non-bypass divider value (actual) - * @modes: possible values of @enable_mask - * @autoidle_reg: register containing the DPLL autoidle mode bitfield - * @idlest_reg: register containing the DPLL idle status bitfield - * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg - * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg - * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg - * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg - * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg - * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg - * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs - * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs - * @flags: DPLL type/features (see below) - * - * Possible values for @flags: - * DPLL_J_TYPE: J-type DPLL (only some 36xx, 4xxx DPLLs) - * - * @freqsel_mask is only used on the OMAP34xx family and AM35xx. - * - * XXX Some DPLLs have multiple bypass inputs, so it's not technically - * correct to only have one @clk_bypass pointer. - * - * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m, - * @last_rounded_n) should be separated from the runtime-fixed fields - * and placed into a different structure, so that the runtime-fixed data - * can be placed into read-only space. - */ -struct dpll_data { - void __iomem*mult_div1_reg; - u32 mult_mask; - u32 div1_mask; - struct clk *clk_bypass; - struct clk *clk_ref; - void __iomem*control_reg; - u32 enable_mask; - unsigned long last_rounded_rate; - u16 last_rounded_m; - u8 last_rounded_m4xen; - u8 last_rounded_lpmode; - u16 max_multiplier; - u8 last_rounded_n; - u8 min_divider; - u16 max_divider; - u8 modes; - void __iomem*autoidle_reg; - void __iomem*idlest_reg; - u32 autoidle_mask; - u32 freqsel_mask; - u32 idlest_mask; - u32 dco_mask; - u32 sddiv_mask; - u32 lpmode_mask; - u32 m4xen_mask; - u8 auto_recal_bit; - u8 recal_en_bit; - u8 recal_st_bit; - u8 flags; -}; - /* * struct clk.flags possibilities * @@ -274,56 +198,6 @@ struct dpll_data { #define INVERT_ENABLE (1 4)/* 0 enables, 1 disables */ #define CLOCK_CLKOUTX2 (1 5)