Re: Dynanic On-The-Fly Operating points for PowerOP

[david singleton <dsingleton@mvista.com>]

On Aug 12, 2006, at 4:14 PM, Matthew Locke wrote:

>
> On Aug 12, 2006, at 1:07 AM, Vitaly Wool wrote:
>> May I disagree? Having an alternative implementation is never a bad
>> thing, unless the sides are unable to co-operate ;)
>> Let's try to compare implementations and their concepts, and benefit 
>> from both.
>
> What are you disagreeing with?  Re-read my statement below.   I don't 
> see the reason for another implementation.  Rather than guess,  I 
> would prefer that Dave tell us why he is submitting a different 
> powerop interface.  There must be something driving him to do so.

Okay, let me see if I can clarify a bit.  I presented the alternative
implementation to compare and contrast ideas, and because I believe this
implementation is a better solution for the following reasons:

I believe this interface between the kernel and user space is cleaner.  
The
system presents the list of supported operating points to the user and 
the
user invokes them by their name.

/sys/power/state is used for setting and displaying the current 
operating point
and /sys/power/supported_states presents the names of the supported 
operating
points to the user.  That's the entire user interface.

I believe the moving of policies, classes and governors out of the 
kernel
and into user space is a better solution.  The user, or power manager 
daemon,
should make the decisions about when and what operating point to set, 
and
which devices to suspend or resume.

The user does not pass in information needed to construct an operating 
point
and let the kernel try and validate the data and protect against 
incorrect
or malicious data that would hang the system.  Operating points are 
constructed
from the hardware vendor supplied data sheets and validated, just like 
cpufreqs,
and tested before the code is integrated into the mainstream.

I believe the architecture independent interface between the kernel and
powerop framework is better and I believe the architecture 
dependent/board
specific interface  is better because:

The entire design revolves around operating points and operating points
can be encapsulated into two data structures and three functions.  The 
powerop
structure contains the architecture independent data and function 
pointers
to the platform dependent routines to transition to the operating point.
The md_data pointer in the powerop structure points to any kind of 
platform
specific data needed by the transition routines.

The platform dependent interface not only lets each platform have its 
own
information and functions for operating state transition, but it also 
lets
individual operating points on the same platform have operating point
specific data and functions.

By encapsulating an operating point into two data structures new 
operating
points can easily be constructed.

Lets consider for a moment the case where Intel creates a new revision 
of the
pxa27x processor for the mainstone.  To implement support for the new 
processor
one would only have to create a set of powerop structures and md_opt 
structures
that contain the information for the new processor's operating points.

The next step would be to insert the new processor identification into
the case statement where the system deteremines the processor id and the
new operating points would be linked into the system you'd be done
implementing a new set of operating points for a new processor.

This would take a matter of hours to create and test new operating 
points
instead of days or weeks.  And with the dynamic on-the-fly loadable 
module
for an operating points creation and testing of new processors would
take a very short time, something the SoC manufacturers might like.

And by doing the mainstone patch wthout having to change any of the 
framework
or interfaces I've convinced myself that the concept, framework and 
interfaces
will work across different architectures and platforms.

Its simple but enormously flexible.


David



>
>>> Is there
>>> something specific missing or wrong with the patches we submitted 
>>> that
>>> required another set of patches to be developed?  By joining in the
>>> discussion, I mean that you should let us know this information.  If
>>> patches are your method for doing so, then at least provide a
>>> description of what your patches address that ours does not.  Right
>>> now, its just unclear why there are two different powerop patchsets.
>>>
>
> Matt
>