[PATCH v2 1/5] ARM: Broadcom: Unconditionally build arch/arm/mach-bcm

[Jason Cooper]

On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
> On 13-07-26 10:11 AM, Jason Cooper wrote:
> >Christian,
> >
> >On Fri, Jul 26, 2013 at 08:55:42AM -0700, Christian Daudt wrote:
> >>[resend in plain text]
> >>On 13-07-26 08:29 AM, Jason Cooper wrote:
> >>>On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
> >>>>From: Domenico Andreoli<domenico.andreoli at linux.com>
> >>>>
> >>>>arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
> >>>>separately. As a matter of flexibility and maintenance, it needs to be
> >>>>always included in the build.
> >>>So if I'm building mach-kirkwood, I _have_ to build Broadcom?  What is
> >>>the *specific* problem you're encountering that this solves?
> >>  No it won't, as the Makefile inside mach-bcm will only pull in
> >>files based on ARCH_ settings. This move is so that a number
> >>different Broadcom SoCs can co-exist inside the mach-bcm directory.
> >
> >Why wouldn't this work?
> >
> >---->8-------
> >diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >index ba412e0..97b6aff 100644
> >--- a/arch/arm/Kconfig
> >+++ b/arch/arm/Kconfig
> >@@ -366,6 +366,12 @@ config ARCH_AT91
> >  	  This enables support for systems based on Atmel
> >  	  AT91RM9200 and AT91SAM9* processors.
> >+config ARCH_BCM
> >+	bool "Broadcom family SoCs"
> >+	help
> >+	  This enables support for systems based on the Broadcom
> >+	  bcm4760 and bcm281XX series SoCs.
> >+
> >  config ARCH_CLPS711X
> >  	bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
> >  	select ARCH_REQUIRE_GPIOLIB
> >diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> >index f112895..4b1f9db 100644
> >--- a/arch/arm/mach-bcm/Kconfig
> >+++ b/arch/arm/mach-bcm/Kconfig
> >@@ -1,5 +1,9 @@
> >-config ARCH_BCM
> >-	bool "Broadcom SoC" if ARCH_MULTI_V7
> >+if ARCH_BCM
> >+
> >+menu "Broadcom SoC Implementations"
> >+
> >+config MACH_BCM281XX
> >+	bool "BCM281XX SoCs" if ARCH_MULTI_V7
> >  	depends on MMU
> >  	select ARCH_REQUIRE_GPIOLIB
> >  	select ARM_ERRATA_754322
> >@@ -17,3 +21,7 @@ config ARCH_BCM
> >  	  It currently supports the 'BCM281XX' family, which includes
> >  	  BCM11130, BCM11140, BCM11351, BCM28145 and
> >  	  BCM28155 variants.
> >+
> >+endmenu
> >+
> >+endif
> >diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> >index 6adb6aec..e3f8f27 100644
> >--- a/arch/arm/mach-bcm/Makefile
> >+++ b/arch/arm/mach-bcm/Makefile
> >@@ -10,6 +10,6 @@
> >  # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >  # GNU General Public License for more details.
> >-obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
> >+obj-$(CONFIG_MACH_BCM281XX)	:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
> >  plus_sec := $(call as-instr,.arch_extension sec,+sec)
> >  AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)
> >
> Because ARCH_BCM is meant to be used for a number of SoC families.

As is ARCH_MVEBU for Marvell.  As kirkwood, dove, orion5x and mv78xx0
complete their conversion to DT and are multiplatform capable, they will
be migrated to mach-mvebu.  As is, it already contains two flavors of
their Armada SoCs.  mach-mvebu/Kconfig does things a little differently
than what I proposed above.  But the end result is the same because the
mach-mvebu/Kconfig file gets sourced, just like mach-bcm/Kconfig.

> We've started upstreaming one (the BCM281XX) but have 2 more
> internally that we're working towards upstreaming. And in the future
> our plan is to keep the Broadcom Mobile SoCs all building under this
> single ARCH_BCM configuration as multiplatform code building a
> single zImage for them.
> The intent of mach-bcm on the other hand is to aggregate future SoC
> chips beyond ARCH_BCM (which is mobile SoC focused) to include other
> Broadcom ARM based SoCs. And there are 2 in the wings at the moment
> making their way into mainline as patches. The idea here being that
> with the new multiplatform code, the mach- dirs contain so little
> code that it makes sense to aggregate a bunch of SoCs from the same
> company in there (and we are the guinea pig on this one).

So are we ;-)

thx,

Jason.