[maemo-developers] Internet Tablet Power Management presentation from linux-pm summit 2007

[From: Igor Stoppa]

On Wed, 2007-07-11 at 10:08 +0200, ext Frantisek Dufka wrote:
> Thanks Igor, it is quite interesting. Maybe there is a bug on page 15 
> with DSP frequency for OP 0, shouldn't the 133 be 233 or 333 (unless you 
> need to slow it down because of speeding up the arm core to meet some 
> power requirement)?

No, no bug unfortunately, simply TI doesn't support the combination with
DSP @ 266 MHz (that would be the proper value).
Of course ymmw and some chips probably can cope with it (actually there
are also thermal issues so i bet that most OMAPs can do it at room
temperature) but in order to provide a certain yield value, the
constraints on the operating range are stricter.

I certainly will run my tablet at higher speed and/or lower voltage;
finland makes it unlikely to incur in heating problems ;-)

> Does it mean the arm core in current N800 can run at 
> 400Mhz?

Yes, the data is for stock N800 (we have this SpeedSorted OMAP2 that can
run with ARM @ 400MHz).

> As for dynamic voltage and frequency scaling did I understood it 
> correctly that even if lower voltage means considerable saving (even if 
> task runs longer) it is almost not worth the hassle due to other issues 
> (latency of voltage/frequency change, static power consumption of other 
> parts, hard prediction of future)?

It just means that the whole system must be considered, not only the
processor. But we do have significant benefits at using the lower OP in
many cases.

It could be that there are benefits at using OP3 simply because of
problems in the current implementation of the sw stack, so fixing them
would make DVFS less attractive.

But while we get all the issues fixed, DVFS seems to help, for example
in reducing boot time and applications load time.

>  Or how big savings do you expect 
> overall from voltage/frequency scaling when the device is mostly idle 
> (i.e being mostly waken up by inefficient system or apps waiting for 
> something and not hogging the CPU). Or maybe the question is how 
> efficient is the system currently, is there something like 
> http://www.linuxpowertop.org/ for omap to see what can be improved or 
> what cannot and could benefit from lower frequency/voltage?

Yes, eventually our goal would also be to provide users with means to
evaluate themselves 3rd party applications.

I remember several times somebody complaining about battery life after
installing some 3rd party application that had not gone through our
validation process. Not that I'm really blaming the developers: one can
do code review up to a certain point, but without proper tools it's hard
to evaluate how pm friendly a caertain application is.

> Do you plan to have user selectable power/speed profiles to let people 
> choose whether they want slower system or shorter battery life?

My personal belief is that the user should not have to care about this:
something is broken if the user has to be involved. The system should
have all the info (and means) to run at good enough speed when needed.

It's a similar case to sleep while idle vs user-controlled suspend: just
because old devices were doing suspend that doesn't make it desirable.

>  Or do 
> you suppose there will be good enough cpufreq governor so it is not 
> needed. 

On demand should fit the bill, with some fixes. Conservative is useles
sfor every practical application, in our case.

> Or do you consider some API so apps can suggest how fast system 
> they want (i.e. media players, games, emulators vs book readers)?

You mean QoS. Yes, that seems to be the general understanding.
Intel too is going in that direction and they have very serious problems
when comparing their hw against OMAP, which is designed from ground up
to be pm friendly.

OMAP2 has retention mode and the transition to/from retention is much
faster than any OP change, so race-to-idle is more important on OMAP
than on x86 devices.

I would expect Intel to get QoS usable before us because of a more
urgent need.

-- 
Cheers, Igor

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