Ottawa Linux Power Management Summit, June 25-26, 2007 - Minutes

Ottawa Linux Power Management Summit, June 25-26, 2007 - Minutes

[Len Brown]

A Linux Power Management "mini-summit" was held in Ottawa
on June 25 and 26, 2007, immediately preceeding the Ottawa Linux Symposium.

An effort was made to follow the best-known-method
for a Linux mini-summit, thought to be the most recent
storage-summit.  The invitation to the meeting was open --
sent to linux-pm@lists.linux-foundation.org in early May.
The focus of the meeting was on technical discussion.  Thus,
only presentations which supported discussion were encouraged,
and the size of the forum was capped at 20.  The agenda was set
by consensus of the attendees.

Thank you to the Intel Open Source Technology Center
for sponsoring the meeting.

Day 1 attendees:

Len Brown, Intel OTC, Linux Kernel ACPI Maintainer
Mark Gross, Intel OTC, embedded Linux team
Paul Mundt, Renesas, Linux Kernel Super-H Maintainer
Kevin Hilman, MontaVista, MV DPM Maintainer
Igor Stoppa, Nokia, OSSO Power Management
Sakari Poussa, Nokia, OSSO Power Management
Dave Jones, Red Hat, Fedora Maintainer, Linux Kernel Cpufreq Maintainer
Klaus Pedersen, Nokia, OSSO Power Management
Ken Rozendal, IBM, Linux on Power
Vivek Kashyap, IBM LTC
Adam Belay, Novell/MIT, cpuidle developer
Eugeny S. Mints, NGS Power Management
Scott E. Preece, Motorola
Marcelo Tosatti, Red Hat, One Laptop Per Child

Day 2 additional attendees:

Tariq Shureih, Intel OTC, MID power policy manager
Rishi Bhattacharya, Texas Instruments
Iliasbiris, Instituto de Tecnologia

notes:

Mark Gross showed off a Classmate PC.  The unit he had was a 900MHz
Celeron (model 13) Find out more at http://classmatepc.com

Mark led a discussion about constraints/quality of service.
An application specifies a QOS/SLA to some middle-ware, which
translates that into operation constraints.  We discussed the
vocabulary for constraints.  More on this below.

Igor Stoppa presented findings from the Nokia Tablet team.
The OMAP1 used in the n770 had idle/big-sleep/deep-sleep.
The OMAP2 is used in the n800, is built on 90nm technology.
The OMAP3 is expected to be built on high leakage 65nm technology,
and thus require software to take advantage of power-gating off states.
Indeed, the OMAP3 has over 30 power gates.

http://linux.omap.com has OMAP Linux resources.
http://source.mvista.com hosts OMAP patches before they get
to kernel.org

Re: Performance States

Igor asserted that once a voltage is selected, it is it always
the best policy to run at the maximum frequency supported by
that voltage.

However, the OMAP2 throws Linux a curve ball when increasing
the ARM core to its maximum speed, it will _reduce_ the speed of
the DSP.  Eg. 400MHz and 133MHz respectively.  cpufreq doesn't
have a concept of this kind of dependency.

cpufreq_set_policy() doesn't match Nokia's needs as it is a 1-way
notification, and there is no way to register constraints.

Igor reported a scaling frequency bug where the current polling
interval and minimum residency formulas in ondemand don't work
on Nokia's hardware.

He also described "spread to deadline" in contrast to "race to
idle".  In spread-to-deadline, the work is run at the minimum rate
such that it will complete in time for a known future deadline.
The deadline might be an expected external periodic communication
event, for example.

Re: pause/resume
Total pause/resume on the n800 is 20-80ms.
PLL re-lock takes about 0.1ms and the voltage ramp is about 5ms
by comparison.  The big time consumer is drivers.  In particular
syncing with screen updates.

Paul Mundt contrasted the clock framework with cpufreq, saying
that one could build a rate table of all P-state transitions.
Though this would need to prototyped to see if it is viable.

