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 <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. >> >> 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
