[RFC 0/3] Support TPS65023 with AM35xx

[RFC 0/3] Support TPS65023 with AM35xx

[Sanjeev Premi]

Intent of this series is to solicit feedback on
on adding basic support for AM3517 and TPS65023.

This is definitely not the complete support, but
wanted to get early comments while i continue to
work.

Sanjeev Premi (3):
  omap: voltage: Allow custom vp_init() implementation
  am35xx: voltage: Add basic initialization
  am35xx: pm: Hook-up with TPS65023

 arch/arm/mach-omap2/am3517_tps.c |   96 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/voltage.c    |   51 +++++++++++++++++++-
 2 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-omap2/am3517_tps.c

-- 
1.7.2.2

[RFC 1/3] omap: voltage: Allow custom vp_init() implementation

[Sanjeev Premi]

Current implementation expects AVS to be available
on the processor - by default. May not be true.

This patch allows the vp_init() to be implemented
per processor (or family) - same as vc_init().

Signed-off-by: Sanjeev Premi <premi@ti.com>
---
 arch/arm/mach-omap2/voltage.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 12be525..bbc36e7 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -312,6 +312,8 @@ static struct dentry *voltage_dir;
 
 /* Init function pointers */
 static void (*vc_init) (struct omap_vdd_info *vdd);
+static void (*vp_init) (struct omap_vdd_info *vdd);
+
 static int (*vdd_data_configure) (struct omap_vdd_info *vdd);
 
 static u32 omap3_voltage_read_reg(u16 mod, u8 offset)
@@ -416,7 +418,7 @@ static void vp_latch_vsel(struct omap_vdd_info *vdd)
 }
 
 /* Generic voltage init functions */
-static void __init vp_init(struct omap_vdd_info *vdd)
+static void __init omap_vp_init(struct omap_vdd_info *vdd)
 {
 	u32 vp_val;
 	u16 mod;
@@ -1557,11 +1559,13 @@ static int __init omap_voltage_early_init(void)
 		vdd_info = omap3_vdd_info;
 		nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
 		vc_init = omap3_vc_init;
+		vp_init = omap_vp_init;
 		vdd_data_configure = omap3_vdd_data_configure;
 	} else if (cpu_is_omap44xx()) {
 		vdd_info = omap4_vdd_info;
 		nr_scalable_vdd = OMAP4_NR_SCALABLE_VDD;
 		vc_init = omap4_vc_init;
+		vp_init = omap_vp_init;
 		vdd_data_configure = omap4_vdd_data_configure;
 	} else {
 		pr_warning("%s: voltage driver support not added\n", __func__);
-- 
1.7.2.2

Re: [RFC 1/3] omap: voltage: Allow custom vp_init() implementation

[Menon, Nishanth]

On Wed, Feb 23, 2011 at 23:28, Sanjeev Premi <premi@ti.com> wrote:
> Current implementation expects AVS to be available
> on the processor - by default. May not be true.
>
> This patch allows the vp_init() to be implemented
> per processor (or family) - same as vc_init().

I believe Voltage Processor != Smart reflex AVS. Smart reflex AVS
module talks to VP talks to VC talks over I2C_SR to PMIC.
absence of AVS does'nt imply VP,VC dont exist or the potential to hook
up a PMIC over I2C_SR. no?

>
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> ---
>  arch/arm/mach-omap2/voltage.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
> index 12be525..bbc36e7 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -312,6 +312,8 @@ static struct dentry *voltage_dir;
>
>  /* Init function pointers */
>  static void (*vc_init) (struct omap_vdd_info *vdd);
> +static void (*vp_init) (struct omap_vdd_info *vdd);
> +
>  static int (*vdd_data_configure) (struct omap_vdd_info *vdd);
>
>  static u32 omap3_voltage_read_reg(u16 mod, u8 offset)
> @@ -416,7 +418,7 @@ static void vp_latch_vsel(struct omap_vdd_info *vdd)
>  }
>
>  /* Generic voltage init functions */
> -static void __init vp_init(struct omap_vdd_info *vdd)
> +static void __init omap_vp_init(struct omap_vdd_info *vdd)
>  {
>        u32 vp_val;
>        u16 mod;
> @@ -1557,11 +1559,13 @@ static int __init omap_voltage_early_init(void)
>                vdd_info = omap3_vdd_info;
>                nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
>                vc_init = omap3_vc_init;
> +               vp_init = omap_vp_init;
>                vdd_data_configure = omap3_vdd_data_configure;
>        } else if (cpu_is_omap44xx()) {
>                vdd_info = omap4_vdd_info;
>                nr_scalable_vdd = OMAP4_NR_SCALABLE_VDD;
>                vc_init = omap4_vc_init;
> +               vp_init = omap_vp_init;
>                vdd_data_configure = omap4_vdd_data_configure;
>        } else {
>                pr_warning("%s: voltage driver support not added\n", __func__);


Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 1/3] omap: voltage: Allow custom vp_init() implementation

[Premi, Sanjeev]

> -----Original Message-----
> From: Menon, Nishanth
> Sent: Thursday, February 24, 2011 12:06 AM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC 1/3] omap: voltage: Allow custom vp_init()
> implementation
> 
> On Wed, Feb 23, 2011 at 23:28, Sanjeev Premi <premi@ti.com> wrote:
> > Current implementation expects AVS to be available
> > on the processor - by default. May not be true.
> >
> > This patch allows the vp_init() to be implemented
> > per processor (or family) - same as vc_init().
> 
> I believe Voltage Processor != Smart reflex AVS. Smart reflex AVS
> module talks to VP talks to VC talks over I2C_SR to PMIC.
> absence of AVS does'nt imply VP,VC dont exist or the potential to hook
> up a PMIC over I2C_SR. no?

[sp] But their role is limited to AVS only. If there is/was no AVS
     what would they be doing? Delta value written via SW on I2C would
     still get TWL working.

     And if you look into the omap_vdd_info you'd see what I meant.
 
