ARM: Broadcom BCM4760 support
Subsystems (3)
v2 cover ARM: Broadcom BCM4760 support
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
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 1/5 ARM: Broadcom: Unconditionally build arch/arm/mach-bcm
Quoted 5 lines · Domenico Andreoli
From: Domenico Andreoli <[email protected]>
arch/arm/mach-bcmcontains 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.
Quoted 26 lines
Cc Christian Daudt <[email protected]>Cc linux-arm-kernel at lists.infradead.orgSigned-off-by Domenico Andreoli <[email protected]>--- arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Index: b/arch/arm/Makefile
===================================================================arch/arm/Makefile +1
-1@@ -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 1/5 ARM: Broadcom: Unconditionally build arch/arm/mach-bcm
[resend in plain text]
Quoted 8 lines · Jason Cooper
Quoted 5 lines · Domenico Andreoli
From: Domenico Andreoli<[email protected]>
arch/arm/mach-bcmcontains 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.
Quoted 7 lines
Quoted 7 lines
Cc Christian Daudt<[email protected]>Cc linux-arm-kernel at lists.infradead.orgSigned-off-by Domenico Andreoli<[email protected]>--- arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Quoted 15 lines
Quoted 7 lines
Index: b/arch/arm/Makefile
===================================================================arch/arm/Makefile textofs-$(CONFIG_ARCH_MSM8960) := 0x0020 · line 151
Quoted 8 lines
arch/arm/Makefile +1
-1@@ -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:
Thanks,
csd
PATCH v2 1/5 ARM: Broadcom: Unconditionally build arch/arm/mach-bcm
Christian,
Quoted 9 lines · Christian Daudt
[resend in plain text]
Quoted 7 lines · Jason Cooper
Quoted 5 lines · Domenico Andreoli
From: Domenico Andreoli<[email protected]>
arch/arm/mach-bcmcontains a plurality of Broadcom SoCs, each configured separately. As a matter of flexibility and maintenance, it needs to be always included in the build.
Quoted 6 lines
Quoted 2 lines
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
Makefileinside mach-bcm will only pull in
files based onARCH_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-------
arch/arm/Kconfig +6 -0
@@ -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
arch/arm/mach-bcm/Kconfig +10 -2
@@ -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
arch/arm/mach-bcm/Makefile +1 -1
@@ -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
Quoted 67 lines · Jason Cooper
Christian,
Quoted 5 lines · Christian Daudt
[resend in plain text]
Quoted 3 lines · Jason Cooper
Quoted 2 lines · Domenico Andreoli
From: Domenico Andreoli<[email protected]>
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
arch/arm/mach-bcmcontains 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
Makefileinside mach-bcm will only pull in
files based onARCH_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-------
arch/arm/Kconfig +6
-0@@ -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_GPIOLIBarch/arm/mach-bcm/Kconfig +10
-2@@ -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 + +endifarch/arm/mach-bcm/Makefile +0
-0
arch/arm/mach-bcm/Makefile line 15
Quoted 7 lines
arch/arm/mach-bcm/Makefile +1
-1@@ -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
Quoted 66 lines · Christian Daudt
Quoted 65 lines · Jason Cooper
Christian,
Quoted 5 lines · Christian Daudt
[resend in plain text]
Quoted 3 lines · Jason Cooper
Quoted 2 lines · Domenico Andreoli
From: Domenico Andreoli<[email protected]>
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
arch/arm/mach-bcmcontains 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
Makefileinside mach-bcm will only pull in
files based onARCH_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-------
arch/arm/Kconfig +6
-0@@ -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_GPIOLIBarch/arm/mach-bcm/Kconfig +10
-2@@ -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 + +endifarch/arm/mach-bcm/Makefile +0
-0@@ -10,6 +10,6 @@
Quoted 8 lines
arch/arm/mach-bcm/Makefile
Quoted 7 lines
arch/arm/mach-bcm/Makefile +1
-1# 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_BCMis 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.
Quoted 4 lines
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_BCMconfiguration as multiplatform code building a
Quoted 8 lines
single zImage for them.
The intent of mach-bcm on the other hand is to aggregate future SoC chips beyondARCH_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
In reply to Christian DaudtQuoted 5 lines · Christian Daudt
Because
ARCH_BCMis 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 singleARCH_BCMconfiguration 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
Quoted 10 lines · Russell King - ARM Linux
Quoted 5 lines · Christian Daudt
Because
ARCH_BCMis 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 singleARCH_BCMconfiguration 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 familyARCH_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.
Quoted 8 lines
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
Quoted 7 lines · Christian Daudt
Quoted 6 lines · Russell King - ARM Linux
Quoted 5 lines · Christian Daudt
Because
ARCH_BCMis 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 singleARCH_BCMconfiguration as multiplatform code building a single zImage for them.
Quoted 5 lines
Quoted 4 lines
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
Quoted 13 lines · Russell King - ARM Linux
Quoted 7 lines · Christian Daudt
Quoted 6 lines · Russell King - ARM Linux
Quoted 5 lines · Christian Daudt
Because
ARCH_BCMis 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 singleARCH_BCMconfiguration as multiplatform code building a single zImage for them.Quoted 5 lines
Quoted 4 lines
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.
Quoted 9 lines
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 --------------
arch/arm/Makefile +1 -1
@@ -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
arch/arm/mach-bcm/Kconfig +13 -2
@@ -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
arch/arm/mach-bcm/Makefile +1 -1
@@ -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
In reply to Russell King - ARM LinuxQuoted 12 lines · Russell King - ARM Linux
Quoted 11 lines · Christian Daudt
Quoted 10 lines · Russell King - ARM Linux
Quoted 5 lines · Christian Daudt
Because
ARCH_BCMis 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 singleARCH_BCMconfiguration 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.
Quoted 6 lines
Quoted 1 line
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.
Quoted 3 lines
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
Quoted 2 lines · Domenico Andreoli
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
Quoted 11 lines · Russell King - ARM Linux
Quoted 2 lines · Domenico Andreoli
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
In reply to Jason CooperQuoted 9 lines · Jason Cooper
Quoted 5 lines · Domenico Andreoli
From: Domenico Andreoli <[email protected]>
arch/arm/mach-bcmcontains 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.
Quoted 41 lines
Notice:
$ git grep '^machine-y' $thx,
Jason.
Quoted 22 lines
Cc Christian Daudt <[email protected]>Cc linux-arm-kernel at lists.infradead.orgSigned-off-by Domenico Andreoli <[email protected]>--- arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Index: b/arch/arm/Makefile
===================================================================arch/arm/Makefile +1
-1@@ -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) += cns3xxxQuoted 4 lines
_______________________________________________
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
Quoted 10 lines · Domenico Andreoli
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) += bcmI 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
Quoted 10 lines · Jason Gunthorpe
Quoted 8 lines · Domenico Andreoli
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
Quoted 8 lines
Quoted 2 lines
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
Quoted 15 lines · Domenico Andreoli
Quoted 14 lines · Jason Gunthorpe
Quoted 10 lines · Domenico Andreoli
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) += bcmI got linker complains about multiple symbol definitiion in case both the config options are selected.
You can't repeat the same dir. Maybe this?
Quoted 7 lines
Quoted 3 lines
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_BROADCOMthen?
I'm fine with skipping ARCH_BROADCOM
Thanks,
csd
PATCH v2 1/5 ARM: Broadcom: Unconditionally build arch/arm/mach-bcm
In reply to Jason GunthorpeQuoted 10 lines · Jason Gunthorpe
Quoted 8 lines · Domenico Andreoli
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
Quoted 8 lines
Quoted 2 lines
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
Quoted 3 lines · Russell King - ARM Linux
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
Quoted 10 lines · Olof Johansson
Quoted 3 lines · Russell King - ARM Linux
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
Quoted 12 lines · Russell King - ARM Linux
Quoted 10 lines · Olof Johansson
Quoted 3 lines · Russell King - ARM Linux
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.
Quoted 5 lines
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
In reply to Russell King - ARM LinuxQuoted 9 lines · Russell King - ARM Linux
Quoted 1 line · Jason Gunthorpe
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
Quoted 6 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux
Quoted 1 line · Jason Gunthorpe
On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
Anyway, there's a simpler solutions to this:
Quoted 8 lines
Quoted 4 lines
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_BCMa silentKconfigsymbol 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
PATCH v2 1/5 ARM: Broadcom: Unconditionally build arch/arm/mach-bcm
In reply to Domenico AndreoliHello,
2013/7/26 Domenico Andreoli <[email protected]>:
Quoted 19 lines · Jason Cooper
Quoted 9 lines · Domenico Andreoli
Quoted 5 lines
From: Domenico Andreoli <[email protected]>
arch/arm/mach-bcmcontains 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
Quoted 6 lines
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.
Signature · 1 line
Florian
PATCH v2 1/5 ARM: Broadcom: Unconditionally build arch/arm/mach-bcm
Quoted 38 lines · Florian Fainelli
Hello,
2013/7/26 Domenico Andreoli <[email protected]>:
Quoted 19 lines · Jason Cooper
Quoted 9 lines · Domenico Andreoli
Quoted 5 lines
From: Domenico Andreoli <[email protected]>
arch/arm/mach-bcmcontains 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) += bcmQuoted 6 lines
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.
Quoted 3 lines
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
In reply to Domenico AndreoliHi,
Quoted 18 lines · Domenico Andreoli
From: Domenico Andreoli <[email protected]>
arch/arm/mach-bcmcontains 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 <[email protected]>Cc linux-arm-kernel at lists.infradead.orgSigned-off-by Domenico Andreoli <[email protected]>--- arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Index: b/arch/arm/Makefile
===================================================================
arch/arm/Makefile textofs-$(CONFIG_ARCH_MSM8960) := 0x0020 · line 151
Quoted 8 lines
arch/arm/Makefile +1
-1@@ -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 2/5 ARM: bcm4760: Add platform infrastructure
In reply to Domenico AndreoliAn 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
In reply to Domenico AndreoliAn 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
In reply to Domenico AndreoliAn 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
In reply to Domenico AndreoliAn 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>
v2 cover ARM: Broadcom BCM4760 support
In reply to Domenico AndreoliDomenico,
Quoted 8 lines · 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.
Please separate devicetree binding documentation from code changes and make sure those patches are Cc:'d to devicetree at vger.kernel.org.
thx,
Jason.