cpufreq on ARM - 2.6 problem

cpufreq on ARM - 2.6 problem

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: cpufreq on ARM - 2.6 problem

[Dominik Brodowski]

On Tue, Sep 02, 2003 at 06:21:59PM +0100, Russell King wrote:
> 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.

[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

Re: cpufreq on ARM - 2.6 problem

[Russell King]

On Tue, Sep 02, 2003 at 10:04:51PM +0200, Dominik Brodowski wrote:
> 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.

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html