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

[david singleton <dsingleton@mvista.com>]

On Aug 12, 2006, at 1:07 AM, Vitaly Wool wrote:

>> Yes, which is why Eugeny and I sent out the take 3 PowerOP patches.  A
>> good discussion ensued and our updated patches are a result of that
>> discussion.  If you disagree with our approach or think something is
>> missing, give us some specific feedback.  Simply sending out a 
>> separate
>> set of PowerOP patches is not joining in the current discussion.  It 
>> is
>> confusing and probably turning people off to the ideas.   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.
>
> 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.

I agree that an alternative implementation is a good way to compare
and contrast ideas.  And Matt knows that I'm easy to work with.

The ideas I'm trying to get across are that the different power 
management
infrastructures can be unified in such a way as to benefit the kernel.
I believe the kernel would benefit from a unified power management
infrastructure and from a simplified approach to power management.

The second idea is that all operating states can be encapsulated
into a simple operating point concept.  And operating points are
created from data supplied from the hardware vendor and validated,
just as cpufreq does today.

The encapsulated operating point mechanism I'm presenting provides
an architecture independent interface to the kernel's power management
framework while providing the necessary architecture
specific functions and data to individual platforms and individual
operating points.

The powerop structure provides the architecture independent interface
to the framework.  The ops vectors provides the architecture, platform
and operating point specific interface to individual systems.  The
void *md_data pointer provides a simple way to get architecture
dependent data to the operating point functions.

The patch I have ready today shows how these architecture
independent and dependent pieces work on an x86 centrino
and on an ARM Xscale platform.

I've convinced myself that an encapsulated operating point
concept can work across different architectures and even
on very complex power management capable hardware.

Both platforms have frequency and voltage management capability,
but the Xscale has a much more complex set of information necessary
to scale frequencies.

The last idea I'm trying to present is that the simplified interface to
use the operating points will benefit the user and the
power manager daemon.  The user is presented a list of
supported operating points and uses them by writing their
name into the /sys/power/state file and the powerop framework
automagically transitions to the named operating point.

The patches are available at

http://source.mvista.com:~dsingleton/

There is the original set that worked on the x86 centrino for
2.6.18-rc1 and a new set that's incorporated suggestions
added the Xscale mainstone platform and been rolled to 2.6.18-rc4.

I'll send the individual patches out inlined in a bit.

David


I
>
>> Um,  I thought the powerop write up and  patches already sent out
>> addressed the goals discussed so far.  We (everyone on the list) need
>> to collaborate on the powerop effort.  Isolated development and
>> attempting to discuss two separate implementations won't get us very
>> far.
>
> I would like to suggest both sides to think over what the main
> differences of the concurring implementations are and share the
> thoughts with this list. That should really be helpful to work out the
> common solution.
>
>> My goal is to get PowerOP into the mainline kernel.  If everyone
>> submits a different powerop implementation for those boards, then
>> people will see a fragmented concept that can not be generalized.  The
>> possibility of Andrew and Linus accepting PowerOP will go from high to
>> never.   Again, I don't see any reason for two separate development
>> efforts and patchsets.  Please stop submitting separate patches and at
>> least attempt to collaborate on the current PowerOP patchsets under
>> discussion.
>
> I wouldn't say so. I would just like to see both implementations
> converging, but that is not to happen immediately. Anyway, this
> implies that both authors pay more attention to the other
> implementation.
>
> Vitaly