> 
> >
> > Signed-off-by: Sanjeev Premi <premi@ti.com>
> > ---
> >  arch/arm/mach-omap2/voltage.c |    6 +++++-
> >  1 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
> omap2/voltage.c
> > index 12be525..bbc36e7 100644
> > --- a/arch/arm/mach-omap2/voltage.c
> > +++ b/arch/arm/mach-omap2/voltage.c
> > @@ -312,6 +312,8 @@ static struct dentry *voltage_dir;
> >
> >  /* Init function pointers */
> >  static void (*vc_init) (struct omap_vdd_info *vdd);
> > +static void (*vp_init) (struct omap_vdd_info *vdd);
> > +
> >  static int (*vdd_data_configure) (struct omap_vdd_info *vdd);
> >
> >  static u32 omap3_voltage_read_reg(u16 mod, u8 offset)
> > @@ -416,7 +418,7 @@ static void vp_latch_vsel(struct omap_vdd_info *vdd)
> >  }
> >
> >  /* Generic voltage init functions */
> > -static void __init vp_init(struct omap_vdd_info *vdd)
> > +static void __init omap_vp_init(struct omap_vdd_info *vdd)
> >  {
> >        u32 vp_val;
> >        u16 mod;
> > @@ -1557,11 +1559,13 @@ static int __init omap_voltage_early_init(void)
> >                vdd_info = omap3_vdd_info;
> >                nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
> >                vc_init = omap3_vc_init;
> > +               vp_init = omap_vp_init;
> >                vdd_data_configure = omap3_vdd_data_configure;
> >        } else if (cpu_is_omap44xx()) {
> >                vdd_info = omap4_vdd_info;
> >                nr_scalable_vdd = OMAP4_NR_SCALABLE_VDD;
> >                vc_init = omap4_vc_init;
> > +               vp_init = omap_vp_init;
> >                vdd_data_configure = omap4_vdd_data_configure;
> >        } else {
> >                pr_warning("%s: voltage driver support not added\n",
> __func__);
> 
> 
> Regards,
> Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/3] omap: voltage: Allow custom vp_init() implementation

[Nishanth Menon]

Premi, Sanjeev wrote, on 02/24/2011 02:15 AM:
>> -----Original Message-----
>> From: Menon, Nishanth
>> Sent: Thursday, February 24, 2011 12:06 AM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: [RFC 1/3] omap: voltage: Allow custom vp_init()
>> implementation
>>
>> On Wed, Feb 23, 2011 at 23:28, Sanjeev Premi<premi@ti.com>  wrote:
>>> Current implementation expects AVS to be available
>>> on the processor - by default. May not be true.
>>>
>>> This patch allows the vp_init() to be implemented
>>> per processor (or family) - same as vc_init().
>>
>> I believe Voltage Processor != Smart reflex AVS. Smart reflex AVS
>> module talks to VP talks to VC talks over I2C_SR to PMIC.
>> absence of AVS does'nt imply VP,VC dont exist or the potential to hook
>> up a PMIC over I2C_SR. no?
>
> [sp] But their role is limited to AVS only. If there is/was no AVS
>       what would they be doing? Delta value written via SW on I2C would
>       still get TWL working.
I dont think so. with SR, the prominence is higher, but normal voltage 
setting, + additional FSMs hooked to VC, VP make it's existance 
independent of AVS - mebbe this detail is just a technical nuance..
>
>       And if you look into the omap_vdd_info you'd see what I meant.

data structure wise, yeah I think we'd have to evolve a bit, Pauls' 
voltage.c cleanup series is one of the tiny steps we have to take.

do feel free to propose any improvements and we can discuss in the ML.

[..]
-- 
Regards,
Nishanth Menon

[RFC 2/3] am35xx: voltage: Add basic initialization

[Sanjeev Premi]

This patch adds basic initialization in
the voltage layer for AM35xx processors.

In absence of AVS, functions vp_init() and
vc_init() are empty.

