This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#8668 - battery runtime: experimental gui boost
Attached to Project:
Rockbox
Opened by Andree Buschmann (Buschel) - Saturday, 01 March 2008, 14:45 GMT+1
Last edited by Andree Buschmann (Buschel) - Sunday, 13 November 2011, 19:04 GMT+1
Opened by Andree Buschmann (Buschel) - Saturday, 01 March 2008, 14:45 GMT+1
Last edited by Andree Buschmann (Buschel) - Sunday, 13 November 2011, 19:04 GMT+1
|
DetailsWe could take this kind of "quick-and-dirty" solution as a starting point for further work on GUI boost for iPod's.
The attached patch does the following: - returning BUTTON_SCROLL_BACK/BUTTON_SCROLL_FWD out of scrollwheel driver (which was missing before) - boost CPU on each received button and unboost after 1s, if the were no further button events This patch should work for all iPod's with a 4G scrollwheel for now. 
gui_boost_v01.patch
(2.4 KiB)
firmware/target/arm/ipod/button-clickwheel.c | 4 ++- firmware/drivers/button.c | 35 +++++++++++++++++++++++++++ 2 files changed, 38 insertions(+), 1 deletion(-) |
This task depends upon
Closed by Andree Buschmann (Buschel)
Sunday, 13 November 2011, 19:04 GMT+1
Reason for closing: Accepted
Additional comments about closing: Reworked to use timeout API, submitted with r30975.
Sunday, 13 November 2011, 19:04 GMT+1
Reason for closing: Accepted
Additional comments about closing: Reworked to use timeout API, submitted with r30975.
Remark 1: mpc-playback without WPS needs ~26.5MHz. With this patch the runtime is about 14.5h (svn = 14h).
Remark 2: flac-playback without WPS needs ~15MHz. I hope to see runtime >16h with this patch -- measurement will follow.
Remark 3: This patch is just to get an impression of the gui boost and to go ahead for the maximum possible runtime, it does not take any care about plugin-behaviour. This patch is no svn-candidate.
Remark 4: Should also work for non-iPod PP-targets.
--------------------------------------------------
Battery bench results with gui boost (@15MHz) and disabled lineout (details attached):
MPC:
overall = 14:24h
90%-10% = 12:09h
FLAC:
overall = 12:46h
90%-10% = 11:10h
FLAC saves a lot of current via very low CPU-usage (~4mA vs. MPC), but needs a lot of additional current for the buffering from HDD (~7.5mA vs. MPC).
--------------------------------------------------
Attached a 3rd version of gui boost with 24MHz normal clock -- as this seems to be more effective than running @15MHz normal clock (gui_boost_v03.patch).
MPC:
overall = 14:42h
90%-10% = 12:31h
(for a 5.5G 30GB of course)
Let me know!
I hope this is helpful, let me know if you want any more tests run.
From discussions on irc the solution provided here is not wanted in svn. Until there has a proper solution been found, I will just keep using this implementation as I am not experiencing any issues with gaming (I just never used games :)
I have updated the patch against r20076. Patch v6 uses 100MHz maximum clock for PP5022/24 and keeps 80MHz for PP5020. As this runs stable on my 5.5G for >1 year now I do not expect any drawbacks. Main advantage is faster buffering which may save some power on the HDD-targets.
Also, it's a total pipe dream, but I totally wish there was some sort of advanced mode for rbutil that you could feed patches. I don't mind the process terribly, but it's a process nonetheless.
Thanks again!
Other discussed approaches try to boost the CPU each time an update of the display (drawing) is taking place. Doing so will need seemless clockswitching (no sync time for PLL) to be able to boost/unboost several times per second. Nevertheless I do personally not like this idea as I expect rockbox to waste power for unneeded boosting: e.g. WPS-updates run smooth @24MHz, but they will be boosted then. Therefor rockbox would need to use a very low normal clock (<24MHz) which allows the codecs to use such boosts for buffer filling -- otherwise the boost for e.g. WPS-updates come on top of the codec boosts. But very low clocks (I have done runtime measurements with 15MHz, see above) seem to be less efficient in terms of mA/MHz.
Either way, I'll probably make use of this patch for a while. I appreciate it.
I like the idea though of having the overclocking being used when drawing is occuring, that would most likely help with the overall smoothness of games and the OCing of the just the general screen!
There are some discussions going about alternative solutions for gui boost -- like boosting while drawing.
I hope the attached 80MHz-version is patchable (cannot test at work). Otherwise I'll update in a few hours.
The version using current_tick does not appear to fix the issue.
Since I've applied also the piezo click
FS#5111, I ear a double piezo click for each movement.The cursor movements still remain correct.
I hear some clicks while listening quiet pieces(with few bands of eq enabled)
I suspect it is generated while it is doing underclocking.(no clicks when it plays flac with constant 24MHz)
Debug screen shows no trace of buffer underrun.
Just amazed no one has noticed that.
- You do not hear such clicking when using the standard build (30/80 MHz)?
- You assume to hear the clicking when the clocks are changing and not when the clock is unboosted?
This patch disables the PLL when underclocking. Are sure that this clicking does not happen with svn (30/80 MHz) and you are sure svn is also chaning the clocks while playback? If so this might be a hint.
Altered boost_state rapidly to 1-0-1-0-... heard no clicks with 24-100MHz.
My conclusion: No hardware related issue with extended frequency range nor PLL noise
but the buffering thread priority has some problem so standard 30MHz also has audible click and because of lowered clock(24MHz) it happens more.
I'll update if I find more.
Has anybody an idea about if this is correct?
Thanks for any hint.
https://github.com/jdgordon/rockbox/tree/gui_boost_on_wheel
edit: this unboosts on the BUTTON_REL event so happens as soon as the user stops moving the wheel. the video feels much less sluggish with this patch compared to svn
IIRC the origional idea for gui boosting was to always boost on input which this doesnt exactly solve (if this is joined with lowering the default clock speed), but this does make my video much nicer to use
Another question: To which targets should HAVE_GUI_BOOST_ON_WHEEL be added? All targets with HAVE_SCROLL_WHEEL?
The wheel ipods for sure need it, I don't remember the e200 or fuze needing it.
- the define is called HAVE_GUI_BOOST to not have this limited to scroll wheel targets
- added this define to all iPods with a 4G keypad
A grep through the code shows various potential trouble spots. One example is the list of lines in the text_editor plugin, at "button = rb->get_action(CONTEXT_LIST,TIMEOUT_BLOCK);". I confirmed the problem using a patch (attached here) which prints characters when boosting and un-boosting. To reproduce, run the text_editor plugin, and scroll. You'll see the B when you scroll, unless already boosted, and you'll see the X when you press play while boosted, after the timeut expires.
I have 2 ideas for a possible solution:
- the first timeout could be limited to the remaining boost time, and after unboosting a second call could be made if necessary.
- do timeout based un-boosting elsewhere, such as a tick task
Because of this it's impossible to unboost from get_action_worker. (My first idea in the last post won't work.) The timeout API seems appropriate here. I wonder if that requires use of a mutex in gui_boost when tick tasks are happening on the COP.