> -----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-ow...@vger.kernel.org [mailto:linux-omap- > > > > ow...@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] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