Marcelo Tosatti shoed off an OLPC XO-1 (http://laptop.org/)
It includes a 433MHz AMD Geode LX.
(this replaced the previous cache-less Geode GX)
The XO-1 has 1G NAND flash 1200x900 LED screen which uses 0.2W min,
1.0 Watts max.  These screen power numbers are truly impressive.

OLPC wants to aggressively auto-suspend to an suspend-to-RAM
like state, except the screen stays on (and wireless stays on).
The system wakes upon user-input.  The requirement for this state
is < 100ms resume latency.  Jim Gettys asserts that the iPAQ could
resume in 10ms by comparison.  Marcelo reports that the XO-1
can resume in 160ms today if USB is disabled.  However, if USB
is enabled, it resumes in 250ms.  He thinks that resume needs to
be multi-threaded, and it needs to be smarter so that it doesn't
blindly resume every device in the system.

XO-1 has a Display Controller (DCON), which will refresh display
even when processor completely powered off.

Regarding wake, enable_irqwake(irq) is ugly b/c it is IRQ specific.
Needs to e enable-wakeup(device) -- a generic API.

Audio amplifier must delay ~100ms power-up to avoid a pop.

OLPC is not using suspend-to-disk, yet.

Discussed the STD vs STR path.  The expectation is that STR can be
faster if it doesn't follow the same path as STD.  Per the list,
Rafael is working on this.

OLPC is using OHM - Open HW Manager -- a generic system manager,
of which power management is just one part.

olpc-pm.c olpc_pm_enter() is kicked off by OHM on detecting idle.

Dave Jones led a discussion on cpufreq.

Re: Accounting vs cpufreq.
Enterprise capacity planning applications get confused by cpufreq.
cpufreq lowers the MHz due to low demand, the management application
sees no idle time left -- indicating that the system has reached capacity
and need to be upgraded.

Dave commented that the cpufreq conservative governor should
be deleted and whatever hooks are needed should simply be added
to ondemand.

MHz vs scheduler: today cpufreq simply tracks idle time and the
schedule is completely unaware that cpufreq changes the frequency.
Application hints may be appropriate for apps to tell the scheduler
about their MHz needs.  Also, the scheduler may be better off
scheduling cycles instead of scheduling time.

Discussion on APERF/MPERF MSRs on Intel processors: The APERF/MPERF
ratio conveys the "actual" to "maximum" MHz ratio since the
MSRs were last reset.  Note that with Intel Dynamic Acceleration
(IDA), this ratio can be greater than 1 -- so maybe "maximum"
needs to be re-worded as "marketing":-)

governors It isn't clear whey there needs to be a governor
per core.  It seems to be unused today, except on incorrectly
administered systems.

user-space: cpuspeed, powernowd not used so much these days.

The fabled DPM/PowerOP/cpufreq integration isn't happening fast.
Per previous discussion, an abstract notion Operating Points
makes the most sense, and perhaps dealing in units of absolute
MHz is not the right model.  Though users are now accustomed to
thinking they know the absolute MHz....

Dave Jones was open to the idea of transforming cpufreq into a
generic clock scaling implementation.

Dave mentioned that Fedora Core 7 32-bit is now shipping with
CONFIG_NOHZ=y and CONFIG_HZ=1000.

