FS#10245 - AMSSansa Adjust Clocking Scheme

Attached to Project: Rockbox
Opened by Jack Halpin (FlynDice) - Monday, 25 May 2009, 21:26 GMT
Last edited by Rafaël Carré (funman) - Tuesday, 26 May 2009, 18:45 GMT
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I was having difficulty getting the clocking schemes correct while trying to test different configurations so I decided to make something that would be a little more convenient. For the most part you can make all your changes in the space of about 5 lines in clock-target.h. There are some changes in. This patch basically includes the synchronous clocking patch because I couldn't figure out how to do without it but it allows you to choose asynchronous mode if you desire to. I also made some cosmetic changes to debug-as3525.c while trying to test some things and included those also(made it easier to double check from the register values for me...). I hope it makes testing easier!
This task depends upon

Closed by  Rafaël Carré (funman)
Tuesday, 26 May 2009, 18:45 GMT
Reason for closing:  Accepted
Additional comments about closing:  kugel was ok
Comment by Thomas Martitz (kugel.) - Monday, 25 May 2009, 23:20 GMT
Are there other changes besides changing the scheme "style-wise"? It seems to change the clocking to cp@192/64 + pclk@64. I think we're going with that, but I'd rather have those changes separate.
Comment by Jack Halpin (FlynDice) - Tuesday, 26 May 2009, 00:06 GMT
You can change the PLL settings to whatever you can configure. I think the patch has 384MHz enabled and 248 MHz commented out. Add in another if you want it, you have to figure out the PLLA setting on your own though and tell it what FCLK, PCLK, and DBOP frequencies you want to run. If you choose a lower PCLK setting it should calculate the divider for you automagically..... The biggest difference from svn is the way the set_cpu_frequency() function is used. Most of the rest works just as before except organized a bit differently to make changing clocking schemes easier.
Comment by Thomas Martitz (kugel.) - Tuesday, 26 May 2009, 00:38 GMT
I just meant: I thought you want the patch in svn. And it's gonna get easier if a patch changes as small parts as possible. So, I'd like to have a change in the actual clocking separate from reorganizing the scheme.
Comment by Jack Halpin (FlynDice) - Tuesday, 26 May 2009, 02:21 GMT
"So, I'd like to have a change in the actual clocking separate from reorganizing the scheme."

If you're looking for something to go into svn take a look at  FS#10191  - AMSSansa Synchronous Clocking then. This patch is mostly what I came up with to make changing schemes for testing easier. I figured if it made it easier for me it might make it easier for someone else also so I should make it available. If it makes it into svn in some form that's fine but my focus was on making testing easier.
Comment by Jack Halpin (FlynDice) - Tuesday, 26 May 2009, 07:58 GMT
This version is mostly a small cleanup of comments I had left in which pertained to the last scheme I was testing. It also adds an automatic choice between synchronous and asynchronous bus depending on whether the FCLK frequency you have chosen is an integer multiple of the PCLK frequency you have chosen. I also have calculated and commented out the possible frequencies you can configure using the FCLK prediv and postdiv dividers for PLLA = 384MHz & 248 MHz.
Comment by Rafaël Carré (funman) - Tuesday, 26 May 2009, 10:50 GMT
If the patch makes testing easier, it should be committed for testers who use SVN

I have some remarks:

- can you remove inclusion of mmu-arm.h , and change comments in system-as3525.c (AS3525_PCLK_DIV1 << 6) | /* div = */ : feels a bit strange, I think the define name is explicit enough, and the frequency can be checked in clock-target.h
- round robin caching isn't related.
- clock selector = 3 = 11b isn't FCLK, but reserved !! You can only base a clock on clk_main (= 24MHz crystal) or on one of the 2 PLLs (we only use PLLA)

Also no need for I2SO mclk dividers, since those are based on the samplerate of the audio being recorded/played. If you want to do that we will need a table of dividers associated to some frequency (that would avoid some runtime calculation).
Comment by Jack Halpin (FlynDice) - Tuesday, 26 May 2009, 14:52 GMT
"- clock selector = 3 = 11b isn't FCLK, but reserved !!"

But it is FCLK for the one case of PCLK_SEL. For synchronous bus the input to the PCLK dividers is FCLK.

I took out the mmu-arm, comments, round robin cache, and I2SO/I out of this one.
Comment by Rafaël Carré (funman) - Tuesday, 26 May 2009, 16:27 GMT
sorry, didn't know about that (for CGU_PERI). Is there a difference here between using PLLA & FCLK as clock source ?

There's still an #include "mmu-arm.h" in ata_sd_as3525.c else the patch looks OK.

Also why using 192MHz as boosted cpufreq, does 248MHz work on your e200v2 ?

Before committing i'd like to test it on my Clip & Fuze.

Also : a big thanks for keeping the good work :)
Comment by Jack Halpin (FlynDice) - Tuesday, 26 May 2009, 17:55 GMT
Ok, I grepped the patch this time and no mmu-arm I promise....

I don't know that there's really a difference between using PLLA or FCLK as the source while using synchronous bus but in the diagram on page 101 of the datasheet there's a line running from FCLK output to PCLK_SEL labeled (sync mode). Perhaps even though the source origin is the same(PLLA), the phase may get shifted slightly going through the FCLK dividers? But then we are taking it through the PCLK dividers so why wouldn't that shift it also? No good answers from me. I'm guessing that the restriction on synchronous bus having FCLK as an integer multiple of PCLK stems from the fact that you use FCLK as the source and run it through an integer divider to make PCLK. I don't think FCLK _must_ be greater than PCLK, I bet it will work with both PCLK_DIV's == 0. I think the idea is that if you run FCLK=PCLK you may as well run fastbus and use the exact same clock signal for both the processor and the bus.

There is no real significance to the 192 Mhz boosted freq other than that's the spot I was at when it occurred to me that this may benefit everyone else and not just me! I've uncommented the 248 MHZ PLLA settings and adjusted the chosen frequencies to make a starting point with 248/62/62 which is closer to current svn at least.

The only differences for the fuze and clip was the DBOP clock setting in the lcd drivers.

Comment by Rafaël Carré (funman) - Tuesday, 26 May 2009, 18:39 GMT
That would obsolete  FS#10191  then.

Patch works fine on my Clip & Fuze.

kugel : are you ok for commit?