[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
Date: Tue, 9 May 2017 18:09:39 +0100
From: Marc Zyngier <marc.zyngier@....com>
To: Eric Anholt <eric@...olt.net>, Phil Elwell <phil@...pberrypi.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Florian Fainelli <f.fainelli@...il.com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
bcm-kernel-feedback-list@...adcom.com,
linux-kernel@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org
Subject: Re: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
On 09/05/17 17:59, Eric Anholt wrote:
> Phil Elwell <phil@...pberrypi.org> writes:
>
>> In order to reduce power consumption and bus traffic, it is sensible
>> for secondary cores to enter a low-power idle state when waiting to
>> be started. The wfe instruction causes a core to wait until an event
>> or interrupt arrives before continuing to the next instruction.
>> The sev instruction sends a wakeup event to the other cores, so call
>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>> waiting cores during booting.
>>
>> It is harmless to use this patch without the corresponding change
>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>> and this patch is not applied then the other cores will sleep forever.
>>
>> See: https://github.com/raspberrypi/linux/issues/1989
>>
>> Signed-off-by: Phil Elwell <phil@...pberrypi.org>
>> ---
>> drivers/irqchip/irq-bcm2836.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>> index e10597c..6dccdf9 100644
>> --- a/drivers/irqchip/irq-bcm2836.c
>> +++ b/drivers/irqchip/irq-bcm2836.c
>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>> writel(secondary_startup_phys,
>> intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>
>> + dsb(sy); /* Ensure write has completed before waking the other CPUs */
>> + sev();
>> +
>> return 0;
>> }
>
> This is also the behavior that the standard arm64 spin-table method has,
> which we unfortunately can't quite use.
And why is that so? Why do you have to reinvent the wheel (and hide the
cloned wheel in an interrupt controller driver)?
That doesn't seem right to me.
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists