On 05/28/2014 08:34 AM, Lorenzo Pieralisi wrote:
> On Wed, May 28, 2014 at 01:22:06PM +0100, Alex Elder wrote:
>> On 05/28/2014 05:36 AM, Lorenzo Pieralisi wrote:
>>> 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 <el...@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.
>>
>> OK, as I mentioned in my other message, I totally
>> agree with you here. It's a total (and building)
>> mess. I discussed this with Mark Rutland at ELC
>> last month and suggested splitting that stuff out
>> of "cpus.txt", which I have now proposed with a
>> patch.
>> https://lkml.org/lkml/2014/5/8/545
>
> I think this makes sense, I will review that patchset, and with this
> approach agreed I am ok with adding a platform specific boot method,
> since it is split up "nicely", do not bother adding a specific driver
> to poke a register (it will be fun to see the number of files we have
> to add to /cpu-enable-method though, big fun).
Great!
I used the existing documentation and the code as a guide in
crafting the text of those descriptions. Some of them I had
to speculate though--especially for ARM64 (for which there is
documentation but nothing in the tree that uses it). So it
needs some informed feedback.
> I still think that it is high time we started pushing back on these
> platform hacks and move towards a common interface like PSCI to boot
> (and suspend) ARM processors, there is no reason whatsoever why this
> can't be done on the platforms you are trying to get merged unless I am
> missing something.
We have no need for anything other than SMP startup at this point
on this platform. If the framework were there for me to use I
would have used it.
Thanks again for working through this with me.
-Alex
> Lorenzo
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
