Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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 FlynDice - 2009-05-25
Last edited by funman - 2009-05-26

FS#10245 - AMSSansa Adjust Clocking Scheme

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!

Closed by  funman
2009-05-26 18:45
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

kugel was ok

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.

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.

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.

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

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.

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

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

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

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.

That would obsolete  FS#10191  then.

Patch works fine on my Clip & Fuze.

kugel : are you ok for commit?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing