2014-05-15 11:26 GMT-07:00 Matt Porter [off-list ref]:

On Thu, May 15, 2014 at 11:03:49AM -0700, Florian Fainelli wrote:

quoted

Hi Alex,

2014-05-15 10:58 GMT-07:00 Alex Elder [off-list ref]:

quoted

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 [off-list ref]

Signed-off-by: Alex Elder <redacted>
---
 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.

quoted

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