FS#9570 - Sansa e200v1: Increased runtime by ~20%

Attached to Project: Rockbox
Opened by Toni (ahellmann) - Saturday, 22 November 2008, 15:11 GMT
Last edited by Andree Buschmann (Buschel) - Friday, 26 December 2008, 15:44 GMT
Task Type Patches
Category Battery/Charging
Status Closed
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This patch improves the runtime on flash based players with PP5022 and PP5024 (Sansa e200v1/c200v1) per battery cycle by about 20%. The average current at MP3 playback decreases from 34mA to 28mA. This could be achieved by powering off the SD controller when not needed and switching off the PLL at 30MHz. Only tested on Sansa E200v1 with no negative side effects.
This task depends upon

Closed by  Andree Buschmann (Buschel)
Friday, 26 December 2008, 15:44 GMT
Reason for closing:  Accepted
Additional comments about closing:  First part (SD) committed with r19194. Second part (clocking) must be combined with a kind of gui boost to keep gui fast enough.
Comment by MichaelGiacomelli (saratoga) - Saturday, 22 November 2008, 15:51 GMT
Hi Toni. Long time no see!

I will look into this tonight on my Sansa, but one question: Buschel played around with the PLL at 24 and 30MHz clock speed, and reported no improvement (though he tested via battery bench and not with a meter). I see you've basically enabled his old code. Did your tests show a difference? If so, how much?

Also, since you were interested in SD card support, have you seen recently  FS#8663 ? We still have occasional file corruption when writing to the SD card in rockbox (either copying between volumes or when in rockbox USB mode).
Comment by Toni (ahellmann) - Saturday, 22 November 2008, 16:17 GMT
The main improvement I got from disabling the SD controller (~4mA), switching off PP gave (<2mA).

Regarding  FS#8663  I have no idea. Is the remaining problem still the '2bytes inserted'? In one of my experiments I did move the USB buffers into IRAM (same as gevaerts did) and got no file corruption. I don't know, why he gave up with that idea.
Comment by MichaelGiacomelli (saratoga) - Monday, 24 November 2008, 03:59 GMT
I've committed the SD changes.

One question before I commit the PLL. The patch leaves the comment " /******** CPUFREQ_NORMAL = 24MHz without PLL ********/" in place, but I think that should be "30MHz without PLL" correct?
Comment by Toni (ahellmann) - Monday, 24 November 2008, 17:27 GMT
Yes, I simply copied the timing parameters from the 30MHz standard configuration and forgot to update the comment. I am wondering, what the PLL is good for. The 'of' also deactivates the PLL after startup.
Comment by MichaelGiacomelli (saratoga) - Monday, 24 November 2008, 21:50 GMT
I didn't realize you had SVN access when I committed that.

I don't remember the exact details but I believe the PLL is needed for clock speeds above some minimum value. Buschel or amiconn could probably give you a better answer.
Comment by Andree Buschmann (Buschel) - Friday, 28 November 2008, 21:32 GMT
Will check. I did my experiments a while ago, but I really thought my iPod wouldn't start then... 2mA saving would be a great improvement though!
Comment by Andree Buschmann (Buschel) - Friday, 26 December 2008, 14:40 GMT
Hmm, just reviewed the change of the PLL-stuff and the savings in current consumption again:

1. The mp3-decoder nows runs @22MHz on PP502x, but the lowest unpatched clock is 30MHz. So, we are waisting 8MHz which equals ~2-2.5mA (3MHz = ~1mA).
2. This patch enables the path for 24MHz (including the disabled PLL). The coded added in this patch configures the PLL, but the PLL is not used (as the clock source is still set to 24MHz). Therefor the change results in running the clock @24Mhz.
This perfectly explains the savings of ~2mA.

So, the changes in system-pp502x.c can be reduced to use "#if 1" instead of "#if 0" to activate the 24MHz clock.
Comment by Andree Buschmann (Buschel) - Friday, 26 December 2008, 14:50 GMT
As the 1st part of this patch (SD stuff) has been committed I think we can close this patch. Changing the clock will need a GUI speedup as the laggy HMI will become worse with switching to 24MHz.