2014-05-15 11:26 GMT-07:00 Matt Porter <mporter@xxxxxxxxxx>: > 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. Ok, makes sense. > > A unique name will be enough and then we can work toward moving things > out to drivers/ over time. Sounds good, thanks! -- Florian -- 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
