* [PATCH v3 0/3] AM35x: Adding PM init @ 2011-09-22 13:29 Abhilash K V 2011-09-22 13:29 ` [PATCH v3 1/3] AM35x: voltage: Basic initialization Abhilash K V 0 siblings, 1 reply; 10+ messages in thread From: Abhilash K V @ 2011-09-22 13:29 UTC (permalink / raw) To: linux-arm-kernel This patch-set fixes the power and voltage management initialization sequence for AM35x. These patches are dependent on the following patch-set [PATCH v4 0/3] AM3517: Booting up which gets the AM3517 EVM booting. The patches are tested on master of git://github.com/tmlind/linux.git Kernel version is 3.1.0-rc6 and last commit on top of which these patches were added is: 0c2838d00350afc5259730c35bbda81598e8875f: Linux-omap rebuilt: Updated to -rc7, merged in dmtimer Cc: Sanjeev Premi <premi@ti.com> --- Changes in v3: * Reworked against the cleaned-up voltage management layer. Changes in v2: * TWL4030 CORE and POWER drivers are no longer built only for ARM and OMAP * changed comments to mark AM35x voltgate-scaling code as ad hoc Abhilash K V (2): AM35x: voltage: Basic initialization OMAP3: Remove auto-selection of PMICs Sanjeev Premi (1): OMAP3: Add support for TPS65023 (AM35x only) arch/arm/configs/omap2plus_defconfig | 3 + arch/arm/mach-omap2/Kconfig | 3 - arch/arm/mach-omap2/Makefile | 3 +- arch/arm/mach-omap2/omap_opp_data.h | 1 + arch/arm/mach-omap2/opp3xxx_data.c | 9 +++ arch/arm/mach-omap2/pm.c | 1 + arch/arm/mach-omap2/pm.h | 9 +++ arch/arm/mach-omap2/pmic_tps65023.c | 84 +++++++++++++++++++++++++ arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 +++- drivers/mfd/Kconfig | 2 +- 10 files changed, 118 insertions(+), 7 deletions(-) create mode 100644 arch/arm/mach-omap2/pmic_tps65023.c ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3 1/3] AM35x: voltage: Basic initialization 2011-09-22 13:29 [PATCH v3 0/3] AM35x: Adding PM init Abhilash K V @ 2011-09-22 13:29 ` Abhilash K V 2011-09-22 13:29 ` [PATCH v3 2/3] OMAP3: Add support for TPS65023 (AM35x only) Abhilash K V 2011-09-22 22:30 ` [PATCH v3 1/3] AM35x: voltage: Basic initialization Kevin Hilman 0 siblings, 2 replies; 10+ messages in thread From: Abhilash K V @ 2011-09-22 13:29 UTC (permalink / raw) To: linux-arm-kernel This patch adds the basic initialization of voltage layer for AM35x. Since AM35x doesn't support voltage scaling, Many functions have been defined to plug into existing voltage layer. Signed-off-by: Sanjeev Premi <premi@ti.com> Signed-off-by: Abhilash K V <abhilash.kv@ti.com> --- arch/arm/mach-omap2/omap_opp_data.h | 1 + arch/arm/mach-omap2/opp3xxx_data.c | 9 +++++++++ arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 ++++++++-- 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-omap2/omap_opp_data.h index c784c12..c7cedf3 100644 --- a/arch/arm/mach-omap2/omap_opp_data.h +++ b/arch/arm/mach-omap2/omap_opp_data.h @@ -88,6 +88,7 @@ extern struct omap_volt_data omap34xx_vddmpu_volt_data[]; extern struct omap_volt_data omap34xx_vddcore_volt_data[]; extern struct omap_volt_data omap36xx_vddmpu_volt_data[]; extern struct omap_volt_data omap36xx_vddcore_volt_data[]; +extern struct omap_volt_data am35xx_vdd_volt_data[]; extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[]; extern struct omap_volt_data omap44xx_vdd_iva_volt_data[]; diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c index d95f3f9..e4a5ee6 100644 --- a/arch/arm/mach-omap2/opp3xxx_data.c +++ b/arch/arm/mach-omap2/opp3xxx_data.c @@ -85,6 +85,15 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = { VOLT_DATA_DEFINE(0, 0, 0, 0), }; +/* AM35x + * + * Fields related to SmartReflex and Voltage Processor are set to 0. + */ +struct omap_volt_data am35xx_vdd_volt_data[] = { + VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 0x0, 0x0, 0x0), + VOLT_DATA_DEFINE(0, 0, 0, 0), +}; + /* OPP data */ static struct omap_opp_def __initdata omap34xx_opp_def_list[] = { diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c b/arch/arm/mach-omap2/voltagedomains3xxx_data.c index 071101d..530082f 100644 --- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c +++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c @@ -85,7 +85,10 @@ void __init omap3xxx_voltagedomains_init(void) * XXX Will depend on the process, validation, and binning * for the currently-running IC */ - if (cpu_is_omap3630()) { + if (cpu_is_omap3505() || cpu_is_omap3517()) { + omap3_voltdm_mpu.volt_data = am35xx_vdd_volt_data; + omap3_voltdm_core.volt_data = am35xx_vdd_volt_data; + } else if (cpu_is_omap3630()) { omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data; omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data; } else { @@ -93,8 +96,11 @@ void __init omap3xxx_voltagedomains_init(void) omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data; } - for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) + for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) { + if (cpu_is_omap3505() || cpu_is_omap3517()) + voltdm->scalable = false; voltdm->sys_clk.name = sys_clk_name; + } voltdm_init(voltagedomains_omap3); }; -- 1.7.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v3 2/3] OMAP3: Add support for TPS65023 (AM35x only) 2011-09-22 13:29 ` [PATCH v3 1/3] AM35x: voltage: Basic initialization Abhilash K V @ 2011-09-22 13:29 ` Abhilash K V 2011-09-22 13:29 ` [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs Abhilash K V 2011-09-22 22:30 ` [PATCH v3 1/3] AM35x: voltage: Basic initialization Kevin Hilman 1 sibling, 1 reply; 10+ messages in thread From: Abhilash K V @ 2011-09-22 13:29 UTC (permalink / raw) To: linux-arm-kernel From: Sanjeev Premi <premi@ti.com> This patch adds support for TPS65023 used with OMAP3 devices. The PMIC is currently hooked to AM35x devices, but can easily be extended for other OMAP3 devices. Signed-off-by: Sanjeev Premi <premi@ti.com> Signed-off-by: Abhilash K V <abhilash.kv@ti.com> --- arch/arm/mach-omap2/Makefile | 3 +- arch/arm/mach-omap2/pm.c | 1 + arch/arm/mach-omap2/pm.h | 9 ++++ arch/arm/mach-omap2/pmic_tps65023.c | 84 +++++++++++++++++++++++++++++++++++ 4 files changed, 96 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/pmic_tps65023.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 46a3497..e71e4bc 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -18,7 +18,8 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o -obj-$(CONFIG_TWL4030_CORE) += omap_twl.o +obj-$(CONFIG_TWL4030_CORE) += omap_twl.o +obj-$(CONFIG_REGULATOR_TPS65023) += pmic_tps65023.o # SMP support ONLY available for OMAP4 obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index da71abc..bb64383 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -255,6 +255,7 @@ static int __init omap2_common_pm_late_init(void) if (omap3_has_sr()) omap3_twl_init(); omap4_twl_init(); + omap3_tps65023_init(); /* Init the voltage layer */ omap_voltage_late_init(); diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index 4e166ad..ce028f6 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -133,5 +133,14 @@ static inline int omap4_twl_init(void) return -EINVAL; } #endif +#ifdef CONFIG_REGULATOR_TPS65023 +extern int omap3_tps65023_init(void); +#else +static inline int omap3_tps65023_init(void) +{ + return -EINVAL; +} +#endif + #endif diff --git a/arch/arm/mach-omap2/pmic_tps65023.c b/arch/arm/mach-omap2/pmic_tps65023.c new file mode 100644 index 0000000..415d804 --- /dev/null +++ b/arch/arm/mach-omap2/pmic_tps65023.c @@ -0,0 +1,84 @@ +/** + * Implements support for TPS65023 + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/err.h> +#include <linux/io.h> +#include <linux/kernel.h> +#include <linux/i2c/twl.h> + +#include "voltage.h" + +#include "pm.h" + +#define TPS65023_VDCDC1_MIN 800000 /* 0.8V */ +#define TPS65023_VDCDC1_STEP 25000 /* 0.025V */ + + +/* + * Get voltage corresponding to specified vsel value using this formula: + * Vout = 0.8V + (25mV x Vsel) + */ +static unsigned long tps65023_vsel_to_uv(const u8 vsel) +{ + return TPS65023_VDCDC1_MIN + (TPS65023_VDCDC1_STEP * vsel); +} + +/* + * Get vsel value corresponding to specified voltage using this formula: + * Vsel = (Vout - 0.8V)/ 25mV + */ +static u8 tps65023_uv_to_vsel(unsigned long uv) +{ + return DIV_ROUND_UP(uv - TPS65023_VDCDC1_MIN, TPS65023_VDCDC1_STEP); +} + +/* + * TPS65023 is currently supported only for AM35x devices. + * Therefore, implementation below is specific to this device pair. + */ + +/** + * Voltage information related to the MPU voltage domain of the + * AM35x processors - in relation to the TPS65023. + */ +static struct omap_voltdm_pmic tps65023_am35xx_mpu_volt_info = { + .step_size = 25000, + .on_volt = 1200000, + .vsel_to_uv = tps65023_vsel_to_uv, + .uv_to_vsel = tps65023_uv_to_vsel, +}; + +int __init omap3_tps65023_init(void) +{ + struct voltagedomain *voltdm; + + if (!cpu_is_omap34xx()) + return -ENODEV; + + if (cpu_is_omap3505() || cpu_is_omap3517()) { + voltdm = voltdm_lookup("mpu"); + omap_voltage_register_pmic(voltdm, + &tps65023_am35xx_mpu_volt_info); + voltdm = voltdm_lookup("core"); + omap_voltage_register_pmic(voltdm, + &tps65023_am35xx_mpu_volt_info); + } else { + /* TODO: + * Support for other devices that support TPS65023 + */ + } + + return 0; +} -- 1.7.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs 2011-09-22 13:29 ` [PATCH v3 2/3] OMAP3: Add support for TPS65023 (AM35x only) Abhilash K V @ 2011-09-22 13:29 ` Abhilash K V 2011-09-22 22:04 ` Kevin Hilman 2011-09-26 9:58 ` Samuel Ortiz 0 siblings, 2 replies; 10+ messages in thread From: Abhilash K V @ 2011-09-22 13:29 UTC (permalink / raw) To: linux-arm-kernel The current implementation almost assumes that only TWL4030/TWL5030/TWl6030 are (or can be) used with the OMAP processors. This is, however, not true. This patch removes the automatic selection of the PMIC from Kconfig. All currently used PMICs are now added to omap2plus_defconfig; any new PMIC that gets supported in future could now be enabled here rather than by changing Kconfig for ARCH_OMAP2PLUS_TYPICAL Signed-off-by: Sanjeev Premi <premi@ti.com> Signed-off-by: Abhilash K V <abhilash.kv@ti.com> --- arch/arm/configs/omap2plus_defconfig | 3 +++ arch/arm/mach-omap2/Kconfig | 3 --- drivers/mfd/Kconfig | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..076b131 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -130,6 +130,9 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MENELAUS=y +CONFIG_TWL4030_CORE=y +CONFIG_TWL4030_POWER=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 7edf802..d40f6d2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -15,9 +15,6 @@ config ARCH_OMAP2PLUS_TYPICAL select I2C select I2C_OMAP select MFD_SUPPORT - select MENELAUS if ARCH_OMAP2 - select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 - select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 help Compile a kernel suitable for booting most boards diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..72e15c8 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -238,7 +238,7 @@ config TWL4030_MADC config TWL4030_POWER bool "Support power resources on TWL4030 family chips" - depends on TWL4030_CORE && ARM + depends on TWL4030_CORE help Say yes here if you want to use the power resources on the TWL4030 family chips. Most of these resources are regulators, -- 1.7.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs 2011-09-22 13:29 ` [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs Abhilash K V @ 2011-09-22 22:04 ` Kevin Hilman 2011-09-22 22:25 ` Tony Lindgren 2011-09-26 9:58 ` Samuel Ortiz 1 sibling, 1 reply; 10+ messages in thread From: Kevin Hilman @ 2011-09-22 22:04 UTC (permalink / raw) To: linux-arm-kernel Abhilash K V <abhilash.kv@ti.com> writes: > The current implementation almost assumes that only almost? ;) > TWL4030/TWL5030/TWl6030 are (or can be) used with the > OMAP processors. This is, however, not true. > > This patch removes the automatic selection of the PMIC > from Kconfig. > All currently used PMICs are now added to omap2plus_defconfig; I don't think adding them to omap2plus_defconfig is right either, as those will get stripped out the next time that file is (re)generated. > any new PMIC that gets supported in future could now be > enabled here rather than by changing Kconfig for > ARCH_OMAP2PLUS_TYPICAL IMO, the right fix is to have the board Kconfig entries select the PMIC being used on those boards. That is the only solution that will scale, and also work when using 'make randconfig'. Kevin > > Signed-off-by: Sanjeev Premi <premi@ti.com> > Signed-off-by: Abhilash K V <abhilash.kv@ti.com> > --- > arch/arm/configs/omap2plus_defconfig | 3 +++ > arch/arm/mach-omap2/Kconfig | 3 --- > drivers/mfd/Kconfig | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig > index d5f00d7..076b131 100644 > --- a/arch/arm/configs/omap2plus_defconfig > +++ b/arch/arm/configs/omap2plus_defconfig > @@ -130,6 +130,9 @@ CONFIG_POWER_SUPPLY=y > CONFIG_WATCHDOG=y > CONFIG_OMAP_WATCHDOG=y > CONFIG_TWL4030_WATCHDOG=y > +CONFIG_MENELAUS=y > +CONFIG_TWL4030_CORE=y > +CONFIG_TWL4030_POWER=y > CONFIG_REGULATOR_TWL4030=y > CONFIG_REGULATOR_TPS65023=y > CONFIG_REGULATOR_TPS6507X=y > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 7edf802..d40f6d2 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -15,9 +15,6 @@ config ARCH_OMAP2PLUS_TYPICAL > select I2C > select I2C_OMAP > select MFD_SUPPORT > - select MENELAUS if ARCH_OMAP2 > - select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 > - select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 > help > Compile a kernel suitable for booting most boards > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 21574bd..72e15c8 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -238,7 +238,7 @@ config TWL4030_MADC > > config TWL4030_POWER > bool "Support power resources on TWL4030 family chips" > - depends on TWL4030_CORE && ARM > + depends on TWL4030_CORE > help > Say yes here if you want to use the power resources on the > TWL4030 family chips. Most of these resources are regulators, ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs 2011-09-22 22:04 ` Kevin Hilman @ 2011-09-22 22:25 ` Tony Lindgren 0 siblings, 0 replies; 10+ messages in thread From: Tony Lindgren @ 2011-09-22 22:25 UTC (permalink / raw) To: linux-arm-kernel * Kevin Hilman <khilman@ti.com> [110922 14:30]: > Abhilash K V <abhilash.kv@ti.com> writes: > > > The current implementation almost assumes that only > > almost? ;) > > > TWL4030/TWL5030/TWl6030 are (or can be) used with the > > OMAP processors. This is, however, not true. > > > > This patch removes the automatic selection of the PMIC > > from Kconfig. > > All currently used PMICs are now added to omap2plus_defconfig; > > I don't think adding them to omap2plus_defconfig is right either, as > those will get stripped out the next time that file is (re)generated. > > > any new PMIC that gets supported in future could now be > > enabled here rather than by changing Kconfig for > > ARCH_OMAP2PLUS_TYPICAL > > IMO, the right fix is to have the board Kconfig entries select the PMIC > being used on those boards. That is the only solution that will scale, > and also work when using 'make randconfig'. Agreed. Tony ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs 2011-09-22 13:29 ` [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs Abhilash K V 2011-09-22 22:04 ` Kevin Hilman @ 2011-09-26 9:58 ` Samuel Ortiz 1 sibling, 0 replies; 10+ messages in thread From: Samuel Ortiz @ 2011-09-26 9:58 UTC (permalink / raw) To: linux-arm-kernel Hi Abhilash, On Thu, Sep 22, 2011 at 06:59:15PM +0530, Abhilash K V wrote: > The current implementation almost assumes that only > TWL4030/TWL5030/TWl6030 are (or can be) used with the > OMAP processors. This is, however, not true. > > This patch removes the automatic selection of the PMIC > from Kconfig. > All currently used PMICs are now added to omap2plus_defconfig; > any new PMIC that gets supported in future could now be > enabled here rather than by changing Kconfig for > ARCH_OMAP2PLUS_TYPICAL > > Signed-off-by: Sanjeev Premi <premi@ti.com> > Signed-off-by: Abhilash K V <abhilash.kv@ti.com> > --- > arch/arm/configs/omap2plus_defconfig | 3 +++ > arch/arm/mach-omap2/Kconfig | 3 --- > drivers/mfd/Kconfig | 2 +- Acked-by: Samuel Ortiz <sameo@linux.intel.com> for the MFD part. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3 1/3] AM35x: voltage: Basic initialization 2011-09-22 13:29 ` [PATCH v3 1/3] AM35x: voltage: Basic initialization Abhilash K V 2011-09-22 13:29 ` [PATCH v3 2/3] OMAP3: Add support for TPS65023 (AM35x only) Abhilash K V @ 2011-09-22 22:30 ` Kevin Hilman 2011-09-23 12:33 ` Koyamangalath, Abhilash 1 sibling, 1 reply; 10+ messages in thread From: Kevin Hilman @ 2011-09-22 22:30 UTC (permalink / raw) To: linux-arm-kernel Hi Abhilash, Abhilash K V <abhilash.kv@ti.com> writes: > This patch adds the basic initialization of voltage layer > for AM35x. Since AM35x doesn't support voltage scaling, I must admit to still being confused by this series. This patch says AM35x doesn't support voltage scaling, and the next patch adds PMIC support, and registers it with the voltage layer. However, with each voltdm->scalable flag set to false, none of the PMIC values will ever be used (by the current voltage layer.) Do you have more patches on top of this that extend the voltage layer to directly use the PMIC instead of using VC or VP? I'm assuming we have some more assumptions in our current voltage layer about the presence of VC/VP that are wrong and need to be fixed. Now that the big voltage layer cleanup is done, I am *very* interested in getting rid of any more assumptions we have in that code about how devices are hooked up with PMICs. Can you summarize how these devices are using (or want to use) the voltage layer? Thanks, Kevin > Many functions have been defined to plug into existing > voltage layer. > > Signed-off-by: Sanjeev Premi <premi@ti.com> > Signed-off-by: Abhilash K V <abhilash.kv@ti.com> > --- > arch/arm/mach-omap2/omap_opp_data.h | 1 + > arch/arm/mach-omap2/opp3xxx_data.c | 9 +++++++++ > arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 ++++++++-- > 3 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-omap2/omap_opp_data.h > index c784c12..c7cedf3 100644 > --- a/arch/arm/mach-omap2/omap_opp_data.h > +++ b/arch/arm/mach-omap2/omap_opp_data.h > @@ -88,6 +88,7 @@ extern struct omap_volt_data omap34xx_vddmpu_volt_data[]; > extern struct omap_volt_data omap34xx_vddcore_volt_data[]; > extern struct omap_volt_data omap36xx_vddmpu_volt_data[]; > extern struct omap_volt_data omap36xx_vddcore_volt_data[]; > +extern struct omap_volt_data am35xx_vdd_volt_data[]; > > extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[]; > extern struct omap_volt_data omap44xx_vdd_iva_volt_data[]; > diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c > index d95f3f9..e4a5ee6 100644 > --- a/arch/arm/mach-omap2/opp3xxx_data.c > +++ b/arch/arm/mach-omap2/opp3xxx_data.c > @@ -85,6 +85,15 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = { > VOLT_DATA_DEFINE(0, 0, 0, 0), > }; > > +/* AM35x > + * > + * Fields related to SmartReflex and Voltage Processor are set to 0. > + */ fix multi-line comment style (search for 'multi-line' in Documentation/CodingStyle) > +struct omap_volt_data am35xx_vdd_volt_data[] = { > + VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 0x0, 0x0, 0x0), > + VOLT_DATA_DEFINE(0, 0, 0, 0), > +}; > + > /* OPP data */ > > static struct omap_opp_def __initdata omap34xx_opp_def_list[] = { > diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c b/arch/arm/mach-omap2/voltagedomains3xxx_data.c > index 071101d..530082f 100644 > --- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c > +++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c > @@ -85,7 +85,10 @@ void __init omap3xxx_voltagedomains_init(void) > * XXX Will depend on the process, validation, and binning > * for the currently-running IC > */ > - if (cpu_is_omap3630()) { > + if (cpu_is_omap3505() || cpu_is_omap3517()) { > + omap3_voltdm_mpu.volt_data = am35xx_vdd_volt_data; > + omap3_voltdm_core.volt_data = am35xx_vdd_volt_data; > + } else if (cpu_is_omap3630()) { > omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data; > omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data; > } else { > @@ -93,8 +96,11 @@ void __init omap3xxx_voltagedomains_init(void) > omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data; > } > > - for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) > + for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) { > + if (cpu_is_omap3505() || cpu_is_omap3517()) > + voltdm->scalable = false; > voltdm->sys_clk.name = sys_clk_name; > + } > > voltdm_init(voltagedomains_omap3); > }; ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3 1/3] AM35x: voltage: Basic initialization 2011-09-22 22:30 ` [PATCH v3 1/3] AM35x: voltage: Basic initialization Kevin Hilman @ 2011-09-23 12:33 ` Koyamangalath, Abhilash 2011-09-23 18:33 ` Kevin Hilman 0 siblings, 1 reply; 10+ messages in thread From: Koyamangalath, Abhilash @ 2011-09-23 12:33 UTC (permalink / raw) To: linux-arm-kernel hi Kevin On Fri, Sep 23, 2011 at 4:00 AM, Hilman, Kevin wrote: > Hi Abhilash, > > Abhilash K V <abhilash.kv@ti.com> writes: > >> This patch adds the basic initialization of voltage layer >> for AM35x. Since AM35x doesn't support voltage scaling, > > I must admit to still being confused by this series. > > This patch says AM35x doesn't support voltage scaling, and the next > patch adds PMIC support, and registers it with the voltage layer. > > However, with each voltdm->scalable flag set to false, none of the PMIC > values will ever be used (by the current voltage layer.) Do you have > more patches on top of this that extend the voltage layer to directly > use the PMIC instead of using VC or VP? > > I'm assuming we have some more assumptions in our current voltage layer > about the presence of VC/VP that are wrong and need to be fixed. Now > that the big voltage layer cleanup is done, I am *very* interested in > getting rid of any more assumptions we have in that code about how > devices are hooked up with PMICs. > > Can you summarize how these devices are using (or want to use) the > voltage layer? [Abhilash K V] Your concerns are grave and am trying to address most, however these are the only points I can make outright: - AM35x has just one voltage domain, so I tried having only one entry in voltagedomains_omap3[ ] ( and calling it "mpu_core", maybe or "mpu" or "core" ?). Either ways, some power-domain, say mpu_pwrdm would try looking for the "mpu_iva" volt-domain and return error, this happens for most powerdomains as their constituent volt-domains are hard-coded (and so unavailable on am35xx). Changing the code (which will be massive) there going against our initial premise that am35xx is still a "type of" omap3 SoC. - TPS65023 PMIC code was originally included as a starting point to support a omap34xx (with SR disabled maybe) with power supplied by a TPS65023. Yes,I agree that since this looks more of like hypothetical scenario right now and so we can do without the addition of file pmic_tps65023.c for now as it doesn't provide any support for scaling. -Abhilash > > Thanks, > > Kevin > >> Many functions have been defined to plug into existing >> voltage layer. >> >> Signed-off-by: Sanjeev Premi <premi@ti.com> >> Signed-off-by: Abhilash K V <abhilash.kv@ti.com> >> --- >> arch/arm/mach-omap2/omap_opp_data.h | 1 + >> arch/arm/mach-omap2/opp3xxx_data.c | 9 +++++++++ >> arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 ++++++++-- >> 3 files changed, 18 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-omap2/omap_opp_data.h >> index c784c12..c7cedf3 100644 >> --- a/arch/arm/mach-omap2/omap_opp_data.h >> +++ b/arch/arm/mach-omap2/omap_opp_data.h >> @@ -88,6 +88,7 @@ extern struct omap_volt_data omap34xx_vddmpu_volt_data[]; >> extern struct omap_volt_data omap34xx_vddcore_volt_data[]; >> extern struct omap_volt_data omap36xx_vddmpu_volt_data[]; >> extern struct omap_volt_data omap36xx_vddcore_volt_data[]; >> +extern struct omap_volt_data am35xx_vdd_volt_data[]; >> >> extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[]; >> extern struct omap_volt_data omap44xx_vdd_iva_volt_data[]; >> diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c >> index d95f3f9..e4a5ee6 100644 >> --- a/arch/arm/mach-omap2/opp3xxx_data.c >> +++ b/arch/arm/mach-omap2/opp3xxx_data.c >> @@ -85,6 +85,15 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = { >> VOLT_DATA_DEFINE(0, 0, 0, 0), >> }; >> >> +/* AM35x >> + * >> + * Fields related to SmartReflex and Voltage Processor are set to 0. >> + */ > > fix multi-line comment style (search for 'multi-line' in Documentation/CodingStyle) > >> +struct omap_volt_data am35xx_vdd_volt_data[] = { >> + VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 0x0, 0x0, 0x0), >> + VOLT_DATA_DEFINE(0, 0, 0, 0), >> +}; >> + >> /* OPP data */ >> >> static struct omap_opp_def __initdata omap34xx_opp_def_list[] = { >> diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c b/arch/arm/mach-omap2/voltagedomains3xxx_data.c >> index 071101d..530082f 100644 >> --- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c >> +++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c >> @@ -85,7 +85,10 @@ void __init omap3xxx_voltagedomains_init(void) >> * XXX Will depend on the process, validation, and binning >> * for the currently-running IC >> */ >> - if (cpu_is_omap3630()) { >> + if (cpu_is_omap3505() || cpu_is_omap3517()) { >> + omap3_voltdm_mpu.volt_data = am35xx_vdd_volt_data; >> + omap3_voltdm_core.volt_data = am35xx_vdd_volt_data; >> + } else if (cpu_is_omap3630()) { >> omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data; >> omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data; >> } else { >> @@ -93,8 +96,11 @@ void __init omap3xxx_voltagedomains_init(void) >> omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data; >> } >> >> - for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) >> + for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) { >> + if (cpu_is_omap3505() || cpu_is_omap3517()) >> + voltdm->scalable = false; >> voltdm->sys_clk.name = sys_clk_name; >> + } >> >> voltdm_init(voltagedomains_omap3); >> }; > ________________________________________ From: Hilman, Kevin Sent: Friday, September 23, 2011 4:00 AM To: Koyamangalath, Abhilash Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; tony at atomide.com; linux at arm.linux.org.uk; sameo at linux.intel.com; Shilimkar, Santosh; Premi, Sanjeev; david.woodhouse at intel.com; christian.gmeiner at gmail.com Subject: Re: [PATCH v3 1/3] AM35x: voltage: Basic initialization Hi Abhilash, Abhilash K V <abhilash.kv@ti.com> writes: > This patch adds the basic initialization of voltage layer > for AM35x. Since AM35x doesn't support voltage scaling, I must admit to still being confused by this series. This patch says AM35x doesn't support voltage scaling, and the next patch adds PMIC support, and registers it with the voltage layer. However, with each voltdm->scalable flag set to false, none of the PMIC values will ever be used (by the current voltage layer.) Do you have more patches on top of this that extend the voltage layer to directly use the PMIC instead of using VC or VP? I'm assuming we have some more assumptions in our current voltage layer about the presence of VC/VP that are wrong and need to be fixed. Now that the big voltage layer cleanup is done, I am *very* interested in getting rid of any more assumptions we have in that code about how devices are hooked up with PMICs. Can you summarize how these devices are using (or want to use) the voltage layer? Thanks, Kevin > Many functions have been defined to plug into existing > voltage layer. > > Signed-off-by: Sanjeev Premi <premi@ti.com> > Signed-off-by: Abhilash K V <abhilash.kv@ti.com> > --- > arch/arm/mach-omap2/omap_opp_data.h | 1 + > arch/arm/mach-omap2/opp3xxx_data.c | 9 +++++++++ > arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 ++++++++-- > 3 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-omap2/omap_opp_data.h > index c784c12..c7cedf3 100644 > --- a/arch/arm/mach-omap2/omap_opp_data.h > +++ b/arch/arm/mach-omap2/omap_opp_data.h > @@ -88,6 +88,7 @@ extern struct omap_volt_data omap34xx_vddmpu_volt_data[]; > extern struct omap_volt_data omap34xx_vddcore_volt_data[]; > extern struct omap_volt_data omap36xx_vddmpu_volt_data[]; > extern struct omap_volt_data omap36xx_vddcore_volt_data[]; > +extern struct omap_volt_data am35xx_vdd_volt_data[]; > > extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[]; > extern struct omap_volt_data omap44xx_vdd_iva_volt_data[]; > diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c > index d95f3f9..e4a5ee6 100644 > --- a/arch/arm/mach-omap2/opp3xxx_data.c > +++ b/arch/arm/mach-omap2/opp3xxx_data.c > @@ -85,6 +85,15 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = { > VOLT_DATA_DEFINE(0, 0, 0, 0), > }; > > +/* AM35x > + * > + * Fields related to SmartReflex and Voltage Processor are set to 0. > + */ fix multi-line comment style (search for 'multi-line' in Documentation/CodingStyle) > +struct omap_volt_data am35xx_vdd_volt_data[] = { > + VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 0x0, 0x0, 0x0), > + VOLT_DATA_DEFINE(0, 0, 0, 0), > +}; > + > /* OPP data */ > > static struct omap_opp_def __initdata omap34xx_opp_def_list[] = { > diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c b/arch/arm/mach-omap2/voltagedomains3xxx_data.c > index 071101d..530082f 100644 > --- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c > +++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c > @@ -85,7 +85,10 @@ void __init omap3xxx_voltagedomains_init(void) > * XXX Will depend on the process, validation, and binning > * for the currently-running IC > */ > - if (cpu_is_omap3630()) { > + if (cpu_is_omap3505() || cpu_is_omap3517()) { > + omap3_voltdm_mpu.volt_data = am35xx_vdd_volt_data; > + omap3_voltdm_core.volt_data = am35xx_vdd_volt_data; > + } else if (cpu_is_omap3630()) { > omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data; > omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data; > } else { > @@ -93,8 +96,11 @@ void __init omap3xxx_voltagedomains_init(void) > omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data; > } > > - for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) > + for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) { > + if (cpu_is_omap3505() || cpu_is_omap3517()) > + voltdm->scalable = false; > voltdm->sys_clk.name = sys_clk_name; > + } > > voltdm_init(voltagedomains_omap3); > }; ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3 1/3] AM35x: voltage: Basic initialization 2011-09-23 12:33 ` Koyamangalath, Abhilash @ 2011-09-23 18:33 ` Kevin Hilman 0 siblings, 0 replies; 10+ messages in thread From: Kevin Hilman @ 2011-09-23 18:33 UTC (permalink / raw) To: linux-arm-kernel Hi Abhilash, "Koyamangalath, Abhilash" <abhilash.kv@ti.com> writes: > On Fri, Sep 23, 2011 at 4:00 AM, Hilman, Kevin wrote: >> Hi Abhilash, Abhilash K V <abhilash.kv@ti.com> writes: >>> This patch adds the basic initialization of voltage layer for >>> AM35x. Since AM35x doesn't support voltage scaling, >> I must admit to still being confused by this series. This patch >> says AM35x doesn't support voltage scaling, and the next patch adds >> PMIC support, and registers it with the voltage layer. However, >> with each voltdm->scalable flag set to false, none of the PMIC >> values will ever be used (by the current voltage layer.) Do you >> have more patches on top of this that extend the voltage layer to >> directly use the PMIC instead of using VC or VP? I'm assuming we >> have some more assumptions in our current voltage layer about the >> presence of VC/VP that are wrong and need to be fixed. Now that the >> big voltage layer cleanup is done, I am *very* interested in getting >> rid of any more assumptions we have in that code about how devices >> are hooked up with PMICs. Can you summarize how these devices are >> using (or want to use) the voltage layer? > [Abhilash K V] Your concerns are grave and am trying to address most, > however these are the only points I can make outright: > > - AM35x has just one voltage domain, so I tried having only one entry > in voltagedomains_omap3[ ] ( and calling it "mpu_core", maybe or "mpu" > or "core" ?). Based the TRM, it's called core. > Either ways, some power-domain, say mpu_pwrdm would try > looking for the "mpu_iva" volt-domain and return error, this happens > for most powerdomains as their constituent volt-domains are hard-coded > (and so unavailable on am35xx). Changing the code (which will be > massive) there going against our initial premise that am35xx is still > a "type of" omap3 SoC. While the AM35x is similar to the OMAP3 in many ways, in terms of power, there are some significant differences that we need to model properly. The problem with the current approach is it's trying to trick the core code into thinking an AM35x is like an OMAP34xx by creating voltage domains that don't exist in hardware. The point of these voltage/power/clock domain data files is to represent *exactly* what is in hardware. Looking closer at SPRUGR0B, I don't think you should be directly using the 34xx powerdomains as a starting point. There are a few reasons: - not all 34xx powerdomains exist on AM35x (at least cam, iva2, USB host are missing) - AM35x powerdomains are in different voltage domains - AM35x powerdomains do not support retention or off (only on and inactive according to SPRUGR0B) > - TPS65023 PMIC code was originally included as a starting point to > support a omap34xx (with SR disabled maybe) with power supplied by a > TPS65023. Yes,I agree that since this looks more of like hypothetical > scenario right now and so we can do without the addition of file > pmic_tps65023.c for now as it doesn't provide any support for scaling. I see now. Adding support for that PMIC to the kernel is fine, I just don't think it makes sense in context of this series for this device, since it does not support voltage scaling, and AFAICT, this PMIC is for DVS uses. Kevin ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-26 9:58 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-22 13:29 [PATCH v3 0/3] AM35x: Adding PM init Abhilash K V 2011-09-22 13:29 ` [PATCH v3 1/3] AM35x: voltage: Basic initialization Abhilash K V 2011-09-22 13:29 ` [PATCH v3 2/3] OMAP3: Add support for TPS65023 (AM35x only) Abhilash K V 2011-09-22 13:29 ` [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs Abhilash K V 2011-09-22 22:04 ` Kevin Hilman 2011-09-22 22:25 ` Tony Lindgren 2011-09-26 9:58 ` Samuel Ortiz 2011-09-22 22:30 ` [PATCH v3 1/3] AM35x: voltage: Basic initialization Kevin Hilman 2011-09-23 12:33 ` Koyamangalath, Abhilash 2011-09-23 18:33 ` Kevin Hilman
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).