[PATCH v2 0/5] ARM: Broadcom BCM4760 support

[PATCH v2 0/5] ARM: Broadcom BCM4760 support

[Domenico Andreoli]

Hi all,

  this is my best proposal for the BCM4760 SoC support so far.

I think I've addressed all the comments made to the previous
patches. Details of the changes since v1 are in each patch.

Ehm... if possible, please review. Thank you.

Best regards,
Domenico

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

[Domenico Andreoli]

An embedded and charset-unspecified text was scrubbed...
Name: arm-unconditionally-build-in-mach-bcm.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/0f13451e/attachment.ksh>

[PATCH v2 2/5] ARM: bcm4760: Add platform infrastructure

[Domenico Andreoli]

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-infrastructure.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/af3ec8a5/attachment.ksh>

[PATCH v2 3/5] ARM: bcm4760: Add system timer

[Domenico Andreoli]

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-system-timer.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/7d59c5a0/attachment.ksh>

[PATCH v2 4/5] ARM: bcm4760: Add ripple counter

[Domenico Andreoli]

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-ripple-counter.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/202cecb9/attachment.ksh>

[PATCH v2 5/5] ARM: bcm4760: Add restart hook

[Domenico Andreoli]

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-restart-hook.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/6647443a/attachment.ksh>

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

[Jason Cooper]

On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
> From: Domenico Andreoli <domenico.andreoli@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?

Notice:

$ git grep '^machine-y'
$

thx,

Jason.

> Cc: Christian Daudt <csd@broadcom.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Domenico Andreoli <domenico.andreoli@linux.com>
> ---
>  arch/arm/Makefile |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: b/arch/arm/Makefile
> ===================================================================
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
>  # Machine directory name.  This list is sorted alphanumerically
>  # by CONFIG_* macro name.
>  machine-$(CONFIG_ARCH_AT91)		+= at91
> -machine-$(CONFIG_ARCH_BCM)		+= bcm
> +machine-y				+= bcm
>  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
>  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
>  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 0/5] ARM: Broadcom BCM4760 support

[Jason Cooper]

Domenico,

On Fri, Jul 26, 2013 at 04:56:39PM +0200, Domenico Andreoli wrote:
> Hi all,
> 
>   this is my best proposal for the BCM4760 SoC support so far.
> 
> I think I've addressed all the comments made to the previous
> patches. Details of the changes since v1 are in each patch.
> 
> Ehm... if possible, please review. Thank you.

Please separate devicetree binding documentation from code changes and
make sure those patches are Cc:'d to devicetree at vger.kernel.org.

thx,

Jason.

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

[Christian Daudt]

[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@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.
>> Cc: Christian Daudt<csd@broadcom.com>
>> Cc:linux-arm-kernel at lists.infradead.org
>> Signed-off-by: Domenico Andreoli<domenico.andreoli@linux.com>
>> ---
>>   arch/arm/Makefile |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: b/arch/arm/Makefile
>> ===================================================================
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
>>   # Machine directory name.  This list is sorted alphanumerically
>>   # by CONFIG_* macro name.
>>   machine-$(CONFIG_ARCH_AT91)		+= at91
>> -machine-$(CONFIG_ARCH_BCM)		+= bcm
>> +machine-y				+= bcm
>>   machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
>>   machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
>>   machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
>>
>>
This patch is already contained in Hauke's patchset from yesterday ( 
http://article.gmane.org/gmane.linux.ports.arm.kernel/254986) so you'll 
need to sync with him on it. In case yours goes in first:
Acked-by: Christian Daudt <csd@broadcom.com>

  Thanks,
    csd

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

[Jason Cooper]

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@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)

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

[Christian Daudt]

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@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. 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).

  Thanks,
    csd

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

[Olof Johansson]

Hi,

On Fri, Jul 26, 2013 at 7:56 AM, Domenico Andreoli
<domenico.andreoli@linux.com> wrote:
> From: Domenico Andreoli <domenico.andreoli@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.
>
> Cc: Christian Daudt <csd@broadcom.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Domenico Andreoli <domenico.andreoli@linux.com>
> ---
>  arch/arm/Makefile |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/arch/arm/Makefile
> ===================================================================
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
>  # Machine directory name.  This list is sorted alphanumerically
>  # by CONFIG_* macro name.
>  machine-$(CONFIG_ARCH_AT91)            += at91
> -machine-$(CONFIG_ARCH_BCM)             += bcm
> +machine-y                              += bcm
>  machine-$(CONFIG_ARCH_BCM2835)         += bcm2835
>  machine-$(CONFIG_ARCH_CLPS711X)                += clps711x
>  machine-$(CONFIG_ARCH_CNS3XXX)         += cns3xxx

