[PATCH v2 1/5] ARM: Broadcom: Unconditionally build arch/arm/mach-bcm
jason at lakedaemon.net
Fri Jul 26 13:33:00 EDT 2013
On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
> On 13-07-26 10:11 AM, Jason Cooper wrote:
> >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?
> >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.
> >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 ;-)
More information about the linux-arm-kernel