From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: zynq: wfi exit on same cpu is valid
Date: Tue, 04 Jun 2013 15:25:08 +0200 [thread overview]
Message-ID: <51ADEAB4.8000702@linaro.org> (raw)
In-Reply-To: <51ADE701.5010000@monstr.eu>
On 06/04/2013 03:09 PM, Michal Simek wrote:
> On 06/04/2013 02:40 PM, Daniel Lezcano wrote:
>> On 06/04/2013 09:29 AM, Michal Simek wrote:
>>> On 06/03/2013 02:43 PM, Daniel Lezcano wrote:
>>>> On 06/03/2013 11:51 AM, Michal Simek wrote:
>>>>> Hi,
>>>>>
>>>>> On 06/03/2013 10:14 AM, Daniel Lezcano wrote:
>>>>>> On 05/31/2013 12:44 PM, Sanjay Singh Rawat wrote:
>>>>>>> The current code considers every wakeup as spurious, which is not
>>>>>>> correct. Handle the same way as other arm platforms are doing.
>>>>>>>
>>>>>>> Signed-off-by: Sanjay Singh Rawat <sanjay.rawat@linaro.org>
>>>>>> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>>>
>>>>>>
>>>>>>> ---
>>>>>>> arch/arm/mach-zynq/hotplug.c | 7 +++++++
>>>>>>> 1 file changed, 7 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/mach-zynq/hotplug.c b/arch/arm/mach-zynq/hotplug.c
>>>>>>> index c89672b..a1ab22c 100644
>>>>>>> --- a/arch/arm/mach-zynq/hotplug.c
>>>>>>> +++ b/arch/arm/mach-zynq/hotplug.c
>>>>>>> @@ -67,6 +67,13 @@ static inline void zynq_platform_do_lowpower(unsigned int cpu, int *spurious)
>>>>>>> dsb();
>>>>>>> wfi();
>>>>>>>
>>>>>>> + if (pen_release == cpu_logical_map(cpu)) {
>>>>>>> + /*
>>>>>>> + * OK, proper wakeup, we're done
>>>>>>> + */
>>>>>>> + break;
>>>>>>> + }
>>>>>>> +
>>>>> what pen_release stands for?
>>>>> I have looked at it and others platform are also using it in platsmp
>>>>> code which is not zynq case.
>>>>> How is it supposed to work and how this variable should be used?
>>>> This variable is used to serialize the secondary cpus boot process.
>>>>
>>>> When the processors boot, all the processors except the CPU0 are in WFI.
>>>>
>>>> Then it is up to CPU0 to wake up the secondary processors:
>>>> 1. it writes the cpu id of the secondary processor in the pen_release
>>>> variable
>>>> 2. it sends a IPI to the secondary cpu in order to make it exiting the
>>>> WFI mode
>>>> 2.1 the secondary processor boots and, when finished, writes the value
>>>> '-1' in the pen_release variable
>>>> 3. meanwhile CPU0 waits for the pen_release to be '-1' before continuing
>>>> to boot the other secondary processors
>>>>
>>>> In the case of the routine "zynq_platform_do_lowpower", the same
>>>> sequence occurs with 'cpu_up', that means you are at the beginning of
>>>> the boot up sequence. So the pen_release value is the cpu id value when
>>>> exiting from WFI (remember it sets to -1 when finished).
>>>>
>>>> If the cpu exits the lopower mode but the pen_release is not the cpu id,
>>>> that means there is something wrong because the cpu exited the WFI mode
>>>> without being in the booting process (the cpu shouldn't receive an hw
>>>> interrupt because they should have been migrated, but just a wake up
>>>> IPI). This is why there's "spurious".
>>>>
>>>> The pen_release contains the hardware id of the CPU, this is why
>>>> cpu_logical_map is used.
>>>>
>>>> I hope that helps
>>> Thanks for explanation.
>>> I have added this patch to zynq/cleanup branch.
>> Actually, I noticed in the boot secondary cpu the pen_release is not
>> initialized at all. The patch is correct but with undefined behavior.
> I know, it is not changed.
> __cpu_logical_map is initialized as 0 in setup.c
> pen_release as -1 in smp.c
>
>> Normally, the secondary cpu are powered on and stays in WFI or whatever
>> more power efficient but the algorithm is to initialize the pen_release
>> with the cpu id physical id, send an IPI and wait for the pen_release to
>> be equal to -1.
>>
>> There is a good example in mach-ux500/platform.c
>>
>> And a good explanation in the "Cortex -A Series programmer's guide" page
>> 23-10.
> Where exactly cpus are waiting in WFI loop?
When the cpu is booted, it runs the idle thread with its idle loop which
calls the cpu_do_idle (WFI).
next prev parent reply other threads:[~2013-06-04 13:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-31 10:44 [PATCH] ARM: zynq: wfi exit on same cpu is valid Sanjay Singh Rawat
2013-06-03 8:14 ` Daniel Lezcano
2013-06-03 9:51 ` Michal Simek
2013-06-03 12:43 ` Daniel Lezcano
2013-06-04 7:29 ` Michal Simek
2013-06-04 12:40 ` Daniel Lezcano
2013-06-04 13:09 ` Michal Simek
2013-06-04 13:25 ` Daniel Lezcano [this message]
2013-06-04 11:39 ` Amit Kucheria
2013-06-04 11:58 ` Daniel Lezcano
2013-06-04 14:10 ` Russell King - ARM Linux
2013-06-04 14:17 ` Russell King - ARM Linux
2013-06-05 9:34 ` Daniel Lezcano
2013-06-05 10:47 ` Michal Simek
2013-06-05 11:29 ` Russell King - ARM Linux
2013-06-05 12:54 ` Michal Simek
[not found] ` <OFF951DD26.F13B5CB1-ON48257B81.003EE068-48257B81.003F07FB@spreadtrum.com>
2013-06-05 12:07 ` Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51ADEAB4.8000702@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).