[linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
khilman at ti.com
Thu May 24 19:16:00 EDT 2012
"Menon, Nishanth" <nm at ti.com> writes:
> On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman <khilman at ti.com> wrote:
>> "Woodruff, Richard" <r-woodruff2 at ti.com> writes:
>>>> From: Hilman, Kevin
>>>> Sent: Tuesday, May 08, 2012 5:17 PM
>>>> A basic OMAP AVS driver has been in mainline for a long time, yet we
>>>> have not seen support submitted for all of these features.
>>> 1.5/3.5 is a feature.
>> And I'm still waiting for it to be submitted upstream.
>>> ABB is requirement for a production useable driver. Higher speed rated
>>> OMAP4 and all OMAP5 added these to be useable.
>>> Yes this is effort. Point of mentioning is to raise awareness of need.
>> I'm well aware of the need.
>>> Yet to be added feature has different meaning than functional gap.
>> And both need to be submitted upstream.
> SR 1.5: http://marc.info/?l=linux-omap&m=129933897910785&w=2
> ABB: http://marc.info/?l=linux-omap&m=130939399209099&w=2
> I am not sure what you mean "need to be submitted upstream"?
You're right. I should've said re-submitted and merged. Both have been
submitted (and reviewed) but no follow up submissions after review, and
thus they're still out of tree.
> Just tired of seeing things perpetually change without considering
> even how to handle features that are mandatory for SoC even with code
> posted upstream to show exactly what it takes..
I'm sorry, but this is not perpetual change.
This driver has been upstream in its current (admittedly
feature-limited) form for a long time, the only thing changing in
$SUBJECT series is the location of the driver. Why all the fuss about
the missing features now?
> I think you do mean merged upstream in this context.
Frameworks always have limitations. The way they get extended/expanded
etc. is by the submission/review/merging of support for new
features/requirements. The process for that is the same as any feature
in any part of the kernel.
Evolution, not intelligent design.
All of that being said, I'm not sure why this thread was hijacked for
this debate in the first place. The point of $SUBJECT series is simply
to move and *existing* framework from arch/arm out to drivers. The only
changes done are cleanups to make this move possible.
I for one would welcome extending this framework to ensure it supports
all the SoC features. I just don't want those features to be a
prerequisite for this move from arch/arm to drivers.
Please, let's get this moved to drivers, and then add support for the
More information about the linux-arm-kernel