On 05/28/2014 08:34 AM, Lorenzo Pieralisi wrote:

On Wed, May 28, 2014 at 01:22:06PM +0100, Alex Elder wrote:

quoted

On 05/28/2014 05:36 AM, Lorenzo Pieralisi wrote:

quoted

On Wed, May 28, 2014 at 04:30:47AM +0100, Alex Elder wrote:

quoted

On 05/27/2014 06:49 AM, Lorenzo Pieralisi wrote:

quoted

On Tue, May 20, 2014 at 06:43:46PM +0100, Alex Elder wrote:

quoted

Broadcom mobile SoCs use a ROM-implemented holding pen for
controlled boot of secondary cores.  A special register is
used to communicate to the ROM that a secondary core should
start executing kernel code.  This enable method is currently
used for members of the bcm281xx and bcm21664 SoC families.

The use of an enable method also allows the SMP operation vector to
be assigned as a result of device tree content for these SoCs.

Signed-off-by: Alex Elder <redacted>

This is getting out of control, it is absolutely ghastly. I wonder how
I can manage to keep cpus.txt updated if anyone with a boot method
du jour adds into cpus.txt, and honestly in this specific case it is even
hard to understand why.

OK, in this message I'll focus on the particulars of this
proposed binding.

quoted

Can't it be done with bindings for the relative register address space
(regmap ?) and platform code just calls the registers driver to set-up the
jump address ? It is platform specific code anyway there is no way you
can make this generic.

I want to clarify what you're after here.

My aim is to add SMP support for a class of Broadcom SMP
machines.  To do so, I'm told I need to use the technique
of assigning the SMP operations vector as a result of
identifying an enable method in the DT.

For 32-bit ARM, there are no generic "enable-method" values.
(I did attempt to create one for "spin-table" but that was
rejected by Russell King.)  For the machines I'm trying to
enable, secondary CPUS start out spinning in a ROM-based
holding pen, and there is no need for a kernel-based one.

However, like a spin-table/holding pen enable method, a
memory location is required for coordination between the
boot CPU running kernel code and secondary CPUs running ROM
code.  My proposal specifies it using a special numeric
property value named "secondary-boot-reg" in the "cpus"
node in the DT.

And as I understand it, the issue you have relates to how
this memory location is specified.

The issue I have relates to cluttering cpus.txt with all
sorts of platform specific SMP boot hacks.

OK, as I mentioned in my other message, I totally
agree with you here.  It's a total (and building)
mess.  I discussed this with Mark Rutland at ELC
last month and suggested splitting that stuff out
of "cpus.txt", which I have now proposed with a
patch.
    https://lkml.org/lkml/2014/5/8/545

I think this makes sense, I will review that patchset, and with this
approach agreed I am ok with adding a platform specific boot method,
since it is split up "nicely", do not bother adding a specific driver
to poke a register (it will be fun to see the number of files we have
to add to /cpu-enable-method though, big fun).

Great!

I used the existing documentation and the code as a guide in
crafting the text of those descriptions.  Some of them I had
to speculate though--especially for ARM64 (for which there is
documentation but nothing in the tree that uses it).  So it
needs some informed feedback.

I still think that it is high time we started pushing back on these
platform hacks and move towards a common interface like PSCI to boot
(and suspend) ARM processors, there is no reason whatsoever why this
can't be done on the platforms you are trying to get merged unless I am
missing something.

We have no need for anything other than SMP startup at this point
on this platform.  If the framework were there for me to use I
would have used it.

Thanks again for working through this with me.

					-Alex

Lorenzo