It's hard to tell what you're trying to do here, since the current
in-tree code works just fine and you're alluding to it having
problems. :)

Are you looking to add new selection of per-SoC config options? If so,
I propose keeping ARCH_BCM as a common, but silent, option that is
just selected by the other SoCs.  See how OMAP does it where
OMAP2/3/4/5 all select ARCH_OMAP2PLUS for comparison.


-Olof

[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@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.

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

[Russell King - ARM Linux]

On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
> Because ARCH_BCM is meant to be used for a number of SoC families. 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.

1. We're moving to a single zImage for everything.  Not just Broadcom.
There's no need for Broadcom stuff to be treated any differently.
Participate in the single zImage project and you will get that benefit
without these games.

2. "library" mach-* support code doesn't go into another mach-* directory.
That's why we have the plat-* stuff.  Please follow this well established
model.  plat-* directories are selected by CONFIG_PLAT_* symbols, so
you would need CONFIG_PLAT_BCM.

Please don't persue your own solutions to problems which were solved years
ago and have established solutions already in place.

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

[Christian Daudt]

On 13-07-26 11:47 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
>> Because ARCH_BCM is meant to be used for a number of SoC families. 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.
> 1. We're moving to a single zImage for everything.  Not just Broadcom.
> There's no need for Broadcom stuff to be treated any differently.
> Participate in the single zImage project and you will get that benefit
> without these games.
I don't follow what is the game being played. The Broadcom mobile team 
is planning on building all future chips out of a single ARCH_ config 
(which we called ARCH_BCM), and others need a separate ARCH_ to build 
(other) specific SoCs for different families. Our ARCH_BCM chip was one 
of the first upstreamed with multiplatform enabled (multi_v7_defconfig 
already selects ARCH_BCM). So right now there are the following 3:
ARCH_BCM -> BCM281XX now + a few others to follow
ARCH_BCM5301X -> BCM530X family
ARCH_BCM4760 -> BCM4760 family.

and these would all reside in mach-bcm. The only problem I see with the 
above is that ARCH_BCM would probably have been more aptly named 
ARCH_MOBILE_BCM as the SoCs showing up under that ARCH are all from the 
mobile team @ Broadcom. And if that is what is confusing people, I'm ok 
with changing that.

>
> 2. "library" mach-* support code doesn't go into another mach-* directory.
> That's why we have the plat-* stuff.  Please follow this well established
> model.  plat-* directories are selected by CONFIG_PLAT_* symbols, so
> you would need CONFIG_PLAT_BCM.
>
> Please don't persue your own solutions to problems which were solved years
> ago and have established solutions already in place.
Maybe I missed something but with the migration to multiplatform (and 
the minimalist size of the ensuing arch-specific files) my understanding 
was that there is no need for PLAT going forward, that all socs from a 
single company can just co-exist under the same mach- directory. If you 
look at mach-bcm at present there are 2 .c files + 1 .S file. With the 
cleanups we are doing to support > 1 family under ARCH_BCM, that number 
is going to grow by 2-4 source files. Adding the 2 other ARCHes above 
will add another handful to a grand total of < 10 source files. None of 
these are 'library' files in the current sense (i.e. each subset of 
these files will only be used for a single ARCH_ config option), so 
there is nothing to move to a plat- directory.
  As an alternative to what is currently being done, I guess could go 
back to the 1-mach-directory-per-arch style so we'd have:
mach-bcm -> ARCH_BCM
mach-bcm5301x -> ARCH_BCM530X
mach-bcm4760 -> ARCH_BCM4760
but each of these dirs will have 2-3 source files. Which is what I heard 
a while back we wanted to start avoiding (the explosition of mach- dirs 
with next-to-nothing in each). Are you proposing we revert to this model ?

  thanks,
    csd

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

[Russell King - ARM Linux]

On Fri, Jul 26, 2013 at 12:09:03PM -0700, Christian Daudt wrote:
> On 13-07-26 11:47 AM, Russell King - ARM Linux wrote:
>> On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
>>> Because ARCH_BCM is meant to be used for a number of SoC families. 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.
>> 1. We're moving to a single zImage for everything.  Not just Broadcom.
>> There's no need for Broadcom stuff to be treated any differently.
>> Participate in the single zImage project and you will get that benefit
>> without these games.
> I don't follow what is the game being played.

I don't really mind what you do, but when you start talking about having
any ARM build always descend into mach-bcm, then something is very wrong
with how you're going about it - you don't see anyone else needing that
in the tree, not even OMAP.

I don't really care if your intention is to decend into mach-bcm and then
do nothing - that's not the point.  The point is we shouldn't even
decend into mach-bcm if there's nothing to be built there.

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

[Christian Daudt]

On 13-07-26 12:39 PM, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 12:09:03PM -0700, Christian Daudt wrote:
>> On 13-07-26 11:47 AM, Russell King - ARM Linux wrote:
>>> On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
>>>> Because ARCH_BCM is meant to be used for a number of SoC families. 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.
>>> 1. We're moving to a single zImage for everything.  Not just Broadcom.
>>> There's no need for Broadcom stuff to be treated any differently.
>>> Participate in the single zImage project and you will get that benefit
>>> without these games.
>> I don't follow what is the game being played.
> I don't really mind what you do, but when you start talking about having
> any ARM build always descend into mach-bcm, then something is very wrong
> with how you're going about it - you don't see anyone else needing that
> in the tree, not even OMAP.
>
> I don't really care if your intention is to decend into mach-bcm and then
> do nothing - that's not the point.  The point is we shouldn't even
> decend into mach-bcm if there's nothing to be built there.
>
Ok, how about creating a ARCH_BROADCOM to select descending into the 
mach-bcm dir, and renaming ARCH_BCM to ARCH_BCMMOBILE, along the lines 
of the attachment ?

  Thanks,
    csd



-------------- next part --------------
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..cdb6662 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_AT91)		+= at91
-machine-$(CONFIG_ARCH_BCM)		+= bcm
+machine-$(CONFIG_ARCH_BROADCOM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index f112895..0367f94 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -1,4 +1,11 @@
-config ARCH_BCM
+config ARCH_BROADCOM
+	bool "Broadcom Multiplatform SOCs"
+
+if ARCH_BROADCOM
+
+menu  "Broadcom SoC Family"
+
+config ARCH_BCMMOBILE
 	bool "Broadcom SoC" if ARCH_MULTI_V7
 	depends on MMU
 	select ARCH_REQUIRE_GPIOLIB
@@ -13,7 +20,11 @@ config ARCH_BCM
 	select SPARSE_IRQ
 	select TICK_ONESHOT
 	help
-	  This enables support for system based on Broadcom SoCs.
+	  This enables support for systems based on Broadcom mobile SoCs.
 	  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..08f9ebe 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_ARCH_BCMMOBILE)	:= 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)

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

