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

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.

You suggest regmap.  I'm using a single 32-bit register,
only at very early boot time, and thereafter access to
it is meaningless.  It seems like overkill if it's only
used for this purpose.  I could hide the register values
in the code, but with the exception of that, the code I'm
using is generic (in the context of this class of Broadcom
machine).  I could specify the register differently somehow,
in a different node, or with a different property.

Is that register part of a larger registers block ? What I wanted
to say is that you can use a driver "API" (we wish) to write that
register, something like eg vexpress does with sysflags:

drivers/mfd/vexpress-sysreg.c

vexpress_flags_set()

instead of grabbing the reg address from a platform specific boot
method DT entry.

I doubt that register exists on its own, even though I have to say this
would force you to write yet another platform specific driver to control
a bunch of registers, I do not see any other solution.

One thing is for certain: I really do not see the point in adding a boot
method per-SoC, and I do not want to end up having a cpus.txt file with a
gazillion entries just because every given platform reinvents the wheel when
it comes to booting an SMP system, cpus.txt would become a document that
describes platform quirks, not a proper binding anymore.

At least all platform specific quirks must be moved out of cpus.txt and
in platform documentation, I understand it is just a cosmetic change but
I want to prevent cpus.txt to become an abomination.

The bottom line here is I'm not sure whether I understand
what you're suggesting, or perhaps why what you suggest is
preferable.  I'm very open to suggestions, I just need it
laid out a bit more detail in order to respond directly.

See above.

Thanks !
Lorenzo

Thanks.

					-Alex

quoted

I really do not see the point in cluttering cpus.txt with this stuff, it
is a platform specific hack, and do not belong in generic bindings in my
opinion.

Thanks,
Lorenzo

quoted

---
 Documentation/devicetree/bindings/arm/cpus.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 333f4ae..c6a2411 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt

@@ -185,6 +185,7 @@ nodes to be present and contain the properties described below.
 			    "qcom,gcc-msm8660"
 			    "qcom,kpss-acc-v1"
 			    "qcom,kpss-acc-v2"
+			    "brcm,bcm11351-cpu-method"
 
 	- cpu-release-addr
 		Usage: required for systems that have an "enable-method"

@@ -209,6 +210,17 @@ nodes to be present and contain the properties described below.
 		Value type: <phandle>
 		Definition: Specifies the ACC[2] node associated with this CPU.
 
+	- secondary-boot-reg
+		Usage:
+			Required for systems that have an "enable-method"
+			property value of "brcm,bcm11351-cpu-method".
+		Value type: <u32>
+		Definition:
+			Specifies the physical address of the register used to
+			request the ROM holding pen code release a secondary
+			CPU.  The value written to the register is formed by
+			encoding the target CPU id into the low bits of the
+			physical start address it should jump to.
 
 Example 1 (dual-cluster big.LITTLE system 32-bit):
 

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html