| Message ID | 1373982727-5492-1-git-send-email-hauke@hauke-m.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Hauke, On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote: > This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. > Currently just booting to a shell is working and nothing else, no > Ethernet, wifi, flash, ... > > This SoC uses a Dual core CPU, but this is currently not implemented. > More information about this SoC can be found here: > http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers > > Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> > --- > > A bootlog can be found here: > http://pastebin.com/0MYYC7Fx > > MAINTAINERS | 7 +++ > arch/arm/Kconfig | 2 + > arch/arm/Kconfig.debug | 5 ++ > arch/arm/Makefile | 1 + > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/bcm5301x-netgear-r6250.dts | 20 +++++++ > arch/arm/boot/dts/bcm5301x.dtsi | 72 ++++++++++++++++++++++++++ > arch/arm/include/debug/bcm53xx.S | 19 +++++++ > arch/arm/mach-bcm53xx/Kconfig | 10 ++++ > arch/arm/mach-bcm53xx/Makefile | 1 + > arch/arm/mach-bcm53xx/bcm53xx.c | 68 ++++++++++++++++++++++++ > 11 files changed, 206 insertions(+) > create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts > create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi > create mode 100644 arch/arm/include/debug/bcm53xx.S > create mode 100644 arch/arm/mach-bcm53xx/Kconfig > create mode 100644 arch/arm/mach-bcm53xx/Makefile > create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index bf61e04..b72ba65 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1795,6 +1795,13 @@ F: arch/arm/boot/dts/bcm2835* > F: arch/arm/configs/bcm2835_defconfig > F: drivers/*/*bcm2835* > > +BROADCOM BCM53XX ARM ARCHICTURE > +M: Hauke Mehrtens <hauke@hauke-m.de> > +L: linux-arm-kernel@lists.infradead.org > +S: Maintained > +F: arch/arm/mach-bcm53xx/ > +F: arch/arm/boot/dts/bcm53* > + > BROADCOM TG3 GIGABIT ETHERNET DRIVER > M: Nithin Nayak Sujir <nsujir@broadcom.com> > M: Michael Chan <mchan@broadcom.com> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index ba412e0..ee7362e 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig" > > source "arch/arm/mach-bcm2835/Kconfig" > > +source "arch/arm/mach-bcm53xx/Kconfig" > + > source "arch/arm/mach-clps711x/Kconfig" > > source "arch/arm/mach-cns3xxx/Kconfig" > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index e401a76..74e32f6 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -93,6 +93,10 @@ choice > bool "Kernel low-level debugging on BCM2835 PL011 UART" > depends on ARCH_BCM2835 > > + config DEBUG_BCM53XX > + bool "Kernel low-level debugging on BCM53XX UART1" > + depends on ARCH_BCM53XX > + > config DEBUG_CLPS711X_UART1 > bool "Kernel low-level debugging messages via UART1" > depends on ARCH_CLPS711X > @@ -762,6 +766,7 @@ endchoice > config DEBUG_LL_INCLUDE > string > default "debug/bcm2835.S" if DEBUG_BCM2835 > + default "debug/bcm53xx.S" if DEBUG_BCM53XX > default "debug/cns3xxx.S" if DEBUG_CNS3XXX > default "debug/exynos.S" if DEBUG_EXYNOS_UART > default "debug/highbank.S" if DEBUG_HIGHBANK_UART > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index c0ac0f5..4a69cd5 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000 > machine-$(CONFIG_ARCH_AT91) += at91 > machine-$(CONFIG_ARCH_BCM) += bcm > machine-$(CONFIG_ARCH_BCM2835) += bcm2835 > +machine-$(CONFIG_ARCH_BCM53XX) += bcm53xx > machine-$(CONFIG_ARCH_CLPS711X) += clps711x > machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx > machine-$(CONFIG_ARCH_DAVINCI) += davinci > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 641b3c9..480a68e 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ > dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ > zynq-zc706.dtb \ > zynq-zed.dtb > +dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb > > targets += dtbs > targets += $(dtb-y) > diff --git a/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts > new file mode 100644 > index 0000000..d1b97aa > --- /dev/null > +++ b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts > @@ -0,0 +1,20 @@ > +/* > + * Broadcom BCM47XX / BCM53XX arm platform code. > + * > + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > + * > + * Licensed under the GNU/GPL. See COPYING for details. > + */ > + > +/dts-v1/; > + > +/include/ "bcm5301x.dtsi" > + > +/ { > + model = "Netgear R6250 V1 (BCM4708)"; > + compatible = "netgear,r6250v1", "brcm,bcm5301x"; > + > + memory { > + reg = <0x00000000 0x08000000>; > + }; > +}; > diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi > new file mode 100644 > index 0000000..638350d > --- /dev/null > +++ b/arch/arm/boot/dts/bcm5301x.dtsi > @@ -0,0 +1,72 @@ > +/* > + * Broadcom BCM47XX / BCM53XX ARM platform code. > + * > + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > + * > + * Licensed under the GNU/GPL. See COPYING for details. > + */ > + > +/include/ "skeleton.dtsi" > + > +/ { > + compatible = "brcm,bcm5301x"; Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board. Arnd, any thoughts here? Another thing is that this is missing a binding definition for this compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt for an example. You should split this patch out separately as the DT maintainers generally want to see bindings as a separate patch for easy independent review. Last thing, compatible strings are not to have wildcards in them. See http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property and note the Warning at the bottom. Also see how bcm2835.txt and bcm11351.txt use a specific model. > + model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC"; > + interrupt-parent = <&gic>; > + > + chosen { > + bootargs = "console=ttyS0,115200 earlyprintk debug"; > + }; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a9"; > + reg = <0>; > + }; > + }; > + > + clocks { > + #address-cells = <1>; > + #size-cells = <0>; > + > + clk_periph: periph { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <400000000>; > + }; > + }; > + > + uart@18000300 { > + compatible = "ns16550"; > + reg = <0x18000300 0x100>; > + interrupts = <0 85 4>; The DT files should be switched to use the C preprocessor like several other machines have already done (see bcm11351.dtsi, for example), you can use the existing GIC includes and have human-redable defines for the edge/level values here and throughout all interrupt properties. > + clock-frequency = <100000000>; > + }; > + > + uart@18000400 { > + compatible = "ns16550"; > + reg = <0x18000400 0x100>; > + interrupts = <0 85 4>; > + clock-frequency = <100000000>; > + }; > + > + gic: interrupt-controller@19021000 { > + compatible = "arm,cortex-a9-gic"; > + #interrupt-cells = <3>; > + #address-cells = <0>; > + interrupt-controller; > + reg = <0x19021000 0x1000>, > + <0x19020100 0x100>; > + }; > + > + timer@19020200 { > + compatible = "arm,cortex-a9-global-timer"; > + reg = <0x19020200 0x100>; > + interrupts = <1 11 0xf04>; > + clocks = <&clk_periph>; > + #clock-cells = <0>; > + }; > +}; > diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S > new file mode 100644 > index 0000000..98c836b > --- /dev/null > +++ b/arch/arm/include/debug/bcm53xx.S > @@ -0,0 +1,19 @@ > +/* > + * Macros used for EARLY_PRINTK, in low-level UART debug console > + * > + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > + * > + * Licensed under the GNU/GPL. See COPYING for details. > + */ > + > +#define BCM53XX_UART1_PHYS 0x18000300 > +#define BCM53XX_UART1_VIRT 0xf1000300 > +#define BCM53XX_UART1_SH 0 > + > + .macro addruart, rp, rv, tmp > + ldr \rp, =BCM53XX_UART1_PHYS @ MMU off, Physical > + ldr \rv, =BCM53XX_UART1_VIRT @ MMU on, Virtual > + .endm > + > +#define UART_SHIFT BCM53XX_UART1_SH > +#include <asm/hardware/debug-8250.S> > diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig > new file mode 100644 > index 0000000..1e16e87 > --- /dev/null > +++ b/arch/arm/mach-bcm53xx/Kconfig > @@ -0,0 +1,10 @@ > +config ARCH_BCM53XX > + bool "Broadcom BCM47XX / BCM53XX ARM SoC" > + select CPU_V7 > + select ARM_GIC > + select HAVE_CLK > + select GENERIC_CLOCKEVENTS > + select GENERIC_TIME > + select ARM_GLOBAL_TIMER > + help > + Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores. > diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile > new file mode 100644 > index 0000000..88da84d > --- /dev/null > +++ b/arch/arm/mach-bcm53xx/Makefile > @@ -0,0 +1 @@ > +obj-y += bcm53xx.o > diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c > new file mode 100644 > index 0000000..aa5bd397 > --- /dev/null > +++ b/arch/arm/mach-bcm53xx/bcm53xx.c > @@ -0,0 +1,68 @@ > +/* > + * Broadcom BCM47XX / BCM53XX ARM platform code. > + * > + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > + * > + * Licensed under the GNU/GPL. See COPYING for details. > + */ > +#include <linux/of_address.h> > +#include <linux/of_platform.h> > +#include <linux/irqchip.h> > +#include <linux/clocksource.h> > +#include <linux/clk-provider.h> > + > +#include <asm/mach/arch.h> > +#include <asm/mach/map.h> > +#include <asm/signal.h> > + > +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, > + struct pt_regs *regs) > +{ > + /* > + * These happen for no good reason > + * possibly left over from CFE > + */ > + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", > + addr, fsr); > + > + /* Returning non-zero causes fault display and panic */ > + return 0; > +} > + > +static void bcm53xx_aborts_enable(void) > +{ > + /* Install our hook */ > + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, > + "imprecise external abort"); > +} > + > +static void __init bcm53xx_timer_init(void) > +{ > + of_clk_init(NULL); > + clocksource_of_init(); > +} > + > +void __init bcm53xx_map_io(void) > +{ > + debug_ll_io_init(); > + bcm53xx_aborts_enable(); > +} > + > +static void __init bcm53xx_dt_init(void) > +{ > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > +} > + > +static const char const *bcm53xx_dt_compat[] = { > + "brcm,bcm5301x", > + "netgear,r6250v1", > + NULL, > +}; > + > +DT_MACHINE_START(BCM53XX, "BCM53XX") > + .init_machine = bcm53xx_dt_init, > + .map_io = bcm53xx_map_io, > + .init_irq = irqchip_init, > + .init_time = bcm53xx_timer_init, > + .dt_compat = bcm53xx_dt_compat, > +MACHINE_END > -- > 1.7.10.4 >
Dear Hauke Mehrtens, On Tue, 16 Jul 2013 15:52:07 +0200, Hauke Mehrtens wrote: > +/include/ "bcm5301x.dtsi" > + > +/ { > + model = "Netgear R6250 V1 (BCM4708)"; > + compatible = "netgear,r6250v1", "brcm,bcm5301x"; I don't think using "brcm,bcm5301x" has a compatible string is very appropriate. It should really reflect which particular SoC this board is using. > diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi > new file mode 100644 > index 0000000..638350d > --- /dev/null > +++ b/arch/arm/boot/dts/bcm5301x.dtsi > @@ -0,0 +1,72 @@ > +/* > + * Broadcom BCM47XX / BCM53XX ARM platform code. > + * > + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > + * > + * Licensed under the GNU/GPL. See COPYING for details. > + */ > + > +/include/ "skeleton.dtsi" > + > +/ { > + compatible = "brcm,bcm5301x"; > + model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC"; Same here. Most likely, there will be difference between those SoCs, so a compatible string of bcm5301x doesn't seem right, and also the model that says this will handle all those platforms. > diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig > new file mode 100644 > index 0000000..1e16e87 > --- /dev/null > +++ b/arch/arm/mach-bcm53xx/Kconfig > @@ -0,0 +1,10 @@ > +config ARCH_BCM53XX > + bool "Broadcom BCM47XX / BCM53XX ARM SoC" So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow. > +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, > + struct pt_regs *regs) > +{ > + /* > + * These happen for no good reason > + * possibly left over from CFE CFE ? > + */ > + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", > + addr, fsr); > + > + /* Returning non-zero causes fault display and panic */ > + return 0; > +} > + > +static void bcm53xx_aborts_enable(void) > +{ > + /* Install our hook */ > + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, > + "imprecise external abort"); > +} > + > +static void __init bcm53xx_timer_init(void) > +{ > + of_clk_init(NULL); > + clocksource_of_init(); > +} > + > +void __init bcm53xx_map_io(void) > +{ > + debug_ll_io_init(); > + bcm53xx_aborts_enable(); > +} That's a nitpick, but I personally tend to like when callbacks are ordered as they are called, i.e ->map_io() first, and then ->init_time(). > +static void __init bcm53xx_dt_init(void) > +{ > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > +} Not needed, this is the default. When ->init_machine() is NULL, the ARM core already calls automatically of_platform_populate(). > + > +static const char const *bcm53xx_dt_compat[] = { > + "brcm,bcm5301x", > + "netgear,r6250v1", > + NULL, Don't list the boards here, only the SoCs. Otherwise, this place is going to become a nightmare of conflicts. > +DT_MACHINE_START(BCM53XX, "BCM53XX") > + .init_machine = bcm53xx_dt_init, > + .map_io = bcm53xx_map_io, > + .init_irq = irqchip_init, > + .init_time = bcm53xx_timer_init, > + .dt_compat = bcm53xx_dt_compat, > +MACHINE_END You also probably want to add this new platform to the multi_v7_defconfig. Best regards, Thomas
On 07/16/2013 05:20 PM, Thomas Petazzoni wrote: > Dear Hauke Mehrtens, > > On Tue, 16 Jul 2013 15:52:07 +0200, Hauke Mehrtens wrote: >> +/include/ "bcm5301x.dtsi" >> + >> +/ { >> + model = "Netgear R6250 V1 (BCM4708)"; >> + compatible = "netgear,r6250v1", "brcm,bcm5301x"; > > I don't think using "brcm,bcm5301x" has a compatible string is very > appropriate. It should really reflect which particular SoC this board > is using. Ok I will change this to brcm,bcm4708 > >> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi >> new file mode 100644 >> index 0000000..638350d >> --- /dev/null >> +++ b/arch/arm/boot/dts/bcm5301x.dtsi >> @@ -0,0 +1,72 @@ >> +/* >> + * Broadcom BCM47XX / BCM53XX ARM platform code. >> + * >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >> + * >> + * Licensed under the GNU/GPL. See COPYING for details. >> + */ >> + >> +/include/ "skeleton.dtsi" >> + >> +/ { >> + compatible = "brcm,bcm5301x"; >> + model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC"; > > Same here. Most likely, there will be difference between those SoCs, so > a compatible string of bcm5301x doesn't seem right, and also the model > that says this will handle all those platforms. This should just be a generic file describing the SoC series. I do not know how different the SoCs from this series are, because I just own one device. ;-) For the older Mips versions of this SoC line all the SoCs announced together just had very tiny differences according to the vendor code it is the same here. > >> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig >> new file mode 100644 >> index 0000000..1e16e87 >> --- /dev/null >> +++ b/arch/arm/mach-bcm53xx/Kconfig >> @@ -0,0 +1,10 @@ >> +config ARCH_BCM53XX >> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" > > So the directory is named mach-bcm53xx, but you also handle BCM47xx > SoCs. This doesn't sound really easy to follow. Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I do not know why there are two different names, probably marketing. Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to not conflict with the MIPS part now. I know this could still cause problems and people will get confused, but I do not know a better name. > >> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, >> + struct pt_regs *regs) >> +{ >> + /* >> + * These happen for no good reason >> + * possibly left over from CFE > > CFE ? Common Firmware Environment This is the boot loader used by Broadcom on these devices: https://en.wikipedia.org/wiki/Common_Firmware_Environment >> + */ >> + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", >> + addr, fsr); >> + >> + /* Returning non-zero causes fault display and panic */ >> + return 0; >> +} >> + >> +static void bcm53xx_aborts_enable(void) >> +{ >> + /* Install our hook */ >> + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, >> + "imprecise external abort"); >> +} >> + >> +static void __init bcm53xx_timer_init(void) >> +{ >> + of_clk_init(NULL); >> + clocksource_of_init(); >> +} >> + >> +void __init bcm53xx_map_io(void) >> +{ >> + debug_ll_io_init(); >> + bcm53xx_aborts_enable(); >> +} > > That's a nitpick, but I personally tend to like when callbacks are > ordered as they are called, i.e ->map_io() first, and then > ->init_time(). Good point. >> +static void __init bcm53xx_dt_init(void) >> +{ >> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); >> +} > > Not needed, this is the default. When ->init_machine() is NULL, the ARM > core already calls automatically of_platform_populate(). Thanks for the Info. >> + >> +static const char const *bcm53xx_dt_compat[] = { >> + "brcm,bcm5301x", >> + "netgear,r6250v1", >> + NULL, > > Don't list the boards here, only the SoCs. Otherwise, this place is > going to become a nightmare of conflicts. Ok I will change this. >> +DT_MACHINE_START(BCM53XX, "BCM53XX") >> + .init_machine = bcm53xx_dt_init, >> + .map_io = bcm53xx_map_io, >> + .init_irq = irqchip_init, >> + .init_time = bcm53xx_timer_init, >> + .dt_compat = bcm53xx_dt_compat, >> +MACHINE_END > > You also probably want to add this new platform to the > multi_v7_defconfig. > > Best regards, > > Thomas >
On 07/16/2013 05:14 PM, Matt Porter wrote: > Hi Hauke, > > On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote: >> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. >> Currently just booting to a shell is working and nothing else, no >> Ethernet, wifi, flash, ... >> >> This SoC uses a Dual core CPU, but this is currently not implemented. >> More information about this SoC can be found here: >> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers >> >> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> >> --- >> >> A bootlog can be found here: >> http://pastebin.com/0MYYC7Fx >> >> MAINTAINERS | 7 +++ >> arch/arm/Kconfig | 2 + >> arch/arm/Kconfig.debug | 5 ++ >> arch/arm/Makefile | 1 + >> arch/arm/boot/dts/Makefile | 1 + >> arch/arm/boot/dts/bcm5301x-netgear-r6250.dts | 20 +++++++ >> arch/arm/boot/dts/bcm5301x.dtsi | 72 ++++++++++++++++++++++++++ >> arch/arm/include/debug/bcm53xx.S | 19 +++++++ >> arch/arm/mach-bcm53xx/Kconfig | 10 ++++ >> arch/arm/mach-bcm53xx/Makefile | 1 + >> arch/arm/mach-bcm53xx/bcm53xx.c | 68 ++++++++++++++++++++++++ >> 11 files changed, 206 insertions(+) >> create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts >> create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi >> create mode 100644 arch/arm/include/debug/bcm53xx.S >> create mode 100644 arch/arm/mach-bcm53xx/Kconfig >> create mode 100644 arch/arm/mach-bcm53xx/Makefile >> create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index bf61e04..b72ba65 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -1795,6 +1795,13 @@ F: arch/arm/boot/dts/bcm2835* >> F: arch/arm/configs/bcm2835_defconfig >> F: drivers/*/*bcm2835* >> >> +BROADCOM BCM53XX ARM ARCHICTURE >> +M: Hauke Mehrtens <hauke@hauke-m.de> >> +L: linux-arm-kernel@lists.infradead.org >> +S: Maintained >> +F: arch/arm/mach-bcm53xx/ >> +F: arch/arm/boot/dts/bcm53* >> + >> BROADCOM TG3 GIGABIT ETHERNET DRIVER >> M: Nithin Nayak Sujir <nsujir@broadcom.com> >> M: Michael Chan <mchan@broadcom.com> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index ba412e0..ee7362e 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig" >> >> source "arch/arm/mach-bcm2835/Kconfig" >> >> +source "arch/arm/mach-bcm53xx/Kconfig" >> + >> source "arch/arm/mach-clps711x/Kconfig" >> >> source "arch/arm/mach-cns3xxx/Kconfig" >> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug >> index e401a76..74e32f6 100644 >> --- a/arch/arm/Kconfig.debug >> +++ b/arch/arm/Kconfig.debug >> @@ -93,6 +93,10 @@ choice >> bool "Kernel low-level debugging on BCM2835 PL011 UART" >> depends on ARCH_BCM2835 >> >> + config DEBUG_BCM53XX >> + bool "Kernel low-level debugging on BCM53XX UART1" >> + depends on ARCH_BCM53XX >> + >> config DEBUG_CLPS711X_UART1 >> bool "Kernel low-level debugging messages via UART1" >> depends on ARCH_CLPS711X >> @@ -762,6 +766,7 @@ endchoice >> config DEBUG_LL_INCLUDE >> string >> default "debug/bcm2835.S" if DEBUG_BCM2835 >> + default "debug/bcm53xx.S" if DEBUG_BCM53XX >> default "debug/cns3xxx.S" if DEBUG_CNS3XXX >> default "debug/exynos.S" if DEBUG_EXYNOS_UART >> default "debug/highbank.S" if DEBUG_HIGHBANK_UART >> diff --git a/arch/arm/Makefile b/arch/arm/Makefile >> index c0ac0f5..4a69cd5 100644 >> --- a/arch/arm/Makefile >> +++ b/arch/arm/Makefile >> @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000 >> machine-$(CONFIG_ARCH_AT91) += at91 >> machine-$(CONFIG_ARCH_BCM) += bcm >> machine-$(CONFIG_ARCH_BCM2835) += bcm2835 >> +machine-$(CONFIG_ARCH_BCM53XX) += bcm53xx >> machine-$(CONFIG_ARCH_CLPS711X) += clps711x >> machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx >> machine-$(CONFIG_ARCH_DAVINCI) += davinci >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> index 641b3c9..480a68e 100644 >> --- a/arch/arm/boot/dts/Makefile >> +++ b/arch/arm/boot/dts/Makefile >> @@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ >> dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ >> zynq-zc706.dtb \ >> zynq-zed.dtb >> +dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb >> >> targets += dtbs >> targets += $(dtb-y) >> diff --git a/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts >> new file mode 100644 >> index 0000000..d1b97aa >> --- /dev/null >> +++ b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts >> @@ -0,0 +1,20 @@ >> +/* >> + * Broadcom BCM47XX / BCM53XX arm platform code. >> + * >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >> + * >> + * Licensed under the GNU/GPL. See COPYING for details. >> + */ >> + >> +/dts-v1/; >> + >> +/include/ "bcm5301x.dtsi" >> + >> +/ { >> + model = "Netgear R6250 V1 (BCM4708)"; >> + compatible = "netgear,r6250v1", "brcm,bcm5301x"; >> + >> + memory { >> + reg = <0x00000000 0x08000000>; >> + }; >> +}; >> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi >> new file mode 100644 >> index 0000000..638350d >> --- /dev/null >> +++ b/arch/arm/boot/dts/bcm5301x.dtsi >> @@ -0,0 +1,72 @@ >> +/* >> + * Broadcom BCM47XX / BCM53XX ARM platform code. >> + * >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >> + * >> + * Licensed under the GNU/GPL. See COPYING for details. >> + */ >> + >> +/include/ "skeleton.dtsi" >> + >> +/ { >> + compatible = "brcm,bcm5301x"; > > Ok, this was nagging at me before I went on my very long vacation. I see > the "brcm" vendor prefix as a real consistency problem. I noticed on the > bcm281xx/kona family, we have been using "bcm" which is not logged in > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > already established use of "brcm" before any of the bcm281xx support > came in. Ideally, the vendor prefix should change to "bcm" since every > reference in the family names is BCM. However, if others want the least > amount of churn in making this consistent, we might have to go with > "brcm" across the board. > > Arnd, any thoughts here? I have no problem with bcm or with brcm. This is a Broadcom Chip and their names are starting with bcm. > Another thing is that this is missing a binding definition for this > compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt > for an example. You should split this patch out separately as the DT > maintainers generally want to see bindings as a separate patch for easy > independent review. Ok I will do that. This will then be merged by Linus in the 3.12 merge window into a working version or how does this work? Currently I have based this patch on top of 3.11-rc1 on which tree should I base my changes? > Last thing, compatible strings are not to have wildcards in them. See > http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property > and note the Warning at the bottom. Also see how bcm2835.txt and > bcm11351.txt use a specific model. Ok will do that. >> + model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC"; >> + interrupt-parent = <&gic>; >> + >> + chosen { >> + bootargs = "console=ttyS0,115200 earlyprintk debug"; >> + }; >> + >> + cpus { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + cpu@0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a9"; >> + reg = <0>; >> + }; >> + }; >> + >> + clocks { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + clk_periph: periph { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <400000000>; >> + }; >> + }; >> + >> + uart@18000300 { >> + compatible = "ns16550"; >> + reg = <0x18000300 0x100>; >> + interrupts = <0 85 4>; > > The DT files should be switched to use the C preprocessor like several > other machines have already done (see bcm11351.dtsi, for example), you > can use the existing GIC includes and have human-redable defines for the > edge/level values here and throughout all interrupt properties. Ok I will read that and change it. >> + clock-frequency = <100000000>; >> + }; >> + >> + uart@18000400 { >> + compatible = "ns16550"; >> + reg = <0x18000400 0x100>; >> + interrupts = <0 85 4>; >> + clock-frequency = <100000000>; >> + }; >> + >> + gic: interrupt-controller@19021000 { >> + compatible = "arm,cortex-a9-gic"; >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x19021000 0x1000>, >> + <0x19020100 0x100>; >> + }; >> + >> + timer@19020200 { >> + compatible = "arm,cortex-a9-global-timer"; >> + reg = <0x19020200 0x100>; >> + interrupts = <1 11 0xf04>; >> + clocks = <&clk_periph>; >> + #clock-cells = <0>; >> + }; >> +}; >> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S >> new file mode 100644 >> index 0000000..98c836b >> --- /dev/null >> +++ b/arch/arm/include/debug/bcm53xx.S >> @@ -0,0 +1,19 @@ >> +/* >> + * Macros used for EARLY_PRINTK, in low-level UART debug console >> + * >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >> + * >> + * Licensed under the GNU/GPL. See COPYING for details. >> + */ >> + >> +#define BCM53XX_UART1_PHYS 0x18000300 >> +#define BCM53XX_UART1_VIRT 0xf1000300 >> +#define BCM53XX_UART1_SH 0 >> + >> + .macro addruart, rp, rv, tmp >> + ldr \rp, =BCM53XX_UART1_PHYS @ MMU off, Physical >> + ldr \rv, =BCM53XX_UART1_VIRT @ MMU on, Virtual >> + .endm >> + >> +#define UART_SHIFT BCM53XX_UART1_SH >> +#include <asm/hardware/debug-8250.S> >> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig >> new file mode 100644 >> index 0000000..1e16e87 >> --- /dev/null >> +++ b/arch/arm/mach-bcm53xx/Kconfig >> @@ -0,0 +1,10 @@ >> +config ARCH_BCM53XX >> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" >> + select CPU_V7 >> + select ARM_GIC >> + select HAVE_CLK >> + select GENERIC_CLOCKEVENTS >> + select GENERIC_TIME >> + select ARM_GLOBAL_TIMER >> + help >> + Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores. >> diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile >> new file mode 100644 >> index 0000000..88da84d >> --- /dev/null >> +++ b/arch/arm/mach-bcm53xx/Makefile >> @@ -0,0 +1 @@ >> +obj-y += bcm53xx.o >> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c >> new file mode 100644 >> index 0000000..aa5bd397 >> --- /dev/null >> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c >> @@ -0,0 +1,68 @@ >> +/* >> + * Broadcom BCM47XX / BCM53XX ARM platform code. >> + * >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >> + * >> + * Licensed under the GNU/GPL. See COPYING for details. >> + */ >> +#include <linux/of_address.h> >> +#include <linux/of_platform.h> >> +#include <linux/irqchip.h> >> +#include <linux/clocksource.h> >> +#include <linux/clk-provider.h> >> + >> +#include <asm/mach/arch.h> >> +#include <asm/mach/map.h> >> +#include <asm/signal.h> >> + >> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, >> + struct pt_regs *regs) >> +{ >> + /* >> + * These happen for no good reason >> + * possibly left over from CFE >> + */ >> + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", >> + addr, fsr); >> + >> + /* Returning non-zero causes fault display and panic */ >> + return 0; >> +} >> + >> +static void bcm53xx_aborts_enable(void) >> +{ >> + /* Install our hook */ >> + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, >> + "imprecise external abort"); >> +} >> + >> +static void __init bcm53xx_timer_init(void) >> +{ >> + of_clk_init(NULL); >> + clocksource_of_init(); >> +} >> + >> +void __init bcm53xx_map_io(void) >> +{ >> + debug_ll_io_init(); >> + bcm53xx_aborts_enable(); >> +} >> + >> +static void __init bcm53xx_dt_init(void) >> +{ >> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); >> +} >> + >> +static const char const *bcm53xx_dt_compat[] = { >> + "brcm,bcm5301x", >> + "netgear,r6250v1", >> + NULL, >> +}; >> + >> +DT_MACHINE_START(BCM53XX, "BCM53XX") >> + .init_machine = bcm53xx_dt_init, >> + .map_io = bcm53xx_map_io, >> + .init_irq = irqchip_init, >> + .init_time = bcm53xx_timer_init, >> + .dt_compat = bcm53xx_dt_compat, >> +MACHINE_END >> -- >> 1.7.10.4 >>
On 07/16/2013 05:39 PM, Hauke Mehrtens wrote: > On 07/16/2013 05:14 PM, Matt Porter wrote: >> Hi Hauke, >> >> On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote: >>> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. >>> Currently just booting to a shell is working and nothing else, no >>> Ethernet, wifi, flash, ... >>> >>> This SoC uses a Dual core CPU, but this is currently not implemented. >>> More information about this SoC can be found here: >>> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers >>> >>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> >>> --- .... >>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi >>> new file mode 100644 >>> index 0000000..638350d >>> --- /dev/null >>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi >>> @@ -0,0 +1,72 @@ >>> +/* >>> + * Broadcom BCM47XX / BCM53XX ARM platform code. >>> + * >>> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >>> + * >>> + * Licensed under the GNU/GPL. See COPYING for details. >>> + */ >>> + >>> +/include/ "skeleton.dtsi" >>> + >>> +/ { >>> + compatible = "brcm,bcm5301x"; >> >> Ok, this was nagging at me before I went on my very long vacation. I see >> the "brcm" vendor prefix as a real consistency problem. I noticed on the >> bcm281xx/kona family, we have been using "bcm" which is not logged in >> vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had >> already established use of "brcm" before any of the bcm281xx support >> came in. Ideally, the vendor prefix should change to "bcm" since every >> reference in the family names is BCM. However, if others want the least >> amount of churn in making this consistent, we might have to go with >> "brcm" across the board. >> >> Arnd, any thoughts here? > > I have no problem with bcm or with brcm. This is a Broadcom Chip and > their names are starting with bcm. > >> Another thing is that this is missing a binding definition for this >> compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt >> for an example. You should split this patch out separately as the DT >> maintainers generally want to see bindings as a separate patch for easy >> independent review. > > Ok I will do that. This will then be merged by Linus in the 3.12 merge > window into a working version or how does this work? > > Currently I have based this patch on top of 3.11-rc1 on which tree > should I base my changes? Should I split out the *.dts files in arch/arm/boot/dts/ and the documentation for brcm,bcm4708 into an other patch? >> Last thing, compatible strings are not to have wildcards in them. See >> http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property >> and note the Warning at the bottom. Also see how bcm2835.txt and >> bcm11351.txt use a specific model. > > Ok will do that. Do I understand this right that I should currently name it exactly like the SoC I know and when a new SoC pops up I should make it compatible to this SoC? I would change this to: compatible = "brcm,bcm4708"; If I find a BCM4709 SoC I will add this like to its dts file, assuming they are mostly the same? compatible = "brcm,bcm4709", "brcm,bcm4708"; > >>> + model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC"; >>> + interrupt-parent = <&gic>; >>> + >>> + chosen { >>> + bootargs = "console=ttyS0,115200 earlyprintk debug"; >>> + }; >>> + >>> + cpus { >>> + #address-cells = <1>; >>> + #size-cells = <0>; >>> + >>> + cpu@0 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a9"; >>> + reg = <0>; >>> + }; >>> + }; >>> + >>> + clocks { >>> + #address-cells = <1>; >>> + #size-cells = <0>; >>> + >>> + clk_periph: periph { >>> + compatible = "fixed-clock"; >>> + #clock-cells = <0>; >>> + clock-frequency = <400000000>; >>> + }; >>> + }; >>> + >>> + uart@18000300 { >>> + compatible = "ns16550"; >>> + reg = <0x18000300 0x100>; >>> + interrupts = <0 85 4>; >> >> The DT files should be switched to use the C preprocessor like several >> other machines have already done (see bcm11351.dtsi, for example), you >> can use the existing GIC includes and have human-redable defines for the >> edge/level values here and throughout all interrupt properties. > > Ok I will read that and change it. > >>> + clock-frequency = <100000000>; >>> + }; >>> + >>> + uart@18000400 { >>> + compatible = "ns16550"; >>> + reg = <0x18000400 0x100>; >>> + interrupts = <0 85 4>; >>> + clock-frequency = <100000000>; >>> + }; >>> + >>> + gic: interrupt-controller@19021000 { >>> + compatible = "arm,cortex-a9-gic"; >>> + #interrupt-cells = <3>; >>> + #address-cells = <0>; >>> + interrupt-controller; >>> + reg = <0x19021000 0x1000>, >>> + <0x19020100 0x100>; >>> + }; >>> + >>> + timer@19020200 { >>> + compatible = "arm,cortex-a9-global-timer"; >>> + reg = <0x19020200 0x100>; >>> + interrupts = <1 11 0xf04>; >>> + clocks = <&clk_periph>; >>> + #clock-cells = <0>; >>> + }; >>> +}; >>> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S >>> new file mode 100644 >>> index 0000000..98c836b >>> --- /dev/null >>> +++ b/arch/arm/include/debug/bcm53xx.S >>> @@ -0,0 +1,19 @@ >>> +/* >>> + * Macros used for EARLY_PRINTK, in low-level UART debug console >>> + * >>> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >>> + * >>> + * Licensed under the GNU/GPL. See COPYING for details. >>> + */ >>> + >>> +#define BCM53XX_UART1_PHYS 0x18000300 >>> +#define BCM53XX_UART1_VIRT 0xf1000300 >>> +#define BCM53XX_UART1_SH 0 >>> + >>> + .macro addruart, rp, rv, tmp >>> + ldr \rp, =BCM53XX_UART1_PHYS @ MMU off, Physical >>> + ldr \rv, =BCM53XX_UART1_VIRT @ MMU on, Virtual >>> + .endm >>> + >>> +#define UART_SHIFT BCM53XX_UART1_SH >>> +#include <asm/hardware/debug-8250.S> >>> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig >>> new file mode 100644 >>> index 0000000..1e16e87 >>> --- /dev/null >>> +++ b/arch/arm/mach-bcm53xx/Kconfig >>> @@ -0,0 +1,10 @@ >>> +config ARCH_BCM53XX >>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" >>> + select CPU_V7 >>> + select ARM_GIC >>> + select HAVE_CLK >>> + select GENERIC_CLOCKEVENTS >>> + select GENERIC_TIME >>> + select ARM_GLOBAL_TIMER >>> + help >>> + Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores. >>> diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile >>> new file mode 100644 >>> index 0000000..88da84d >>> --- /dev/null >>> +++ b/arch/arm/mach-bcm53xx/Makefile >>> @@ -0,0 +1 @@ >>> +obj-y += bcm53xx.o >>> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c >>> new file mode 100644 >>> index 0000000..aa5bd397 >>> --- /dev/null >>> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c >>> @@ -0,0 +1,68 @@ >>> +/* >>> + * Broadcom BCM47XX / BCM53XX ARM platform code. >>> + * >>> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >>> + * >>> + * Licensed under the GNU/GPL. See COPYING for details. >>> + */ >>> +#include <linux/of_address.h> >>> +#include <linux/of_platform.h> >>> +#include <linux/irqchip.h> >>> +#include <linux/clocksource.h> >>> +#include <linux/clk-provider.h> >>> + >>> +#include <asm/mach/arch.h> >>> +#include <asm/mach/map.h> >>> +#include <asm/signal.h> >>> + >>> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, >>> + struct pt_regs *regs) >>> +{ >>> + /* >>> + * These happen for no good reason >>> + * possibly left over from CFE >>> + */ >>> + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", >>> + addr, fsr); >>> + >>> + /* Returning non-zero causes fault display and panic */ >>> + return 0; >>> +} >>> + >>> +static void bcm53xx_aborts_enable(void) >>> +{ >>> + /* Install our hook */ >>> + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, >>> + "imprecise external abort"); >>> +} >>> + >>> +static void __init bcm53xx_timer_init(void) >>> +{ >>> + of_clk_init(NULL); >>> + clocksource_of_init(); >>> +} >>> + >>> +void __init bcm53xx_map_io(void) >>> +{ >>> + debug_ll_io_init(); >>> + bcm53xx_aborts_enable(); >>> +} >>> + >>> +static void __init bcm53xx_dt_init(void) >>> +{ >>> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); >>> +} >>> + >>> +static const char const *bcm53xx_dt_compat[] = { >>> + "brcm,bcm5301x", >>> + "netgear,r6250v1", >>> + NULL, >>> +}; >>> + >>> +DT_MACHINE_START(BCM53XX, "BCM53XX") >>> + .init_machine = bcm53xx_dt_init, >>> + .map_io = bcm53xx_map_io, >>> + .init_irq = irqchip_init, >>> + .init_time = bcm53xx_timer_init, >>> + .dt_compat = bcm53xx_dt_compat, >>> +MACHINE_END >>> -- >>> 1.7.10.4 >>> >
Hello, Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : > > + compatible = "brcm,bcm5301x"; > > Ok, this was nagging at me before I went on my very long vacation. I see > the "brcm" vendor prefix as a real consistency problem. I noticed on the > bcm281xx/kona family, we have been using "bcm" which is not logged in > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > already established use of "brcm" before any of the bcm281xx support > came in. Ideally, the vendor prefix should change to "bcm" since every > reference in the family names is BCM. However, if others want the least > amount of churn in making this consistent, we might have to go with > "brcm" across the board. I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let the bcm281x/kona family support code be merged and use "bcm" there, without registering it. Besides, a simple rule of number here wins: git grep "brcm," * | wc -l 63 git grep "bcm," * | wc -l 25 (as of Linux 3.11-rc1) So consistency we should get the bcm281x/kona DT bindings to rename their vendor prefix as well.
On Tue, Jul 16, 2013 at 05:20:23PM +0200, Thomas Petazzoni wrote: > Dear Hauke Mehrtens, > > On Tue, 16 Jul 2013 15:52:07 +0200, Hauke Mehrtens wrote: > > +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, > > + struct pt_regs *regs) > > +{ > > + /* > > + * These happen for no good reason > > + * possibly left over from CFE > > CFE ? > > > + */ > > + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", > > + addr, fsr); > > + > > + /* Returning non-zero causes fault display and panic */ > > + return 0; > > +} > > + > > +static void bcm53xx_aborts_enable(void) > > +{ > > + /* Install our hook */ > > + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, > > + "imprecise external abort"); > > +} > > + > > +static void __init bcm53xx_timer_init(void) > > +{ > > + of_clk_init(NULL); > > + clocksource_of_init(); > > +} > > + > > +void __init bcm53xx_map_io(void) > > +{ > > + debug_ll_io_init(); > > + bcm53xx_aborts_enable(); > > +} > > That's a nitpick, but I personally tend to like when callbacks are > ordered as they are called, i.e ->map_io() first, and then > ->init_time(). A more important nitpick is... it would be better to have the call to the aborts enable function in the init_early() callback, not the map_io() callback. Too often people overload stuff into these specific callbacks which makes maintanence of non-platform code pain in the butt. The init_early() callback was specifically added by me to remove this kind of crappage of map_io(). Please use it. Thanks.
On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: > Hello, > > Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : > > > + compatible = "brcm,bcm5301x"; > > > > Ok, this was nagging at me before I went on my very long vacation. I see > > the "brcm" vendor prefix as a real consistency problem. I noticed on the > > bcm281xx/kona family, we have been using "bcm" which is not logged in > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > > already established use of "brcm" before any of the bcm281xx support > > came in. Ideally, the vendor prefix should change to "bcm" since every > > reference in the family names is BCM. However, if others want the least > > amount of churn in making this consistent, we might have to go with > > "brcm" across the board. > > I would like to keep "brcm" here because that is what has been defined as a > vendor prefix, and is used beyond the scope of the ARM Linux kernel support > even within Broadcom. Maybe it was an oversight, or rather a mistake to let > the bcm281x/kona family support code be merged and use "bcm" there, without > registering it. Besides, a simple rule of number here wins: > > git grep "brcm," * | wc -l > 63 > git grep "bcm," * | wc -l > 25 > > (as of Linux 3.11-rc1) > > So consistency we should get the bcm281x/kona DT bindings to rename their > vendor prefix as well. Yeah, this is why I grudgingly agree that it should go bcm->brcm, brcm was already established and bcm is only in used on this one family so far. Even though I don't like the extra character. :) Christian: if you don't have objections here I can generate a series to update this across the board. -Matt
On Tue, Jul 16, 2013 at 05:39:46PM +0200, Hauke Mehrtens wrote: > On 07/16/2013 05:14 PM, Matt Porter wrote: > > Hi Hauke, > > > > On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote: > >> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. > >> Currently just booting to a shell is working and nothing else, no > >> Ethernet, wifi, flash, ... > >> > >> This SoC uses a Dual core CPU, but this is currently not implemented. > >> More information about this SoC can be found here: > >> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers > >> > >> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> > >> --- > >> > >> A bootlog can be found here: > >> http://pastebin.com/0MYYC7Fx > >> > >> MAINTAINERS | 7 +++ > >> arch/arm/Kconfig | 2 + > >> arch/arm/Kconfig.debug | 5 ++ > >> arch/arm/Makefile | 1 + > >> arch/arm/boot/dts/Makefile | 1 + > >> arch/arm/boot/dts/bcm5301x-netgear-r6250.dts | 20 +++++++ > >> arch/arm/boot/dts/bcm5301x.dtsi | 72 ++++++++++++++++++++++++++ > >> arch/arm/include/debug/bcm53xx.S | 19 +++++++ > >> arch/arm/mach-bcm53xx/Kconfig | 10 ++++ > >> arch/arm/mach-bcm53xx/Makefile | 1 + > >> arch/arm/mach-bcm53xx/bcm53xx.c | 68 ++++++++++++++++++++++++ > >> 11 files changed, 206 insertions(+) > >> create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts > >> create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi > >> create mode 100644 arch/arm/include/debug/bcm53xx.S > >> create mode 100644 arch/arm/mach-bcm53xx/Kconfig > >> create mode 100644 arch/arm/mach-bcm53xx/Makefile > >> create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index bf61e04..b72ba65 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -1795,6 +1795,13 @@ F: arch/arm/boot/dts/bcm2835* > >> F: arch/arm/configs/bcm2835_defconfig > >> F: drivers/*/*bcm2835* > >> > >> +BROADCOM BCM53XX ARM ARCHICTURE > >> +M: Hauke Mehrtens <hauke@hauke-m.de> > >> +L: linux-arm-kernel@lists.infradead.org > >> +S: Maintained > >> +F: arch/arm/mach-bcm53xx/ > >> +F: arch/arm/boot/dts/bcm53* > >> + > >> BROADCOM TG3 GIGABIT ETHERNET DRIVER > >> M: Nithin Nayak Sujir <nsujir@broadcom.com> > >> M: Michael Chan <mchan@broadcom.com> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >> index ba412e0..ee7362e 100644 > >> --- a/arch/arm/Kconfig > >> +++ b/arch/arm/Kconfig > >> @@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig" > >> > >> source "arch/arm/mach-bcm2835/Kconfig" > >> > >> +source "arch/arm/mach-bcm53xx/Kconfig" > >> + > >> source "arch/arm/mach-clps711x/Kconfig" > >> > >> source "arch/arm/mach-cns3xxx/Kconfig" > >> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > >> index e401a76..74e32f6 100644 > >> --- a/arch/arm/Kconfig.debug > >> +++ b/arch/arm/Kconfig.debug > >> @@ -93,6 +93,10 @@ choice > >> bool "Kernel low-level debugging on BCM2835 PL011 UART" > >> depends on ARCH_BCM2835 > >> > >> + config DEBUG_BCM53XX > >> + bool "Kernel low-level debugging on BCM53XX UART1" > >> + depends on ARCH_BCM53XX > >> + > >> config DEBUG_CLPS711X_UART1 > >> bool "Kernel low-level debugging messages via UART1" > >> depends on ARCH_CLPS711X > >> @@ -762,6 +766,7 @@ endchoice > >> config DEBUG_LL_INCLUDE > >> string > >> default "debug/bcm2835.S" if DEBUG_BCM2835 > >> + default "debug/bcm53xx.S" if DEBUG_BCM53XX > >> default "debug/cns3xxx.S" if DEBUG_CNS3XXX > >> default "debug/exynos.S" if DEBUG_EXYNOS_UART > >> default "debug/highbank.S" if DEBUG_HIGHBANK_UART > >> diff --git a/arch/arm/Makefile b/arch/arm/Makefile > >> index c0ac0f5..4a69cd5 100644 > >> --- a/arch/arm/Makefile > >> +++ b/arch/arm/Makefile > >> @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000 > >> machine-$(CONFIG_ARCH_AT91) += at91 > >> machine-$(CONFIG_ARCH_BCM) += bcm > >> machine-$(CONFIG_ARCH_BCM2835) += bcm2835 > >> +machine-$(CONFIG_ARCH_BCM53XX) += bcm53xx > >> machine-$(CONFIG_ARCH_CLPS711X) += clps711x > >> machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx > >> machine-$(CONFIG_ARCH_DAVINCI) += davinci > >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > >> index 641b3c9..480a68e 100644 > >> --- a/arch/arm/boot/dts/Makefile > >> +++ b/arch/arm/boot/dts/Makefile > >> @@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ > >> dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ > >> zynq-zc706.dtb \ > >> zynq-zed.dtb > >> +dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb > >> > >> targets += dtbs > >> targets += $(dtb-y) > >> diff --git a/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts > >> new file mode 100644 > >> index 0000000..d1b97aa > >> --- /dev/null > >> +++ b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts > >> @@ -0,0 +1,20 @@ > >> +/* > >> + * Broadcom BCM47XX / BCM53XX arm platform code. > >> + * > >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > >> + * > >> + * Licensed under the GNU/GPL. See COPYING for details. > >> + */ > >> + > >> +/dts-v1/; > >> + > >> +/include/ "bcm5301x.dtsi" > >> + > >> +/ { > >> + model = "Netgear R6250 V1 (BCM4708)"; > >> + compatible = "netgear,r6250v1", "brcm,bcm5301x"; > >> + > >> + memory { > >> + reg = <0x00000000 0x08000000>; > >> + }; > >> +}; > >> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi > >> new file mode 100644 > >> index 0000000..638350d > >> --- /dev/null > >> +++ b/arch/arm/boot/dts/bcm5301x.dtsi > >> @@ -0,0 +1,72 @@ > >> +/* > >> + * Broadcom BCM47XX / BCM53XX ARM platform code. > >> + * > >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > >> + * > >> + * Licensed under the GNU/GPL. See COPYING for details. > >> + */ > >> + > >> +/include/ "skeleton.dtsi" > >> + > >> +/ { > >> + compatible = "brcm,bcm5301x"; > > > > Ok, this was nagging at me before I went on my very long vacation. I see > > the "brcm" vendor prefix as a real consistency problem. I noticed on the > > bcm281xx/kona family, we have been using "bcm" which is not logged in > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > > already established use of "brcm" before any of the bcm281xx support > > came in. Ideally, the vendor prefix should change to "bcm" since every > > reference in the family names is BCM. However, if others want the least > > amount of churn in making this consistent, we might have to go with > > "brcm" across the board. > > > > Arnd, any thoughts here? > > I have no problem with bcm or with brcm. This is a Broadcom Chip and > their names are starting with bcm. See Florian's quantified argument for using brcm. > > > Another thing is that this is missing a binding definition for this > > compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt > > for an example. You should split this patch out separately as the DT > > maintainers generally want to see bindings as a separate patch for easy > > independent review. > > Ok I will do that. This will then be merged by Linus in the 3.12 merge > window into a working version or how does this work? Yes, your target is the 3.12 merge window at this point. > Currently I have based this patch on top of 3.11-rc1 on which tree > should I base my changes? That's good. Unless some major change comes into the arm-soc tree and you are asked to rebase versus that. > > Last thing, compatible strings are not to have wildcards in them. See > > http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property > > and note the Warning at the bottom. Also see how bcm2835.txt and > > bcm11351.txt use a specific model. > > Ok will do that. > > >> + model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC"; > >> + interrupt-parent = <&gic>; > >> + > >> + chosen { > >> + bootargs = "console=ttyS0,115200 earlyprintk debug"; > >> + }; > >> + > >> + cpus { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + cpu@0 { > >> + device_type = "cpu"; > >> + compatible = "arm,cortex-a9"; > >> + reg = <0>; > >> + }; > >> + }; > >> + > >> + clocks { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + clk_periph: periph { > >> + compatible = "fixed-clock"; > >> + #clock-cells = <0>; > >> + clock-frequency = <400000000>; > >> + }; > >> + }; > >> + > >> + uart@18000300 { > >> + compatible = "ns16550"; > >> + reg = <0x18000300 0x100>; > >> + interrupts = <0 85 4>; > > > > The DT files should be switched to use the C preprocessor like several > > other machines have already done (see bcm11351.dtsi, for example), you > > can use the existing GIC includes and have human-redable defines for the > > edge/level values here and throughout all interrupt properties. > > Ok I will read that and change it. > > >> + clock-frequency = <100000000>; > >> + }; > >> + > >> + uart@18000400 { > >> + compatible = "ns16550"; > >> + reg = <0x18000400 0x100>; > >> + interrupts = <0 85 4>; > >> + clock-frequency = <100000000>; > >> + }; > >> + > >> + gic: interrupt-controller@19021000 { > >> + compatible = "arm,cortex-a9-gic"; > >> + #interrupt-cells = <3>; > >> + #address-cells = <0>; > >> + interrupt-controller; > >> + reg = <0x19021000 0x1000>, > >> + <0x19020100 0x100>; > >> + }; > >> + > >> + timer@19020200 { > >> + compatible = "arm,cortex-a9-global-timer"; > >> + reg = <0x19020200 0x100>; > >> + interrupts = <1 11 0xf04>; > >> + clocks = <&clk_periph>; > >> + #clock-cells = <0>; > >> + }; > >> +}; > >> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S > >> new file mode 100644 > >> index 0000000..98c836b > >> --- /dev/null > >> +++ b/arch/arm/include/debug/bcm53xx.S > >> @@ -0,0 +1,19 @@ > >> +/* > >> + * Macros used for EARLY_PRINTK, in low-level UART debug console > >> + * > >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > >> + * > >> + * Licensed under the GNU/GPL. See COPYING for details. > >> + */ > >> + > >> +#define BCM53XX_UART1_PHYS 0x18000300 > >> +#define BCM53XX_UART1_VIRT 0xf1000300 > >> +#define BCM53XX_UART1_SH 0 > >> + > >> + .macro addruart, rp, rv, tmp > >> + ldr \rp, =BCM53XX_UART1_PHYS @ MMU off, Physical > >> + ldr \rv, =BCM53XX_UART1_VIRT @ MMU on, Virtual > >> + .endm > >> + > >> +#define UART_SHIFT BCM53XX_UART1_SH > >> +#include <asm/hardware/debug-8250.S> > >> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig > >> new file mode 100644 > >> index 0000000..1e16e87 > >> --- /dev/null > >> +++ b/arch/arm/mach-bcm53xx/Kconfig > >> @@ -0,0 +1,10 @@ > >> +config ARCH_BCM53XX > >> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" > >> + select CPU_V7 > >> + select ARM_GIC > >> + select HAVE_CLK > >> + select GENERIC_CLOCKEVENTS > >> + select GENERIC_TIME > >> + select ARM_GLOBAL_TIMER > >> + help > >> + Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores. > >> diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile > >> new file mode 100644 > >> index 0000000..88da84d > >> --- /dev/null > >> +++ b/arch/arm/mach-bcm53xx/Makefile > >> @@ -0,0 +1 @@ > >> +obj-y += bcm53xx.o > >> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c > >> new file mode 100644 > >> index 0000000..aa5bd397 > >> --- /dev/null > >> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c > >> @@ -0,0 +1,68 @@ > >> +/* > >> + * Broadcom BCM47XX / BCM53XX ARM platform code. > >> + * > >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > >> + * > >> + * Licensed under the GNU/GPL. See COPYING for details. > >> + */ > >> +#include <linux/of_address.h> > >> +#include <linux/of_platform.h> > >> +#include <linux/irqchip.h> > >> +#include <linux/clocksource.h> > >> +#include <linux/clk-provider.h> > >> + > >> +#include <asm/mach/arch.h> > >> +#include <asm/mach/map.h> > >> +#include <asm/signal.h> > >> + > >> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, > >> + struct pt_regs *regs) > >> +{ > >> + /* > >> + * These happen for no good reason > >> + * possibly left over from CFE > >> + */ > >> + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", > >> + addr, fsr); > >> + > >> + /* Returning non-zero causes fault display and panic */ > >> + return 0; > >> +} > >> + > >> +static void bcm53xx_aborts_enable(void) > >> +{ > >> + /* Install our hook */ > >> + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, > >> + "imprecise external abort"); > >> +} > >> + > >> +static void __init bcm53xx_timer_init(void) > >> +{ > >> + of_clk_init(NULL); > >> + clocksource_of_init(); > >> +} > >> + > >> +void __init bcm53xx_map_io(void) > >> +{ > >> + debug_ll_io_init(); > >> + bcm53xx_aborts_enable(); > >> +} > >> + > >> +static void __init bcm53xx_dt_init(void) > >> +{ > >> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > >> +} > >> + > >> +static const char const *bcm53xx_dt_compat[] = { > >> + "brcm,bcm5301x", > >> + "netgear,r6250v1", > >> + NULL, > >> +}; > >> + > >> +DT_MACHINE_START(BCM53XX, "BCM53XX") > >> + .init_machine = bcm53xx_dt_init, > >> + .map_io = bcm53xx_map_io, > >> + .init_irq = irqchip_init, > >> + .init_time = bcm53xx_timer_init, > >> + .dt_compat = bcm53xx_dt_compat, > >> +MACHINE_END > >> -- > >> 1.7.10.4 > >> >
On Tue, Jul 16, 2013 at 08:13:09PM +0200, Hauke Mehrtens wrote: > On 07/16/2013 05:39 PM, Hauke Mehrtens wrote: > > On 07/16/2013 05:14 PM, Matt Porter wrote: > >> Hi Hauke, > >> > >> On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote: > >>> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. > >>> Currently just booting to a shell is working and nothing else, no > >>> Ethernet, wifi, flash, ... > >>> > >>> This SoC uses a Dual core CPU, but this is currently not implemented. > >>> More information about this SoC can be found here: > >>> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers > >>> > >>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> > >>> --- > > .... > > >>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi > >>> new file mode 100644 > >>> index 0000000..638350d > >>> --- /dev/null > >>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi > >>> @@ -0,0 +1,72 @@ > >>> +/* > >>> + * Broadcom BCM47XX / BCM53XX ARM platform code. > >>> + * > >>> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > >>> + * > >>> + * Licensed under the GNU/GPL. See COPYING for details. > >>> + */ > >>> + > >>> +/include/ "skeleton.dtsi" > >>> + > >>> +/ { > >>> + compatible = "brcm,bcm5301x"; > >> > >> Ok, this was nagging at me before I went on my very long vacation. I see > >> the "brcm" vendor prefix as a real consistency problem. I noticed on the > >> bcm281xx/kona family, we have been using "bcm" which is not logged in > >> vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > >> already established use of "brcm" before any of the bcm281xx support > >> came in. Ideally, the vendor prefix should change to "bcm" since every > >> reference in the family names is BCM. However, if others want the least > >> amount of churn in making this consistent, we might have to go with > >> "brcm" across the board. > >> > >> Arnd, any thoughts here? > > > > I have no problem with bcm or with brcm. This is a Broadcom Chip and > > their names are starting with bcm. > > > >> Another thing is that this is missing a binding definition for this > >> compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt > >> for an example. You should split this patch out separately as the DT > >> maintainers generally want to see bindings as a separate patch for easy > >> independent review. > > > > Ok I will do that. This will then be merged by Linus in the 3.12 merge > > window into a working version or how does this work? > > > > Currently I have based this patch on top of 3.11-rc1 on which tree > > should I base my changes? > > Should I split out the *.dts files in arch/arm/boot/dts/ and the > documentation for brcm,bcm4708 into an other patch? It's common to keep the binding separate for easy standalone review by the DT maintainers (now changing) and on devicetree-discuss). Since the .dts files are separate logical change, it's common to separate that out as well. > >> Last thing, compatible strings are not to have wildcards in them. See > >> http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property > >> and note the Warning at the bottom. Also see how bcm2835.txt and > >> bcm11351.txt use a specific model. > > > > Ok will do that. > > Do I understand this right that I should currently name it exactly like > the SoC I know and when a new SoC pops up I should make it compatible to > this SoC? Yes. > I would change this to: > compatible = "brcm,bcm4708"; > > If I find a BCM4709 SoC I will add this like to its dts file, assuming > they are mostly the same? > compatible = "brcm,bcm4709", "brcm,bcm4708"; You want the base one to be the first in the family as best as you know. Everything else is then compatible to that. On the bcm281xx family side, you can see that the numbering scheme is wacky such that the first in family is bcm11351, but we refer to it by the wildcarded name of the latest parts in the family. -Matt
On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote: > On 07/16/2013 05:20 PM, Thomas Petazzoni wrote: > > > >> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig > >> new file mode 100644 > >> index 0000000..1e16e87 > >> --- /dev/null > >> +++ b/arch/arm/mach-bcm53xx/Kconfig > >> @@ -0,0 +1,10 @@ > >> +config ARCH_BCM53XX > >> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" > > > > So the directory is named mach-bcm53xx, but you also handle BCM47xx > > SoCs. This doesn't sound really easy to follow. At the time of the BCM281XX merge we considered that such directories would mostly contain board files only, being these new entries DT based. Hence the choice of mach-bcm to collect all of them. I think you should then put this stuff there. > Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I > do not know why there are two different names, probably marketing. > > Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a > MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to > not conflict with the MIPS part now. I know this could still cause > problems and people will get confused, but I do not know a better name. I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are ARM11, single-core SoCs. Can we agree on a nice naming so that we actually clarify this silliness? Regards, Domenico
On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: > Hello, > > Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : > > > + compatible = "brcm,bcm5301x"; > > > > Ok, this was nagging at me before I went on my very long vacation. I see > > the "brcm" vendor prefix as a real consistency problem. I noticed on the > > bcm281xx/kona family, we have been using "bcm" which is not logged in > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > > already established use of "brcm" before any of the bcm281xx support > > came in. Ideally, the vendor prefix should change to "bcm" since every > > reference in the family names is BCM. However, if others want the least > > amount of churn in making this consistent, we might have to go with > > "brcm" across the board. > > I would like to keep "brcm" here because that is what has been defined as a > vendor prefix, and is used beyond the scope of the ARM Linux kernel support > even within Broadcom. Maybe it was an oversight, or rather a mistake to let brcm is the stock ticker. As far as I can search, this is the convention for the vendor prefixes. I'm theb not that surprised that it's common within broadcom ;) Regards, Domenico
Hi Hauke, On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote: > This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. > Currently just booting to a shell is working and nothing else, no > Ethernet, wifi, flash, ... > > This SoC uses a Dual core CPU, but this is currently not implemented. > More information about this SoC can be found here: > http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers > > Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> > --- ... > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index e401a76..74e32f6 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -93,6 +93,10 @@ choice > bool "Kernel low-level debugging on BCM2835 PL011 UART" > depends on ARCH_BCM2835 > > + config DEBUG_BCM53XX > + bool "Kernel low-level debugging on BCM53XX UART1" > + depends on ARCH_BCM53XX > + > config DEBUG_CLPS711X_UART1 > bool "Kernel low-level debugging messages via UART1" > depends on ARCH_CLPS711X > @@ -762,6 +766,7 @@ endchoice > config DEBUG_LL_INCLUDE > string > default "debug/bcm2835.S" if DEBUG_BCM2835 > + default "debug/bcm53xx.S" if DEBUG_BCM53XX > default "debug/cns3xxx.S" if DEBUG_CNS3XXX > default "debug/exynos.S" if DEBUG_EXYNOS_UART > default "debug/highbank.S" if DEBUG_HIGHBANK_UART ... > diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S > new file mode 100644 > index 0000000..98c836b > --- /dev/null > +++ b/arch/arm/include/debug/bcm53xx.S > @@ -0,0 +1,19 @@ > +/* > + * Macros used for EARLY_PRINTK, in low-level UART debug console > + * > + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > + * > + * Licensed under the GNU/GPL. See COPYING for details. > + */ > + > +#define BCM53XX_UART1_PHYS 0x18000300 > +#define BCM53XX_UART1_VIRT 0xf1000300 > +#define BCM53XX_UART1_SH 0 > + > + .macro addruart, rp, rv, tmp > + ldr \rp, =BCM53XX_UART1_PHYS @ MMU off, Physical > + ldr \rv, =BCM53XX_UART1_VIRT @ MMU on, Virtual > + .endm > + > +#define UART_SHIFT BCM53XX_UART1_SH > +#include <asm/hardware/debug-8250.S> don't know if it's worth to add this debug uart support here. there is a series from Russel to consolidate 8250 and pl01x debug uarts. maybe you want to delay this. > diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c > new file mode 100644 > index 0000000..aa5bd397 > --- /dev/null > +++ b/arch/arm/mach-bcm53xx/bcm53xx.c > @@ -0,0 +1,68 @@ > +/* > + * Broadcom BCM47XX / BCM53XX ARM platform code. > + * > + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > + * > + * Licensed under the GNU/GPL. See COPYING for details. > + */ > +#include <linux/of_address.h> > +#include <linux/of_platform.h> > +#include <linux/irqchip.h> > +#include <linux/clocksource.h> > +#include <linux/clk-provider.h> > + > +#include <asm/mach/arch.h> > +#include <asm/mach/map.h> > +#include <asm/signal.h> > + > +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, > + struct pt_regs *regs) > +{ > + /* > + * These happen for no good reason > + * possibly left over from CFE > + */ > + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", > + addr, fsr); > + > + /* Returning non-zero causes fault display and panic */ > + return 0; > +} > + > +static void bcm53xx_aborts_enable(void) > +{ > + /* Install our hook */ > + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, > + "imprecise external abort"); > +} > + > +static void __init bcm53xx_timer_init(void) > +{ > + of_clk_init(NULL); > + clocksource_of_init(); > +} > + > +void __init bcm53xx_map_io(void) > +{ > + debug_ll_io_init(); > + bcm53xx_aborts_enable(); > +} > + > +static void __init bcm53xx_dt_init(void) > +{ > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > +} > + > +static const char const *bcm53xx_dt_compat[] = { > + "brcm,bcm5301x", > + "netgear,r6250v1", > + NULL, > +}; > + > +DT_MACHINE_START(BCM53XX, "BCM53XX") > + .init_machine = bcm53xx_dt_init, > + .map_io = bcm53xx_map_io, > + .init_irq = irqchip_init, > + .init_time = bcm53xx_timer_init, > + .dt_compat = bcm53xx_dt_compat, > +MACHINE_END the trend is to consolidate machine descriptors. so .init_irq can go, irqchip_init is picked anyway if .init_irq is NULL. also .init_time could be dropped, it can be specified using CLOCKSOURCE_OF_DECLARE(), but I see bcm53xx_timer_init is already quite minimal here and I'm struggling to see the big picture here. So mine is actually a question for others... :) Regards, Domenico
On Tuesday 16 July 2013, Matt Porter wrote: > > diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi > > new file mode 100644 > > index 0000000..638350d > > --- /dev/null > > +++ b/arch/arm/boot/dts/bcm5301x.dtsi > > @@ -0,0 +1,72 @@ > > +/* > > + * Broadcom BCM47XX / BCM53XX ARM platform code. > > + * > > + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> > > + * > > + * Licensed under the GNU/GPL. See COPYING for details. > > + */ > > + > > +/include/ "skeleton.dtsi" > > + > > +/ { > > + compatible = "brcm,bcm5301x"; > > Ok, this was nagging at me before I went on my very long vacation. I see > the "brcm" vendor prefix as a real consistency problem. I noticed on the > bcm281xx/kona family, we have been using "bcm" which is not logged in > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > already established use of "brcm" before any of the bcm281xx support > came in. Ideally, the vendor prefix should change to "bcm" since every > reference in the family names is BCM. However, if others want the least > amount of churn in making this consistent, we might have to go with > "brcm" across the board. > > Arnd, any thoughts here? No strong feelings on the bcm vs brcm side, but please make it consistent. > Last thing, compatible strings are not to have wildcards in them. See > http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property > and note the Warning at the bottom. Also see how bcm2835.txt and > bcm11351.txt use a specific model. +1 Arnd
On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: > Hello, > > Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : > > > + compatible = "brcm,bcm5301x"; > > > > Ok, this was nagging at me before I went on my very long vacation. I see > > the "brcm" vendor prefix as a real consistency problem. I noticed on the > > bcm281xx/kona family, we have been using "bcm" which is not logged in > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > > already established use of "brcm" before any of the bcm281xx support > > came in. Ideally, the vendor prefix should change to "bcm" since every > > reference in the family names is BCM. However, if others want the least > > amount of churn in making this consistent, we might have to go with > > "brcm" across the board. > > I would like to keep "brcm" here because that is what has been defined as a > vendor prefix, and is used beyond the scope of the ARM Linux kernel support > even within Broadcom. Maybe it was an oversight, or rather a mistake to let [Update: I thought some more about this and investigated why Broadcom started using "bcm" and changed my mind] Can you provide a cite? I can tell you that within Broadcom they have been moving to get rid of it. That is why you see all this Broadcom originated code using "bcm" because it actually matches their part number prefix. As further evidence of the preference for "bcm", feel free to look through the entire public catalog of parts at http://www.broadcom.com/products/ and note that they all have BCM as the part prefix...this carries over into all driver references to the parts as well including everything in the wireless world. > the bcm281x/kona family support code be merged and use "bcm" there, without > registering it. Besides, a simple rule of number here wins: > > git grep "brcm," * | wc -l > 63 > git grep "bcm," * | wc -l > 25 > > (as of Linux 3.11-rc1) > > So consistency we should get the bcm281x/kona DT bindings to rename their > vendor prefix as well. I believe getting this "right" is far more important than the difference in churn of a mere 38 instances of use of brcm. "Right" is two things: 1) it needs to be consistent 2) it should be what makes sense. -Matt
2013/7/23 Matt Porter <matt.porter@linaro.org>: > On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: >> Hello, >> >> Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : >> > > + compatible = "brcm,bcm5301x"; >> > >> > Ok, this was nagging at me before I went on my very long vacation. I see >> > the "brcm" vendor prefix as a real consistency problem. I noticed on the >> > bcm281xx/kona family, we have been using "bcm" which is not logged in >> > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had >> > already established use of "brcm" before any of the bcm281xx support >> > came in. Ideally, the vendor prefix should change to "bcm" since every >> > reference in the family names is BCM. However, if others want the least >> > amount of churn in making this consistent, we might have to go with >> > "brcm" across the board. >> >> I would like to keep "brcm" here because that is what has been defined as a >> vendor prefix, and is used beyond the scope of the ARM Linux kernel support >> even within Broadcom. Maybe it was an oversight, or rather a mistake to let > > [Update: I thought some more about this and investigated why Broadcom started > using "bcm" and changed my mind] > > Can you provide a cite? Well, I can tell you that this is what my group is using for its vendor prefix in DT because this is the one that was allocated in vendor-prefixes.txt. This is also what the upstream BCM63xx DSL SoC is using even though that port is still WIP, so could be subject to changing. > I can tell you that within Broadcom they have > been moving to get rid of it. That is why you see all this Broadcom > originated code using "bcm" because it actually matches their part > number prefix. As further evidence of the preference for "bcm", feel free to > look through the entire public catalog of parts at > http://www.broadcom.com/products/ and note that they all have BCM as the part > prefix...this carries over into all driver references to the parts as well > including everything in the wireless world. If you want to add more confusion, because there is, drivers/staging/bcm which stands for Beceem has been later acquired by Broadcom, eventually turning this 3 letter word into something "consistent" from a Broadcom point of view. As far as I am concerned, I would just stick with the allocated vendor prefix and replace "bcm" with "brcm" because the allocated one is the authoritative one. > >> the bcm281x/kona family support code be merged and use "bcm" there, without >> registering it. Besides, a simple rule of number here wins: >> >> git grep "brcm," * | wc -l >> 63 >> git grep "bcm," * | wc -l >> 25 >> >> (as of Linux 3.11-rc1) >> >> So consistency we should get the bcm281x/kona DT bindings to rename their >> vendor prefix as well. > > I believe getting this "right" is far more important than the difference > in churn of a mere 38 instances of use of brcm. "Right" is two things: > 1) it needs to be consistent 2) it should be what makes sense. I agree, which is the reason why I would stick with the vendor prefix and end the story there. -- Florian
On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: > On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: > > Hello, > > > > Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : > > > > + compatible = "brcm,bcm5301x"; > > > > > > Ok, this was nagging at me before I went on my very long vacation. I see > > > the "brcm" vendor prefix as a real consistency problem. I noticed on the > > > bcm281xx/kona family, we have been using "bcm" which is not logged in > > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > > > already established use of "brcm" before any of the bcm281xx support > > > came in. Ideally, the vendor prefix should change to "bcm" since every > > > reference in the family names is BCM. However, if others want the least > > > amount of churn in making this consistent, we might have to go with > > > "brcm" across the board. > > > > I would like to keep "brcm" here because that is what has been defined as a > > vendor prefix, and is used beyond the scope of the ARM Linux kernel support > > even within Broadcom. Maybe it was an oversight, or rather a mistake to let > > brcm is the stock ticker. As far as I can search, this is the convention > for the vendor prefixes. No, correlation does not equal causation. The fact that some vendor prefixes in DT match the stock symbol is by chance of 3-4 character name being the same...nothing more. It's pretty easy to see that the "ti" vendor prefix has no relation at all to their TXN symbol so that blows that convention out of the water. Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :) For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. > I'm theb not that surprised that it's common within broadcom ;) It's no longer common as mentioned in my other post. -Matt
2013/7/23 Matt Porter <matt.porter@linaro.org>: > On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: >> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: >> > Hello, >> > >> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : >> > > > + compatible = "brcm,bcm5301x"; >> > > >> > > Ok, this was nagging at me before I went on my very long vacation. I see >> > > the "brcm" vendor prefix as a real consistency problem. I noticed on the >> > > bcm281xx/kona family, we have been using "bcm" which is not logged in >> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had >> > > already established use of "brcm" before any of the bcm281xx support >> > > came in. Ideally, the vendor prefix should change to "bcm" since every >> > > reference in the family names is BCM. However, if others want the least >> > > amount of churn in making this consistent, we might have to go with >> > > "brcm" across the board. >> > >> > I would like to keep "brcm" here because that is what has been defined as a >> > vendor prefix, and is used beyond the scope of the ARM Linux kernel support >> > even within Broadcom. Maybe it was an oversight, or rather a mistake to let >> >> brcm is the stock ticker. As far as I can search, this is the convention >> for the vendor prefixes. > > No, correlation does not equal causation. The fact that some vendor > prefixes in DT match the stock symbol is by chance of 3-4 character name > being the same...nothing more. That was a bad argument as was later explained to me, I won't use that reason again. > > It's pretty easy to see that the "ti" vendor prefix has no relation at > all to their TXN symbol so that blows that convention out of the water. > Rather, the prefix is based on somebody's notion of how that vendor's > part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, > never TXN OMAP. :) > > For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. It was appropriate before being the "wrong" vendor prefix was allocated, now that "brcm" has been allocated we should stick to it because otherwise we will break existing and on-going DT work. At the very least, all possible confusion would be avoided by using "broadcom" instead of any other abreviation. -- Florian
On 07/23/2013 08:56 PM, Florian Fainelli wrote: > If you want to add more confusion, because there is, > drivers/staging/bcm which stands for Beceem has been later acquired by > Broadcom, eventually turning this 3 letter word into something > "consistent" from a Broadcom point of view. As far as I am concerned, > I would just stick with the allocated vendor prefix and replace "bcm" > with "brcm" because the allocated one is the authoritative one. Nice, huh. In device-tree notation it identifies the vendor and I agree that brcm is a better/preferred vendor id. The confusion here is that the device identifiers are all prefixed with "bcm", which is something different than the vendor id. I do not think consistency was the goal in the acquisition of Beceem ;-) >> > >>> >>the bcm281x/kona family support code be merged and use "bcm" there, without >>> >>registering it. Besides, a simple rule of number here wins: >>> >> >>> >>git grep "brcm," * | wc -l >>> >>63 >>> >>git grep "bcm," * | wc -l >>> >>25 >>> >> >>> >>(as of Linux 3.11-rc1) >>> >> >>> >>So consistency we should get the bcm281x/kona DT bindings to rename their >>> >>vendor prefix as well. >> > >> >I believe getting this "right" is far more important than the difference >> >in churn of a mere 38 instances of use of brcm. "Right" is two things: >> >1) it needs to be consistent 2) it should be what makes sense. > I agree, which is the reason why I would stick with the vendor prefix > and end the story there. Agree. > -- > Florian Regards, Arend
On Tue, Jul 23, 2013 at 07:56:26PM +0100, Florian Fainelli wrote: > 2013/7/23 Matt Porter <matt.porter@linaro.org>: > > On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: > >> Hello, > >> > >> Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : > >> > > + compatible = "brcm,bcm5301x"; > >> > > >> > Ok, this was nagging at me before I went on my very long vacation. I see > >> > the "brcm" vendor prefix as a real consistency problem. I noticed on the > >> > bcm281xx/kona family, we have been using "bcm" which is not logged in > >> > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > >> > already established use of "brcm" before any of the bcm281xx support > >> > came in. Ideally, the vendor prefix should change to "bcm" since every > >> > reference in the family names is BCM. However, if others want the least > >> > amount of churn in making this consistent, we might have to go with > >> > "brcm" across the board. > >> > >> I would like to keep "brcm" here because that is what has been defined as a > >> vendor prefix, and is used beyond the scope of the ARM Linux kernel support > >> even within Broadcom. Maybe it was an oversight, or rather a mistake to let > > > > [Update: I thought some more about this and investigated why Broadcom started > > using "bcm" and changed my mind] > > > > Can you provide a cite? > > Well, I can tell you that this is what my group is using for its > vendor prefix in DT because this is the one that was allocated in > vendor-prefixes.txt. This is also what the upstream BCM63xx DSL SoC is > using even though that port is still WIP, so could be subject to > changing. > > > I can tell you that within Broadcom they have > > been moving to get rid of it. That is why you see all this Broadcom > > originated code using "bcm" because it actually matches their part > > number prefix. As further evidence of the preference for "bcm", feel free to > > look through the entire public catalog of parts at > > http://www.broadcom.com/products/ and note that they all have BCM as the part > > prefix...this carries over into all driver references to the parts as well > > including everything in the wireless world. > > If you want to add more confusion, because there is, > drivers/staging/bcm which stands for Beceem has been later acquired by > Broadcom, eventually turning this 3 letter word into something > "consistent" from a Broadcom point of view. As far as I am concerned, > I would just stick with the allocated vendor prefix and replace "bcm" > with "brcm" because the allocated one is the authoritative one. > > > > >> the bcm281x/kona family support code be merged and use "bcm" there, without > >> registering it. Besides, a simple rule of number here wins: > >> > >> git grep "brcm," * | wc -l > >> 63 > >> git grep "bcm," * | wc -l > >> 25 > >> > >> (as of Linux 3.11-rc1) > >> > >> So consistency we should get the bcm281x/kona DT bindings to rename their > >> vendor prefix as well. > > > > I believe getting this "right" is far more important than the difference > > in churn of a mere 38 instances of use of brcm. "Right" is two things: > > 1) it needs to be consistent 2) it should be what makes sense. > > I agree, which is the reason why I would stick with the vendor prefix > and end the story there. It doesn't end there. An update to all the in process stuff has to happen, plus the upstream stuff. So in both cases there are changes to be made both upstream and with work-in-progress. The only difference is that I was suggesting an update to correct the prefix in vendor-prefixes.txt. However, if I'm the only one that cares enough to speak up for "bcm" I'll abandon that and submit the patch to adjust bcm281xx to be compliant with the current state of vendor-prefixes.txt. :) -Matt
On 07/19/2013 04:23 AM, Domenico Andreoli wrote: > Hi Hauke, > > On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote: >> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. >> Currently just booting to a shell is working and nothing else, no >> Ethernet, wifi, flash, ... >> >> This SoC uses a Dual core CPU, but this is currently not implemented. >> More information about this SoC can be found here: >> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers >> >> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> >> --- > > ... > >> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug >> index e401a76..74e32f6 100644 >> --- a/arch/arm/Kconfig.debug >> +++ b/arch/arm/Kconfig.debug >> @@ -93,6 +93,10 @@ choice >> bool "Kernel low-level debugging on BCM2835 PL011 UART" >> depends on ARCH_BCM2835 >> >> + config DEBUG_BCM53XX >> + bool "Kernel low-level debugging on BCM53XX UART1" >> + depends on ARCH_BCM53XX >> + >> config DEBUG_CLPS711X_UART1 >> bool "Kernel low-level debugging messages via UART1" >> depends on ARCH_CLPS711X >> @@ -762,6 +766,7 @@ endchoice >> config DEBUG_LL_INCLUDE >> string >> default "debug/bcm2835.S" if DEBUG_BCM2835 >> + default "debug/bcm53xx.S" if DEBUG_BCM53XX >> default "debug/cns3xxx.S" if DEBUG_CNS3XXX >> default "debug/exynos.S" if DEBUG_EXYNOS_UART >> default "debug/highbank.S" if DEBUG_HIGHBANK_UART > > ... > >> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S >> new file mode 100644 >> index 0000000..98c836b >> --- /dev/null >> +++ b/arch/arm/include/debug/bcm53xx.S >> @@ -0,0 +1,19 @@ >> +/* >> + * Macros used for EARLY_PRINTK, in low-level UART debug console >> + * >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >> + * >> + * Licensed under the GNU/GPL. See COPYING for details. >> + */ >> + >> +#define BCM53XX_UART1_PHYS 0x18000300 >> +#define BCM53XX_UART1_VIRT 0xf1000300 >> +#define BCM53XX_UART1_SH 0 >> + >> + .macro addruart, rp, rv, tmp >> + ldr \rp, =BCM53XX_UART1_PHYS @ MMU off, Physical >> + ldr \rv, =BCM53XX_UART1_VIRT @ MMU on, Virtual >> + .endm >> + >> +#define UART_SHIFT BCM53XX_UART1_SH >> +#include <asm/hardware/debug-8250.S> > > don't know if it's worth to add this debug uart support here. there is a > series from Russel to consolidate 8250 and pl01x debug uarts. maybe you > want to delay this. Yes, I saw the patch submission and now it is in linux-next. I will add debugging into a separate patch. > >> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c >> new file mode 100644 >> index 0000000..aa5bd397 >> --- /dev/null >> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c >> @@ -0,0 +1,68 @@ >> +/* >> + * Broadcom BCM47XX / BCM53XX ARM platform code. >> + * >> + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> >> + * >> + * Licensed under the GNU/GPL. See COPYING for details. >> + */ >> +#include <linux/of_address.h> >> +#include <linux/of_platform.h> >> +#include <linux/irqchip.h> >> +#include <linux/clocksource.h> >> +#include <linux/clk-provider.h> >> + >> +#include <asm/mach/arch.h> >> +#include <asm/mach/map.h> >> +#include <asm/signal.h> >> + >> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, >> + struct pt_regs *regs) >> +{ >> + /* >> + * These happen for no good reason >> + * possibly left over from CFE >> + */ >> + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", >> + addr, fsr); >> + >> + /* Returning non-zero causes fault display and panic */ >> + return 0; >> +} >> + >> +static void bcm53xx_aborts_enable(void) >> +{ >> + /* Install our hook */ >> + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, >> + "imprecise external abort"); >> +} >> + >> +static void __init bcm53xx_timer_init(void) >> +{ >> + of_clk_init(NULL); >> + clocksource_of_init(); >> +} >> + >> +void __init bcm53xx_map_io(void) >> +{ >> + debug_ll_io_init(); >> + bcm53xx_aborts_enable(); >> +} >> + >> +static void __init bcm53xx_dt_init(void) >> +{ >> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); >> +} >> + >> +static const char const *bcm53xx_dt_compat[] = { >> + "brcm,bcm5301x", >> + "netgear,r6250v1", >> + NULL, >> +}; >> + >> +DT_MACHINE_START(BCM53XX, "BCM53XX") >> + .init_machine = bcm53xx_dt_init, >> + .map_io = bcm53xx_map_io, >> + .init_irq = irqchip_init, >> + .init_time = bcm53xx_timer_init, >> + .dt_compat = bcm53xx_dt_compat, >> +MACHINE_END > > the trend is to consolidate machine descriptors. > > so .init_irq can go, irqchip_init is picked anyway if .init_irq is NULL. Thanks for the info, I will removed it. > > also .init_time could be dropped, it can be specified using > CLOCKSOURCE_OF_DECLARE(), but I see bcm53xx_timer_init is already quite > minimal here and I'm struggling to see the big picture here. So mine is > actually a question for others... :) I will leave it for now like it is, if someone has a better idea I will change it. Hauke
On 07/19/2013 03:36 AM, Domenico Andreoli wrote: > On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote: >> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote: >>> >>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig >>>> new file mode 100644 >>>> index 0000000..1e16e87 >>>> --- /dev/null >>>> +++ b/arch/arm/mach-bcm53xx/Kconfig >>>> @@ -0,0 +1,10 @@ >>>> +config ARCH_BCM53XX >>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" >>> >>> So the directory is named mach-bcm53xx, but you also handle BCM47xx >>> SoCs. This doesn't sound really easy to follow. > > At the time of the BCM281XX merge we considered that such directories would > mostly contain board files only, being these new entries DT based. Hence > the choice of mach-bcm to collect all of them. > > I think you should then put this stuff there. So you think I should move the file from arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ? Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from the same family and they should be supported by the same code, so there is no reason to have a bcm47xx.c and a bcm53xx.c. >> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I >> do not know why there are two different names, probably marketing. >> >> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a >> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to >> not conflict with the MIPS part now. I know this could still cause >> problems and people will get confused, but I do not know a better name. > > I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are ARM11, > single-core SoCs. > > Can we agree on a nice naming so that we actually clarify this silliness? We could name it BCM5301X like it is named the the vendor source code. Currently there are the following SoCs of this family available: BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707, BCM4708 and BCM4709. Internal there are two different chip IDs available 53010 (BCM4707) and 53018 (BCM53018). Hauke
On 13-07-23 12:22 PM, Matt Porter wrote: >>>> the bcm281x/kona family support code be merged and use "bcm" there, without >>>> registering it. Besides, a simple rule of number here wins: >>>> >>>> git grep "brcm," * | wc -l >>>> 63 >>>> git grep "bcm," * | wc -l >>>> 25 >>>> >>>> (as of Linux 3.11-rc1) >>>> >>>> So consistency we should get the bcm281x/kona DT bindings to rename their >>>> vendor prefix as well. >>> I believe getting this "right" is far more important than the difference >>> in churn of a mere 38 instances of use of brcm. "Right" is two things: >>> 1) it needs to be consistent 2) it should be what makes sense. >> I agree, which is the reason why I would stick with the vendor prefix >> and end the story there. > It doesn't end there. An update to all the in process stuff has to > happen, plus the upstream stuff. So in both cases there are changes to > be made both upstream and with work-in-progress. The only difference is > that I was suggesting an update to correct the prefix in > vendor-prefixes.txt. > > However, if I'm the only one that cares enough to speak up for "bcm" > I'll abandon that and submit the patch to adjust bcm281xx to be > compliant with the current state of vendor-prefixes.txt. :) > bcm has been used internally but not consistently - about as consistently as brcm has been used in upstream :) Given that I've submitted most/all of the non-compliant code, I'll send a patch rectifying it and request internal team to switch to using brcm, for devicetree bindings, as atonement. If Matt doesn't beat me to it... Thanks, csd
On 07/24/2013 02:44 AM, Domenico Andreoli wrote: > On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de > <mailto:hauke@hauke-m.de>> wrote: >> On 07/19/2013 03:36 AM, Domenico Andreoli wrote: >>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote: >>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote: >>>>> >>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig > b/arch/arm/mach-bcm53xx/Kconfig >>>>>> new file mode 100644 >>>>>> index 0000000..1e16e87 >>>>>> --- /dev/null >>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig >>>>>> @@ -0,0 +1,10 @@ >>>>>> +config ARCH_BCM53XX >>>>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" >>>>> >>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx >>>>> SoCs. This doesn't sound really easy to follow. >>> >>> At the time of the BCM281XX merge we considered that such directories > would >>> mostly contain board files only, being these new entries DT based. Hence >>> the choice of mach-bcm to collect all of them. >>> >>> I think you should then put this stuff there. >> >> So you think I should move the file from >> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ? > > yes > > this looks more comsistent with the actual soc name: > arch/arm/mach-bcm/bcm530xx.c > > but I find also acceptable the complete name of the "parent" soc (as I'm > doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351) have more in common than the vendor name, so I do not think it is a good idea to place them all at mach-bcm. >> Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from >> the same family and they should be supported by the same code, so there >> is no reason to have a bcm47xx.c and a bcm53xx.c. >> >>>> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I >>>> do not know why there are two different names, probably marketing. >>>> >>>> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a >>>> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to >>>> not conflict with the MIPS part now. I know this could still cause >>>> problems and people will get confused, but I do not know a better name. >>> >>> I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are > ARM11, >>> single-core SoCs. >>> >>> Can we agree on a nice naming so that we actually clarify this silliness? >> >> We could name it BCM5301X like it is named the the vendor source code. >> Currently there are the following SoCs of this family available: >> BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017, >> BCM53018, BCM4707, BCM4708 and BCM4709. > > There is not a clear single pattern here, whatever choice won't be 100% > right. Users will need to read some help to pick the right choice. > BCM53010? But mine is not a strong opinion. > >> Internal there are two different >> chip IDs available 53010 (BCM4707) and 53018 (BCM53018). > > what do you mean with "internal" here? There is some register in the chip where the chipid is stored, according to the vendor code these two values are currently possible. This was changed for every generation with the MIPS SoCs, while one generation had some SoCs. Hauke
On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote: > On 07/24/2013 02:44 AM, Domenico Andreoli wrote: > > On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de > > <mailto:hauke@hauke-m.de>> wrote: > >> On 07/19/2013 03:36 AM, Domenico Andreoli wrote: > >>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote: > >>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote: > >>>>> > >>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig > > b/arch/arm/mach-bcm53xx/Kconfig > >>>>>> new file mode 100644 > >>>>>> index 0000000..1e16e87 > >>>>>> --- /dev/null > >>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig > >>>>>> @@ -0,0 +1,10 @@ > >>>>>> +config ARCH_BCM53XX > >>>>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" > >>>>> > >>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx > >>>>> SoCs. This doesn't sound really easy to follow. > >>> > >>> At the time of the BCM281XX merge we considered that such directories > > would > >>> mostly contain board files only, being these new entries DT based. Hence > >>> the choice of mach-bcm to collect all of them. > >>> > >>> I think you should then put this stuff there. > >> > >> So you think I should move the file from > >> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ? > > > > yes > > > > this looks more comsistent with the actual soc name: > > arch/arm/mach-bcm/bcm530xx.c > > > > but I find also acceptable the complete name of the "parent" soc (as I'm > > doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c > > I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351) > have more in common than the vendor name, so I do not think it is a good > idea to place them all at mach-bcm. In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever two or more SoCs share can hopefully modelled in a driver and as such would go in the drivers/ subtree. What's left is really SoC specific and, again hopefully, very minimal. There should not be any SoC so weird to require a whole subdirectory full of that SoC specific stuff. So grouping everything by vendor name looks quite appealing to me. Sharing the same subdir requires people working in it to talk and find agreements some more than the sparsely populated subdir did (because there is not a single maintainer who owns it). I think this is a big advantage Broadcomers can start with right now. > > >> Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from > >> the same family and they should be supported by the same code, so there > >> is no reason to have a bcm47xx.c and a bcm53xx.c. > >> > >>>> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I > >>>> do not know why there are two different names, probably marketing. > >>>> > >>>> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a > >>>> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to > >>>> not conflict with the MIPS part now. I know this could still cause > >>>> problems and people will get confused, but I do not know a better name. > >>> > >>> I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are > > ARM11, > >>> single-core SoCs. > >>> > >>> Can we agree on a nice naming so that we actually clarify this silliness? > >> > >> We could name it BCM5301X like it is named the the vendor source code. > >> Currently there are the following SoCs of this family available: > >> BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017, > >> BCM53018, BCM4707, BCM4708 and BCM4709. > > > > There is not a clear single pattern here, whatever choice won't be 100% > > right. Users will need to read some help to pick the right choice. > > BCM53010? But mine is not a strong opinion. > > > >> Internal there are two different > >> chip IDs available 53010 (BCM4707) and 53018 (BCM53018). > > > > what do you mean with "internal" here? > > There is some register in the chip where the chipid is stored, according > to the vendor code these two values are currently possible. This was > changed for every generation with the MIPS SoCs, while one generation > had some SoCs. Only two chipids for all these SoCs? Not that changes anything to me, I'm only trying to understand the beast. > > Hauke
On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote: > 2013/7/23 Matt Porter <matt.porter@linaro.org>: > > On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: > >> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: > >> > Hello, > >> > > >> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : > >> > > > + compatible = "brcm,bcm5301x"; > >> > > > >> > > Ok, this was nagging at me before I went on my very long vacation. I see > >> > > the "brcm" vendor prefix as a real consistency problem. I noticed on the > >> > > bcm281xx/kona family, we have been using "bcm" which is not logged in > >> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > >> > > already established use of "brcm" before any of the bcm281xx support > >> > > came in. Ideally, the vendor prefix should change to "bcm" since every > >> > > reference in the family names is BCM. However, if others want the least > >> > > amount of churn in making this consistent, we might have to go with > >> > > "brcm" across the board. > >> > > >> > I would like to keep "brcm" here because that is what has been defined as a > >> > vendor prefix, and is used beyond the scope of the ARM Linux kernel support > >> > even within Broadcom. Maybe it was an oversight, or rather a mistake to let > >> > >> brcm is the stock ticker. As far as I can search, this is the convention > >> for the vendor prefixes. > > > > No, correlation does not equal causation. The fact that some vendor > > prefixes in DT match the stock symbol is by chance of 3-4 character name > > being the same...nothing more. > > That was a bad argument as was later explained to me, I won't use that > reason again. I cited the stock ticker only because IIRC it's the reason my initial proposal for bcm has been ditched in favour of brcm when bcm2835 was initially proposed. > > It's pretty easy to see that the "ti" vendor prefix has no relation at > > all to their TXN symbol so that blows that convention out of the water. > > Rather, the prefix is based on somebody's notion of how that vendor's > > part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, > > never TXN OMAP. :) > > > > For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. > > It was appropriate before being the "wrong" vendor prefix was > allocated, now that "brcm" has been allocated we should stick to it > because otherwise we will break existing and on-going DT work. I still prefer bcm to brcm and I find enough evidence that bcm would be better in the long term. So if Broadcomers can agree on bcm, now it's still the cheapest time to fix in that direction, later will not be better. my 2c dom
On 07/25/2013 12:54 AM, Domenico Andreoli wrote: > On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote: >> On 07/24/2013 02:44 AM, Domenico Andreoli wrote: >>> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de >>> <mailto:hauke@hauke-m.de>> wrote: >>>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote: >>>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote: >>>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote: >>>>>>> >>>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig >>> b/arch/arm/mach-bcm53xx/Kconfig >>>>>>>> new file mode 100644 >>>>>>>> index 0000000..1e16e87 >>>>>>>> --- /dev/null >>>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig >>>>>>>> @@ -0,0 +1,10 @@ >>>>>>>> +config ARCH_BCM53XX >>>>>>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" >>>>>>> >>>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx >>>>>>> SoCs. This doesn't sound really easy to follow. >>>>> >>>>> At the time of the BCM281XX merge we considered that such directories >>> would >>>>> mostly contain board files only, being these new entries DT based. Hence >>>>> the choice of mach-bcm to collect all of them. >>>>> >>>>> I think you should then put this stuff there. >>>> >>>> So you think I should move the file from >>>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ? >>> >>> yes >>> >>> this looks more comsistent with the actual soc name: >>> arch/arm/mach-bcm/bcm530xx.c >>> >>> but I find also acceptable the complete name of the "parent" soc (as I'm >>> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c >> >> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351) >> have more in common than the vendor name, so I do not think it is a good >> idea to place them all at mach-bcm. > > In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever > two or more SoCs share can hopefully modelled in a driver and as such > would go in the drivers/ subtree. What's left is really SoC specific and, > again hopefully, very minimal. > > There should not be any SoC so weird to require a whole subdirectory full > of that SoC specific stuff. So grouping everything by vendor name looks > quite appealing to me. > > Sharing the same subdir requires people working in it to talk and find > agreements some more than the sparsely populated subdir did (because there > is not a single maintainer who owns it). I think this is a big advantage > Broadcomers can start with right now. I want to be able to build the BCM5301X SoC without building the current CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ? My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom submenu, but not build any code. Then the list of Broadcom SoCs is opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM. Hauke
On 13-07-25 01:33 PM, Hauke Mehrtens wrote: > On 07/25/2013 12:54 AM, Domenico Andreoli wrote: >> On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote: >>> On 07/24/2013 02:44 AM, Domenico Andreoli wrote: >>>> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de >>>> <mailto:hauke@hauke-m.de>> wrote: >>>>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote: >>>>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote: >>>>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote: >>>>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig >>>> b/arch/arm/mach-bcm53xx/Kconfig >>>>>>>>> new file mode 100644 >>>>>>>>> index 0000000..1e16e87 >>>>>>>>> --- /dev/null >>>>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig >>>>>>>>> @@ -0,0 +1,10 @@ >>>>>>>>> +config ARCH_BCM53XX >>>>>>>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC" >>>>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx >>>>>>>> SoCs. This doesn't sound really easy to follow. >>>>>> At the time of the BCM281XX merge we considered that such directories >>>> would >>>>>> mostly contain board files only, being these new entries DT based. Hence >>>>>> the choice of mach-bcm to collect all of them. >>>>>> >>>>>> I think you should then put this stuff there. >>>>> So you think I should move the file from >>>>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ? >>>> yes >>>> >>>> this looks more comsistent with the actual soc name: >>>> arch/arm/mach-bcm/bcm530xx.c >>>> >>>> but I find also acceptable the complete name of the "parent" soc (as I'm >>>> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c >>> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351) >>> have more in common than the vendor name, so I do not think it is a good >>> idea to place them all at mach-bcm. >> In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever >> two or more SoCs share can hopefully modelled in a driver and as such >> would go in the drivers/ subtree. What's left is really SoC specific and, >> again hopefully, very minimal. >> >> There should not be any SoC so weird to require a whole subdirectory full >> of that SoC specific stuff. So grouping everything by vendor name looks >> quite appealing to me. >> >> Sharing the same subdir requires people working in it to talk and find >> agreements some more than the sparsely populated subdir did (because there >> is not a single maintainer who owns it). I think this is a big advantage >> Broadcomers can start with right now. > I want to be able to build the BCM5301X SoC without building the current > CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ? > My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom > submenu, but not build any code. Then the list of Broadcom SoCs is > opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM. > > CONFIG_ARCH_BCM wasn't the best name, but it is there now. We intend to upstream the (mobile-team) ARM SoCs going forward, and have them be multiplatform and all buildable into a single zImage with the ARCH_BCM config option. Which is why this option does not have a chip name on it. Take ARCH_BCM == Broadcom Mobile team SoCs (I think that's what the help on it says). thanks, csd
On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote: > 2013/7/25 Domenico Andreoli <cavokz@gmail.com>: > > On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote: > >> 2013/7/23 Matt Porter <matt.porter@linaro.org>: > >> > On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: > >> >> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote: > >> >> > Hello, > >> >> > > >> >> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a écrit : > >> >> > > > + compatible = "brcm,bcm5301x"; > >> >> > > > >> >> > > Ok, this was nagging at me before I went on my very long > vacation. I see > >> >> > > the "brcm" vendor prefix as a real consistency problem. I noticed > on the > >> >> > > bcm281xx/kona family, we have been using "bcm" which is not > logged in > >> >> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had > >> >> > > already established use of "brcm" before any of the bcm281xx > support > >> >> > > came in. Ideally, the vendor prefix should change to "bcm" since > every > >> >> > > reference in the family names is BCM. However, if others want the > least > >> >> > > amount of churn in making this consistent, we might have to go > with > >> >> > > "brcm" across the board. > >> >> > > >> >> > I would like to keep "brcm" here because that is what has been > defined as a > >> >> > vendor prefix, and is used beyond the scope of the ARM Linux kernel > support > >> >> > even within Broadcom. Maybe it was an oversight, or rather a > mistake to let > >> >> > >> >> brcm is the stock ticker. As far as I can search, this is the > convention > >> >> for the vendor prefixes. > >> > > >> > No, correlation does not equal causation. The fact that some vendor > >> > prefixes in DT match the stock symbol is by chance of 3-4 character > name > >> > being the same...nothing more. > >> > >> That was a bad argument as was later explained to me, I won't use that > >> reason again. > > > > I cited the stock ticker only because IIRC it's the reason my initial > > proposal for bcm has been ditched in favour of brcm when bcm2835 was > > initially proposed. > > > >> > It's pretty easy to see that the "ti" vendor prefix has no relation at > >> > all to their TXN symbol so that blows that convention out of the water. > >> > Rather, the prefix is based on somebody's notion of how that vendor's > >> > part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, > >> > never TXN OMAP. :) > >> > > >> > For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. > >> > >> It was appropriate before being the "wrong" vendor prefix was > >> allocated, now that "brcm" has been allocated we should stick to it > >> because otherwise we will break existing and on-going DT work. > > > > I still prefer bcm to brcm and I find enough evidence that bcm would be > > better in the long term. > > > > So if Broadcomers can agree on bcm, now it's still the cheapest time to > > fix in that direction, later will not be better. > > If we are to fix it in stone, once and for all, let's go for the full name > which would avoid any kind of future confusion (this also seems to be the > tendency with new vendor prefixes these days). That way we could make > everyone happy with say: "broadcom,bcm2835". Would that work for everyone? I really like that. -Matt
On 13-07-25 05:04 PM, Matt Porter wrote: > On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote: >> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>: >>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote: >>>> 2013/7/23 Matt Porter <matt.porter@linaro.org>: >>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: >>>>> It's pretty easy to see that the "ti" vendor prefix has no relation at >>>>> all to their TXN symbol so that blows that convention out of the water. >>>>> Rather, the prefix is based on somebody's notion of how that vendor's >>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, >>>>> never TXN OMAP. :) >>>>> >>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. >>>> It was appropriate before being the "wrong" vendor prefix was >>>> allocated, now that "brcm" has been allocated we should stick to it >>>> because otherwise we will break existing and on-going DT work. >>> I still prefer bcm to brcm and I find enough evidence that bcm would be >>> better in the long term. >>> >>> So if Broadcomers can agree on bcm, now it's still the cheapest time to >>> fix in that direction, later will not be better. >> If we are to fix it in stone, once and for all, let's go for the full name >> which would avoid any kind of future confusion (this also seems to be the >> tendency with new vendor prefixes these days). That way we could make >> everyone happy with say: "broadcom,bcm2835". Would that work for everyone? > I really like that. > > -Matt > broadcom works for me also. thanks, csd
On Fri, Jul 26, 2013 at 03:16:52PM -0700, Christian Daudt wrote: > On 13-07-25 05:04 PM, Matt Porter wrote: > >On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote: > >>2013/7/25 Domenico Andreoli <cavokz@gmail.com>: > >>>On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote: > >>>>2013/7/23 Matt Porter <matt.porter@linaro.org>: > >>>>>On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: > >>>>>It's pretty easy to see that the "ti" vendor prefix has no relation at > >>>>>all to their TXN symbol so that blows that convention out of the water. > >>>>>Rather, the prefix is based on somebody's notion of how that vendor's > >>>>>part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, > >>>>>never TXN OMAP. :) > >>>>> > >>>>>For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. > >>>>It was appropriate before being the "wrong" vendor prefix was > >>>>allocated, now that "brcm" has been allocated we should stick to it > >>>>because otherwise we will break existing and on-going DT work. > >>>I still prefer bcm to brcm and I find enough evidence that bcm would be > >>>better in the long term. > >>> > >>>So if Broadcomers can agree on bcm, now it's still the cheapest time to > >>>fix in that direction, later will not be better. > >>If we are to fix it in stone, once and for all, let's go for the full name > >>which would avoid any kind of future confusion (this also seems to be the > >>tendency with new vendor prefixes these days). That way we could make > >>everyone happy with say: "broadcom,bcm2835". Would that work for everyone? > >I really like that. > > > >-Matt > > > broadcom works for me also. > thanks, > csd seconded thanks, Domenico
I'm CC'ing in the DT bindings maintainers in case they have any comment. On 07/26/2013 04:16 PM, Christian Daudt wrote: > On 13-07-25 05:04 PM, Matt Porter wrote: >> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote: >>> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>: >>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote: >>>>> 2013/7/23 Matt Porter <matt.porter@linaro.org>: >>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: >>>>>> It's pretty easy to see that the "ti" vendor prefix has no >>>>>> relation at >>>>>> all to their TXN symbol so that blows that convention out of the >>>>>> water. >>>>>> Rather, the prefix is based on somebody's notion of how that vendor's >>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, >>>>>> never TXN OMAP. :) >>>>>> >>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. >>>>> It was appropriate before being the "wrong" vendor prefix was >>>>> allocated, now that "brcm" has been allocated we should stick to it >>>>> because otherwise we will break existing and on-going DT work. >>>> I still prefer bcm to brcm and I find enough evidence that bcm would be >>>> better in the long term. >>>> >>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to >>>> fix in that direction, later will not be better. >>> If we are to fix it in stone, once and for all, let's go for the full >>> name >>> which would avoid any kind of future confusion (this also seems to be >>> the >>> tendency with new vendor prefixes these days). That way we could make >>> everyone happy with say: "broadcom,bcm2835". Would that work for >>> everyone? >> I really like that. >> >> -Matt >> > broadcom works for me also. > thanks, > csd I have no strong objection at this point in principle to renaming the vendor prefix used by the RPi support, although it will cause a bunch of pointless churn in the drivers to match the new compatible values, and in the pinctrl bindings for the custom properties there...
On Fri, Jul 26, 2013 at 11:30:29PM +0100, Stephen Warren wrote: > I'm CC'ing in the DT bindings maintainers in case they have any comment. > > On 07/26/2013 04:16 PM, Christian Daudt wrote: > > On 13-07-25 05:04 PM, Matt Porter wrote: > >> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote: > >>> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>: > >>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote: > >>>>> 2013/7/23 Matt Porter <matt.porter@linaro.org>: > >>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: > >>>>>> It's pretty easy to see that the "ti" vendor prefix has no > >>>>>> relation at > >>>>>> all to their TXN symbol so that blows that convention out of the > >>>>>> water. > >>>>>> Rather, the prefix is based on somebody's notion of how that vendor's > >>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, > >>>>>> never TXN OMAP. :) > >>>>>> > >>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. > >>>>> It was appropriate before being the "wrong" vendor prefix was > >>>>> allocated, now that "brcm" has been allocated we should stick to it > >>>>> because otherwise we will break existing and on-going DT work. > >>>> I still prefer bcm to brcm and I find enough evidence that bcm would be > >>>> better in the long term. > >>>> > >>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to > >>>> fix in that direction, later will not be better. > >>> If we are to fix it in stone, once and for all, let's go for the full > >>> name > >>> which would avoid any kind of future confusion (this also seems to be > >>> the > >>> tendency with new vendor prefixes these days). That way we could make > >>> everyone happy with say: "broadcom,bcm2835". Would that work for > >>> everyone? > >> I really like that. > >> > >> -Matt > >> > > broadcom works for me also. > > thanks, > > csd > > I have no strong objection at this point in principle to renaming the > vendor prefix used by the RPi support, although it will cause a bunch of > pointless churn in the drivers to match the new compatible values, and > in the pinctrl bindings for the custom properties there... > I'd be happy to have "broadcom" for all *new* bindings, as it's already in some bindings alongside "bcm" and "brcm", and is certainly the clearest of the available options. However, given the strong feelings of many against breaking existing dts, we need to support the existing instances of "bcm" and "brcm" in bindings. This doesn't preclude us also supporting "broadcom,$DEVICE" alongside the existing "bcm,$DEVICE" and/or "brcm,$DEVICE" for those that have a strong desire for consistency in future dts, unless there's a feeling that creates too much churn. In the end, this is a purely cosmetic change, so we can live with it as-is at the cost of another entry in an FAQ somewhere. Thanks, Mark.
On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote: > On Fri, Jul 26, 2013 at 11:30:29PM +0100, Stephen Warren wrote: > > I'm CC'ing in the DT bindings maintainers in case they have any comment. > > > > On 07/26/2013 04:16 PM, Christian Daudt wrote: > > > On 13-07-25 05:04 PM, Matt Porter wrote: > > >> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote: > > >>> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>: > > >>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote: > > >>>>> 2013/7/23 Matt Porter <matt.porter@linaro.org>: > > >>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote: > > >>>>>> It's pretty easy to see that the "ti" vendor prefix has no > > >>>>>> relation at > > >>>>>> all to their TXN symbol so that blows that convention out of the > > >>>>>> water. > > >>>>>> Rather, the prefix is based on somebody's notion of how that vendor's > > >>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, > > >>>>>> never TXN OMAP. :) > > >>>>>> > > >>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate. > > >>>>> It was appropriate before being the "wrong" vendor prefix was > > >>>>> allocated, now that "brcm" has been allocated we should stick to it > > >>>>> because otherwise we will break existing and on-going DT work. > > >>>> I still prefer bcm to brcm and I find enough evidence that bcm would be > > >>>> better in the long term. > > >>>> > > >>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to > > >>>> fix in that direction, later will not be better. > > >>> If we are to fix it in stone, once and for all, let's go for the full > > >>> name > > >>> which would avoid any kind of future confusion (this also seems to be > > >>> the > > >>> tendency with new vendor prefixes these days). That way we could make > > >>> everyone happy with say: "broadcom,bcm2835". Would that work for > > >>> everyone? > > >> I really like that. > > >> > > >> -Matt > > >> > > > broadcom works for me also. > > > thanks, > > > csd > > > > I have no strong objection at this point in principle to renaming the > > vendor prefix used by the RPi support, although it will cause a bunch of > > pointless churn in the drivers to match the new compatible values, and > > in the pinctrl bindings for the custom properties there... > > > > I'd be happy to have "broadcom" for all *new* bindings, as it's already > in some bindings alongside "bcm" and "brcm", and is certainly the > clearest of the available options. > > However, given the strong feelings of many against breaking existing > dts, we need to support the existing instances of "bcm" and "brcm" in Whoa, how would existing dts break? At this instant in time, all the bindings and dts are still in the kernel tree. A series to address this make all bindings, drivers, and dts consistent in one shot. > bindings. This doesn't preclude us also supporting "broadcom,$DEVICE" > alongside the existing "bcm,$DEVICE" and/or "brcm,$DEVICE" for those > that have a strong desire for consistency in future dts, unless there's > a feeling that creates too much churn. As it stands now, "bcm" is 100% unacceptable. It is not captured in vendor-prefixes.txt and thus all the drivers/dts using it should have been rejected. It *has* to be fixed by either 1) adding the additional prefix to vendor-prefixes.txt 2) changing it to the registered prefix "brcm" 3) changing to another unified prefix > In the end, this is a purely cosmetic change, so we can live with it > as-is at the cost of another entry in an FAQ somewhere. The only argument I have against this is that DT bindings that went upstream in the last 6 months or more really should be considered more of staging quality. They've had little oversight as has been illuminated in recent events leading to the maintainership change. Since mistakes were made in keeping to the vision of bindings being specification quality and set in stone, it makes little sense to me to create this spec filled with multiple legacy names. Especially at a point where the binding maintainership and process is just starting to mature. With that said, we can fix the current broken state of the "bcm" bindings with a one line patch to vendor-prefixes.txt. If avoiding churn is the highest priority I'd be happy to do that and just end this discussion. -Matt
On 07/29/2013 07:20 AM, Matt Porter wrote: > On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote: ... >> I'd be happy to have "broadcom" for all *new* bindings, as it's already >> in some bindings alongside "bcm" and "brcm", and is certainly the >> clearest of the available options. >> >> However, given the strong feelings of many against breaking existing >> dts, we need to support the existing instances of "bcm" and "brcm" in > > Whoa, how would existing dts break? At this instant in time, all the > bindings and dts are still in the kernel tree. A series to address this > make all bindings, drivers, and dts consistent in one shot. While there are some *.dts files in the kernel source tree, that is no guarantee that: a) People don't have custom *.dts files that are not in the kernel source tree, and hence can't be updated by Linux kernel patches. b) People actually replace their *.dtb when updating their zImage. Since DT is explicitly supposed to be an ABI, everything is explicitly supposed to work if they do only update their zImage and not their *.dtb.
On 13-07-29 10:06 AM, Stephen Warren wrote: > On 07/29/2013 07:20 AM, Matt Porter wrote: >> On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote: > ... >>> I'd be happy to have "broadcom" for all *new* bindings, as it's already >>> in some bindings alongside "bcm" and "brcm", and is certainly the >>> clearest of the available options. >>> >>> However, given the strong feelings of many against breaking existing >>> dts, we need to support the existing instances of "bcm" and "brcm" in >> Whoa, how would existing dts break? At this instant in time, all the >> bindings and dts are still in the kernel tree. A series to address this >> make all bindings, drivers, and dts consistent in one shot. > While there are some *.dts files in the kernel source tree, that is no > guarantee that: > > a) People don't have custom *.dts files that are not in the kernel > source tree, and hence can't be updated by Linux kernel patches. > > b) People actually replace their *.dtb when updating their zImage. Since > DT is explicitly supposed to be an ABI, everything is explicitly > supposed to work if they do only update their zImage and not their *.dtb. > In the interest of maintaining compatibility, we've discussed this internally @ Broadcom and we'll be standardizing on brcm vendor prefix going forward (at least the 2 teams represented in this thread...). Given that I am responsible for all of the current offending uses of "bcm," in dt bindings, and I can assure that switching them at this point causes no damage to the platforms (as the kernel tree being upstreamed is not yet being used internally), I'll follow up with a patch to switch these "bcm," uses into "brcm,". Going forward, our new drivers will switch to brcm, prior to being submitted upstream. With that, we can safely remove all vestiges of "bcm," dt prefix. Thanks, csd
diff --git a/MAINTAINERS b/MAINTAINERS index bf61e04..b72ba65 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1795,6 +1795,13 @@ F: arch/arm/boot/dts/bcm2835* F: arch/arm/configs/bcm2835_defconfig F: drivers/*/*bcm2835* +BROADCOM BCM53XX ARM ARCHICTURE +M: Hauke Mehrtens <hauke@hauke-m.de> +L: linux-arm-kernel@lists.infradead.org +S: Maintained +F: arch/arm/mach-bcm53xx/ +F: arch/arm/boot/dts/bcm53* + BROADCOM TG3 GIGABIT ETHERNET DRIVER M: Nithin Nayak Sujir <nsujir@broadcom.com> M: Michael Chan <mchan@broadcom.com> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ba412e0..ee7362e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig" source "arch/arm/mach-bcm2835/Kconfig" +source "arch/arm/mach-bcm53xx/Kconfig" + source "arch/arm/mach-clps711x/Kconfig" source "arch/arm/mach-cns3xxx/Kconfig" diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index e401a76..74e32f6 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -93,6 +93,10 @@ choice bool "Kernel low-level debugging on BCM2835 PL011 UART" depends on ARCH_BCM2835 + config DEBUG_BCM53XX + bool "Kernel low-level debugging on BCM53XX UART1" + depends on ARCH_BCM53XX + config DEBUG_CLPS711X_UART1 bool "Kernel low-level debugging messages via UART1" depends on ARCH_CLPS711X @@ -762,6 +766,7 @@ endchoice config DEBUG_LL_INCLUDE string default "debug/bcm2835.S" if DEBUG_BCM2835 + default "debug/bcm53xx.S" if DEBUG_BCM53XX default "debug/cns3xxx.S" if DEBUG_CNS3XXX default "debug/exynos.S" if DEBUG_EXYNOS_UART default "debug/highbank.S" if DEBUG_HIGHBANK_UART diff --git a/arch/arm/Makefile b/arch/arm/Makefile index c0ac0f5..4a69cd5 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000 machine-$(CONFIG_ARCH_AT91) += at91 machine-$(CONFIG_ARCH_BCM) += bcm machine-$(CONFIG_ARCH_BCM2835) += bcm2835 +machine-$(CONFIG_ARCH_BCM53XX) += bcm53xx machine-$(CONFIG_ARCH_CLPS711X) += clps711x machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx machine-$(CONFIG_ARCH_DAVINCI) += davinci diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 641b3c9..480a68e 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ zynq-zc706.dtb \ zynq-zed.dtb +dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb targets += dtbs targets += $(dtb-y) diff --git a/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts new file mode 100644 index 0000000..d1b97aa --- /dev/null +++ b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts @@ -0,0 +1,20 @@ +/* + * Broadcom BCM47XX / BCM53XX arm platform code. + * + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> + * + * Licensed under the GNU/GPL. See COPYING for details. + */ + +/dts-v1/; + +/include/ "bcm5301x.dtsi" + +/ { + model = "Netgear R6250 V1 (BCM4708)"; + compatible = "netgear,r6250v1", "brcm,bcm5301x"; + + memory { + reg = <0x00000000 0x08000000>; + }; +}; diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi new file mode 100644 index 0000000..638350d --- /dev/null +++ b/arch/arm/boot/dts/bcm5301x.dtsi @@ -0,0 +1,72 @@ +/* + * Broadcom BCM47XX / BCM53XX ARM platform code. + * + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> + * + * Licensed under the GNU/GPL. See COPYING for details. + */ + +/include/ "skeleton.dtsi" + +/ { + compatible = "brcm,bcm5301x"; + model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC"; + interrupt-parent = <&gic>; + + chosen { + bootargs = "console=ttyS0,115200 earlyprintk debug"; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a9"; + reg = <0>; + }; + }; + + clocks { + #address-cells = <1>; + #size-cells = <0>; + + clk_periph: periph { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <400000000>; + }; + }; + + uart@18000300 { + compatible = "ns16550"; + reg = <0x18000300 0x100>; + interrupts = <0 85 4>; + clock-frequency = <100000000>; + }; + + uart@18000400 { + compatible = "ns16550"; + reg = <0x18000400 0x100>; + interrupts = <0 85 4>; + clock-frequency = <100000000>; + }; + + gic: interrupt-controller@19021000 { + compatible = "arm,cortex-a9-gic"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x19021000 0x1000>, + <0x19020100 0x100>; + }; + + timer@19020200 { + compatible = "arm,cortex-a9-global-timer"; + reg = <0x19020200 0x100>; + interrupts = <1 11 0xf04>; + clocks = <&clk_periph>; + #clock-cells = <0>; + }; +}; diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S new file mode 100644 index 0000000..98c836b --- /dev/null +++ b/arch/arm/include/debug/bcm53xx.S @@ -0,0 +1,19 @@ +/* + * Macros used for EARLY_PRINTK, in low-level UART debug console + * + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> + * + * Licensed under the GNU/GPL. See COPYING for details. + */ + +#define BCM53XX_UART1_PHYS 0x18000300 +#define BCM53XX_UART1_VIRT 0xf1000300 +#define BCM53XX_UART1_SH 0 + + .macro addruart, rp, rv, tmp + ldr \rp, =BCM53XX_UART1_PHYS @ MMU off, Physical + ldr \rv, =BCM53XX_UART1_VIRT @ MMU on, Virtual + .endm + +#define UART_SHIFT BCM53XX_UART1_SH +#include <asm/hardware/debug-8250.S> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig new file mode 100644 index 0000000..1e16e87 --- /dev/null +++ b/arch/arm/mach-bcm53xx/Kconfig @@ -0,0 +1,10 @@ +config ARCH_BCM53XX + bool "Broadcom BCM47XX / BCM53XX ARM SoC" + select CPU_V7 + select ARM_GIC + select HAVE_CLK + select GENERIC_CLOCKEVENTS + select GENERIC_TIME + select ARM_GLOBAL_TIMER + help + Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores. diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile new file mode 100644 index 0000000..88da84d --- /dev/null +++ b/arch/arm/mach-bcm53xx/Makefile @@ -0,0 +1 @@ +obj-y += bcm53xx.o diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c new file mode 100644 index 0000000..aa5bd397 --- /dev/null +++ b/arch/arm/mach-bcm53xx/bcm53xx.c @@ -0,0 +1,68 @@ +/* + * Broadcom BCM47XX / BCM53XX ARM platform code. + * + * Copyright 2013 Hauke Mehrtens <hauke@hauke-m.de> + * + * Licensed under the GNU/GPL. See COPYING for details. + */ +#include <linux/of_address.h> +#include <linux/of_platform.h> +#include <linux/irqchip.h> +#include <linux/clocksource.h> +#include <linux/clk-provider.h> + +#include <asm/mach/arch.h> +#include <asm/mach/map.h> +#include <asm/signal.h> + +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr, + struct pt_regs *regs) +{ + /* + * These happen for no good reason + * possibly left over from CFE + */ + pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n", + addr, fsr); + + /* Returning non-zero causes fault display and panic */ + return 0; +} + +static void bcm53xx_aborts_enable(void) +{ + /* Install our hook */ + hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0, + "imprecise external abort"); +} + +static void __init bcm53xx_timer_init(void) +{ + of_clk_init(NULL); + clocksource_of_init(); +} + +void __init bcm53xx_map_io(void) +{ + debug_ll_io_init(); + bcm53xx_aborts_enable(); +} + +static void __init bcm53xx_dt_init(void) +{ + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); +} + +static const char const *bcm53xx_dt_compat[] = { + "brcm,bcm5301x", + "netgear,r6250v1", + NULL, +}; + +DT_MACHINE_START(BCM53XX, "BCM53XX") + .init_machine = bcm53xx_dt_init, + .map_io = bcm53xx_map_io, + .init_irq = irqchip_init, + .init_time = bcm53xx_timer_init, + .dt_compat = bcm53xx_dt_compat, +MACHINE_END
This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ... This SoC uses a Dual core CPU, but this is currently not implemented. More information about this SoC can be found here: http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- A bootlog can be found here: http://pastebin.com/0MYYC7Fx MAINTAINERS | 7 +++ arch/arm/Kconfig | 2 + arch/arm/Kconfig.debug | 5 ++ arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/bcm5301x-netgear-r6250.dts | 20 +++++++ arch/arm/boot/dts/bcm5301x.dtsi | 72 ++++++++++++++++++++++++++ arch/arm/include/debug/bcm53xx.S | 19 +++++++ arch/arm/mach-bcm53xx/Kconfig | 10 ++++ arch/arm/mach-bcm53xx/Makefile | 1 + arch/arm/mach-bcm53xx/bcm53xx.c | 68 ++++++++++++++++++++++++ 11 files changed, 206 insertions(+) create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi create mode 100644 arch/arm/include/debug/bcm53xx.S create mode 100644 arch/arm/mach-bcm53xx/Kconfig create mode 100644 arch/arm/mach-bcm53xx/Makefile create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c