On 05/27/2014 06:49 AM, Lorenzo Pieralisi wrote: > On Tue, May 20, 2014 at 06:43:46PM +0100, Alex Elder wrote: >> 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 <elder@xxxxxxxxxx> > > 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. > 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. 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. 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. Thanks. -Alex > 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 > >> --- >> 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 linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
