linaro-kernel-bounces@lists.linaro.org wrote on 2013-06-05 18:47:46:
From: Michal Simek monstr@monstr.eu To: Russell King - ARM Linux linux@arm.linux.org.uk, Cc: Lists linaro-kernel linaro-kernel@lists.linaro.org, Patch Tracking patches@linaro.org, michal.simek@xilinx.com, Lists LAKML linux-arm-kernel@lists.infradead.org Date: 2013-06-05 18:48 Subject: Re: [PATCH] ARM: zynq: wfi exit on same cpu is valid Sent by: linaro-kernel-bounces@lists.linaro.org
On 06/04/2013 04:17 PM, Russell King - ARM Linux wrote:
On Tue, Jun 04, 2013 at 03:10:17PM +0100, Russell King - ARM Linux
wrote:
On Tue, Jun 04, 2013 at 01:58:31PM +0200, Daniel Lezcano wrote:
On 06/04/2013 01:39 PM, Amit Kucheria wrote:
I'm curious why it is called pen_release. :) Is there some
historical
link to some HW lines?
I tried to figure out the same but I did not found any information
on
that. I assumed the name could be referring to a simplified mutual exclusion algorithm from the 'Dining philosophers problem' [1] where
the
fork is a pen.
Where it comes from is the original ARM SMP patches from early 2000,
which
everyone has blindly copied with no thought about what they're doing.
This
is why I'm totally against any consolidation of this code, because
I'm of
the opinion that _no one_ other than the ARM Ltd development
platforms
should be using it.
"pen" means "holding pen". It comes about because early on in the
SMP
development, ARM SMP platforms had four CPUs, and it was only
possible to
release all three secondary CPUs from the boot loader simultaneously
to
a common piece of code.
As the kernel was not able to serialize the release of each CPU, ARM
Ltd
worked around this problem by having all the CPUs jump to assembly
code
which "holds" the CPUs which we didn't want to boot yet, and the CPUs are released one at a time by setting pen_release to the hardware CPU number.
Modern platforms either have just one secondary CPU, or they have a
way
to control the reset/power to the secondary CPU. This makes the
holding
pen entirely redundant, and such platforms should _not_ make use of
any
kind of holding pen.
And yes, indeed, zynq can control the secondary CPU:
void zynq_slcr_cpu_start(int cpu) { /* enable CPUn */ writel(SLCR_A9_CPU_CLKSTOP << cpu, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL); /* enable CLK for CPUn */ writel(0x0 << cpu, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL); }
void zynq_slcr_cpu_stop(int cpu) { /* stop CLK and reset CPUn */ writel((SLCR_A9_CPU_CLKSTOP | SLCR_A9_CPU_RST) << cpu, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL); }
So there's no need for the pen. There's no need for the low power
crap
in hotplug.c, there's no need for the pen in hotplug.c. You just
arrange
for the secondary CPU to have its clock stopped and reset when it is taken offline.
Hotplugging a CPU back in _should_ be no different from its initial bringup into the kernel.
I have tested that and cpu_die code is performed on cpu which should die. And simple calling zynq_slcr_cpu_stop() on cpu which should die just doesn't work. There is probably any expectation which I can't see.
Feel free to suggest me proper solution.
Thanks, Michal
Hi Michal, Because most SOC design is that secondary cpu can not powerdown by itself. These are some instructions is running in the bus.
We can only put the core in lowpower mode using wfi/wfe by itself. If wakeup or boot this core from die/deepsleep again, we don't need to use holding pen.
Steve
Regards.