Re: Alternative Concept [Was: Re: [RFC] CPUFreq PowerOP integration, Intro 0/3]

Dominik Brodowski
2006-10-26T03:06:42Z

Hi,

On Mon, Oct 09, 2006 at 11:21:23AM -0700, Mark Gross wrote:
> > D) Verification
> i.e. constraint checking and enforcement

Exactly.

> > Let's assume that there is an OMAP1 PM module which implements a ->set and
> > ->get function for all of them. A yet-to-be-defined interface then tells
> > this PM module
> >
> > "I want to increase the CPU frequency from C1 MHz to C2 MHz!"
> >
> > ->set(CPU_VLTG, C2);
> did you mean ->set(CPU, C2) ?

Yes, sorry about the confusion.

> > The core would determine that the latter two states are now allwed, and
> > using some sensible algorithm (e.g. "where do I not have to switch too many
> > knobs", or minimize the costs of switching) decide between those two.
> > Basically, it would recignize now that it is OK to proceed from state Nr. 1
> > to Nr. 3, but that this means that "tc" also needs to be changed. After
> > notifing relevant subsystems using the clock and voltage frameworks, it
> > would then proceed to set the hardware accordingly.
>
> This adds a sort of tree search defining a power state path from a
> current state to one of the possible target stats with C2. In this case
> the only way to get to CPU==C2 is to change TC to D2 and deal with all
> the ripples that will cause.
>
> One question is how do we know that changing TC is a better way to go
> than changing CPU_VLTG? We'll need to figure out an ordering in the
> phase space of power states. Thinking out loud, I would try to pick the
> target state based on latency if there are more than one targets to
> satisfy the ->set() request.

That sounds like an interesting approach.

> > I think that this might be much easier to implement than your PowerOP /
> > operating points / PM core / PowerOP - cpufreq interaction patches. As a
> > matter of fact, some parts of your operating points table infrastructure
> > may be usable for the concept outlined above. So, what do you think? What
> > does everyone else involved think about this alternative approach?
> >
>
> I still see a need to take the first step of enabling "lots of knobs".
> This is the primary goal of the PowerOp patch set. The stuff with the
> sysfs is just an interface to set/get the operating points while a
> more complete solution like what you are talking about evolves.

Unfortunately, PowerOp gets the "lots of knobs" on its head, in my
opinion...

Thanks,
Dominik