• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.2
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Jack Halpin - 2009-05-07
Last edited by Rafaël Carré - 2009-05-26

FS#10191 - AMSSansa Synchronous Clocking

While trying to get the mmu working correctly I managed to get a synchronous clocking scheme to work and thought I would post it for comments. This is probably more of a proof of concept type of thing but I figure it can’t hurt to test it out and see how it compares to the current asynchronous clocking scheme. I have left the assembler routines embedded in the .c code to simplify things and also enabled round robin caching.

Closed by  Rafaël Carré
2009-05-26 18:45
Reason for closing:  Duplicate
Additional comments about closing:  

 FS#10245  is more complete, and committed

Jack Halpin commented on 2009-05-10 00:44

When I tested the synchronous clocking setup I discovered it was faster than the current svn asynchronous so I cleaned it up a bit for version 2. I get a slight (10 MHz) improvement over svn with test_codec and a pretty substantial(40%) increase in fps with test_fps.

Dustin Skoracki commented on 2009-05-10 08:40

With the first patch I noticed that rb is not always booting (nearly every fifth boot failed) but with the new patch it works. I noticed some things:
- playing mp3 needs 40 to 50 MHz less than svn
- the “spacerocks-wheel-bug” ( is gone
- playback stops when starting pictureflow plugin (in svn pictureflow works with playback)

Jack Halpin commented on 2009-05-12 04:24

Playback works with pictureflow now. I believe that issue was not related to this patch. I have had exactly one instance of this not booting and it was with the microsd installed. It has booted normally every other time(probably close to 30 -40 times now).

Graham Hawkins commented on 2009-05-12 11:41

I’m probably missing something here - if so sorry :)
But if you dynamically change the PCLK frequency (in set_cpu_frequency), don’t you also need to dynamically change the divisors for the clocks that are derived from PCLK (I2C for example)?

Jack Halpin commented on 2009-05-12 16:49

No, you are most certainly not missing anything, that was also my thought initially but when I tried to adjust the other divisors I got strange results. My thinking is that all of the peripherals that are based off of PCLK get their initial divisor based on the 62MHz in clock-target.h. and the reference frequency we give them there. So when I run PCLK at half speed, all those peripheral speeds are now half speed which I believe is still within their frequency range. I never adjust PLLA so anything that is not clocked off of PCLK or FCLK should not change. That was my reasoning at least but I surely encourage you to tear it apart and improve it!

Graham Hawkins commented on 2009-05-13 10:09

I haven’t looked at the peripheral clocks yet. I was thinking about a slightly different strategy for sync clocking. I wondered about leaving the mode as sync for both normal and boost, and using PCLK_DIV1_SEL to take the PCLK from 62MHz to 31MHz while leaving the SDRAM clock mpmc_clk running at 62MHz. I’ve tried it on my e260v2 and it seems to work OK. What do you think? I’ve attached a patch.

Graham Hawkins commented on 2009-05-15 06:46

I have had a chance to try your patch and my suggestion back to back. Yours seems way more responsive when the FCLK is not boosted. So maybe mine is not such a good idea.. not sure why yet.

Jack Halpin commented on 2009-05-16 14:56

“Yours seems way more responsive when the FCLK is not boosted”

Well I figured it out.. Seems I’ve performed a bit of cold fusion here! I was adjusting the wrong divider for FCLK. Instead of dividing by it by 2 I was multiplying by 7/8. Hence the nice performance. Here’s a patch with the correct dividers or you can just change CGU_PROC |= (1« 2); to CGU_PROC |= (1« 4);

Graham Hawkins commented on 2009-05-16 15:19

Me also! «5 instead of « 6 when trying to adjust PCLK_DIV1_SEL. ‘Code in haste, repent at leisure’ - or something… It just crashes when I adjust PCLK_DIV1_SEL. Trying to work out why.

Graham Hawkins commented on 2009-05-18 08:29

Following my last ill considered patch - here’s one I thought about more carefully. I’m afraid it’s a bit untidy because of the compile time macros I used to test different clock configs.
I also used FlynDice’s synchronous_clocking_3.patch, and his very useful HW info patch from the forum AMS thread. I tested against SVN:20931.
I made some measurements of MP3 decode performance (boosted), and LCD update rates (unboosted). I’m interested in the latter because my e260v2 UI performance is a bit laggy, and I was interested in the least bad option.
Sync clocking seems to give ~5% increase in MP3 decode performance.
Sync clocking also seems to give ~25% better unboosted LCD update rates than fastbus, although the comparison might not be fair, since the sync option uses an FCLK/PCLK of 62/31MHz, but fastbus effectively uses the same 31Mhz for both. In anycase, it is worth changing the DBOP_CLK divisor for the unboosted state, as it gives a significant improvement to UI usability. Vanilla 20931 also gives similar UI performance, but the unboosted clock config seems to be illegal (i.e. async awith PCLK > FCLK).
My original scheme to have FCLK=MPMC_CLK=61MHz, PCLK=31MHz fails to boot. I need to read some more about the MPMC to understand why.
I have attached detailed results.

Graham Hawkins commented on 2009-05-18 08:32

“My original scheme to have FCLK=MPMC_CLK=61MHz, PCLK=31MHz” should read “My original scheme to have FCLK=MPMC_CLK=_62_MHz, PCLK=31MHz”

Rafaël Carré commented on 2009-05-18 14:43

in my previous tests, I could never boot with mpmc_clk != pclk.

It seems that the OF uses a 65MHz limit for mpmc_clk, but I’m not 100% sure since there is a lot of code related to pclk that I didn’t understand.

Rafaël Carré commented on 2009-05-26 10:39

Here is a patch which uses synchronous clocking when boosted, and fastbus when unboosted.

The battery bench comparison can be found at

Do you have objections for it going to SVN ?

Dustin Skoracki commented on 2009-05-26 15:28

The last patch is working very well:
- playing mp3 needs much less MHz (average about 75 MHz on my 128 kBit/s files and average about 115 MHz on my 320 kBit/s files)
- ui-responding is perfect


Available keyboard shortcuts


Task Details

Task Editing