[PATCH v2 11/12] cpuidle: mvebu: Add initial CPU idle support for Armada 370/XP SoC

Gregory CLEMENT gregory.clement at free-electrons.com
Mon Oct 14 10:14:12 EDT 2013


Hi Lorenzo,
[...]
>> +       if (index == MV_CPU_DEEP_IDLE)
>> +               deepidle = true;
>> +
>> +       cpu_suspend(deepidle, armada_370_xp_cpu_suspend);
>> +
>> +       cpu_init();
> 
> I do not think cpu_init() is needed. Either core resumes through
> cpu_resume, and there cpu_init() is called for you, or there is no
> reason to call cpu_init() since CPU was not shutdown.

You're right: I have removed it on the new version I have just sent.


[...]

>> @@ -0,0 +1,91 @@
>> +/*
>> + * CPU idle low level implementation for Marvell Armada 370 and Armada XP SoCs
>> + *
>> + * Copyright (C) 2013 Marvell
>> + *
>> + * Nadav Haklai <nadavh at marvell.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2.  This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + */
>> +#include <linux/linkage.h>
>> +
>> +
>> +/*
>> +* armadaxp_cpu_suspend: enter cpu deepIdle state
>> +* input:
>> +*/
>> +ENTRY(armada_370_xp_cpu_suspend)
>> +/* Save ARM registers */
>> +       stmfd   sp!, {r4 - r11, lr}     @ save registers on stack
>> +
>> +       bl armada_370_xp_pmsu_idle_prepare
>> +       /*
>> +        * Invalidate L1 data cache. Even though only invalidate is
>> +        * necessary exported flush API is used here. Doing clean
>> +        * on already clean cache would be almost NOP.
>> +        */
>> +       bl v7_flush_dcache_all
>> +
>> +       /*
>> +        * Clear the SCTLR.C bit to prevent further data cache
>> +        * allocation. Clearing SCTLR.C would make all the data accesses
>> +        * strongly ordered and would not hit the cache.
>> +        */
>> +       mrc     p15, 0, r0, c1, c0, 0
>> +       bic     r0, r0, #(1 << 2)       @ Disable the C bit
>> +       mcr     p15, 0, r0, c1, c0, 0
>> +       isb
>> +
>> +       bl v7_flush_dcache_all
>> +
> 
> This code looks familiar and the first cache flush is not needed.
> 
> look at arch/arm/mach-vexpress/tc2_pm.c -> tc2_pm_down()
> 
> I know that probably the SMP bit in ACTLR is managed differently in this
> architecture but still, cache flushing should still apply and the TC2
> sequence is the proper one, unless you explain to me why that does not
> work on this chipset.

Here we follow the advices you gave in your presentation at Linaro Connect
Q2-2012: "Idling ARMs in a Busy World: Linux Power Management for ARM
multi-cluster systems"
http://www.linaro.org/documents/download/84a5990d6f227c90e3d3a3ad2af0e22c4fd1d0bd4a6c7
at p21.

Quoting the author of the original version od the code :
"Since the second flush is almost NOPs, I preferred to keep them both in the same sequence."


> 
>> +       /* Data memory barrier and Data sync barrier */
>> +       dsb
>> +       dmb
>> +
>> +       bl armada_370_xp_disable_snoop_ena
>> +
>> +       dsb                             @ Data Synchronization Barrier
>> +
>> +/*
>> + * ===================================
>> + * == WFI instruction => Enter idle ==
>> + * ===================================
>> + */
>> +
>> +       wfi                             @ wait for interrupt
> 
> Here core is running out of coherency and I do not see any tlb invalidation in
> the resume path from non-OFF mode. Please can you elaborate on this ?
> 

The TLB invalidation should take place in /arch/arm/kernel/suspend.c  cpu_suspend( )
in case the return value is 0 caused by cpu_suspend_abort.
Did we missed something?

[...]
> 
> I have further comments on the set (in particular on the inner workings
> of coherency and how CPUs get in and out of idle - ie how this is
> managed by the power controller) but I will keep them for next version,
> when the first set of review comments is addressed.
> 

You can make your comments on the last version I have just sent.

Thanks for your review

Gregory
-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com



More information about the linux-arm-kernel mailing list