Signed-off-by: Sanjeev Premi <premi@ti.com>
---
 arch/arm/mach-omap2/voltage.c |   45 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 44 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index bbc36e7..63dac11 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -194,6 +194,30 @@ static struct omap_vdd_info omap3_vdd_info[] = {
 
 #define OMAP3_NR_SCALABLE_VDD ARRAY_SIZE(omap3_vdd_info)
 
+/*
+ * AM3517 VDD structures
+ * TODO: The values in vp_offs are just a copy of OMAP3 for now.
+ *       Assignments need to be looked again; but appears that
+ *       they won't ever be used.
+ */
+static struct omap_vdd_info am3517_vdd_info[] = {
+        {
+                .vp_offs = {
+                        .vpconfig       = OMAP3_PRM_VP1_CONFIG_OFFSET,
+                        .vstepmin       = OMAP3_PRM_VP1_VSTEPMIN_OFFSET,
+                        .vstepmax       = OMAP3_PRM_VP1_VSTEPMAX_OFFSET,
+                        .vlimitto       = OMAP3_PRM_VP1_VLIMITTO_OFFSET,
+                        .vstatus        = OMAP3_PRM_VP1_STATUS_OFFSET,
+                        .voltage        = OMAP3_PRM_VP1_VOLTAGE_OFFSET,
+                },
+                .voltdm = {
+                        .name = "mpu",
+                },
+        },
+};
+
+#define AM3517_NR_SCALABLE_VDD 0
+
 /* OMAP4 VDD sturctures */
 static struct omap_vdd_info omap4_vdd_info[] = {
 	{
@@ -1551,11 +1575,30 @@ int __init omap_voltage_late_init(void)
 }
 
 /**
+ * AM35xx - dummy initialization of voltage controller
+ */
+static void __init am3517_vc_init(struct omap_vdd_info *vdd)
+{
+}
+/**
+ * AM35xx - dummy initialization of voltage processor
+ */
+static void __init am3517_vp_init(struct omap_vdd_info *vdd)
+{
+}
+
+/**
  * omap_voltage_early_init()- Volatage driver early init
  */
 static int __init omap_voltage_early_init(void)
 {
-	if (cpu_is_omap34xx()) {
+	if (cpu_is_omap3505() || cpu_is_omap3517()) {
+		vdd_info	= am3517_vdd_info;
+		nr_scalable_vdd	= AM3517_NR_SCALABLE_VDD;
+		vc_init		= am3517_vc_init;
+		vp_init		= am3517_vp_init;
+		vdd_data_configure = omap3_vdd_data_configure;
+	} else if (cpu_is_omap34xx()) {
 		vdd_info = omap3_vdd_info;
 		nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
 		vc_init = omap3_vc_init;
-- 
1.7.2.2

Re: [RFC 2/3] am35xx: voltage: Add basic initialization

[Menon, Nishanth]

On Wed, Feb 23, 2011 at 23:28, Sanjeev Premi <premi@ti.com> wrote:
> This patch adds basic initialization in
> the voltage layer for AM35xx processors.
>
> In absence of AVS, functions vp_init() and
> vc_init() are empty.
>
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> ---
>  arch/arm/mach-omap2/voltage.c |   45 ++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 44 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
> index bbc36e7..63dac11 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -194,6 +194,30 @@ static struct omap_vdd_info omap3_vdd_info[] = {
>
>  #define OMAP3_NR_SCALABLE_VDD ARRAY_SIZE(omap3_vdd_info)
>
> +/*
> + * AM3517 VDD structures
> + * TODO: The values in vp_offs are just a copy of OMAP3 for now.
> + *       Assignments need to be looked again; but appears that
> + *       they won't ever be used.
> + */
> +static struct omap_vdd_info am3517_vdd_info[] = {
> +        {
> +                .vp_offs = {
> +                        .vpconfig       = OMAP3_PRM_VP1_CONFIG_OFFSET,
> +                        .vstepmin       = OMAP3_PRM_VP1_VSTEPMIN_OFFSET,
> +                        .vstepmax       = OMAP3_PRM_VP1_VSTEPMAX_OFFSET,
> +                        .vlimitto       = OMAP3_PRM_VP1_VLIMITTO_OFFSET,
> +                        .vstatus        = OMAP3_PRM_VP1_STATUS_OFFSET,
> +                        .voltage        = OMAP3_PRM_VP1_VOLTAGE_OFFSET,
> +                },
> +                .voltdm = {
> +                        .name = "mpu",
> +                },
> +        },
> +};
aah! no potential of scaling for Core domain here? ok, I am starting
to get the picture of your question in
http://marc.info/?t=129847134400006&r=1&w=2 with TPS65023.


> +
> +#define AM3517_NR_SCALABLE_VDD 0
> +
>  /* OMAP4 VDD sturctures */
>  static struct omap_vdd_info omap4_vdd_info[] = {
>        {
> @@ -1551,11 +1575,30 @@ int __init omap_voltage_late_init(void)
>  }
>
>  /**
> + * AM35xx - dummy initialization of voltage controller
> + */
> +static void __init am3517_vc_init(struct omap_vdd_info *vdd)
> +{
> +}
> +/**
> + * AM35xx - dummy initialization of voltage processor
> + */
> +static void __init am3517_vp_init(struct omap_vdd_info *vdd)
> +{
> +}
> +
> +/**
>  * omap_voltage_early_init()- Volatage driver early init
>  */
>  static int __init omap_voltage_early_init(void)
>  {
> -       if (cpu_is_omap34xx()) {
> +       if (cpu_is_omap3505() || cpu_is_omap3517()) {
> +               vdd_info        = am3517_vdd_info;
> +               nr_scalable_vdd = AM3517_NR_SCALABLE_VDD;
> +               vc_init         = am3517_vc_init;
> +               vp_init         = am3517_vp_init;
> +               vdd_data_configure = omap3_vdd_data_configure;
> +       } else if (cpu_is_omap34xx()) {
>                vdd_info = omap3_vdd_info;
>                nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
>                vc_init = omap3_vc_init;
ok I think (maybe wrongly) features is a better mechanism to introduce
this here. may even be something to look at vc and vp as seperate
devices even initialized at hwmod level - currently we do not do it
and we have a messy voltage.c with all kind of offset initialization.


Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Sanjeev Premi]

Add glue logic to hook-up AM35x processors
with TPS65023.

Signed-off-by: Sanjeev Premi <premi@ti.com>
---
 arch/arm/mach-omap2/am3517_tps.c |   96 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 96 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/am3517_tps.c

diff --git a/arch/arm/mach-omap2/am3517_tps.c b/arch/arm/mach-omap2/am3517_tps.c
new file mode 100644
index 0000000..cddd7eb
--- /dev/null
+++ b/arch/arm/mach-omap2/am3517_tps.c
@@ -0,0 +1,96 @@
+/**
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Based on omap_twl.c
+ * 
+ * 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 <plat/voltage.h>
+
+#include "pm.h"
+
+/*
+ * TODO: Copy of OMAP3 definitions to get thru compilation.
+ *       May not be needed in final implementation. Need to
+ *       relook at the the need again.
+ */
+#define OMAP3_SRI2C_SLAVE_ADDR		0x12
+#define OMAP3_VDD_MPU_SR_CONTROL_REG	0x00
+#define OMAP3_VDD_CORE_SR_CONTROL_REG	0x01
+#define OMAP3_VP_CONFIG_ERROROFFSET	0x00
+#define OMAP3_VP_VSTEPMIN_VSTEPMIN	0x1
+#define OMAP3_VP_VSTEPMAX_VSTEPMAX	0x04
+#define OMAP3_VP_VLIMITTO_TIMEOUT_US	200
+
+#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
+#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c
+
+/**
+ * TBD: Update the formula below.
+ *      Needs to be derived from a table.
+ */
+static unsigned long tps65023_vsel_to_uv(const u8 vsel)
+{
+	return (((vsel * 250) + 6000)) * 100;
+}
+
+/**
+ * TBD: Update the formula below.
+ *      Needs to be derived from a table.
+ */
+static u8 tps65023_uv_to_vsel(unsigned long uv)
+{
+	return DIV_ROUND_UP(uv - 600000, 25000);
+}
+
+/**
+ * TBD: Just a copy of OMAP3 PMIC info.
+ *      Many fields below don't make much sense for AM3517,
+ *      but keeping them as is for now.
+ */
+static struct omap_volt_pmic_info am3517_volt_info = {
+	.slew_rate		= 4000,
+	.step_size		= 25000,
+	.on_volt                = 1200000,
+	.onlp_volt              = 1000000,
+	.ret_volt               = 975000,
+	.off_volt               = 600000,
+	.volt_setup_time        = 0xfff,
+	.vp_erroroffset		= OMAP3_VP_CONFIG_ERROROFFSET,
+	.vp_vstepmin		= OMAP3_VP_VSTEPMIN_VSTEPMIN,
+	.vp_vstepmax		= OMAP3_VP_VSTEPMAX_VSTEPMAX,
+	.vp_vddmin		= OMAP3430_VP2_VLIMITTO_VDDMIN,
+	.vp_vddmax		= OMAP3430_VP2_VLIMITTO_VDDMAX,
+	.vp_timeout_us		= OMAP3_VP_VLIMITTO_TIMEOUT_US,
+	.i2c_slave_addr		= OMAP3_SRI2C_SLAVE_ADDR,
+	.pmic_reg		= OMAP3_VDD_CORE_SR_CONTROL_REG,
+	.vsel_to_uv		= tps65023_vsel_to_uv,
+	.uv_to_vsel		= tps65023_uv_to_vsel,
+};
+
+int __init am3517_tps_init(void)
+{
+	struct voltagedomain *voltdm;
+
+	if (!cpu_is_omap3505() && !cpu_is_omap3517())
+		return -ENODEV;
+
+	voltdm = omap_voltage_domain_lookup("mpu");
+	omap_voltage_register_pmic(voltdm, &am3517_volt_info);
+
+	return 0;
+}
+
-- 
1.7.2.2

Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Menon, Nishanth]

On Wed, Feb 23, 2011 at 23:28, Sanjeev Premi <premi@ti.com> wrote:
> Add glue logic to hook-up AM35x processors
> with TPS65023.
>
> Signed-off-by: Sanjeev Premi <premi@ti.com>

[...]
> +/**
> + * TBD: Just a copy of OMAP3 PMIC info.
> + *      Many fields below don't make much sense for AM3517,
> + *      but keeping them as is for now.
> + */
> +static struct omap_volt_pmic_info am3517_volt_info = {
> +       .slew_rate              = 4000,
> +       .step_size              = 25000,
> +       .on_volt                = 1200000,
> +       .onlp_volt              = 1000000,
> +       .ret_volt               = 975000,
> +       .off_volt               = 600000,
> +       .volt_setup_time        = 0xfff,
> +       .vp_erroroffset         = OMAP3_VP_CONFIG_ERROROFFSET,
> +       .vp_vstepmin            = OMAP3_VP_VSTEPMIN_VSTEPMIN,
> +       .vp_vstepmax            = OMAP3_VP_VSTEPMAX_VSTEPMAX,
> +       .vp_vddmin              = OMAP3430_VP2_VLIMITTO_VDDMIN,
> +       .vp_vddmax              = OMAP3430_VP2_VLIMITTO_VDDMAX,
> +       .vp_timeout_us          = OMAP3_VP_VLIMITTO_TIMEOUT_US,
> +       .i2c_slave_addr         = OMAP3_SRI2C_SLAVE_ADDR,
> +       .pmic_reg               = OMAP3_VDD_CORE_SR_CONTROL_REG,
> +       .vsel_to_uv             = tps65023_vsel_to_uv,
> +       .uv_to_vsel             = tps65023_uv_to_vsel,
> +};
I see your point in http://marc.info/?l=linux-omap&m=129847126805656&w=2
"Check the definition of omap_volt_pmic_info and omap_volt_data.

Just to "hack" support we can fill *don't care* values for the
fields not supported and wrap processing under if (cpu_is_....())
checks; but this doesn't appear to be a good solution"
PMIC specific data:
> +       .slew_rate              = 4000,
> +       .step_size              = 25000,

SoC specific data + PMIC limits:
> +       .on_volt                = 1200000,
> +       .onlp_volt              = 1000000,
> +       .ret_volt               = 975000,
> +       .off_volt               = 600000,

I dont like the following at all!
> +       .volt_setup_time        = 0xfff,

SOC specific
> +       .vp_erroroffset         = OMAP3_VP_CONFIG_ERROROFFSET,
> +       .vp_vstepmin            = OMAP3_VP_VSTEPMIN_VSTEPMIN,
> +       .vp_vstepmax            = OMAP3_VP_VSTEPMAX_VSTEPMAX,
> +       .vp_vddmin              = OMAP3430_VP2_VLIMITTO_VDDMIN,
> +       .vp_vddmax              = OMAP3430_VP2_VLIMITTO_VDDMAX,
> +       .vp_timeout_us          = OMAP3_VP_VLIMITTO_TIMEOUT_US,

PMIC speciic
> +       .i2c_slave_addr         = OMAP3_SRI2C_SLAVE_ADDR,
> +       .pmic_reg               = OMAP3_VDD_CORE_SR_CONTROL_REG,
> +       .vsel_to_uv             = tps65023_vsel_to_uv,
> +       .uv_to_vsel             = tps65023_uv_to_vsel,

Yeah they ought to be split properly IMHO.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Premi, Sanjeev]

> -----Original Message-----
> From: Menon, Nishanth
> Sent: Thursday, February 24, 2011 12:14 AM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> 
> On Wed, Feb 23, 2011 at 23:28, Sanjeev Premi <premi@ti.com> wrote:
> > Add glue logic to hook-up AM35x processors
> > with TPS65023.
> >
> > Signed-off-by: Sanjeev Premi <premi@ti.com>
> 
> [...]
> > +/**
> > + * TBD: Just a copy of OMAP3 PMIC info.
> > + *      Many fields below don't make much sense for AM3517,
> > + *      but keeping them as is for now.
> > + */
> > +static struct omap_volt_pmic_info am3517_volt_info = {
> > +       .slew_rate              = 4000,
> > +       .step_size              = 25000,
> > +       .on_volt                = 1200000,
> > +       .onlp_volt              = 1000000,
> > +       .ret_volt               = 975000,
> > +       .off_volt               = 600000,
> > +       .volt_setup_time        = 0xfff,
> > +       .vp_erroroffset         = OMAP3_VP_CONFIG_ERROROFFSET,
> > +       .vp_vstepmin            = OMAP3_VP_VSTEPMIN_VSTEPMIN,
> > +       .vp_vstepmax            = OMAP3_VP_VSTEPMAX_VSTEPMAX,
> > +       .vp_vddmin              = OMAP3430_VP2_VLIMITTO_VDDMIN,
> > +       .vp_vddmax              = OMAP3430_VP2_VLIMITTO_VDDMAX,
> > +       .vp_timeout_us          = OMAP3_VP_VLIMITTO_TIMEOUT_US,
> > +       .i2c_slave_addr         = OMAP3_SRI2C_SLAVE_ADDR,
> > +       .pmic_reg               = OMAP3_VDD_CORE_SR_CONTROL_REG,
> > +       .vsel_to_uv             = tps65023_vsel_to_uv,
> > +       .uv_to_vsel             = tps65023_uv_to_vsel,
> > +};
> I see your point in http://marc.info/?l=linux-omap&m=129847126805656&w=2
> "Check the definition of omap_volt_pmic_info and omap_volt_data.
> 
> Just to "hack" support we can fill *don't care* values for the
> fields not supported and wrap processing under if (cpu_is_....())
> checks; but this doesn't appear to be a good solution"
> PMIC specific data:
> > +       .slew_rate              = 4000,
> > +       .step_size              = 25000,
> 
> SoC specific data + PMIC limits:
> > +       .on_volt                = 1200000,
> > +       .onlp_volt              = 1000000,
> > +       .ret_volt               = 975000,
> > +       .off_volt               = 600000,
> 
> I dont like the following at all!
> > +       .volt_setup_time        = 0xfff,
> 
> SOC specific
> > +       .vp_erroroffset         = OMAP3_VP_CONFIG_ERROROFFSET,
> > +       .vp_vstepmin            = OMAP3_VP_VSTEPMIN_VSTEPMIN,
> > +       .vp_vstepmax            = OMAP3_VP_VSTEPMAX_VSTEPMAX,
> > +       .vp_vddmin              = OMAP3430_VP2_VLIMITTO_VDDMIN,
> > +       .vp_vddmax              = OMAP3430_VP2_VLIMITTO_VDDMAX,
> > +       .vp_timeout_us          = OMAP3_VP_VLIMITTO_TIMEOUT_US,
> 
> PMIC speciic
> > +       .i2c_slave_addr         = OMAP3_SRI2C_SLAVE_ADDR,
> > +       .pmic_reg               = OMAP3_VDD_CORE_SR_CONTROL_REG,
> > +       .vsel_to_uv             = tps65023_vsel_to_uv,
> > +       .uv_to_vsel             = tps65023_uv_to_vsel,
> 
> Yeah they ought to be split properly IMHO.

[sp] Gr8. Good abstraction of PMIC functions and SoC functions
     related to VC/PC would be necessary. More importantly
     keeping the interfaces pluggable for different PMICs.

~sanjeev
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Vishwanath Sripathy]

Sanjeev,

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Sanjeev Premi
> Sent: Wednesday, February 23, 2011 11:29 PM
> To: linux-omap@vger.kernel.org
> Cc: Sanjeev Premi
> Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
>
> Add glue logic to hook-up AM35x processors
> with TPS65023.
It seems that you are not really using Voltage layer for any interaction
with TPS65023 as you are not using VP and VC. Then what is the purpose of
registering this PMIC with Voltage layer. I fail to understand the purpose
of this patch series.

Vishwa
>
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> ---
>  arch/arm/mach-omap2/am3517_tps.c |   96
> ++++++++++++++++++++++++++++++++++++++
>  1 files changed, 96 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/am3517_tps.c
>
> diff --git a/arch/arm/mach-omap2/am3517_tps.c b/arch/arm/mach-
> omap2/am3517_tps.c
> new file mode 100644
> index 0000000..cddd7eb
> --- /dev/null
> +++ b/arch/arm/mach-omap2/am3517_tps.c
> @@ -0,0 +1,96 @@
> +/**
> + * Copyright (C) 2011 Texas Instruments Incorporated -
> http://www.ti.com/
> + *
> + * Based on omap_twl.c
> + *
> + * 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 <plat/voltage.h>
> +
> +#include "pm.h"
> +
> +/*
> + * TODO: Copy of OMAP3 definitions to get thru compilation.
> + *       May not be needed in final implementation. Need to
> + *       relook at the the need again.
> + */
> +#define OMAP3_SRI2C_SLAVE_ADDR		0x12
> +#define OMAP3_VDD_MPU_SR_CONTROL_REG	0x00
> +#define OMAP3_VDD_CORE_SR_CONTROL_REG	0x01
> +#define OMAP3_VP_CONFIG_ERROROFFSET	0x00
> +#define OMAP3_VP_VSTEPMIN_VSTEPMIN	0x1
> +#define OMAP3_VP_VSTEPMAX_VSTEPMAX	0x04
> +#define OMAP3_VP_VLIMITTO_TIMEOUT_US	200
> +
> +#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
> +#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c
> +
> +/**
> + * TBD: Update the formula below.
> + *      Needs to be derived from a table.
> + */
> +static unsigned long tps65023_vsel_to_uv(const u8 vsel)
> +{
> +	return (((vsel * 250) + 6000)) * 100;
> +}
> +
> +/**
> + * TBD: Update the formula below.
> + *      Needs to be derived from a table.
> + */
> +static u8 tps65023_uv_to_vsel(unsigned long uv)
> +{
> +	return DIV_ROUND_UP(uv - 600000, 25000);
> +}
> +
> +/**
> + * TBD: Just a copy of OMAP3 PMIC info.
> + *      Many fields below don't make much sense for AM3517,
> + *      but keeping them as is for now.
> + */
> +static struct omap_volt_pmic_info am3517_volt_info = {
> +	.slew_rate		= 4000,
> +	.step_size		= 25000,
> +	.on_volt                = 1200000,
> +	.onlp_volt              = 1000000,
> +	.ret_volt               = 975000,
> +	.off_volt               = 600000,
> +	.volt_setup_time        = 0xfff,
> +	.vp_erroroffset		=
> OMAP3_VP_CONFIG_ERROROFFSET,
> +	.vp_vstepmin		= OMAP3_VP_VSTEPMIN_VSTEPMIN,
> +	.vp_vstepmax		= OMAP3_VP_VSTEPMAX_VSTEPMAX,
> +	.vp_vddmin		= OMAP3430_VP2_VLIMITTO_VDDMIN,
> +	.vp_vddmax		= OMAP3430_VP2_VLIMITTO_VDDMAX,
> +	.vp_timeout_us		=
> OMAP3_VP_VLIMITTO_TIMEOUT_US,
> +	.i2c_slave_addr		= OMAP3_SRI2C_SLAVE_ADDR,
> +	.pmic_reg		= OMAP3_VDD_CORE_SR_CONTROL_REG,
> +	.vsel_to_uv		= tps65023_vsel_to_uv,
> +	.uv_to_vsel		= tps65023_uv_to_vsel,
> +};
> +
> +int __init am3517_tps_init(void)
> +{
> +	struct voltagedomain *voltdm;
> +
> +	if (!cpu_is_omap3505() && !cpu_is_omap3517())
> +		return -ENODEV;
> +
> +	voltdm = omap_voltage_domain_lookup("mpu");
> +	omap_voltage_register_pmic(voltdm, &am3517_volt_info);
> +
> +	return 0;
> +}
> +
> --
> 1.7.2.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Premi, Sanjeev]

> -----Original Message-----
> From: Sripathy, Vishwanath
> Sent: Thursday, February 24, 2011 3:35 PM
> To: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> 
> Sanjeev,
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Sanjeev Premi
> > Sent: Wednesday, February 23, 2011 11:29 PM
> > To: linux-omap@vger.kernel.org
> > Cc: Sanjeev Premi
> > Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> >
> > Add glue logic to hook-up AM35x processors
> > with TPS65023.
> It seems that you are not really using Voltage layer for any interaction
> with TPS65023 as you are not using VP and VC. Then what is the purpose of
> registering this PMIC with Voltage layer. I fail to understand the purpose
> of this patch series.

[sp] Then, can you suggest how do I get the AM35x EVM to boot? Given the
     current limitation of all voltage related data being "extracted" from
     the voltage layer - which expects only TWLx0y0 PMICs.

> 
> Vishwa
> >
> > Signed-off-by: Sanjeev Premi <premi@ti.com>

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Vishwanath Sripathy]

> -----Original Message-----
> From: Premi, Sanjeev [mailto:premi@ti.com]
> Sent: Monday, March 07, 2011 8:51 PM
> To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
> Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
>
> > -----Original Message-----
> > From: Sripathy, Vishwanath
> > Sent: Thursday, February 24, 2011 3:35 PM
> > To: Premi, Sanjeev; linux-omap@vger.kernel.org
> > Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> >
> > Sanjeev,
> >
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > owner@vger.kernel.org] On Behalf Of Sanjeev Premi
> > > Sent: Wednesday, February 23, 2011 11:29 PM
> > > To: linux-omap@vger.kernel.org
> > > Cc: Sanjeev Premi
> > > Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> > >
> > > Add glue logic to hook-up AM35x processors
> > > with TPS65023.
> > It seems that you are not really using Voltage layer for any
interaction
> > with TPS65023 as you are not using VP and VC. Then what is the
> purpose of
> > registering this PMIC with Voltage layer. I fail to understand the
> purpose
> > of this patch series.
>
> [sp] Then, can you suggest how do I get the AM35x EVM to boot? Given
> the
>      current limitation of all voltage related data being "extracted"
from
>      the voltage layer - which expects only TWLx0y0 PMICs.
Pls use regulator framework for setting the voltage for your PMIC.

Vishwa

>
> >
> > Vishwa
> > >
> > > Signed-off-by: Sanjeev Premi <premi@ti.com>

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Premi, Sanjeev]

> -----Original Message-----
> From: Sripathy, Vishwanath
> Sent: Monday, March 07, 2011 10:01 PM
> To: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[snip]...[snip]

> > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > > owner@vger.kernel.org] On Behalf Of Sanjeev Premi
> > > > Sent: Wednesday, February 23, 2011 11:29 PM
> > > > To: linux-omap@vger.kernel.org
> > > > Cc: Sanjeev Premi
> > > > Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> > > >
> > > > Add glue logic to hook-up AM35x processors
> > > > with TPS65023.
> > > It seems that you are not really using Voltage layer for any
> interaction
> > > with TPS65023 as you are not using VP and VC. Then what is the
> > purpose of
> > > registering this PMIC with Voltage layer. I fail to understand the
> > purpose
> > > of this patch series.
> >
> > [sp] Then, can you suggest how do I get the AM35x EVM to boot? Given
> > the
> >      current limitation of all voltage related data being "extracted"
> from
> >      the voltage layer - which expects only TWLx0y0 PMICs.
> Pls use regulator framework for setting the voltage for your PMIC.

[sp] If you follow the current framework, voltage.c is ingrained with
OMAP3 initialization and same holds good for opp[_3xxx_data].c.

It would have been great if current implementation allowed pluggable
interface to a PMIC. As it stands today, it isn't.

Until implemented, workarounds have to be put in place to get platform(s)
working. Though patch series is being done for AM35x with TPS65023. The
similar workaround would be required for OMAP3 with TPS65023 (for example).

...and I expect workaround to be simple and unobtrusive.

See:
core_initcall(omap_voltage_early_init);
device_initcall(omap3_opp_init);
late_initcall(omap2_common_pm_late_init);

~sanjeev

[snip]..[snip]

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Vishwanath Sripathy]

