> -----Original Message----- > From: Menon, Nishanth > Sent: Tuesday, March 08, 2011 6:58 PM > To: Premi, Sanjeev > Cc: Sripathy, Vishwanath; linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 > > On Tue, Mar 8, 2011 at 18:48, Premi, Sanjeev <premi@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
