Rockbox Development > New Ports
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...
--- Quote from: kugel. on May 23, 2009, 01:44:55 PM ---At 62MHz, we're probably limited by the 31MHz of the CPU, as there was no increase at all.
--- End quote ---
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...
--- Quote ---Making it dependent on the cpu frequency (i.e. 62MHz while boosted, 31MHz while not) isn't exactly trivial.
--- End quote ---
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.
--- Quote ---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).
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version