This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#7036 - Sansa: Increase battery runtime
|
DetailsIncrease battery runtime on the sansa e200 by:
1. enabling frequency scaling 2. shutdown of the lcd controller (if backlight off) 3. shutdown of the ata controller (if no diskaccess in progress) According to the current measurements the current is reduced from 65mA (current svn) to 45mA (patched) with mp3 128kB and medium volume. That means some more hours of runtime per battery cycle. In addition this patch includes the updated anti audio glitch patch. 
battery-optimized.diff
(7.7 KiB)
rockbox-optimized/firmware/export/config-e200.h | 4 rockbox-optimized/firmware/target/arm/pcm-pp.c | 4 rockbox-optimized/firmware/target/arm/sandisk/sansa-e200/ata-e200.c | 16 ++ rockbox-optimized/firmware/target/arm/sandisk/sansa-e200/backlight-e200.c | 12 + rockbox-optimized/firmware/target/arm/sandisk/sansa-e200/backlight-target.h | 1 rockbox-optimized/firmware/target/arm/sandisk/sansa-e200/lcd-e200.c | 65 ++++++---- 6 files changed, 76 insertions(+), 26 deletions(-) |
This task depends upon
Closed by Jonathan Gordon (jdgordon)
Saturday, 19 May 2007, 10:48 GMT+2
Reason for closing: Accepted
Additional comments about closing: cpu freq scaling wasnt accepted, but will be eventually..
Saturday, 19 May 2007, 10:48 GMT+2
Reason for closing: Accepted
Additional comments about closing: cpu freq scaling wasnt accepted, but will be eventually..
For patches to be included, they should have individual purposes.
But be aware, that you need the above full patch for better audio quality (no channel swapping, etc).
The previous posted anti audio glitch patch http://www.rockbox.org/tracker/task/6908 doesn't sync anymore with current svn.
So for ease better use the cumulative patch above. :)
This is a bit unclear to us on IRC. Does this patch depend on #6908? If so, perhaps you could separate these into multiple .patch files that could be independently tested? It seems to me the main complaint with 6908 (this may be incorrect), is that disabling those cache flushes had other side effects unrelated to what it was fixing. I don't see any obvious relationship between cache flushing and disabling the ATA controller and enabling frequency scaling. Perhaps these two issues could be put in seperate tasks so that they can be independently tested, and so that they are not bottlenecked with the cache flushing issue is examined.
having a look at the debug audio screen, the boost ratio is 50% (which should be fine, but its constantly boost-unboosting it) so I wonder if there is any real saving from enabling cpu scaling because of all the time spent switching?
and has been said, please split fs#6908 and update that patch separately.
50% boost means half of the time at 30MHz the half 75MHz, which leads to 50% of the time 45MHz corresponding to 11mA current saved.
So this is already a noticable reduction (5.5mA from 65mA => about 1hour more play time).
I checked your commits together with the 'battery-optimized-cleaned.diff' patch, which only reduces power consumption:
- still get those ticks and channel swapping (due to frequency scaling enabled)
- after a certain time the lcd display fades out (don't know exactly, wether this happened to the patch before)
I also checked your commits together with the 'battery-optimized.diff' patch, which reduces power consumption AND removes audio glitches:
- no issues found
Conclusion: The audio glitches are very obvious and the display is affected too, if frequency scaling is enabled. Currently, if you want good sound AND better battery runtime: 'battery-optimized.diff' patch is best. I will update patch #6908 for a not completely impossible inclusion in svn.
which commits are you talking about? the button change? that shouldnt affect anything.
It's perfectly ok, that the sansa switches permanently from boosted to unboosted. The boost itself should take around ~10ms, so if it switches at an interval of 2/sec, it is only 'wasted' 10ms from 500ms.
Ah, I thought you talked about your commits yesterday morning. I thought those did reduce the channel swapping.
Nice work!
I can't see any problem with these. If nobody beats me to it, I hope to get them committed this weekend (after testing them on my Sansa.)
Dan
Also, why do you only do lcd_enable(true) for non-bootloader builds?
lcd_enable() is only set for non-bootloader builds, because otherwise you get the bootloader text, which is not wanted me thinks.
If you apply the 'cleaned' patch be aware of the additional audio problems (without applying #6908).
This is why I am still for 'battery_optimized.diff'.
They don't call lcd_update to draw the text unless they encounter certain errors, or you hold down a button (usually the Right button).
The current svn bootloader is perfectly fine in that respect.
Now I have updated both patches, to work well with the bootloader and the application.
- removed the suspicious lcd_enable(true) from lcd_init (device is enabled already earlier)
- always indicate backlight on for the bootloader
For flawless audio playback also the updated anti-audio-glitch-resynced-update have to be applied.
MikeS: There is no special power saving treatment for the cpu/cop besides the frequency scaling.
LCD: 12mA
ATA: 4mA
CPU: 6mA
I think this can be closed. Except activating frequency scaling the ideas of this patch are now available in svn.