[Domenico Andreoli]

On Fri, Jul 26, 2013 at 11:29:18AM -0400, Jason Cooper wrote:
> On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
> > From: Domenico Andreoli <domenico.andreoli@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?

In mach-bcm we (or I, it's not very clear to me) want to have support for
multiple SoCs.

In trying the approach

machine-$(CONFIG_ARCH_BCM)		+= bcm
machine-$(CONFIG_ARCH_BCM4760)		+= bcm

I got linker complains about multiple symbol definitiion in case both the
config options are selected.

The first thought was to use a common option which purpose was only to
include the subdir but then, given my allergy to the tons of config options
with usually not straghtforward purpose, I opted for something more simple.

> 
> Notice:
> 
> $ git grep '^machine-y'
> $
> 
> thx,
> 
> Jason.
> 
> > Cc: Christian Daudt <csd@broadcom.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Domenico Andreoli <domenico.andreoli@linux.com>
> > ---
> >  arch/arm/Makefile |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: b/arch/arm/Makefile
> > ===================================================================
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
> >  # Machine directory name.  This list is sorted alphanumerically
> >  # by CONFIG_* macro name.
> >  machine-$(CONFIG_ARCH_AT91)		+= at91
> > -machine-$(CONFIG_ARCH_BCM)		+= bcm
> > +machine-y				+= bcm
> >  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
> >  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
> >  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Domenico Andreoli]

