[PATCH] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start
dianders at chromium.org
Tue Jun 10 08:21:59 PDT 2014
On Tue, Jun 10, 2014 at 1:12 AM, Chander Kashyap
<chander.kashyap at linaro.org> wrote:
> On 10 June 2014 04:08, Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:
>> On Mon, Jun 09, 2014 at 06:03:31PM +0100, Doug Anderson wrote:
>>> Cold boot and resume from suspend are detected via various special
>>> flags in various special locations. Resume from suspend looks at
>>> INFORM1 (0x10048004) for flags. This register is 0 during a cold boot
>>> and has special values set by the kernel at resume time.
>>> It also looks as if some code looks at 0x10040900 (PMU_SPARE0) to help
>>> tell initial cold boot and secondary CPU bringup.
>> Ok, thanks a lot. It looks like firmware paths should be ready to
>> detect cold vs warm boot, and hopefully do not rely on a specific
>> MPIDR to come up first out of power states.
>>> > I am asking to check if on this platform CPUidle (where the notion of
>>> > primary CPU disappears) has a chance to run properly.
>>> I believe it should be possible, but we don't have CPUidle implemented
>>> in our current system. Abhilash may be able to comment more.
> Cpuidle is implemented for exynos5420, and is tested on chromebook.
My S-state knowledge is not strong, but I believe that Lorenzo's
questions matter if we're using S2 for CPUidle (where we actually turn
off power and hot unplug CPUs) but not when we're using S1 for CPUidle
(where we just enter WFI/WFE).
I believe that in ChromeOS we use S1 CPUidle and that it works fine.
We've never implemented S2 that I'm aware of.
More information about the linux-arm-kernel