FS#9800 - Zero-wait boost for PP502X

Attached to Project: Rockbox
Opened by Björn Stenberg (zagor) - Wednesday, 14 January 2009, 23:01 GMT
Last edited by Marcin Bukat (MarcinBukat) - Sunday, 05 June 2011, 11:22 GMT
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System PortalPlayer-based
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The same thing as  FS#9797 , but for PP5022 and PP5024.

Frequencies used are 20 MHz and 80 MHz.

Applicable targets: C200, E200, HDD1630, Ipod Mini2g, Ipod Nano, Ipod Video, SA9200.
This task depends upon

Closed by  Marcin Bukat (MarcinBukat)
Sunday, 05 June 2011, 11:22 GMT
Reason for closing:  Out of Date
Additional comments about closing:  We doesn't gain much with current power management implementation.
Comment by MichaelGiacomelli (saratoga) - Thursday, 15 January 2009, 00:16 GMT
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.
Comment by Andree Buschmann (Buschel) - Thursday, 15 January 2009, 06:19 GMT
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.
Comment by Björn Stenberg (zagor) - Thursday, 15 January 2009, 07:40 GMT
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.
Comment by Andree Buschmann (Buschel) - Thursday, 15 January 2009, 08:15 GMT
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 */

Comment by Johannes Linke (Jaykay) - Saturday, 17 January 2009, 16:08 GMT
this patch doesnt change the runtime. i made a bench with .ogg ~256 kbps on e200. without patch: 18:03, with patch: 18:05.
Comment by MichaelGiacomelli (saratoga) - Saturday, 17 January 2009, 16:25 GMT
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.
Comment by Johannes Linke (Jaykay) - Saturday, 17 January 2009, 16:33 GMT
kugel aid i would need something that runs boosted. ill do the same for mp3 ;)
Comment by MichaelGiacomelli (saratoga) - Saturday, 17 January 2009, 16:36 GMT
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.
Comment by Johannes Linke (Jaykay) - Sunday, 18 January 2009, 22:16 GMT
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,
Comment by Dave Hooper (stripwax) - Sunday, 02 August 2009, 11:21 GMT
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.