On Fri, Jul 26, 2013 at 08:39:08PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 12:09:03PM -0700, Christian Daudt wrote:
> > On 13-07-26 11:47 AM, Russell King - ARM Linux wrote:
> >> On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
> >>> Because ARCH_BCM is meant to be used for a number of SoC families. 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.
> >> 1. We're moving to a single zImage for everything.  Not just Broadcom.
> >> There's no need for Broadcom stuff to be treated any differently.
> >> Participate in the single zImage project and you will get that benefit
> >> without these games.
> > I don't follow what is the game being played.
> 
> I don't really mind what you do, but when you start talking about having
> any ARM build always descend into mach-bcm, then something is very wrong
> with how you're going about it - you don't see anyone else needing that
> in the tree, not even OMAP.

That was a Great Idea(tm) of mine that obviously needed some rebuttal.
No insult was implied for those not having had it in solving the very
same problem.

BTW I asked this very same question [1] and got _zero_ feedback so I
thought it was worth a patch.

> I don't really care if your intention is to decend into mach-bcm and then
> do nothing - that's not the point.  The point is we shouldn't even
> decend into mach-bcm if there's nothing to be built there.

I've got the point but didn't fully understand why would be so wrong to
walk one more subdir even if nothing is going to be built.

thanks,
Domenico