> -----Original Message-----
> From: Premi, Sanjeev [mailto:premi@ti.com]
> Sent: Tuesday, March 08, 2011 5:56 PM
> To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
> Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
>
> > -----Original Message-----
> > From: Sripathy, Vishwanath
> > Sent: Monday, March 07, 2011 10:01 PM
> > To: Premi, Sanjeev; linux-omap@vger.kernel.org
> > Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
>
> [snip]...[snip]
>
> > > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > > > owner@vger.kernel.org] On Behalf Of Sanjeev Premi
> > > > > Sent: Wednesday, February 23, 2011 11:29 PM
> > > > > To: linux-omap@vger.kernel.org
> > > > > Cc: Sanjeev Premi
> > > > > Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> > > > >
> > > > > Add glue logic to hook-up AM35x processors
> > > > > with TPS65023.
> > > > It seems that you are not really using Voltage layer for any
> > interaction
> > > > with TPS65023 as you are not using VP and VC. Then what is the
> > > purpose of
> > > > registering this PMIC with Voltage layer. I fail to understand the
> > > purpose
> > > > of this patch series.
> > >
> > > [sp] Then, can you suggest how do I get the AM35x EVM to boot?
> Given
> > > the
> > >      current limitation of all voltage related data being
"extracted"
> > from
> > >      the voltage layer - which expects only TWLx0y0 PMICs.
> > Pls use regulator framework for setting the voltage for your PMIC.
>
> [sp] If you follow the current framework, voltage.c is ingrained with
> OMAP3 initialization and same holds good for opp[_3xxx_data].c.
>
> It would have been great if current implementation allowed pluggable
> interface to a PMIC. As it stands today, it isn't.
Pls suggest what kind of pluggable interfaces you are looking for.
I would expect basic PM IC initialization to be done as part of
corresponding PMIC code and voltage layer is not the place to do PMIC
initialization.

