Rockbox Ports are now being developed for various digital audio players!
At 62MHz, we're probably limited by the 31MHz of the CPU, as there was no increase at all.
Making it dependent on the cpu frequency (i.e. 62MHz while boosted, 31MHz while not) isn't exactly trivial.
I don't think we should clock it as high as possible to gain maximum performance and to make the UI more pleasent (scrollwheel responsiveness also depends a bit on dbop).
Errm.. that implies PCLK > FCLK, which is not a legal combination, for asynch or synch clocking. Sadly ARM DDI0184B is silent about what punishment awaits those who violate this tenet...
If PCLK is 62MHz boosted & 31MHz unboosted, DBOP clock can have a divisor of 1 (or 0 if we talk about the value written to HW). I think that's fairly trivial . However, keeping the I2C clock constant is probably less trivial, but it's not clear to me if that is important. There is also the issue of fm_delay(), which is heavily dependant on CPU clock rate - again, I don't know whether it is important - but maybe it has something to do with the FM radio sometimes failing to work.
I find the wheel responsiveness is very dependant on on DBOP clock, especially when <~40MHz. That may be because I have an e260v2 rather than a Fuze. The e260v2 code sends 2x as many OS messages per wheel rotation. Each driver sends one message per 'wheel click'. But the e260v2 has 24 clicks/rotation, rather than the 12 of the Fuze. So the CPU gets hit harder in the e260v2 case for a given rotation rate.
changing the divider is trivial of course. But changing it dynamically with the cpu freq, plus making it dependent on the backlight (if we want it always clocked low without backlight) is not so trivial anymore.On the other hand, it may be much easier as I imagine, I haven't really looked into doing it since I'm waiting for the battery bench first.
I've found something that may make this seem undesireable though. In playing around with different frequency settings and observing the buffering thread I've noticed that the average MHz to play a .mp3 decreases very substantially when PCLK is higher. As an example with synchronous bus, FCLK 192, PCLK 64 for boosted, and fastbus FCLK=PCLK=64 for unboosted I get an average of 91MHz decoding an mp3, boosted 21% of the time. If I go to 192/48 I get 160 MHz to decode and boosted 78% of the time. At 192/38.4 it runs boosted(192MHz) at 100% and in fact sound starts dropping out because it can't keep up. I got similar results with FCLK at 248 and varying PCLK's . It seems with 248 though there's enough extra processor while boosted to keep sound going.
If we can check the status of the backlight I think it can be done very easily as part of the set_cpu_frequency() function used for boosting/unboosting. I think we could just check if the backlight is off and if so reset the frequency to normal/2 instead of normal.
mkamsboot should be made more intolerant.I think if you're not using the correct target, only a warning will be issued while it should abort.I also plan to make modifications of untested firmwares (unknown md5sum) fail, and if people want to test a new firmware they would have to modify the source.
I opt for removing the divider.
Page created in 0.586 seconds with 68 queries.