[maemo-developers] Frequencies scaling with OS2008

[From: Igor Stoppa]

On Mon, 2007-12-31 at 12:52 +0000, ext Simon Pickering wrote:
> >> It is interesting if it is possible to lock ARM/DSP frequency at 400/166
> >> instead of 330/220 when playing video. That would probably improve
> >> built-in player performance on some heavy bitrate/resolution videos.
> 
> Would this be possible then? What knocks the CPU speed down when the  
> DSP is used (or rather when a music file is played)?

A dsp task loaded changes the cpufreq policy, so that the only allowed
frequency for ARM is 330

Having the audio path open, but no dsp tack loaded (arm audio) sets the
clock to 400MHz.

>  The media player  
> presumably? Assuming it is the media player that makes the change, I  
> presume that mplayer should run at 400MHz all the time?

If mplayer is not using any dsp codec, it should already be in such
case.

> > Sadly, because of DSP sw issues, little power saving is possible when
> > the DSP is running (ARM can still go to idle and most of the processor
> > can have its clock gated, but it's not possible to reach OMAP
> > retention). It would be nice to have the DSP able to sleep between
> > frames; the time taken to decode an mp3 frame is significantly shorter
> > than the related playback.
> 
> Presumably the background IDL thread implements power saving functions  
> and is present in the dsp kernel? What actually prevents the DSP from  
> sleeping between frames? 

Far from optimal design.

In other word there has not been enough commitment to push the sw
envelope so that it could actually leverage what the hw can do. The
current architecture met the (relatively relaxed) time requirement that
were set and therefore it didn't receive any further improvement.

> If the mp3 task is written using semaphores  
> around the data transfer/notification functions, shouldn't the task  
> yield to the background thread after it has decoded a frame and DMA'd  
> it to the audio codec hardware?

The mixer is still running and it has a significant timeout, iirc.
Also, 'm not so sure that the tasks are actually behaving so nicely.

I'm not really into audio, but if you try to decode some mp3 that
requires a lot of dsp time vs one that requires very little (silence?),
I'm almost certain that there will be no sigificant difference in terms
of power consumption.

It should be easy to verify with a large enough SD and some mp3
handcrafting skills (several copy & paste of the right type of data
should be enough).

-- 
Cheers, Igor

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