Vishwa
>
> Until implemented, workarounds have to be put in place to get
> platform(s)
> working. Though patch series is being done for AM35x with TPS65023.
> The
> similar workaround would be required for OMAP3 with TPS65023 (for
> example).
>
> ...and I expect workaround to be simple and unobtrusive.
>
> See:
> core_initcall(omap_voltage_early_init);
> device_initcall(omap3_opp_init);
> late_initcall(omap2_common_pm_late_init);
>
> ~sanjeev
>
> [snip]..[snip]

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Premi, Sanjeev]

> -----Original Message-----
> From: Sripathy, Vishwanath
> Sent: Tuesday, March 08, 2011 6:16 PM
> To: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> 
> > -----Original Message-----
> > From: Premi, Sanjeev [mailto:premi@ti.com]
> > Sent: Tuesday, March 08, 2011 5:56 PM
> > To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
> > Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> >
> > > -----Original Message-----
> > > From: Sripathy, Vishwanath
> > > Sent: Monday, March 07, 2011 10:01 PM
> > > To: Premi, Sanjeev; linux-omap@vger.kernel.org
> > > Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> >
> > [snip]...[snip]
> >
> > > > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > > > > owner@vger.kernel.org] On Behalf Of Sanjeev Premi
> > > > > > Sent: Wednesday, February 23, 2011 11:29 PM
> > > > > > To: linux-omap@vger.kernel.org
> > > > > > Cc: Sanjeev Premi
> > > > > > Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> > > > > >
> > > > > > Add glue logic to hook-up AM35x processors
> > > > > > with TPS65023.
> > > > > It seems that you are not really using Voltage layer for any
> > > interaction
> > > > > with TPS65023 as you are not using VP and VC. Then what is the
> > > > purpose of
> > > > > registering this PMIC with Voltage layer. I fail to understand the
> > > > purpose
> > > > > of this patch series.
> > > >
> > > > [sp] Then, can you suggest how do I get the AM35x EVM to boot?
> > Given
> > > > the
> > > >      current limitation of all voltage related data being
> "extracted"
> > > from
> > > >      the voltage layer - which expects only TWLx0y0 PMICs.
> > > Pls use regulator framework for setting the voltage for your PMIC.
> >
> > [sp] If you follow the current framework, voltage.c is ingrained with
> > OMAP3 initialization and same holds good for opp[_3xxx_data].c.
> >
> > It would have been great if current implementation allowed pluggable
> > interface to a PMIC. As it stands today, it isn't.
> Pls suggest what kind of pluggable interfaces you are looking for.
> I would expect basic PM IC initialization to be done as part of
> corresponding PMIC code and voltage layer is not the place to do PMIC
> initialization.

