Re: cpufreq on ARM - 2.6 problem

[Russell King <rmk@arm.linux.org.uk>]

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