[PATCH v3 0/3] AM35x: Adding PM init

[PATCH v3 0/3] AM35x: Adding PM init

[Abhilash K V]

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

[PATCH v3 1/3] AM35x: voltage: Basic initialization

[Abhilash K V]

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

[PATCH v3 2/3] OMAP3: Add support for TPS65023 (AM35x only)

[Abhilash K V]

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

[PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs

[Abhilash K V]

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

[PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs

[Kevin Hilman]

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,

[PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs

[Tony Lindgren]

* 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

[PATCH v3 1/3] AM35x: voltage: Basic initialization

[Kevin Hilman]

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);
>  };

[PATCH v3 1/3] AM35x: voltage: Basic initialization

[Koyamangalath, Abhilash]

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);
>  };

[PATCH v3 1/3] AM35x: voltage: Basic initialization

[Kevin Hilman]

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

[PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs

[Samuel Ortiz]

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/