[sp] You seem to be missing the whole point on need of workaround.
     A walk-through in init sequence of OMAP and implicit dependencies
     with PMIC related code should help understanding it better.

     Pluggable interface is quite simple, choose TPS65023 as PMIC and
     I get NO code related to TWL4030 in my build.

     Do note that I haven't talked about voltage scaling so far. It is
     all about initial voltage settings. Hence the mention of initcalls
     earlier.

> 
> Vishwa
> >
> > Until implemented, workarounds have to be put in place to get
> > platform(s)
> > working. Though patch series is being done for AM35x with TPS65023.
> > The
> > similar workaround would be required for OMAP3 with TPS65023 (for
> > example).
> >
> > ...and I expect workaround to be simple and unobtrusive.
> >
> > See:
> > core_initcall(omap_voltage_early_init);
> > device_initcall(omap3_opp_init);
> > late_initcall(omap2_common_pm_late_init);
> >
> > ~sanjeev
> >
> > [snip]..[snip]

Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Nishanth Menon]

Premi, Sanjeev wrote, on 03/08/2011 05:56 PM:
[...]
>>>>>
>>>>> Add glue logic to hook-up AM35x processors
>>>>> with TPS65023.
>>>> It seems that you are not really using Voltage layer for any
>> interaction
>>>> with TPS65023 as you are not using VP and VC. Then what is the
>>> purpose of
>>>> registering this PMIC with Voltage layer. I fail to understand the
>>> purpose
>>>> of this patch series.
>>>
>>> [sp] Then, can you suggest how do I get the AM35x EVM to boot? Given
>>> the
>>>       current limitation of all voltage related data being "extracted"
>> from
>>>       the voltage layer - which expects only TWLx0y0 PMICs.
>> Pls use regulator framework for setting the voltage for your PMIC.
>
> [sp] If you follow the current framework, voltage.c is ingrained with
> OMAP3 initialization and same holds good for opp[_3xxx_data].c.
>
> It would have been great if current implementation allowed pluggable
> interface to a PMIC. As it stands today, it isn't.
Partly true - there are PMIC abstractions that have been attempted in 
current voltage layer - but only TWL is used - so yep, implementation 
probably needs evolution and yes again that TPS here is a perfect choice 
to make the implementation generic and scalable.

