Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
kugel.:
--- Quote from: daytona955 on May 23, 2009, 02:47:31 PM ---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...
--- End quote ---
Our PCLK has always been 62MHz, and our CPU clock (FCLK) always varying between 248MHz and 31MHz depending on the state. I didn't know about the restrictions, but I haven't noticed obvious problems yet.
--- Quote from: daytona955 ---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.
--- End quote ---
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.
--- Quote from: daytona955 ---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.
--- End quote ---
However, the fuze and e200 equally call the dbop read function (the actual hardware polling) every half tick, no matter of how many messages are sent. And the e200 doesn't even ask the dbop if a lcd update is going, while the fuze still does. It doesn't have much to do with the messages sent.
However, below this 31MHz I have noticed badly decreasing wheel responsability too.
FlynDice:
--- Quote from: kugel. on May 23, 2009, 03:11:16 PM ---
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.
--- End quote ---
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.
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.
As it seems I have a penchant these days for proclaiming I have a solution to world peace and can demonstrate cold fusion in the lab would someone be so kind as to verify.... ;)
daytona955:
--- Quote from: FlynDice on May 24, 2009, 12:52:17 AM ---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.
--- End quote ---
Might this be due in part to the fact that the MPMC clock is derived from PCLK? So if PCLK is reduced from 64 to 48, and we leave unchanged the MPMC registers characterising the SDRAM (in terms of MPMC clock cycles), we are in effect telling the MPMC that the SDRAM is slower by a factor of 64/48...
I did try (in a patch in FlynDice's FS#10191) using PCLK_DIV1 to get a 62MHz MPMC clock and a 31MHz PCLK to avoid this, but RB failed to boot.
funman:
I've run battery_bench on my Clip & Fuze for 3 combinations:
* unmodified SVN : maximal battery life
* raise cpufreq_default & cpufreq_normal to 124MHz, synchronous : between 10% and 25% battery life decrease
* raise cpufreq_default & cpufreq_normal to 62MHz, synchronous, and lower pclk to 31MHz when unboosted: almost no battery life decrease, and even increase on my fuze
But I didn't test extensively performance.
From what I hear from you guys, it seem that we should use the maximal frequency for PCLK.
FlynDice : Did you run battery_bench when using fastbus for unboosted mode ? (fclk = pclk = 62MHz) ?
If there's not much loss I think this is the way to go.
I'll try to recharge my DAPs before going to work, so I can run the test and have the results for tomorrow.
kugel.:
--- Quote from: FlynDice on May 24, 2009, 12:52:17 AM ---
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.
--- End quote ---
But I don't think you want to call set_cpu_frequency when the backlight goes on and off? Or wait until the next boost toggle for updated dbop clocks?
Maybe it's not hard to do, but it's not exactly trivial as far as it seems to me.
EDIT:
PS: ~9h with playing 320kbit mp3 with backlight next to always on (plus another cpu consuming feature: crossfeed) and 62MHz dbop. Not bad at all IMO. Going to test lower dbop clock now.
PS2: I think maxing PCLK seems like a good thing to do as per FlynDice "messurements".
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version