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 <[EMAIL PROTECTED]> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