>
> Until implemented, workarounds have to be put in place to get platform(s)
> working. Though patch series is being done for AM35x with TPS65023. The
> similar workaround would be required for OMAP3 with TPS65023 (for example).
>
> ...and I expect workaround to be simple and unobtrusive.
>
> See:
> core_initcall(omap_voltage_early_init);
> device_initcall(omap3_opp_init);
> late_initcall(omap2_common_pm_late_init);

Thinking from a generic soln perspective, lets try and split this into 
multiple issues:
a) OPP and Voltage layer voltages - these need to be PMIC aware as well. 
See my comment on http://marc.info/?l=linux-omap&m=129955003611548&w=2 
-> essentially means that pmic_voltage information should be registered 
earlier to opp init

b) split up structure information for voltage layer - this should be 
done in a manner to make PMIC, Board and OMAP SoC information independent.

c) Ability to plug in multiple PMICs in two manners:
    i) use PMIC with VC/VP/SR combinations.
    ii) use PMIC which is plugged on regulator frameworks.

If anyone is attempting cleanups, it might be a good idea to base on the 
accepted cleanups from pm-core branch which is planned for 39-rc1 to 
prevent any surprises ;)

-- 
Regards,
Nishanth Menon

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Premi, Sanjeev]

> -----Original Message-----
> From: Menon, Nishanth
> Sent: Tuesday, March 08, 2011 6:16 PM
> To: Premi, Sanjeev
> Cc: Sripathy, Vishwanath; linux-omap@vger.kernel.org
> Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> 
> Premi, Sanjeev wrote, on 03/08/2011 05:56 PM:
> [...]
> >>>>>
> >>>>> Add glue logic to hook-up AM35x processors
> >>>>> with TPS65023.
> >>>> It seems that you are not really using Voltage layer for any
> >> interaction
> >>>> with TPS65023 as you are not using VP and VC. Then what is the
> >>> purpose of
> >>>> registering this PMIC with Voltage layer. I fail to understand the
> >>> purpose
> >>>> of this patch series.
> >>>
> >>> [sp] Then, can you suggest how do I get the AM35x EVM to boot? Given
> >>> the
> >>>       current limitation of all voltage related data being "extracted"
> >> from
> >>>       the voltage layer - which expects only TWLx0y0 PMICs.
> >> Pls use regulator framework for setting the voltage for your PMIC.
> >
> > [sp] If you follow the current framework, voltage.c is ingrained with
> > OMAP3 initialization and same holds good for opp[_3xxx_data].c.
> >
> > It would have been great if current implementation allowed pluggable
> > interface to a PMIC. As it stands today, it isn't.
> Partly true - there are PMIC abstractions that have been attempted in
> current voltage layer - but only TWL is used - so yep, implementation
> probably needs evolution and yes again that TPS here is a perfect choice
> to make the implementation generic and scalable.

[sp] There were alternate proposals - esp for TPS working with TWL earlier;
     but couldn't find way upstream. As TWL weighed higher - being the
     default PMIC; and not many users of TPS.

     But yes; now is the time.
> 
> >
> > Until implemented, workarounds have to be put in place to get
> platform(s)
> > working. Though patch series is being done for AM35x with TPS65023. The
> > similar workaround would be required for OMAP3 with TPS65023 (for
> example).
> >
> > ...and I expect workaround to be simple and unobtrusive.
> >
> > See:
> > core_initcall(omap_voltage_early_init);
> > device_initcall(omap3_opp_init);
> > late_initcall(omap2_common_pm_late_init);
> 
> Thinking from a generic soln perspective, lets try and split this into
> multiple issues:
> a) OPP and Voltage layer voltages - these need to be PMIC aware as well.
> See my comment on http://marc.info/?l=linux-omap&m=129955003611548&w=2
> -> essentially means that pmic_voltage information should be registered
> earlier to opp init
> 
> b) split up structure information for voltage layer - this should be
> done in a manner to make PMIC, Board and OMAP SoC information independent.
> 
> c) Ability to plug in multiple PMICs in two manners:
>     i) use PMIC with VC/VP/SR combinations.
>     ii) use PMIC which is plugged on regulator frameworks.
> 
> If anyone is attempting cleanups, it might be a good idea to base on the
> accepted cleanups from pm-core branch which is planned for 39-rc1 to
> prevent any surprises ;)

