* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 13:52 [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU Hauke Mehrtens
@ 2013-07-16 15:14 ` Matt Porter
2013-07-16 15:39 ` Hauke Mehrtens
` (2 more replies)
2013-07-16 15:20 ` Thomas Petazzoni
2013-07-19 2:23 ` Domenico Andreoli
2 siblings, 3 replies; 38+ messages in thread
From: Matt Porter @ 2013-07-16 15:14 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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 at 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 at 18000400 {
> + compatible = "ns16550";
> + reg = <0x18000400 0x100>;
> + interrupts = <0 85 4>;
> + clock-frequency = <100000000>;
> + };
> +
> + gic: interrupt-controller at 19021000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0x19021000 0x1000>,
> + <0x19020100 0x100>;
> + };
> +
> + timer at 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
>
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 15:14 ` Matt Porter
@ 2013-07-16 15:39 ` Hauke Mehrtens
2013-07-16 18:13 ` Hauke Mehrtens
2013-07-16 23:44 ` Matt Porter
2013-07-16 23:08 ` Florian Fainelli
2013-07-19 13:03 ` Arnd Bergmann
2 siblings, 2 replies; 38+ messages in thread
From: Hauke Mehrtens @ 2013-07-16 15:39 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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 at 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 at 18000400 {
>> + compatible = "ns16550";
>> + reg = <0x18000400 0x100>;
>> + interrupts = <0 85 4>;
>> + clock-frequency = <100000000>;
>> + };
>> +
>> + gic: interrupt-controller at 19021000 {
>> + compatible = "arm,cortex-a9-gic";
>> + #interrupt-cells = <3>;
>> + #address-cells = <0>;
>> + interrupt-controller;
>> + reg = <0x19021000 0x1000>,
>> + <0x19020100 0x100>;
>> + };
>> +
>> + timer at 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
>>
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 15:39 ` Hauke Mehrtens
@ 2013-07-16 18:13 ` Hauke Mehrtens
2013-07-16 23:52 ` Matt Porter
2013-07-16 23:44 ` Matt Porter
1 sibling, 1 reply; 38+ messages in thread
From: Hauke Mehrtens @ 2013-07-16 18:13 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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 at 18000400 {
>>> + compatible = "ns16550";
>>> + reg = <0x18000400 0x100>;
>>> + interrupts = <0 85 4>;
>>> + clock-frequency = <100000000>;
>>> + };
>>> +
>>> + gic: interrupt-controller at 19021000 {
>>> + compatible = "arm,cortex-a9-gic";
>>> + #interrupt-cells = <3>;
>>> + #address-cells = <0>;
>>> + interrupt-controller;
>>> + reg = <0x19021000 0x1000>,
>>> + <0x19020100 0x100>;
>>> + };
>>> +
>>> + timer at 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
>>>
>
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 18:13 ` Hauke Mehrtens
@ 2013-07-16 23:52 ` Matt Porter
0 siblings, 0 replies; 38+ messages in thread
From: Matt Porter @ 2013-07-16 23:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 15:39 ` Hauke Mehrtens
2013-07-16 18:13 ` Hauke Mehrtens
@ 2013-07-16 23:44 ` Matt Porter
1 sibling, 0 replies; 38+ messages in thread
From: Matt Porter @ 2013-07-16 23:44 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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 at 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 at 18000400 {
> >> + compatible = "ns16550";
> >> + reg = <0x18000400 0x100>;
> >> + interrupts = <0 85 4>;
> >> + clock-frequency = <100000000>;
> >> + };
> >> +
> >> + gic: interrupt-controller at 19021000 {
> >> + compatible = "arm,cortex-a9-gic";
> >> + #interrupt-cells = <3>;
> >> + #address-cells = <0>;
> >> + interrupt-controller;
> >> + reg = <0x19021000 0x1000>,
> >> + <0x19020100 0x100>;
> >> + };
> >> +
> >> + timer at 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
> >>
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 15:14 ` Matt Porter
2013-07-16 15:39 ` Hauke Mehrtens
@ 2013-07-16 23:08 ` Florian Fainelli
2013-07-16 23:42 ` Matt Porter
` (2 more replies)
2013-07-19 13:03 ` Arnd Bergmann
2 siblings, 3 replies; 38+ messages in thread
From: Florian Fainelli @ 2013-07-16 23:08 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
Florian
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 23:08 ` Florian Fainelli
@ 2013-07-16 23:42 ` Matt Porter
2013-07-19 2:06 ` Domenico Andreoli
2013-07-23 18:49 ` Matt Porter
2 siblings, 0 replies; 38+ messages in thread
From: Matt Porter @ 2013-07-16 23:42 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 23:08 ` Florian Fainelli
2013-07-16 23:42 ` Matt Porter
@ 2013-07-19 2:06 ` Domenico Andreoli
2013-07-23 18:57 ` Matt Porter
2013-07-23 18:49 ` Matt Porter
2 siblings, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2013-07-19 2:06 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-19 2:06 ` Domenico Andreoli
@ 2013-07-23 18:57 ` Matt Porter
2013-07-23 19:05 ` Florian Fainelli
0 siblings, 1 reply; 38+ messages in thread
From: Matt Porter @ 2013-07-23 18:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-23 18:57 ` Matt Porter
@ 2013-07-23 19:05 ` Florian Fainelli
2013-07-24 23:11 ` Domenico Andreoli
0 siblings, 1 reply; 38+ messages in thread
From: Florian Fainelli @ 2013-07-23 19:05 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-23 19:05 ` Florian Fainelli
@ 2013-07-24 23:11 ` Domenico Andreoli
[not found] ` <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2013-07-24 23:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 23:08 ` Florian Fainelli
2013-07-16 23:42 ` Matt Porter
2013-07-19 2:06 ` Domenico Andreoli
@ 2013-07-23 18:49 ` Matt Porter
2013-07-23 18:56 ` Florian Fainelli
2 siblings, 1 reply; 38+ messages in thread
From: Matt Porter @ 2013-07-23 18:49 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-23 18:49 ` Matt Porter
@ 2013-07-23 18:56 ` Florian Fainelli
2013-07-23 19:14 ` Arend van Spriel
2013-07-23 19:22 ` Matt Porter
0 siblings, 2 replies; 38+ messages in thread
From: Florian Fainelli @ 2013-07-23 18:56 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-23 18:56 ` Florian Fainelli
@ 2013-07-23 19:14 ` Arend van Spriel
2013-07-23 19:22 ` Matt Porter
1 sibling, 0 replies; 38+ messages in thread
From: Arend van Spriel @ 2013-07-23 19:14 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-23 18:56 ` Florian Fainelli
2013-07-23 19:14 ` Arend van Spriel
@ 2013-07-23 19:22 ` Matt Porter
2013-07-24 0:10 ` Christian Daudt
1 sibling, 1 reply; 38+ messages in thread
From: Matt Porter @ 2013-07-23 19:22 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-23 19:22 ` Matt Porter
@ 2013-07-24 0:10 ` Christian Daudt
[not found] ` <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
0 siblings, 1 reply; 38+ messages in thread
From: Christian Daudt @ 2013-07-24 0:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 15:14 ` Matt Porter
2013-07-16 15:39 ` Hauke Mehrtens
2013-07-16 23:08 ` Florian Fainelli
@ 2013-07-19 13:03 ` Arnd Bergmann
2 siblings, 0 replies; 38+ messages in thread
From: Arnd Bergmann @ 2013-07-19 13:03 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 13:52 [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU Hauke Mehrtens
2013-07-16 15:14 ` Matt Porter
@ 2013-07-16 15:20 ` Thomas Petazzoni
2013-07-16 15:35 ` Hauke Mehrtens
2013-07-16 23:19 ` Russell King - ARM Linux
2013-07-19 2:23 ` Domenico Andreoli
2 siblings, 2 replies; 38+ messages in thread
From: Thomas Petazzoni @ 2013-07-16 15:20 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 15:20 ` Thomas Petazzoni
@ 2013-07-16 15:35 ` Hauke Mehrtens
2013-07-19 1:36 ` Domenico Andreoli
2013-07-16 23:19 ` Russell King - ARM Linux
1 sibling, 1 reply; 38+ messages in thread
From: Hauke Mehrtens @ 2013-07-16 15:35 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 15:35 ` Hauke Mehrtens
@ 2013-07-19 1:36 ` Domenico Andreoli
2013-07-23 22:10 ` Hauke Mehrtens
0 siblings, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2013-07-19 1:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-19 1:36 ` Domenico Andreoli
@ 2013-07-23 22:10 ` Hauke Mehrtens
0 siblings, 0 replies; 38+ messages in thread
From: Hauke Mehrtens @ 2013-07-23 22:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 15:20 ` Thomas Petazzoni
2013-07-16 15:35 ` Hauke Mehrtens
@ 2013-07-16 23:19 ` Russell King - ARM Linux
1 sibling, 0 replies; 38+ messages in thread
From: Russell King - ARM Linux @ 2013-07-16 23:19 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-16 13:52 [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU Hauke Mehrtens
2013-07-16 15:14 ` Matt Porter
2013-07-16 15:20 ` Thomas Petazzoni
@ 2013-07-19 2:23 ` Domenico Andreoli
2013-07-23 21:54 ` Hauke Mehrtens
2 siblings, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2013-07-19 2:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-19 2:23 ` Domenico Andreoli
@ 2013-07-23 21:54 ` Hauke Mehrtens
0 siblings, 0 replies; 38+ messages in thread
From: Hauke Mehrtens @ 2013-07-23 21:54 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 38+ messages in thread