SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[funman]

MCI_CLOCK register is only changed after sd_init_card succeeded (to give maximal frequency = pclk) and in init_pl180_controller (which is only called once in sd_init(), and then at each sdhc card insertion)

So the frequency shouldn't change .. weird!

Did you check the hard value of the registers for nand & sd card, or only the frequency ?

[FlynDice]

This was one of the areas in debugclocks that I had to massage slightly to work but I think I got it right.  I used the following 2 defines for the registers which I beleive are correct for MCI_CLOCK:

#define MCI_NAND        *((volatile unsigned long *)(NAND_FLASH_BASE + 0x04))
#define MCI_SD          *((volatile unsigned long *)(SD_MCI_BASE + 0x04))

As ARM has taken the pl180 docs off their website I'm kind of feeling my way along here but the results seem to be consistent.  When there is no disk access going on(my assumption is that on disk access I get the pesky button light "feature") the registers show zero for dividers but when there is disk access there is a divider present and it shows the frequency as 405 khz.  As soon as disk access stops the divider is cleared to zero and the frequency shows PCLK freq.  When I tried to check things out in the code I couldn't find a place where the divider was reset unless perhaps MCI_CLOCK_BYPASS does this( no docs though....)

EDIT:  Oh one more detail to the setup that was partly working, the IDE frquency was set at 90 but showing 76 MHz

[funman]

I'll give you the pl180 docs I have later.

I identified a problem in MCI_* clock frequencies : if bit 10 is set : divide logic is bypassed and the resulting frequency is pclk.

Also we disable nand & sd modules when there is no transaction to save power : I believe the MCI_* value at this moment has no meaning.

Finally I think 405kHz value is a rounding error in divide function, because 62000000 / ((0x4c*2)+1) == 400000

[kugel.]

I'm playing a bit around with the DBOP clock.

test_fps showed that when I use 62MHz instead of 31MHz, the framerate noticeably increases. But only when the cpu is boosted too (e.g. 197 vs 246 fps). At 62MHz, we're probably limited by the 31MHz of the CPU, as there was no increase at all.

I'm doing a battery bench now (with caption backlight and 120s backlight timeout, so the backlight is on almost always and updates are not disabled). I hope to find that the dbop clock has no noticeable impact on battery life, so that we can run it always with 62MHz (we could still clock it low in lcd_enable). 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).

[daytona955]

The following are the out-pourings of a Rockbox noob - so feel free to take them with a pinch of salt...

At 62MHz, we're probably limited by the 31MHz of the CPU, as there was no increase at all.

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...

Making it dependent on the cpu frequency (i.e. 62MHz while boosted, 31MHz while not) isn't exactly trivial.

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 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).

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.

[kugel.]

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...

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.

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.

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 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.

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]

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.

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]

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.

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.]

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.

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".

[saratoga]

One thing I want to double check:  mkamsboot's output will only take on the target its made for right?  So you can't accidentally flash a V1 clip bootloader onto a V2?

Additionally, i've ordered an e200v2, which has easy access to the battery terminals, so I can make whatever power measurements people are interested in seeing once I get it.

[funman]

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.

EDIT: committed

Here are the plots (almost no difference for Fuze, except longer battery life with lower pclk)
For one test, my Clip wasn't fully loaded, but you can still see the difference.

[kugel.]

So, the difference between DBOP @62MHz and DBOP @15MHz (lower was not possible) is non-existent. Both give me 9h in my heavy test.

I opt for removing the divider.

[funman]

I opt for removing the divider.

Please just let me test on my Clip as well since the screen is different. That way we can make the change for all models.

[kugel.]

I also tested CPU @ 192/64 and PCLK@64 (just by changing clock-target.h for now) and get major speed ups in decoding and test_fps.