> -----Original Message-----
> From: Menon, Nishanth
> Sent: Tuesday, March 08, 2011 6:16 PM
> To: Premi, Sanjeev
> Cc: Sripathy, Vishwanath; linux-omap@xxxxxxxxxxxxxxx
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
