lkml.org 
[lkml]   [2014]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 1/5] devicetree: bindings: document Broadcom CPU enable method
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@linaro.org>
> >
> > 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>



\
 
 \ /
  Last update: 2014-05-28 13:21    [W:0.445 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site