Re: [Gumstix-users] Frequency scaling

[Craig H. <cr...@hu...>]

On Apr 10, 2005, at 9:28 AM, Darren Gibbs wrote:

> I've experimented with other frequencies by hacking u-boot.  Here's a=20=

> list of possibilities I grabbed from somewhere in the source tree but=20=

> I can't remember where right now:
>
> /* Use the run mode frequencies for the CPUFREQ_POLICY_PERFORMANCE=20
> policy */
> static pxa_freqs_t pxa255_run_freqs[] =3D
> {
>     /* CPU   MEMBUS  CCCR  DIV2*/
>     { 99533,  99533, 0x121, 1}, /* run=3D 99, turbo=3D 99, PXbus=3D50, =
=20
> SDRAM=3D50 */
>     {132710, 132710, 0x123, 1}, /* run=3D133, turbo=3D133, PXbus=3D66, =
=20
> SDRAM=3D66 */
>     {199066,  99533, 0x141, 0}, /* run=3D199, turbo=3D199, PXbus=3D99, =
=20
> SDRAM=3D99 */
>     {265421, 132710, 0x143, 0}, /* run=3D265, turbo=3D265, PXbus=3D133,=20=

> SDRAM=3D133 */
>     {331776, 165888, 0x145, 1}, /* run=3D331, turbo=3D331, PXbus=3D166,=20=

> SDRAM=3D83 */
>     {398131,  99533, 0x161, 0}, /* run=3D398, turbo=3D398, PXbus=3D99, =
=20
> SDRAM=3D99 */
>     {398131, 132710, 0x1c3, 0}, /* run=3D265, turbo=3D398, PXbus=3D133,=20=

> SDRAM=3D133 */
>     {530842, 132710, 0x163, 0}, /* run=3D531, turbo=3D531, PXbus=3D133,=20=

> SDRAM=3D133 */
>     {0,}
> };
>
> I've tried 0x163 (531/133) on a 400MHz gumstix which didn't work,=20
> although Craig has reported being able to run a 200MHz gumstix at 531=20=

> with no obvious problems.  I've been using 0x143 (265/133) on 200MHz=20=

> gumstix which works great.
>
> Craig has mentioned that changing the frequency at runtime is=20
> problematic: " [it] has some negative consequences for some peripheral=20=

> devices sometimes, due to an errata in the Intel CPU, but can work in=20=

> some circumstances if the consequences are understood."
>
> You may be able to learn more from searching the mailing list =
archives.

I have modified the 2.6 cpufreq driver to speak PXA255.  But there is=20
an erratum in the PXA hardware which makes switching CPU frequencies at=20=

runtime problematic.  It tends to work OK if you don't do it very=20
often, but definitely will bite you fast if you use a governor like the=20=

ONDEMAND one which switches frequencies very often.  The erratum is=20
this:

26. Indeterminate results may occur in certain peripherals during a=20
Frequency
change if they are active
Problem: Indeterminate results may occur in certain peripherals while=20
transmitting or receiving data during a
frequency change sequence.
Implication:
Workaround: If the operation of these peripherals would be adversely=20
affected, then these peripherals would have
to be disabled during a frequency change.
=95 MMC
=95 FFUART
=95 STUART
=95 BTUART
=95 IrDA
=95 SSP
=95 UDC
=95 AC97
Status: No Fix


What this means in practice is that if you dynamically change CPU=20
frequencies, a lot of drivers will have the hardware state change from=20=

under them -- often this means they break unrecoverably.  For example,=20=

the pxa-ac97 audio driver will have all its volumes reset to 0 in a way=20=

which can't be recovered by aumix -- you have to unload the driver then=20=

reload it to fix this.  But you can't unload the driver iirc because=20
some other register's state has changed there too, and the driver=20
errors while unloading.  So you have to unload, then switch CPU freq,=20
then reload.  Works OK with userspace governor, since you can control=20
when the cpufreq switch happens to some degree.  Doesn't work so good=20
with the automatic frequency changing, since they're not hookable to=20
call your "unload these drivers then reload them" script.  Similarly,=20
the HCI state dies if you have the bluetooth modules loaded during a=20
freq change.  Probably other drivers will similarly fail oddly.

C=