lkml.org 
[lkml]   [2014]   [May]   [27]   [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 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.

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
>>
>>
>



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