[sp] Without trying to understand much internal details on the proposed
     solution, workaround is necessary to get AM35x platforms to even boot
     on current baselines.

     Using regulator framework etc. are long poles; that can easily be
     avoided; and this RFC was meant for that.

     Knowing that there is already a clean-up effort; simple workaround
     makes even better proposition.
     
> 
> --
> Regards,
> Nishanth Menon

Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Menon, Nishanth]

On Tue, Mar 8, 2011 at 18:48, Premi, Sanjeev <premi@ti.com> wrote:
[...]
>> Thinking from a generic soln perspective, lets try and split this into
>> multiple issues:
>> a) OPP and Voltage layer voltages - these need to be PMIC aware as well.
>> See my comment on http://marc.info/?l=linux-omap&m=129955003611548&w=2
>> -> essentially means that pmic_voltage information should be registered
>> earlier to opp init
>>
>> b) split up structure information for voltage layer - this should be
>> done in a manner to make PMIC, Board and OMAP SoC information independent.
>>
>> c) Ability to plug in multiple PMICs in two manners:
>>     i) use PMIC with VC/VP/SR combinations.
>>     ii) use PMIC which is plugged on regulator frameworks.
>>
>> If anyone is attempting cleanups, it might be a good idea to base on the
>> accepted cleanups from pm-core branch which is planned for 39-rc1 to
>> prevent any surprises ;)
>
> [sp] Without trying to understand much internal details on the proposed
>     solution, workaround is necessary to get AM35x platforms to even boot
>     on current baselines.
>
>     Using regulator framework etc. are long poles; that can easily be
>     avoided; and this RFC was meant for that.
>
>     Knowing that there is already a clean-up effort; simple workaround
>     makes even better proposition.
Personally speaking, it is better we do the cleanup and integrate to
mainline. since we are in the process of cleaning up, it might be a
good idea for contributions from you and all interested folks to
ensure that the final code will support the configurations we all need
:)

meanwhile, any temp hacks might be better off in private trees is my 2 cents..
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Premi, Sanjeev]

> -----Original Message-----
> From: Menon, Nishanth
> Sent: Tuesday, March 08, 2011 6:58 PM
> To: Premi, Sanjeev
> Cc: Sripathy, Vishwanath; linux-omap@vger.kernel.org
> Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> 
> On Tue, Mar 8, 2011 at 18:48, Premi, Sanjeev <premi@ti.com> wrote:
> [...]
> >> Thinking from a generic soln perspective, lets try and split this into
> >> multiple issues:
> >> a) OPP and Voltage layer voltages - these need to be PMIC aware as
> well.
> >> See my comment on http://marc.info/?l=linux-omap&m=129955003611548&w=2
> >> -> essentially means that pmic_voltage information should be registered
> >> earlier to opp init
> >>
> >> b) split up structure information for voltage layer - this should be
> >> done in a manner to make PMIC, Board and OMAP SoC information
> independent.
> >>
> >> c) Ability to plug in multiple PMICs in two manners:
> >>     i) use PMIC with VC/VP/SR combinations.
> >>     ii) use PMIC which is plugged on regulator frameworks.
> >>
> >> If anyone is attempting cleanups, it might be a good idea to base on
> the
> >> accepted cleanups from pm-core branch which is planned for 39-rc1 to
> >> prevent any surprises ;)
> >
> > [sp] Without trying to understand much internal details on the proposed
> >     solution, workaround is necessary to get AM35x platforms to even
> boot
> >     on current baselines.
> >
> >     Using regulator framework etc. are long poles; that can easily be
> >     avoided; and this RFC was meant for that.
> >
> >     Knowing that there is already a clean-up effort; simple workaround
> >     makes even better proposition.
> Personally speaking, it is better we do the cleanup and integrate to
> mainline. since we are in the process of cleaning up, it might be a
> good idea for contributions from you and all interested folks to
> ensure that the final code will support the configurations we all need
> :)
> 
> meanwhile, any temp hacks might be better off in private trees is my 2
> cents..

[sp] There is a "thick" red line between hack and workaround :)
     Subtle... but both have their utility at specific instances.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023

[Kevin Hilman]

"Menon, Nishanth" <nm@ti.com> writes:

> On Tue, Mar 8, 2011 at 18:48, Premi, Sanjeev <premi@ti.com> wrote:
> [...]
>>> Thinking from a generic soln perspective, lets try and split this into
>>> multiple issues:
>>> a) OPP and Voltage layer voltages - these need to be PMIC aware as well.
>>> See my comment on http://marc.info/?l=linux-omap&m=129955003611548&w=2
>>> -> essentially means that pmic_voltage information should be registered
>>> earlier to opp init
>>>
>>> b) split up structure information for voltage layer - this should be
>>> done in a manner to make PMIC, Board and OMAP SoC information independent.
>>>
>>> c) Ability to plug in multiple PMICs in two manners:
>>>     i) use PMIC with VC/VP/SR combinations.
>>>     ii) use PMIC which is plugged on regulator frameworks.
>>>
>>> If anyone is attempting cleanups, it might be a good idea to base on the
>>> accepted cleanups from pm-core branch which is planned for 39-rc1 to
>>> prevent any surprises ;)
>>
>> [sp] Without trying to understand much internal details on the proposed
>>     solution, workaround is necessary to get AM35x platforms to even boot
>>     on current baselines.
>>
>>     Using regulator framework etc. are long poles; that can easily be
>>     avoided; and this RFC was meant for that.
>>
>>     Knowing that there is already a clean-up effort; simple workaround
>>     makes even better proposition.
> Personally speaking, it is better we do the cleanup and integrate to
> mainline. since we are in the process of cleaning up, it might be a
> good idea for contributions from you and all interested folks to
> ensure that the final code will support the configurations we all need

We have kwown for a long time that we have hard-coded PMIC assumptions
in the current code.  We have slowly added some minimal ways to make
PMIC-variable things pluggable, but indeed it has only ever been tested
with TWL* PMICs.

The best way to fix this going forward is for those who are adding
support for other PMICs to propose solutions that will make this scale
to other PMICs.

If that involves short-term hacks/workarounds to get things
building/booting on non-TWL4030 platforms, that is OK with me.  But I
would also like to be sure that efforts are underway to do it the right
way in parallel.

Kevin



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html