[PATCH 0/9] Experimental S3C2410A cpufreq driver
laforge at openmoko.org
Wed Feb 13 11:58:25 CET 2008
On Wed, Feb 13, 2008 at 12:16:38AM -0200, Cesar Eduardo Barros wrote:
>> Both Sound and USB derive their clocks from the UPLL, not the MPLL. USB
>> depends on a 48MHz clock in order to operate at all.
> There are two issues with the USB device in GTA01:
> - The datasheet for some reason says PCLK should be more than 20MHz
> - When I try testing cpufreq with USB plugged and try to change the
> frequencies via ssh over USB ("echo 202800 > scaling_setspeed"), the USB
> on the GTA01 locks up and only recovers after a reset. Setting the
> frequency with the USB unplugged and plugging it later (even if at a
> different frequency) works fine.
yes, this probably is related to lost clock cycles or other issues at
the time the PLL is reconfigured. It's probably worth for somebody with
a digital scope or even a spectrum analyzer to look at the 48MHz clock,
triggered by a GPIO that is set from the code just before reconfiguring
I'm not suggesting that you should be the one doing this, but I'm merely
stating that this would be my suggestion on how to debug this issue.
Werner has a ridiculous amount of experience debuging s3c24xx USB clock
related issues, so maybe he has some suggestions, too ;)
>> So unless we suspend to RAM, I think the UPLL should be kept running at
>> its original speed. cpufreq should only touch MPLL.
> It would be good for power saving reasons to turn the UPLL off if
> nothing is using it (bluetooth disabled, not connected to the host;
> GTA01 AFAIK cannot use UPLL for the sound).
I'm sorry, I must have mixed this up with a different SoC. Indeed, the
S3C2410A and S3C2442B cannot use the UPLL for the audio clock (which is
a pity, since 48MHz base clock would be great for typical audio clock
>> Please note that there are some intrinsic dependencies, i.e. the Samsung
>> docs state that you should not set only one of the two PLLs, but always
>> both together. I've ran into quite some strange problems.
>> Interestingly, for me setting the PLL's in the opposite order of what
>> samsung recommends worked better than the other way around.
> I don't recall seeing that on the datasheet; I will see if I can find
> something about that later.
I didn't find it again, either. So maybe it's a hallucination, or I
read it somewhere in a comment of samsung-supplied source code for their
usb ram loader :/ I'll check again.
> See s3c2410_get_transition_latency() and
> s3c2442_get_transition_latency(). Both try to find out how long will it
> take for the PLL lock time to pass (on GTA01 only to tell the cpufreq
> core the transition latency, on GTA02 also to know how long to wait
> after turning on the PLL before it can be used). However, the formula
> used is pure guesswork (I'm guessing it counts cycles from the 12MHz
I think this is the logical conclusion, since there is no other clock
during PLL reconfiguration.
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-kernel