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

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

[Woodruff, Richard]

> C) Notification
> 
> Let's look at the "notification" stage first -- that's what 
> current cpufreq
> notifiers do in a very basic way. However, this is also what 
> the new clock
> and voltage frameworks are trying to do, right? So that's the 
> lesser problem
> now.

No, the clock frame work does not do notifications to drivers.

The procedure for system wide frequency scaling using the clock frame
work:
 1: Get a root clock handle (clk_get)
 2: Validate a new target clock rate (clk_get_rate + clk_round_rate)
*3: Use Notification services from some _other_ frame work to drivers
 4: Set the new rate (clk_set_rate)
	- This setting changes potentially several levels of derived
clocks

The clock frame work allows simple maintenance of device local clocks or
the ability to change root clocks or groups of root clocks.  Root clock
changes are the ones which are used with system frequency scaling and
these changes _may_ need the notification depending on the level of
system coupling.


* Reading below in your message you address and seem to get this...  The
following text just shows generally what happens in some current
operating point centric systems.

--------------------
- In an operating point centric system the key root clocks (or other
fundamental system wide variables like power domain) are parameters in
the operating point.  

- Prior to trying to change in an operating point or a parameter in a
given point, the frame work does a dependency check to registered
drivers which care about operating point parameter changes.  Drivers
which are sensitive to these changes may register constraints to be
_considered_ by the frame work at change times.

- Once the system has decided the change is ok it then notifies the
driver to prepare for the parameter set change.  The controlling frame
works (possibly multiple ones) are used to make the system changes.  The
driver is then notified the change is done.
--------------------

> D) Verification
> 
> So, how to do this verification? Basically, there are two approaches:
> 
> 1) ask every other subsystem whether the new value is OK with it.
> 	This is what cpufreq currently suggests to do. It is evident
> 	that this gets overly complicated with lots of dependencies
> 	and dependencies within the dependencies -- both in terms
> 	of concept and in terms of time the verification code takes
> 	to execute.
> 	Advantages:
> 	- easy to expand, also in runtime (e.g. USB system is
> 		modprobed and telling you of a new minimum voltage
> 		requirement on certain circumstances)
> 	- does not limit choices for each knob
> 	Disadvantages:
> 	- might get very complex
> 
> 2) look up all valid states in a table
> 	This is basically what PowerOP and the "operating points"
> 	concept suggests: if you want to change one value, you check
> 	what operating points a) contain the new value and b) is
> 	most suitable to you.
> 	Advantages:
> 	- fast
> 	- pre-defined set of operating points which the system
> 	  designer is comfortable with
> 	Disadvantages:
> 	- needs to be limited to "core" of the system as else
> 	  the tables may get overly large
> 	- limits the choices

That is a pretty good summary.

Depending on your operating point definition you don't always have to
limit yourself here.  An operating point parameter need not directly be
associated with the physical value of the domain it represents.  Meaning
you don't need to put 1.05 volts in for the parameter, you can define it
as some other value which needs translating/defining by the core.

> E) So, why not combine the best of both worlds?

More reading necessary ...

Thanks,
Richard W.

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

[Dominik Brodowski]

Hi,

On Sun, Oct 08, 2006 at 09:28:15AM -0500, Woodruff, Richard wrote:
> > D) Verification
> > 
> > So, how to do this verification? Basically, there are two approaches:
> > 
> > 1) ask every other subsystem whether the new value is OK with it.
> > 	This is what cpufreq currently suggests to do. It is evident
> > 	that this gets overly complicated with lots of dependencies
> > 	and dependencies within the dependencies -- both in terms
> > 	of concept and in terms of time the verification code takes
> > 	to execute.
> > 	Advantages:
> > 	- easy to expand, also in runtime (e.g. USB system is
> > 		modprobed and telling you of a new minimum voltage
> > 		requirement on certain circumstances)
> > 	- does not limit choices for each knob
> > 	Disadvantages:
> > 	- might get very complex
> > 
> > 2) look up all valid states in a table
> > 	This is basically what PowerOP and the "operating points"
> > 	concept suggests: if you want to change one value, you check
> > 	what operating points a) contain the new value and b) is
> > 	most suitable to you.
> > 	Advantages:
> > 	- fast
> > 	- pre-defined set of operating points which the system
> > 	  designer is comfortable with
> > 	Disadvantages:
> > 	- needs to be limited to "core" of the system as else
> > 	  the tables may get overly large
> > 	- limits the choices
> 
> That is a pretty good summary.
> 
> Depending on your operating point definition you don't always have to
> limit yourself here.  An operating point parameter need not directly be
> associated with the physical value of the domain it represents.  Meaning
> you don't need to put 1.05 volts in for the parameter, you can define it
> as some other value which needs translating/defining by the core.

First, thanks for your insightful comments. Second, well, we can of course
use some discrete values instead of "real" values -- however, if we get the
chance, I think it's nicer to put the "real" values there. Unless we need
floating point ;)

Thanks,
	Dominik

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

[Woodruff, Richard]

Hi,

> > Depending on your operating point definition you don't always have
to
> > limit yourself here.  An operating point parameter need not directly
be
> > associated with the physical value of the domain it represents.
Meaning
> > you don't need to put 1.05 volts in for the parameter, you can
define it
> > as some other value which needs translating/defining by the core.
> 
> First, thanks for your insightful comments. Second, well, we can of
course
> use some discrete values instead of "real" values -- however, if we
get
> the
> chance, I think it's nicer to put the "real" values there. Unless we
need
> floating point ;)

Yes, floating point funny... really I was hoping for denormalized number
usage, not just '1.05V' instead of 1050mV ;)

For me an operating point ends up being a mix of directly interpretable
physical parameters and a couple more generic ones.  They are all
'fundamental'. The generic ones describe a level for an entire domain.
Upon parameter change I would update the specific domain control
register, then, a secondary (usually symmetric) action may need to be
preformed to members of that domain.

For example I have 3 domains.  I want to put one domain into a higher
latency idle state and leave the other two in a higher responsive state.
I have 3 parameters in my OPP for those domains generic idle state.  I
change the parameter to put that one domain into idle.  This gets
translated into a call out where each member module (peripheral) enables
a local idle feature (perhaps more as necessary).  There may be 2 or 20
or ? modules contained in that domain.  Next, the domains master idle
bit is set, and once all the members reach idle the domain can change
state.

Listing all 20 devices in the OPP isn't necessary when you are looking
to achieve a fundamental domain specific action.  A single parameter to
express this is useful.

There was recently a latency patch I saw on lkml used with a wireless
driver.  I think that patch along with some decision logic would fit
nicely into this kind of scheme.  Before I set a domain idle bit, I can
have available the latency information to say if it will work out.

In our implementation you must track the stack up of latencies.  Each
level of idle from the device, to the interconnect, to the domain, and
to the DPLL will add another additive level of latency.  If you just set
individual ones with out summing them up, you will find your quality of
service will be bad and you get bad playback on mp3 and the like with
certain device state mixes.

If you don't associate the devices in this type of system you end up
limiting the kind of power savings which is achievable.

Regards/Thanks,
Richard W.

> 
> Thanks,
> 	Dominik