On Wed, May 28, 2014 at 04:30:47AM +0100, Alex Elder wrote: > 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. 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 > > > 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 devicetree" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
