cpufreq on ARM - 2.6 problem

Hi,

There seems to be a problem with cpufreq on SA11x0 platforms when resuming. The effect seems to be a hang. I suspect that this is caused by the cpufreq resume method being a sys device (and therefore called with interrupts off). It sets the CPU clock rate, which in turn calls the transition notifier, which might (and does) sleep.

(of course, all this happens when the serial console is disabled because its a device not a sysdevice, so getting debug out of the system is nigh on impossible.)

I'm not sure what the right way to handle this is, and still ensure that all drivers have the right settings for stuff like SDRAM and LCD timings.

I'm also concerned that the backport of 2.6 stuff to 2.4 may introduce the same problem into 2.4 kernels.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[cc'ed Pat for his knowledge of sysdevice handling and of the suspend/resume process]

AFAICS, the following two things can occur:

pre-suspend early during resume
1.) frequency: A frequency: A -- all notifiers, the CPUfreq core,
all drivers think[*] the CPU frequency equals A, it is A, so we don't need to worry about anything.

2.) frequency: B frequency: A -- the CPUfreq core and all
(external) drivers think[*] the CPU frequency is equal to B, but it is A. Because of this, the CPU speed must be set AS SOON AS POSSIBLE to B. But as all other pieces of kernel code think it still equals "B", there is no need to call notifiers. The irqs_disabled() check in cpufreq_notifiy_transition() is triggered and blocks the call to the notifiers.

So, [as long as you use the latest 2.6.0-test4 source] I doubt that it is a hang in the cpufreq transition notifiers as they are never even called.

Dominik

In which case, its probably this in cpu-sa1110.c:

        /*
         * The clock could be going away for some time.  Set the SDRAMs
         * to refresh rapidly (every 64 memory clock cycles).  To get
         * through the whole array, we need to wait 262144 mclk cycles.
         * We wait 20ms to be safe.
         */
        sdram_set_refresh(2);
        set_current_state(TASK_UNINTERRUPTIBLE);
        schedule_timeout(20 * HZ / 1000);

then. I guess we need to case this with irqs_disabled() and use mdelay instead. Grr.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html