Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Battery/Charging
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by ahellmann - 2008-11-22
Last edited by Buschel - 2008-12-26

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

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.

Closed by  Buschel
2008-12-26 15:44
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.

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).

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.

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?

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.

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.

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!

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.

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing