GCLK at 25 MHz using NGW PLL1 ...

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm looking at a prototype where I need a 25 MHz clock, and it seems like it should be easy to get that using one of the GCLK pins. But ... how?

Clearly PLL0 output is no help; that's 130 Mhz on NGW, divide-by-5 gives "a bit too fast". OSC0 is at 20 Mhz (and OSC1 is at 12 MHz). So neither is directly useful, but it should be easy to put either one through PLL1 (unused!) and get a frequency that's an integer multiple of 25 Mhz. The GCLK can then divide that.

Now NGW docs say that the RC filter on PLL1 is tuned for 80 MHz if fed from OSC0 ... not helpful. But that's with PLLDIV=4 giving 5 MHz input to the multiplier stage ...

So my first question: is it "safe" to just use PLLMUL=20 to get a 100 MHz output, instead of the 16 on that webpage? Then divide-by-4 will be just right for 25 MHz. (And divide-by-8 gives 12.5 MHz, also useful.) I expect the answer here to be "yes".

Leading to second question: clk_set_rate("pll1", 100MHz) will fail ... is anyone working on (Linux) hacks to make setting PLL rates behave? I can just hack it together of course. But if my current understanding is correct, a general solution should be possible ... which adjusts PLLMUL with only concerns about output range, and might even be able to tweak PLLDIV if it knew the constraints from the relevant board-specific RC filter.

And the third: If I hook PLL1 up to OSC1 (currently unused), what frequency is that RC filter going to be aiming for? Still 5 MHz?? When PLLDIV=3 that gives 4 MHz (a good match for those RC values??), then PLLMUL=25 gives the same 100 MHz output so GCLK divide-by-4 (or 8) works. I'd run the PLL tool Atmel mentions, but it doesn't work in OpenOffice 2.2 and so I can't get help that way.

(Also: similar questions for STK1002 ... although there the webpage has goofed up PLL0 and PLL1, since clearly it's PLL0 that outputs 140 MHz. I think it's just MUL and DIV and Fout that got swapped. If the 100MHz number is correct, GCLK there should be easy.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can not change the PLL you clock the CPU clock from when running from that PLL.

I would alter the PLL in u-boot.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can change CPU core speeds through cpufreq, how does that work? I mean it can only switch between 140MHz and 70MHz so it isn't infinitely tunable, but it must be able to be done in theory, no?

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HCE: CPU runs from PLL0, not PLL1. And PLL1 is currently unused, so it can't matter much where it gets set ... that whole clock tree is unused, it can't affect anything! :)

Squidgit: Don't care about CPU clock, and in fact I'd rather keep it orthogonal. That's why I asked about PLL1 not PLL0. 10.5.4 says the requirement is f(CPU) >= f(HSB) >= f(PBA), and elsewhere recommends a 4:2:1 ratio ... so in theory those rates could go to 1:1:1 by updating CKSEL appropriately. Of course the trick is that updating f(HSB) also updates the memory clock, which can be tricky ... often the idea is to run code updating memory clock out of SRAM (or flash, at boot) so as not to complicate fetching the next instructions from DRAM ... ;) The reason the whole clock tree doesn't usually get reprogrammed, despite the bas synchronous clock being quite tunable, is that you'd need to reclock every peripheral that "knows" its input clocks. Not something kernel.org Linux allows today, but some other operatings systems have been known to do that (and even some custom embedded Linuxes). Reclocking turns out to be more of a PITA than it's worth in power savings.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, indeed, I guess I was more replying to hce than your original posting.

Going back to that original posting, yeah it shouldn't be too hard to write an appropriate set_rate function for the plls. To be completely safe, as you say, the function would have to have some board-level info regarding filter setups. This is ugly but at32ap7000.c already has the osc32k/osc0/osc1 rates hard-coded so it wouldn't be much worse than what's already there.

I haven't delved too deeply but PLL1 has no users in my kernel atm, nor does OSC1, so you should be fine [1].

-S.

[1] A few minutes ago David Brownell posted a nice clock-tree visualization patch for avr32 to lkml. I just built a new kernel, ran it on my stk1000 and verified that pll0 and osc0 are not used in my setup. patch attached if'n ya wanna eye over.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This (untested) patch might perhaps be what you need?

http://avr32linux.org/archives/k...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's along the right lines, thanks. Though it has obvious holes ... it ignores the details of the external low pass RC filter, which I suspect is not good. Plus I think set_rate() is supposed to be exact; if "near" is OK, round_rate() first to figure out what to do. I'll have a closer look later.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Squidget -- still can't download attachments here! Transitioning this machine over to Firefox, but it's not done yet. I like that debugfs patch, it's handy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how:

Mostly seemed to behave, though I've not yet checked the GCLK output pin. Attached see a patch I needed.

Attachment(s):