Rockbox

No issues on my Sansa e200v1. Playback works as expected and the GUI feels roughly the same.

Also, average CPU is below 30MHz, so I expect we're saving battery.

Just a few comments. When I played around with the clocks on my 5.5G iPod I experienced less battery runtime when using 12, 15 or 20MHz as default clock -- compared to 24MHz. Maybe the current consumption becomes non-linear in this area. Of course we will nevertheless get more runtime at 20MHz compared to 30MHz. This was using a codec which needed ~23MHz for decoding.

Another idea: Why not changing the boost clock to >80MHz for PP5022/24? My 5.5G is running at 100MHz since more than a year now. E.g. we could use 96/24MHz (or 100/20) for PP5022/24 and 72/24 (80/20) for PP5020. Doing so does not cost any runtime (expect for "boosted only" applications of course), but I allows a bit faster buffering.

Buschel: Did you use the PLL for 12/15/20 MHz clock, and straight 24MHz input for 24? I.e. could the PLL be the difference in power consumption?

The reason I boost at 80 is simply because the current code does, and I didn't know higher speeds were possible/stable. Naturally I would like boost to be as fast as possible.

In terms of current consumption it doesn't matter if you use the PLL or not for 24MHz. And yes, I used PLL for 12/15/20/24 MHz + 24MHz without PLL (the "#if 0"ed code in system-pp502x.c). Maybe someone can measure the current consumption with different clocks? I thought saratoga has the possibility to do so with his e200?

One example to be found in  FS#8668 , Battery bench with mpc codec:
1. normal clock = 24MHz: 90-10% runtime = 12:31h (total runtime 14:42h)
2. normal clock = 15MHz: 90-10% runtime = 12:09h (total runtime 14:24h)
The results are pretty clear.

Regarding the max clock: The maximum was limited to 80MHz because this is the specified max for PP5020 and there were problems on some PP5022/24-targets with higher clocks. We should check this again now.

100MHZ: //PLL_CONTROL = 0x8a021906; /* 100 MHz = (25/6 * 24MHz) / 1 */

this patch doesnt change the runtime. i made a bench with .ogg ~256 kbps on e200. without patch: 18:03, with patch: 18:05.

You won't see a run time improvement with Ogg since it needs more then 30MHz for real time decode. However, its good to see that theres no overhead associated with this boosting scheme.

kugel aid i would need something that runs boosted. ill do the same for mp3 ;)

No you need something that runs unboosted in the old system, such as MP3/FLAC/MPC, to see any improvement. If the codec already boosts like Ogg, AAC or WMA, then lowering the clock doesn't save anything.

how about this: 22:28 without this patch, 23:21 with this patch.

first bench done with r19396, second with r19772. when anybody thinks that i should do a bench with a clean r19772 for a better comparison, please tell me.
both benchs done with the same album, mp3 ~192kbps VBR,

It seems this causes clicks/pops (faint) when pressing buttons on ipod video 5g. As if the button boost action causes audio dropouts of a few samples.