Kevin Hillman led a discussion on DPM (Dynamic Power Management,
http://dynamicpower.sourceforge.net/)

DPM has been shipping since Linux-2.4 and is a part of many
successful products, so it will continue to be supported.

One key aspect of DPM is that it allows customers to put their
platform-specific proprietary control code in user-space.

DPM has hooks in the scheduler where applications explicitly
request an operating state.

MontaVista is hoping to migrate to mainline, now that mainline is
becoming more capable.  In particular, they need solid tickless,
cpufreq, and wake-up events.

Paul Mundt described the cutting edge in the Super-H space.
The SH4A-SMP has 4 cores and it expected to be used in high-end
consumer electronics, navigation etc.  It has per-core voltage
regulation, and CPU offline saves real power.  Often ITRON is
run on a core.

Mark Gross led a discussion on Device QOS Parameters, to see
if common language might be suitable, say in a sysfs interface.
We brain-stormed on how throughput, rate, power gain, latency,
acoustic and timeout applied to various classes of devices;
such as storage, wired and wireless networks, and the display.

Suspend/Resume:
Earlier on the list, Linus stated that he might
prefer multiple entry points that do simpler functions rather
than the over-loaded .suspend/.resume I/F we have today.

Adam Belay described a 2-pass device suspend to ram loop, where .stop is
first called for each device before the first .suspend is called:

.start .stop
        dont touch hardware able to return failure
.suspend(target state)
        saves HW state enable wake feature invoke D-state
        (power-off)
[take STD snapshot here] .resume

There is also a .reset especially for kexec that can be called
after .stop.  It removes the IRQ and int src.

The .stop loop allows a device to veto the suspend and for the
system to quickly back out of the operation.

sysfs brainstorm...

 /sys/class/power/state
 /sys/device/.../power/state
        A class could provide default hooks for devices.

Tariq Shureih presented an effort to implement a Linux Power Policy
Manager (PPM).  This effort is primarily intended to fill the needs
of Linux mobile-internet-devices (http://moblin.org/)
However, nothing limits its use to that market segment.

The big question was how this compares to the OHM effort.
http://ohm.freedesktop.org

The initial answer is that PPM will be BSD licensed,
and OHM will be LGPL.

Nokia in the lab hopes to replace their proprietary solution
with OHM.

We discussed powertop.
Go to http://linuxpowertop.org/ for the latest.

Virtualization.  Observed that power management comes "for free"
in the hosted model and there is heavy lifting to make it work
in the hypervisor model.

In particular, Xen, the popular hypervisor-hybrid model currently
lacks C-state and P-state support.

Re: Ottawa Linux Power Management Summit, June 25-26, 2007 - Minutes

[Rafael J. Wysocki]

On Wednesday, 5 September 2007 10:26, Len Brown wrote:
> A Linux Power Management "mini-summit" was held in Ottawa
> on June 25 and 26, 2007, immediately preceeding the Ottawa Linux Symposium.
> 
> An effort was made to follow the best-known-method
> for a Linux mini-summit, thought to be the most recent
> storage-summit.  The invitation to the meeting was open --
> sent to linux-pm@lists.linux-foundation.org in early May.
> The focus of the meeting was on technical discussion.  Thus,
> only presentations which supported discussion were encouraged,
> and the size of the forum was capped at 20.  The agenda was set
> by consensus of the attendees.
> 
> Thank you to the Intel Open Source Technology Center
> for sponsoring the meeting.
> 
> Day 1 attendees:
> 
> Len Brown, Intel OTC, Linux Kernel ACPI Maintainer
> Mark Gross, Intel OTC, embedded Linux team
> Paul Mundt, Renesas, Linux Kernel Super-H Maintainer
> Kevin Hilman, MontaVista, MV DPM Maintainer
> Igor Stoppa, Nokia, OSSO Power Management
> Sakari Poussa, Nokia, OSSO Power Management
> Dave Jones, Red Hat, Fedora Maintainer, Linux Kernel Cpufreq Maintainer
> Klaus Pedersen, Nokia, OSSO Power Management
> Ken Rozendal, IBM, Linux on Power
> Vivek Kashyap, IBM LTC
> Adam Belay, Novell/MIT, cpuidle developer
> Eugeny S. Mints, NGS Power Management
> Scott E. Preece, Motorola
> Marcelo Tosatti, Red Hat, One Laptop Per Child
> 
> Day 2 additional attendees:
> 
> Tariq Shureih, Intel OTC, MID power policy manager
> Rishi Bhattacharya, Texas Instruments
> Iliasbiris, Instituto de Tecnologia
> 
> notes:
> 
> Mark Gross showed off a Classmate PC.  The unit he had was a 900MHz
> Celeron (model 13) Find out more at http://classmatepc.com
> 
> Mark led a discussion about constraints/quality of service.
> An application specifies a QOS/SLA to some middle-ware, which
> translates that into operation constraints.  We discussed the
> vocabulary for constraints.  More on this below.
> 
> Igor Stoppa presented findings from the Nokia Tablet team.
> The OMAP1 used in the n770 had idle/big-sleep/deep-sleep.
> The OMAP2 is used in the n800, is built on 90nm technology.
> The OMAP3 is expected to be built on high leakage 65nm technology,
> and thus require software to take advantage of power-gating off states.
> Indeed, the OMAP3 has over 30 power gates.
> 
> http://linux.omap.com has OMAP Linux resources.
> http://source.mvista.com hosts OMAP patches before they get
> to kernel.org
> 
> Re: Performance States
> 
> Igor asserted that once a voltage is selected, it is it always
> the best policy to run at the maximum frequency supported by
> that voltage.
> 
> However, the OMAP2 throws Linux a curve ball when increasing
> the ARM core to its maximum speed, it will _reduce_ the speed of
> the DSP.  Eg. 400MHz and 133MHz respectively.  cpufreq doesn't
> have a concept of this kind of dependency.
> 
> cpufreq_set_policy() doesn't match Nokia's needs as it is a 1-way
> notification, and there is no way to register constraints.
> 
> Igor reported a scaling frequency bug where the current polling
> interval and minimum residency formulas in ondemand don't work
> on Nokia's hardware.
> 
> He also described "spread to deadline" in contrast to "race to
> idle".  In spread-to-deadline, the work is run at the minimum rate
> such that it will complete in time for a known future deadline.
> The deadline might be an expected external periodic communication
> event, for example.
> 
> Re: pause/resume
> Total pause/resume on the n800 is 20-80ms.
> PLL re-lock takes about 0.1ms and the voltage ramp is about 5ms
> by comparison.  The big time consumer is drivers.  In particular
> syncing with screen updates.
> 
> Paul Mundt contrasted the clock framework with cpufreq, saying
> that one could build a rate table of all P-state transitions.
> Though this would need to prototyped to see if it is viable.
> 
> Marcelo Tosatti shoed off an OLPC XO-1 (http://laptop.org/)
> It includes a 433MHz AMD Geode LX.
> (this replaced the previous cache-less Geode GX)
> The XO-1 has 1G NAND flash 1200x900 LED screen which uses 0.2W min,
> 1.0 Watts max.  These screen power numbers are truly impressive.
> 
> OLPC wants to aggressively auto-suspend to an suspend-to-RAM
> like state, except the screen stays on (and wireless stays on).
> The system wakes upon user-input.  The requirement for this state
> is < 100ms resume latency.  Jim Gettys asserts that the iPAQ could
> resume in 10ms by comparison.  Marcelo reports that the XO-1
> can resume in 160ms today if USB is disabled.  However, if USB
> is enabled, it resumes in 250ms.  He thinks that resume needs to
> be multi-threaded, and it needs to be smarter so that it doesn't
> blindly resume every device in the system.
> 
> XO-1 has a Display Controller (DCON), which will refresh display
> even when processor completely powered off.
> 
> Regarding wake, enable_irqwake(irq) is ugly b/c it is IRQ specific.
> Needs to e enable-wakeup(device) -- a generic API.
> 
> Audio amplifier must delay ~100ms power-up to avoid a pop.
> 
> OLPC is not using suspend-to-disk, yet.
> 
> Discussed the STD vs STR path.  The expectation is that STR can be
> faster if it doesn't follow the same path as STD.  Per the list,
> Rafael is working on this.

Well, in 2.6.23 the hibernation (STD is a PCish name) and suspend (ie.
STR, standby, etc.) code paths will be separate on the highest level.  Still,
they both use the freezer and device_suspend()/device_resume() , which consume
the majority of the suspend/resume time.

> OLPC is using OHM - Open HW Manager -- a generic system manager,
> of which power management is just one part.
> 
> olpc-pm.c olpc_pm_enter() is kicked off by OHM on detecting idle.
> 
> Dave Jones led a discussion on cpufreq.
> 
> Re: Accounting vs cpufreq.
> Enterprise capacity planning applications get confused by cpufreq.
> cpufreq lowers the MHz due to low demand, the management application
> sees no idle time left -- indicating that the system has reached capacity
> and need to be upgraded.
> 
> Dave commented that the cpufreq conservative governor should
> be deleted and whatever hooks are needed should simply be added
> to ondemand.
> 
> MHz vs scheduler: today cpufreq simply tracks idle time and the
> schedule is completely unaware that cpufreq changes the frequency.
> Application hints may be appropriate for apps to tell the scheduler
> about their MHz needs.  Also, the scheduler may be better off
> scheduling cycles instead of scheduling time.
> 
> Discussion on APERF/MPERF MSRs on Intel processors: The APERF/MPERF
> ratio conveys the "actual" to "maximum" MHz ratio since the
> MSRs were last reset.  Note that with Intel Dynamic Acceleration
> (IDA), this ratio can be greater than 1 -- so maybe "maximum"
> needs to be re-worded as "marketing":-)
> 
> governors It isn't clear whey there needs to be a governor
> per core.  It seems to be unused today, except on incorrectly
> administered systems.
> 
> user-space: cpuspeed, powernowd not used so much these days.
> 
> The fabled DPM/PowerOP/cpufreq integration isn't happening fast.
> Per previous discussion, an abstract notion Operating Points
> makes the most sense, and perhaps dealing in units of absolute
> MHz is not the right model.  Though users are now accustomed to
> thinking they know the absolute MHz....
> 
> Dave Jones was open to the idea of transforming cpufreq into a
> generic clock scaling implementation.
> 
> Dave mentioned that Fedora Core 7 32-bit is now shipping with
> CONFIG_NOHZ=y and CONFIG_HZ=1000.

CONFIG_NOHZ is known to break suspend and resume on some machines.  These
problems are being fixed over time, but that's a risky decision for a
distribution to switch it on by default.

> Kevin Hillman led a discussion on DPM (Dynamic Power Management,
> http://dynamicpower.sourceforge.net/)
> 
> DPM has been shipping since Linux-2.4 and is a part of many
> successful products, so it will continue to be supported.
> 
> One key aspect of DPM is that it allows customers to put their
> platform-specific proprietary control code in user-space.
> 
> DPM has hooks in the scheduler where applications explicitly
> request an operating state.
> 
> MontaVista is hoping to migrate to mainline, now that mainline is
> becoming more capable.  In particular, they need solid tickless,
> cpufreq, and wake-up events.
> 
> Paul Mundt described the cutting edge in the Super-H space.
> The SH4A-SMP has 4 cores and it expected to be used in high-end
> consumer electronics, navigation etc.  It has per-core voltage
> regulation, and CPU offline saves real power.  Often ITRON is
> run on a core.
> 
> Mark Gross led a discussion on Device QOS Parameters, to see
> if common language might be suitable, say in a sysfs interface.
> We brain-stormed on how throughput, rate, power gain, latency,
> acoustic and timeout applied to various classes of devices;
> such as storage, wired and wireless networks, and the display.
> 
> Suspend/Resume:
> Earlier on the list, Linus stated that he might
> prefer multiple entry points that do simpler functions rather
> than the over-loaded .suspend/.resume I/F we have today.
> 
> Adam Belay described a 2-pass device suspend to ram loop, where .stop is
> first called for each device before the first .suspend is called:
> 
> .start .stop
>         dont touch hardware able to return failure
> .suspend(target state)
>         saves HW state enable wake feature invoke D-state
>         (power-off)
> [take STD snapshot here] .resume
> 
> There is also a .reset especially for kexec that can be called
> after .stop.  It removes the IRQ and int src.

I think we'll need some more callbacks than that.  For example, we may need to
add a prepare_to_stop() callback allowing the driver to allocate additional
memory etc. before .stop() is called.

> The .stop loop allows a device to veto the suspend and for the
> system to quickly back out of the operation.

If we want to remove the freezer, we may want to use .stop() to make the driver
start blocking I/O data going from processes to the device and the other way
around.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Ottawa Linux Power Management Summit, June 25-26, 2007 - Minutes

[Dave Jones]

On Sun, Sep 09, 2007 at 02:26:39PM +0200, Rafael J. Wysocki wrote:

 > > Dave mentioned that Fedora Core 7 32-bit is now shipping with
 > > CONFIG_NOHZ=y and CONFIG_HZ=1000.
 > 
 > CONFIG_NOHZ is known to break suspend and resume on some machines.  These
 > problems are being fixed over time, but that's a risky decision for a
 > distribution to switch it on by default.

Expect to see everyone else doing the same thing in the next versions.
Without field-testing this stuff it remains busted.  A lot of bugs got
found and fixed by having this in Fedora that weren't tripped over
by linux-kernel testers at all.

	Dave

-- 
http://www.codemonkey.org.uk

Re: Ottawa Linux Power Management Summit, June 25-26, 2007 - Minutes

[Rafael J. Wysocki]

On Monday, 24 September 2007 21:41, Dave Jones wrote:
> On Sun, Sep 09, 2007 at 02:26:39PM +0200, Rafael J. Wysocki wrote:
> 
>  > > Dave mentioned that Fedora Core 7 32-bit is now shipping with
>  > > CONFIG_NOHZ=y and CONFIG_HZ=1000.
>  > 
>  > CONFIG_NOHZ is known to break suspend and resume on some machines.  These
>  > problems are being fixed over time, but that's a risky decision for a
>  > distribution to switch it on by default.
> 
> Expect to see everyone else doing the same thing in the next versions.
> Without field-testing this stuff it remains busted.  A lot of bugs got
> found and fixed by having this in Fedora that weren't tripped over
> by linux-kernel testers at all.

Well, that's certainly true.

Still, we have open suspend bugs in which NO_HZ appears to be the culprit,
eg. http://bugzilla.kernel.org/show_bug.cgi?id=8680

Greetings,
Rafael

Re: Ottawa Linux Power Management Summit, June 25-26, 2007 - Minutes

[Thomas Gleixner]

On Tue, 2007-09-25 at 13:39 +0200, Rafael J. Wysocki wrote:
> On Monday, 24 September 2007 21:41, Dave Jones wrote:
> > On Sun, Sep 09, 2007 at 02:26:39PM +0200, Rafael J. Wysocki wrote:
> > 
> >  > > Dave mentioned that Fedora Core 7 32-bit is now shipping with
> >  > > CONFIG_NOHZ=y and CONFIG_HZ=1000.
> >  > 
> >  > CONFIG_NOHZ is known to break suspend and resume on some machines.  These
> >  > problems are being fixed over time, but that's a risky decision for a
> >  > distribution to switch it on by default.
> > 
> > Expect to see everyone else doing the same thing in the next versions.
> > Without field-testing this stuff it remains busted.  A lot of bugs got
> > found and fixed by having this in Fedora that weren't tripped over
> > by linux-kernel testers at all.
> 
> Well, that's certainly true.
> 
> Still, we have open suspend bugs in which NO_HZ appears to be the culprit,
> eg. http://bugzilla.kernel.org/show_bug.cgi?id=8680

Grr, kernel.org bugzilla is down. I take a look later.

Btw. I got an interesting private response to the latest ACPI fixes:

> >    ACPI: disable lower idle C-states across suspend/resume
> > 
> > Finally, the weird suspend/resume behavior of my Dell-420 laptop has
> > disapeared (no way to adjust brightness after a suspend when not in the
> > docking station). It was always dark after a resume and made the laptop
> > unuseable in practice.
> 
> I cheered too early:
> I just discovered that suspending to ram works well for the first time,
> but after that it's still the same problem. Suspend to disk always
> worked well btw. But somehow there is a difference now: when switching
> to a normal console (ctrl-alt-F1 e.g.) and switching back to X the
> brightness works again. Another thing: I now can also suspend *in* the
> docking station, take it *out* and resume without problems, which never
> worked before :)

Len, did you / Venki look into a similar solution for cpuidle yet ? I'd
like to update -hrt ASAP. If not I just hack it in for now.

	tglx

cpufreq-set problems [Was: Re: Ottawa Linux Power Management Summit, June 25-26, 2007 - Minutes]

[Dominik Brodowski]

Hi,

On Wed, Sep 05, 2007 at 04:26:04AM -0400, Len Brown wrote:
> cpufreq_set_policy() doesn't match Nokia's needs as it is a 1-way
> notification, and there is no way to register constraints.

Could you elaborate a bit on this? cpufreq_update_policy() and
cpufreq_register_notifier() allows to register constraints, and then you can
use cpufreq_update_policy().

Best,
	Dominik

Re: cpufreq-set problems [Was: Re: Ottawa Linux Power Management Summit, June 25-26, 2007 - Minutes]

[Igor Stoppa]

Hi,
On Sun, 2007-10-28 at 14:54 +0100, ext Dominik Brodowski wrote:
> Hi,
> 
> On Wed, Sep 05, 2007 at 04:26:04AM -0400, Len Brown wrote:
> > cpufreq_set_policy() doesn't match Nokia's needs as it is a 1-way
> > notification, and there is no way to register constraints.
> 
> Could you elaborate a bit on this? cpufreq_update_policy() and
> cpufreq_register_notifier() allows to register constraints, and then you can
> use cpufreq_update_policy().

we are using update policy, but the problem with the notifications as
cpufreq handles them, is that we wanted to have a specific sequence of
operations been done, while (if i'm not wrong) the cpufreq notifications
do not provide this feature.

Probably this is not really needed for traditional x86 systems, while
SoC allow to know at design time what sort of devices will be present in
the system.


-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)