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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux