On Thu, May 15, 2014 at 11:03:49AM -0700, Florian Fainelli wrote: > Hi Alex, > > 2014-05-15 10:58 GMT-07:00 Alex Elder <elder@xxxxxxxxxx>: > > This patch adds SMP support for BCM281XX and BCM21664 family SoCs. > > > > This feature is controlled with a distinct config option such that a > > SMP-enabled multi-v7 binary can be configured to run these SoCs in > > uniprocessor mode. Since this SMP functionality is used for > > multiple Broadcom mobile chip families the config option is called > > ARCH_BCM_MOBILE_SMP (for lack of a better name). > > > > On SoCs of this type, the secondary core is not held in reset on > > power-on. Instead it loops in a ROM-based holding pen. To release > > it, one must write into a special register a jump address whose > > low-order bits have been replaced with a secondary core's id, then > > trigger an event with SEV. On receipt of an event, the ROM code > > will examine the register's contents, and if the low-order bits > > match its cpu id, it will clear them and write the value back to the > > register just prior to jumping to the address specified. > > > > The location of the special register is defined in the device tree > > using a "secondary-boot-reg" property in a node whose "enable-method" > > matches. > > > > Derived from code originally provided by Ray Jui <rjui@xxxxxxxxxxxx> > > > > Signed-off-by: Alex Elder <elder@xxxxxxxxxx> > > --- > > arch/arm/mach-bcm/Kconfig | 18 +++- > > arch/arm/mach-bcm/Makefile | 3 + > > arch/arm/mach-bcm/platsmp.c | 201 ++++++++++++++++++++++++++++++++++++++++++++ > > Could we make that name a little bit more specific to the mobile SoCs? > There are other BCM SoCs either currently supported in this directory > (BCM5310X), or making their way to be supported (brcmstb, bcm63xx), > and those share nothing with the Mobile SoC SMP code. Right. > Maybe we should create another level directory within mach-bcm... Let's not go that far. The general direction we need to go is to work toward removing this code from mach-bcm/ completely. I don't really want to see us adding directories and encouraging burying a lot of new files in them. A unique name will be enough and then we can work toward moving things out to drivers/ over time. -Matt -- 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
