omap: pm: assumptions on TWL and SmartReflex.

omap: pm: assumptions on TWL and SmartReflex.

[Premi, Sanjeev]

Hi all,

While trying to suport TPS65023 with AM3517 processor, i realize
that much of the code has implicit assumption on usage of TWLx0y0
PMIC and Smartreflex.

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.

Also, the PMIC specific code doesn't really belong to mach-omap2.
OR was there a specific reason to keep it here??

Looking for thoughts, comments, explanations, ...

Best regards,
Sanjeev

Re: omap: pm: assumptions on TWL and SmartReflex.

[Menon, Nishanth]

On Wed, Feb 23, 2011 at 19:57, Premi, Sanjeev <premi@ti.com> wrote:
> Hi all,
>
> While trying to suport TPS65023 with AM3517 processor, i realize
> that much of the code has implicit assumption on usage of TWLx0y0
> PMIC and Smartreflex.
Looking at the data sheet, single SCLK, SDAT makes me think that you
are potentially attempting SR Class2 here. am I right?

The other potential usage is configure the chip over vcbypass and then
use class3 with reg address 0x6, 0x8 for DCDC1 and LDO1/2-> though i
am not sure how you'd use SR for LDO1/2 with 200mA and non linear
value2voltage.. the other possibility is you have two independent
TPS65023 chips on each rail..
may be you could briefly explain how you are integrating it all up to
understand the weakness of the datastructures involved..

> 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.
yes, there are improvements possible. we probably need to see your
usage to comeup with something that works for all of us
>
> Also, the PMIC specific code doesn't really belong to mach-omap2.
> OR was there a specific reason to keep it here??
potentially - but there are PMIC specific parameters that need to be
configured for the SR driver to function as well..

Regards,
Nishanth Menon

RE: omap: pm: assumptions on TWL and SmartReflex.

[Vishwanath Sripathy]

Sanjeev,

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, February 24, 2011 12:02 AM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: omap: pm: assumptions on TWL and SmartReflex.
>
> On Wed, Feb 23, 2011 at 19:57, Premi, Sanjeev <premi@ti.com> wrote:
> > Hi all,
> >
> > While trying to suport TPS65023 with AM3517 processor, i realize
> > that much of the code has implicit assumption on usage of TWLx0y0
> > PMIC and Smartreflex.
> Looking at the data sheet, single SCLK, SDAT makes me think that you
> are potentially attempting SR Class2 here. am I right?
>
> The other potential usage is configure the chip over vcbypass and then
> use class3 with reg address 0x6, 0x8 for DCDC1 and LDO1/2-> though i
> am not sure how you'd use SR for LDO1/2 with 200mA and non linear
> value2voltage.. the other possibility is you have two independent
> TPS65023 chips on each rail..
> may be you could briefly explain how you are integrating it all up to
> understand the weakness of the datastructures involved..
>
> > Check the definition of omap_volt_pmic_info and omap_volt_data.
Most of these parameters are required by OMAP for VP/VC configuration. I
agree that these parameters need to be segregated better to have PM IC
specific, OMAP specific and Board specific parameters. But I do not
understand why you are saying that these are TWL specific.

Can TPS65023 be controlled via VC/VP over i2c4? If so then these
parameters will be needed by VC/VP to control the PM IC.
If not, then there is no need to hook up your PMIC with OMAP voltage
layer. You can perhaps use regulator framework for setting the voltage.

Regards
Vishwa
> >
> > 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.
> yes, there are improvements possible. we probably need to see your
> usage to comeup with something that works for all of us
> >
> > Also, the PMIC specific code doesn't really belong to mach-omap2.
> > OR was there a specific reason to keep it here??
> potentially - but there are PMIC specific parameters that need to be
> configured for the SR driver to function as well..
>
> 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