Re: [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
On Thu, Feb 23, 2012 at 03:08, Tero Kristo t-kri...@ti.com wrote: On Wed, 2012-02-22 at 19:37 -0600, Menon, Nishanth wrote: On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote: [...] diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index 949938d..940a0d6 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h [...] @@ -171,6 +169,18 @@ struct omap_voltdm_pmic { u8 (*uv_to_vsel) (unsigned long uV); }; +struct omap_vp_param { + u32 vddmax; + u32 vddmin; +}; + Thinking a little deeper about this(SoC level vdd min and max) on a slightly different angle- core of the question that intend to answer are: - what is the least voltage we want to allow in active transtion? it should not be lower than retention voltage. I think this is a fair assumption, so we could init the vddmin to be the same as the retention voltage for the domain (or even drop the parameter.) - what is the max voltage we want to allow in active transition? it should be the max Nom voltage of all the OPPs for that domain. Isn't it higher? I guess smartreflex can scale voltages even up from the nominal level if we have a really old and/or bad silicon. Limiting this to max opp would be bad, no? Maybe we could use max opp voltage + some margin though... but what would be a safe margin here? Vnom voltage definition tends to be a variant - yep. at least OMAP3,4 have intended to have Vnom as the max voltage for the worst corner lot sample at end of life - aka worst possible voltage for that OPP. But with newer process technologies of the future SoCs, this definition might turn out to become the start voltage. OK, it is safer to have vnom max at max SoC supported voltage i guess to prevent code churn in the future and maintain compatibility with current SoCs. 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: [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
On Wed, 2012-02-22 at 19:37 -0600, Menon, Nishanth wrote: On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote: [...] diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index 949938d..940a0d6 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h [...] @@ -171,6 +169,18 @@ struct omap_voltdm_pmic { u8 (*uv_to_vsel) (unsigned long uV); }; +struct omap_vp_param { + u32 vddmax; + u32 vddmin; +}; + Thinking a little deeper about this(SoC level vdd min and max) on a slightly different angle- core of the question that intend to answer are: - what is the least voltage we want to allow in active transtion? it should not be lower than retention voltage. I think this is a fair assumption, so we could init the vddmin to be the same as the retention voltage for the domain (or even drop the parameter.) - what is the max voltage we want to allow in active transition? it should be the max Nom voltage of all the OPPs for that domain. Isn't it higher? I guess smartreflex can scale voltages even up from the nominal level if we have a really old and/or bad silicon. Limiting this to max opp would be bad, no? Maybe we could use max opp voltage + some margin though... but what would be a safe margin here? In effect, why do we even need to register voltdm-vp_param-vdd[min|max]? We already have that info - right? On the other hand it might be safer to do this way to handle quirks in future SoCs.. but thought I'd spit it out anyways.. +struct omap_vc_param { and elsewhere - please add kernel-doc struct documentation as well when new structs are introduced? Yea, I can add those for next version. + u32 on; + u32 onlp; + u32 ret; + u32 off; +}; + [...] 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: [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote: [...] diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index 949938d..940a0d6 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h [...] @@ -171,6 +169,18 @@ struct omap_voltdm_pmic { u8 (*uv_to_vsel) (unsigned long uV); }; +struct omap_vp_param { + u32 vddmax; + u32 vddmin; +}; + Thinking a little deeper about this(SoC level vdd min and max) on a slightly different angle- core of the question that intend to answer are: - what is the least voltage we want to allow in active transtion? it should not be lower than retention voltage. - what is the max voltage we want to allow in active transition? it should be the max Nom voltage of all the OPPs for that domain. In effect, why do we even need to register voltdm-vp_param-vdd[min|max]? We already have that info - right? On the other hand it might be safer to do this way to handle quirks in future SoCs.. but thought I'd spit it out anyways.. +struct omap_vc_param { and elsewhere - please add kernel-doc struct documentation as well when new structs are introduced? + u32 on; + u32 onlp; + u32 ret; + u32 off; +}; + [...] 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
[PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
Introduced two new voltage domain specific parameter structures, omap_vp_param and omap_vc_param. These are used to describe the minimum and maximum voltages for the voltagedomains, and also the sleep voltage levels. Existing voltage levels are also moved into these new structures, and the voltage domain code is changed to use these. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/omap_twl.c| 25 --- arch/arm/mach-omap2/vc.c | 241 ++--- arch/arm/mach-omap2/vc.h |8 +- arch/arm/mach-omap2/vc3xxx_data.c | 22 +++ arch/arm/mach-omap2/vc44xx_data.c | 28 +++ arch/arm/mach-omap2/voltage.h | 18 ++- arch/arm/mach-omap2/voltagedomains3xxx_data.c |5 + arch/arm/mach-omap2/voltagedomains44xx_data.c |8 + arch/arm/mach-omap2/vp.h |7 + arch/arm/mach-omap2/vp3xxx_data.c | 10 + arch/arm/mach-omap2/vp44xx_data.c | 15 ++ 11 files changed, 331 insertions(+), 56 deletions(-) diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c index 5224fbd..2f20242 100644 --- a/arch/arm/mach-omap2/omap_twl.c +++ b/arch/arm/mach-omap2/omap_twl.c @@ -141,11 +141,6 @@ static u8 twl6030_uv_to_vsel(unsigned long uv) static struct omap_voltdm_pmic omap3_mpu_pmic = { .slew_rate = 4000, .step_size = 12500, - .on_volt= 120, - .onlp_volt = 100, - .ret_volt = 975000, - .off_volt = 60, - .volt_setup_time= 0xfff, .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET, .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN, .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX, @@ -162,11 +157,6 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = { static struct omap_voltdm_pmic omap3_core_pmic = { .slew_rate = 4000, .step_size = 12500, - .on_volt= 120, - .onlp_volt = 100, - .ret_volt = 975000, - .off_volt = 60, - .volt_setup_time= 0xfff, .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET, .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN, .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX, @@ -183,11 +173,6 @@ static struct omap_voltdm_pmic omap3_core_pmic = { static struct omap_voltdm_pmic omap4_mpu_pmic = { .slew_rate = 4000, .step_size = 12660, - .on_volt= 1375000, - .onlp_volt = 1375000, - .ret_volt = 83, - .off_volt = 0, - .volt_setup_time= 0, .vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET, .vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN, .vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX, @@ -205,11 +190,6 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = { static struct omap_voltdm_pmic omap4_iva_pmic = { .slew_rate = 4000, .step_size = 12660, - .on_volt= 1188000, - .onlp_volt = 1188000, - .ret_volt = 83, - .off_volt = 0, - .volt_setup_time= 0, .vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET, .vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN, .vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX, @@ -227,11 +207,6 @@ static struct omap_voltdm_pmic omap4_iva_pmic = { static struct omap_voltdm_pmic omap4_core_pmic = { .slew_rate = 4000, .step_size = 12660, - .on_volt= 120, - .onlp_volt = 120, - .ret_volt = 83, - .off_volt = 0, - .volt_setup_time= 0, .vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET, .vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN, .vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX, diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c index 031d116..af061c3 100644 --- a/arch/arm/mach-omap2/vc.c +++ b/arch/arm/mach-omap2/vc.c @@ -10,14 +10,18 @@ #include linux/kernel.h #include linux/delay.h #include linux/init.h +#include linux/clk.h +#include linux/io.h #include plat/cpu.h +#include plat/prcm.h #include voltage.h #include vc.h #include prm-regbits-34xx.h #include prm-regbits-44xx.h #include prm44xx.h +#include scrm44xx.h /** * struct omap_vc_channel_cfg - describe the cfg_channel bitfield @@ -136,6 +140,8 @@ int omap_vc_pre_scale(struct voltagedomain *voltdm, vc_cmdval |= (*target_vsel vc-common-cmd_on_shift); voltdm-write(vc_cmdval, vc-cmdval_reg); +