Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

2012-05-24 Thread Kevin Hilman
Menon, Nishanth n...@ti.com writes:

 On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman khil...@ti.com wrote:
 Woodruff, Richard r-woodru...@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.

 ditto

 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-omapm=129933897910785w=2
 ABB: http://marc.info/?l=linux-omapm=130939399209099w=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.

Correct.

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[1].

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
missing features.

Thanks,

Kevin

[1] http://kerneltrap.org/Linux/Kernel_Evolution
--
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


Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

2012-05-23 Thread Menon, Nishanth
On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman khil...@ti.com wrote:
 Woodruff, Richard r-woodru...@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.

 ditto

 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-omapm=129933897910785w=2
ABB: http://marc.info/?l=linux-omapm=130939399209099w=2

I am not sure what you mean need to be submitted upstream?

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 think you do mean
merged upstream in this context.


Regards,
Nishanth Menon
--
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


Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

2012-05-09 Thread Koen Kooi

Op 9 mei 2012, om 02:39 heeft Woodruff, Richard het volgende geschreven:

 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.
 
 ABB is requirement for a production useable driver. 

ABB/FBB is also needed for 1GHz support on omap3 based SoCs like AM37xx and 
DM37xx.

regards,

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


Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

2012-05-09 Thread Kevin Hilman
Woodruff, Richard r-woodru...@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. 

ditto

 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.

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


Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

2012-05-08 Thread Kevin Hilman
Woodruff, Richard r-woodru...@ti.com writes:

   The only thing the higher-level layers might potentially need to
   do is to enable/disable AVS around transitions (e.g. when
   changing OPP,AVS is disabled before changing OPP and
   only re-enabled when the newnominal voltage has been
   acheived.)

 Getting clean baseline in place is huge step but actual production
 interfaces will need to comprehend some OPP to AVS dependencies beyond
 on/off.

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.

When folks are motivated to propose such changes upstream, we will be
happy to discuss them and add support for them to the AVS driver.

Until then, the primary purpose of this series is to do some minimal
cleanup of an *existing* driver so it can be moved into drivers/*.  New
features can be added there as easily as they could've been added when
it was a driver under arch/arm.

Kevin

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


RE: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

2012-05-08 Thread Woodruff, Richard
 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.

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.

Yet to be added feature has different meaning than functional gap.

Regards,
Richard W.

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