UCLK

[Joerg Reisenweber]

Am Do  28. August 2008 schrieb Cesar Eduardo Barros:
> Andy Green escreveu:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Somebody in the thread at some point said:
> > | In a message from Ben Dooks on linux-arm-kernel about cpufreq, he said:
> > |
> > |  > > - My patches have code to use hardware flow control to "pause" the
> > |  > > serial ports during frequency transitions, so as to not confuse the
> > |  > > GTA01 GSM modem (or Openmoko's gsmd).
> > |  >
> > |  > That is useful for designs that forgot to provide a stable UCLK to
> > |  > provide UART baud clocks... all of the ones that I've had a direct
> > |  > hand in working on feed back or feed in an external known (and 
stable)
> > |  > clock.
> > |
> > | It might be worth considering this on future designs (looking at the
> > | schematics, GTA01 uses the pin for something else, while GTA02 doesn't
> > | connect the pin at all).
> > 
> > It's a good point, it would help the UART continuity during clock
> > change.  But it means adding an oscillator somewhere?  There's a PLL
> > from the Wolfson we could maybe use.
> 
> A possible trick would be to route the output of the USB PLL to a pin, 
> and have a trace linking that pin to the UART external clock. The USB 
> PLL isn't affected when the main PLL changes (or at least shouldn't be).
> 
> For the GTA02, for instance, that would mean a trace between 
> UEXTCLK/GPH8 and CLKOUT1/GPH10 (which would also allow several other 
> options besided the USB PLL). Both pins are free on the GTA02, but I 
> don't know if routing that trace would be easy (especially considering 
> the trace would be carrying a 48MHz signal).
> 
> For a USB clock of 48MHz, that would give us a UBRDIV of 25 for 115200, 
> which feeding the formula in the reverse results in a baud rate of 
> 115385, an error of 0.16% (unless I made a mistake on the calculations). 
> This is less than the about 1.87% where things start having problems.
> 
> Of course, even with all that it would still be a good idea to "pause" 
> the flow control during the PLL lock time to avoid a buffer overrun, but 
> the AFC might be able to do it automatically for us. The problem avoided 
> by using a stable clock is mainly the frequency changing (or the clock 
> stopping) in the middle of a byte.

Sounds very attractive, and stopping clock in midst of an inbound byte is an 
absolute NoGo for e.g. GSM-TTY. To avoid this we had to assert flow control 
to stop, and then delay for the maximum time to take effect of this. This 
delay slows down clock rate changes considerably.
Probably routing of a 48MHz signal from one pin of CPU to another is no issue 
(if we care for decent shielding of this trace ;-). However we can't do this 
for devices prior to GTA02A8 (A7 maybe), for obvious reasons. So sw would 
have to check for hw-revision (once again ;-).

Should we try to set up a ECN demanding future (GTA02) devices to have this? 
Andy? Werner? I consider engineering risk very low, as we always may fall 
back to current scheme.

cheers
jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/hardware/attachments/20080828/65b158e4/attachment-0001.pgp