Zagor: It would potentially mean running boosted forever Which means running at high speed for maybe 30 secondsīut *if* we can do boosting almost for free, why even bother with timeouts? Saratoga: the only way to avoid that is to tie "timeout gui not in use" to backlight timeoutĪnd once I finish with MP3 it'll be more like 15% It's surely noticeable, but calling it a lot is exaggerating Unfortunatel the simple scheme wastes a lot of power on PP because of the GUI responisveness issueĪnd argueable we're already staving the GUI a little, I've seen people complain that my MP3 optimizations actually made the GUI worseĪmiconn: we could save 2 mA right now just by dropping the normal clock to 24MHz The i.MX31 is a different matter, as already mentioned I'd keep the simple 2-freq scheme on all targets with fixed core voltage. If the timeout on GUI in use is fairly long at least Normal and GUI not in use | Normal and GUI in use | and Boosted Saratoga: that would give strange variations in scroll speeds or updates of complex wps etc. Saratoga: ah, but that it does no matter how much other cpu use there is I think a pretty simple solution is to just make CPU_NORMAL depend on if the buttons have been touched recently
#Floola 2048 code
I just know that if the PCM buffer gets low, the CPU boostsĪmiconn: I agree that tagging code for boosting doesn't feel terribly simple/elegant either Saratoga: I can't find the "starve" boosting in playback.c. Zagor: Buschel, Toni and I proposed that, but people said we can't do that right now because the GUI and plugins become ugly I mean we waste more power every second right now by having a 30MHz normal clock then I'm proposing to waste for 5 or 10 seconds at a time I'd expect the version with 4096 byte sectors handled in rockbox to be considerably slower on 512-byte writes than the other I will post the result in a moment, I still have to do it at 80Mhz then we're boosting for fractions of seconds instead of 5-10. Saratoga: reduce average clockspeed and boost heavy code instead. I'm just saying we can skip updating the screen when backlight is off, hence not having to boost.īecause the normal clock speed can be reduced, and the average clock made lower overall I don't want clock speed tied to backlight. Zagor: properly implemented it can actually save power Saratoga: leaving it at heightened speed for several seconds doesn't sound very economicĪmiconn: I am testing the HD and it seems that changing the parameter to 4096 is twice as fast as if I comment the line I orginally proposed tieing clock speed to the LCD time out, but people thought that was clumsy as well Zagor: its been discussed using that logic too idle = turned off display = much less heavy work Yeah but we already have the backligt/display timeout for that. Hmm, in fact there's another thing: I don't know whether we need to do the core sync magic when using the divider for boosting. I was thinking change the normal CPU clock to maybe 40 or 45MHz and leave it there for 5-10 seconds Zagor: if the buttons are pressed then someone is probably looking at the screen though, so things like WPS updates should happen as fast as possible too 9 times out of 10, the idle state simply doesn't do many heavy things with "free" boosting, simply boost heavy things. Saratoga: I think using button timin feels a bit backwards. #rockbox log for 00:00 :11Ĥ5MHz would do just as well but use 11mA less currentīut there's another important point to consider: the i.MX 31 Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update. Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. The icon identifies that the person is a core developer (has commit access). #rockbox Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next dayĬlick in the nick column to highlight everything a person has said.
0 kommentar(er)