[1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/253500

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

[Russell King - ARM Linux]

On Sat, Jul 27, 2013 at 12:28:09AM +0200, Domenico Andreoli wrote:
> I've got the point but didn't fully understand why would be so wrong to
> walk one more subdir even if nothing is going to be built.

Consider what would happen if we decended the 61 mach- subdirectories
on every build run when only one was really required.  Even though
kbuild tries to be fast, there's still a non-zero amount of time
involved with finding out there's nothing to be done - and you
will still end up generating a built-in.o file even though there's
no other objects, which will then also be included in the final
link - again, adding to the work which has to be done.

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

[Jason Gunthorpe]

On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:

> In mach-bcm we (or I, it's not very clear to me) want to have support for
> multiple SoCs.
> 
> In trying the approach
> 
> machine-$(CONFIG_ARCH_BCM)		+= bcm
> machine-$(CONFIG_ARCH_BCM4760)		+= bcm
> 
> I got linker complains about multiple symbol definitiion in case both the
> config options are selected.

You can't repeat the same dir. Maybe this?

bcm-machine-$(CONFIG_ARCH_BCM) := bmc
bcm-machine-$(CONFIG_ARCH_BCM4760) := bmc
machine-y += $(bcm-machine-y)

Regards,
Jason

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

[Domenico Andreoli]

On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
> On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
> 
> > In mach-bcm we (or I, it's not very clear to me) want to have support for
> > multiple SoCs.
> > 
> > In trying the approach
> > 
> > machine-$(CONFIG_ARCH_BCM)		+= bcm
> > machine-$(CONFIG_ARCH_BCM4760)		+= bcm
> > 
> > I got linker complains about multiple symbol definitiion in case both the
> > config options are selected.
> 
> You can't repeat the same dir. Maybe this?
> 
> bcm-machine-$(CONFIG_ARCH_BCM) := bmc
> bcm-machine-$(CONFIG_ARCH_BCM4760) := bmc
> machine-y += $(bcm-machine-y)

nice! I prefer this to the config option used only to descend the dir,
you never know how it is going to be abused.

Christian, would you agree in ditching ARCH_BROADCOM then?

Russel, is it ok?

thanks,
Domenico

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

[Domenico Andreoli]

On Fri, Jul 26, 2013 at 11:38:29PM +0100, Russell King - ARM Linux wrote:
> On Sat, Jul 27, 2013 at 12:28:09AM +0200, Domenico Andreoli wrote:
> > I've got the point but didn't fully understand why would be so wrong to
> > walk one more subdir even if nothing is going to be built.
> 
> Consider what would happen if we decended the 61 mach- subdirectories
> on every build run when only one was really required.  Even though
> kbuild tries to be fast, there's still a non-zero amount of time
> involved with finding out there's nothing to be done - and you
> will still end up generating a built-in.o file even though there's
> no other objects, which will then also be included in the final
> link - again, adding to the work which has to be done.

crystal clear. thanks.

Domenico

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

[Russell King - ARM Linux]

On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
> On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
> 
> > In mach-bcm we (or I, it's not very clear to me) want to have support for
> > multiple SoCs.
> > 
> > In trying the approach
> > 
> > machine-$(CONFIG_ARCH_BCM)		+= bcm
> > machine-$(CONFIG_ARCH_BCM4760)		+= bcm
> > 
> > I got linker complains about multiple symbol definitiion in case both the
> > config options are selected.
> 
> You can't repeat the same dir. Maybe this?
> 
> bcm-machine-$(CONFIG_ARCH_BCM) := bmc
> bcm-machine-$(CONFIG_ARCH_BCM4760) := bmc
> machine-y += $(bcm-machine-y)

Thank you for making me look at that file and see how people fail to read
my comments about keeping stuff appropriately sorted.  Really makes me
wonder why I bother.

Anyway, there's a simpler solutions to this:

machdirs := $(patsubst %,arch/arm/mach-%/,$(sort $(machine-y)))
platdirs := $(patsubst %,arch/arm/plat-%/,$(Sort $(plat-y)))

which will remove all duplicates.

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

[Christian Daudt]

On 13-07-26 04:28 PM, Domenico Andreoli wrote:
> On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
>> On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
>>
>>> In mach-bcm we (or I, it's not very clear to me) want to have support for
>>> multiple SoCs.
>>>
>>> In trying the approach
>>>
>>> machine-$(CONFIG_ARCH_BCM)		+= bcm
>>> machine-$(CONFIG_ARCH_BCM4760)		+= bcm
>>>
>>> I got linker complains about multiple symbol definitiion in case both the
>>> config options are selected.
>> You can't repeat the same dir. Maybe this?
>>
>> bcm-machine-$(CONFIG_ARCH_BCM) := bmc
>> bcm-machine-$(CONFIG_ARCH_BCM4760) := bmc
>> machine-y += $(bcm-machine-y)
> nice! I prefer this to the config option used only to descend the dir,
> you never know how it is going to be abused.
>
> Christian, would you agree in ditching ARCH_BROADCOM then?
I'm fine with skipping ARCH_BROADCOM
  Thanks,
    csd

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

[Olof Johansson]

On Fri, Jul 26, 2013 at 4:42 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Thank you for making me look at that file and see how people fail to read
> my comments about keeping stuff appropriately sorted.  Really makes me
> wonder why I bother.

Grmbl. This one escaped me probably because the comment is at the top,
so I didn't see it when just reviewing the patch. I should obviously
have caught it anyway since the list was so obviously sorted before.
My bad. I'll send a patch in a bit.


-Olof

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

[Russell King - ARM Linux]

On Fri, Jul 26, 2013 at 05:01:08PM -0700, Olof Johansson wrote:
> On Fri, Jul 26, 2013 at 4:42 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Thank you for making me look at that file and see how people fail to read
> > my comments about keeping stuff appropriately sorted.  Really makes me
> > wonder why I bother.
> 
> Grmbl. This one escaped me probably because the comment is at the top,
> so I didn't see it when just reviewing the patch. I should obviously
> have caught it anyway since the list was so obviously sorted before.
> My bad. I'll send a patch in a bit.

I've already a patch in my fixes.  It'll appear in -next probably after
the weekend (as next doesn't update over weekends.)

Note that the misordering is not due to these patches, but other previous
patches.

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

[Olof Johansson]

On Fri, Jul 26, 2013 at 5:04 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jul 26, 2013 at 05:01:08PM -0700, Olof Johansson wrote:
>> On Fri, Jul 26, 2013 at 4:42 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > Thank you for making me look at that file and see how people fail to read
>> > my comments about keeping stuff appropriately sorted.  Really makes me
>> > wonder why I bother.
>>
>> Grmbl. This one escaped me probably because the comment is at the top,
>> so I didn't see it when just reviewing the patch. I should obviously
>> have caught it anyway since the list was so obviously sorted before.
>> My bad. I'll send a patch in a bit.
>
> I've already a patch in my fixes.  It'll appear in -next probably after
> the weekend (as next doesn't update over weekends.)
>
> Note that the misordering is not due to these patches, but other previous
> patches.

Ok, sounds good.

And yeah, it's pretty obvious based on the order that it has crept in over time.


-Olof

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

[Arnd Bergmann]

On Saturday 27 July 2013, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
> > On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
>
> Anyway, there's a simpler solutions to this:
> 
> machdirs := $(patsubst %,arch/arm/mach-%/,$(sort $(machine-y)))
> platdirs := $(patsubst %,arch/arm/plat-%/,$(Sort $(plat-y)))
> 
> which will remove all duplicates.

This does sound like the easiest solution, although I still think
Olof's suggestion of making ARCH_BCM a silent Kconfig symbol would be
just as good if we just have this one instance.

	Arnd

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

[Florian Fainelli]

Hello,

2013/7/26 Domenico Andreoli <cavokz@gmail.com>:
> On Fri, Jul 26, 2013 at 11:29:18AM -0400, Jason Cooper wrote:
>> On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
>> > From: Domenico Andreoli <domenico.andreoli@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?
>
> In mach-bcm we (or I, it's not very clear to me) want to have support for
> multiple SoCs.
>
> In trying the approach
>
> machine-$(CONFIG_ARCH_BCM)              += bcm
> machine-$(CONFIG_ARCH_BCM4760)          += bcm
>
> I got linker complains about multiple symbol definitiion in case both the
> config options are selected.
>
> The first thought was to use a common option which purpose was only to
> include the subdir but then, given my allergy to the tons of config options
> with usually not straghtforward purpose, I opted for something more simple.

I do not understand why are you trying so hard to put your SoC support
in mach-bcm. I was one of the only people to complain that mach-bcm
was both confusing and not generic enough to cover all Broadcom SoCs.
I still think it should have been specified to mach-bcmmobile or
something like mach-bcm28xxx. Back in the days where ARM drivers were
mostly living in arch/arm/*, it *might* have made some sense but now,
I really think that you should go with your own mach-bcm470x
directory.

BCM47060, BCM53xx and BCM28xx all have both different CPU backends and
different on-chip peripherals, which are even connected differently,
put clearly, they share very little but the ARM architecture.
-- 
Florian

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

[Domenico Andreoli]

On Thu, Aug 01, 2013 at 10:23:48AM +0100, Florian Fainelli wrote:
> Hello,
> 
> 2013/7/26 Domenico Andreoli <cavokz@gmail.com>:
> > On Fri, Jul 26, 2013 at 11:29:18AM -0400, Jason Cooper wrote:
> >> On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
> >> > From: Domenico Andreoli <domenico.andreoli@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?
> >
> > In mach-bcm we (or I, it's not very clear to me) want to have support for
> > multiple SoCs.
> >
> > In trying the approach
> >
> > machine-$(CONFIG_ARCH_BCM)              += bcm
> > machine-$(CONFIG_ARCH_BCM4760)          += bcm
> >
> > I got linker complains about multiple symbol definitiion in case both the
> > config options are selected.
> >
> > The first thought was to use a common option which purpose was only to
> > include the subdir but then, given my allergy to the tons of config options
> > with usually not straghtforward purpose, I opted for something more simple.
> 
> I do not understand why are you trying so hard to put your SoC support
> in mach-bcm. I was one of the only people to complain that mach-bcm
> was both confusing and not generic enough to cover all Broadcom SoCs.
> I still think it should have been specified to mach-bcmmobile or
> something like mach-bcm28xxx. Back in the days where ARM drivers were
> mostly living in arch/arm/*, it *might* have made some sense but now,
> I really think that you should go with your own mach-bcm470x
> directory.
> 
> BCM47060, BCM53xx and BCM28xx all have both different CPU backends and
> different on-chip peripherals, which are even connected differently,
> put clearly, they share very little but the ARM architecture.

I've already explained my point elsewhere in this thread. It's not technical,
it's social. I don't see any technical disproportion to go either way.

thanks,
Domenico

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

[Domenico Andreoli]

On Sat, Jul 27, 2013 at 04:38:16PM +0200, Arnd Bergmann wrote:
> On Saturday 27 July 2013, Russell King - ARM Linux wrote:
> > On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
> > > On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
> >
> > Anyway, there's a simpler solutions to this:
> > 
> > machdirs := $(patsubst %,arch/arm/mach-%/,$(sort $(machine-y)))
> > platdirs := $(patsubst %,arch/arm/plat-%/,$(Sort $(plat-y)))
> > 
> > which will remove all duplicates.
> 
> This does sound like the easiest solution, although I still think
> Olof's suggestion of making ARCH_BCM a silent Kconfig symbol would be
> just as good if we just have this one instance.

I know that time is always tight and there is also this DT ABI discussion
ongoing but do I have any chance to get any ack on this series?

Should I post a new set? It would be only to fix again the build of mach-bcm,
I've nothing else pending.

Thanks,
Domenico