* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
@ 2013-07-16 13:52 Hauke Mehrtens
2013-07-16 15:14 ` Matt Porter
` (2 more replies)
0 siblings, 3 replies; 38+ messages in thread
From: Hauke Mehrtens @ 2013-07-16 13:52 UTC (permalink / raw)
To: linux-arm-kernel
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";
+ 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>;
+ 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 related [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: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 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: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 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 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 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 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 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: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-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-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-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 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-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 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-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
* [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-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
[not found] ` <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
@ 2013-07-24 19:21 ` Hauke Mehrtens
2013-07-24 22:54 ` Domenico Andreoli
0 siblings, 1 reply; 38+ messages in thread
From: Hauke Mehrtens @ 2013-07-24 19:21 UTC (permalink / raw)
To: linux-arm-kernel
On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de
> <mailto:hauke@hauke-m.de>> wrote:
>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
>>>>>
>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
> b/arch/arm/mach-bcm53xx/Kconfig
>>>>>> new file mode 100644
>>>>>> index 0000000..1e16e87
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>>>>> @@ -0,0 +1,10 @@
>>>>>> +config ARCH_BCM53XX
>>>>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>>>>
>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
>>>>> SoCs. This doesn't sound really easy to follow.
>>>
>>> At the time of the BCM281XX merge we considered that such directories
> would
>>> mostly contain board files only, being these new entries DT based. Hence
>>> the choice of mach-bcm to collect all of them.
>>>
>>> I think you should then put this stuff there.
>>
>> So you think I should move the file from
>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
>
> yes
>
> this looks more comsistent with the actual soc name:
> arch/arm/mach-bcm/bcm530xx.c
>
> but I find also acceptable the complete name of the "parent" soc (as I'm
> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
have more in common than the vendor name, so I do not think it is a good
idea to place them all at mach-bcm.
>> Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from
>> the same family and they should be supported by the same code, so there
>> is no reason to have a bcm47xx.c and a bcm53xx.c.
>>
>>>> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I
>>>> do not know why there are two different names, probably marketing.
>>>>
>>>> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a
>>>> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to
>>>> not conflict with the MIPS part now. I know this could still cause
>>>> problems and people will get confused, but I do not know a better name.
>>>
>>> I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are
> ARM11,
>>> single-core SoCs.
>>>
>>> Can we agree on a nice naming so that we actually clarify this silliness?
>>
>> We could name it BCM5301X like it is named the the vendor source code.
>> Currently there are the following SoCs of this family available:
>> BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017,
>> BCM53018, BCM4707, BCM4708 and BCM4709.
>
> There is not a clear single pattern here, whatever choice won't be 100%
> right. Users will need to read some help to pick the right choice.
> BCM53010? But mine is not a strong opinion.
>
>> Internal there are two different
>> chip IDs available 53010 (BCM4707) and 53018 (BCM53018).
>
> what do you mean with "internal" here?
There is some register in the chip where the chipid is stored, according
to the vendor code these two values are currently possible. This was
changed for every generation with the MIPS SoCs, while one generation
had some SoCs.
Hauke
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-24 19:21 ` Hauke Mehrtens
@ 2013-07-24 22:54 ` Domenico Andreoli
2013-07-25 20:33 ` Hauke Mehrtens
0 siblings, 1 reply; 38+ messages in thread
From: Domenico Andreoli @ 2013-07-24 22:54 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
> On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
> > On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de
> > <mailto:hauke@hauke-m.de>> wrote:
> >> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
> >>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
> >>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
> >>>>>
> >>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
> > b/arch/arm/mach-bcm53xx/Kconfig
> >>>>>> new file mode 100644
> >>>>>> index 0000000..1e16e87
> >>>>>> --- /dev/null
> >>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
> >>>>>> @@ -0,0 +1,10 @@
> >>>>>> +config ARCH_BCM53XX
> >>>>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC"
> >>>>>
> >>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
> >>>>> SoCs. This doesn't sound really easy to follow.
> >>>
> >>> At the time of the BCM281XX merge we considered that such directories
> > would
> >>> mostly contain board files only, being these new entries DT based. Hence
> >>> the choice of mach-bcm to collect all of them.
> >>>
> >>> I think you should then put this stuff there.
> >>
> >> So you think I should move the file from
> >> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
> >
> > yes
> >
> > this looks more comsistent with the actual soc name:
> > arch/arm/mach-bcm/bcm530xx.c
> >
> > but I find also acceptable the complete name of the "parent" soc (as I'm
> > doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
>
> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
> have more in common than the vendor name, so I do not think it is a good
> idea to place them all at mach-bcm.
In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
two or more SoCs share can hopefully modelled in a driver and as such
would go in the drivers/ subtree. What's left is really SoC specific and,
again hopefully, very minimal.
There should not be any SoC so weird to require a whole subdirectory full
of that SoC specific stuff. So grouping everything by vendor name looks
quite appealing to me.
Sharing the same subdir requires people working in it to talk and find
agreements some more than the sparsely populated subdir did (because there
is not a single maintainer who owns it). I think this is a big advantage
Broadcomers can start with right now.
>
> >> Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from
> >> the same family and they should be supported by the same code, so there
> >> is no reason to have a bcm47xx.c and a bcm53xx.c.
> >>
> >>>> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I
> >>>> do not know why there are two different names, probably marketing.
> >>>>
> >>>> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a
> >>>> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to
> >>>> not conflict with the MIPS part now. I know this could still cause
> >>>> problems and people will get confused, but I do not know a better name.
> >>>
> >>> I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are
> > ARM11,
> >>> single-core SoCs.
> >>>
> >>> Can we agree on a nice naming so that we actually clarify this silliness?
> >>
> >> We could name it BCM5301X like it is named the the vendor source code.
> >> Currently there are the following SoCs of this family available:
> >> BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017,
> >> BCM53018, BCM4707, BCM4708 and BCM4709.
> >
> > There is not a clear single pattern here, whatever choice won't be 100%
> > right. Users will need to read some help to pick the right choice.
> > BCM53010? But mine is not a strong opinion.
> >
> >> Internal there are two different
> >> chip IDs available 53010 (BCM4707) and 53018 (BCM53018).
> >
> > what do you mean with "internal" here?
>
> There is some register in the chip where the chipid is stored, according
> to the vendor code these two values are currently possible. This was
> changed for every generation with the MIPS SoCs, while one generation
> had some SoCs.
Only two chipids for all these SoCs? Not that changes anything to me,
I'm only trying to understand the beast.
>
> Hauke
^ 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-24 22:54 ` Domenico Andreoli
@ 2013-07-25 20:33 ` Hauke Mehrtens
2013-07-25 21:37 ` Christian Daudt
0 siblings, 1 reply; 38+ messages in thread
From: Hauke Mehrtens @ 2013-07-25 20:33 UTC (permalink / raw)
To: linux-arm-kernel
On 07/25/2013 12:54 AM, Domenico Andreoli wrote:
> On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
>> On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
>>> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de
>>> <mailto:hauke@hauke-m.de>> wrote:
>>>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
>>>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
>>>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
>>> b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..1e16e87
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>> +config ARCH_BCM53XX
>>>>>>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>>>>>>
>>>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
>>>>>>> SoCs. This doesn't sound really easy to follow.
>>>>>
>>>>> At the time of the BCM281XX merge we considered that such directories
>>> would
>>>>> mostly contain board files only, being these new entries DT based. Hence
>>>>> the choice of mach-bcm to collect all of them.
>>>>>
>>>>> I think you should then put this stuff there.
>>>>
>>>> So you think I should move the file from
>>>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
>>>
>>> yes
>>>
>>> this looks more comsistent with the actual soc name:
>>> arch/arm/mach-bcm/bcm530xx.c
>>>
>>> but I find also acceptable the complete name of the "parent" soc (as I'm
>>> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
>>
>> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
>> have more in common than the vendor name, so I do not think it is a good
>> idea to place them all at mach-bcm.
>
> In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
> two or more SoCs share can hopefully modelled in a driver and as such
> would go in the drivers/ subtree. What's left is really SoC specific and,
> again hopefully, very minimal.
>
> There should not be any SoC so weird to require a whole subdirectory full
> of that SoC specific stuff. So grouping everything by vendor name looks
> quite appealing to me.
>
> Sharing the same subdir requires people working in it to talk and find
> agreements some more than the sparsely populated subdir did (because there
> is not a single maintainer who owns it). I think this is a big advantage
> Broadcomers can start with right now.
I want to be able to build the BCM5301X SoC without building the current
CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ?
My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom
submenu, but not build any code. Then the list of Broadcom SoCs is
opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.
Hauke
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-25 20:33 ` Hauke Mehrtens
@ 2013-07-25 21:37 ` Christian Daudt
2013-07-25 21:58 ` Domenico Andreoli
0 siblings, 1 reply; 38+ messages in thread
From: Christian Daudt @ 2013-07-25 21:37 UTC (permalink / raw)
To: linux-arm-kernel
On 13-07-25 01:33 PM, Hauke Mehrtens wrote:
> On 07/25/2013 12:54 AM, Domenico Andreoli wrote:
>> On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
>>> On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
>>>> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de
>>>> <mailto:hauke@hauke-m.de>> wrote:
>>>>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
>>>>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
>>>>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
>>>>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
>>>> b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>>> new file mode 100644
>>>>>>>>> index 0000000..1e16e87
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>>> +config ARCH_BCM53XX
>>>>>>>>> + bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>>>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
>>>>>>>> SoCs. This doesn't sound really easy to follow.
>>>>>> At the time of the BCM281XX merge we considered that such directories
>>>> would
>>>>>> mostly contain board files only, being these new entries DT based. Hence
>>>>>> the choice of mach-bcm to collect all of them.
>>>>>>
>>>>>> I think you should then put this stuff there.
>>>>> So you think I should move the file from
>>>>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
>>>> yes
>>>>
>>>> this looks more comsistent with the actual soc name:
>>>> arch/arm/mach-bcm/bcm530xx.c
>>>>
>>>> but I find also acceptable the complete name of the "parent" soc (as I'm
>>>> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
>>> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
>>> have more in common than the vendor name, so I do not think it is a good
>>> idea to place them all at mach-bcm.
>> In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
>> two or more SoCs share can hopefully modelled in a driver and as such
>> would go in the drivers/ subtree. What's left is really SoC specific and,
>> again hopefully, very minimal.
>>
>> There should not be any SoC so weird to require a whole subdirectory full
>> of that SoC specific stuff. So grouping everything by vendor name looks
>> quite appealing to me.
>>
>> Sharing the same subdir requires people working in it to talk and find
>> agreements some more than the sparsely populated subdir did (because there
>> is not a single maintainer who owns it). I think this is a big advantage
>> Broadcomers can start with right now.
> I want to be able to build the BCM5301X SoC without building the current
> CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ?
> My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom
> submenu, but not build any code. Then the list of Broadcom SoCs is
> opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.
>
>
CONFIG_ARCH_BCM wasn't the best name, but it is there now. We intend to
upstream the (mobile-team) ARM SoCs going forward, and have them be
multiplatform and all buildable into a single zImage with the ARCH_BCM
config option. Which is why this option does not have a chip name on it.
Take ARCH_BCM == Broadcom Mobile team SoCs (I think that's what the help
on it says).
thanks,
csd
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-25 21:37 ` Christian Daudt
@ 2013-07-25 21:58 ` Domenico Andreoli
0 siblings, 0 replies; 38+ messages in thread
From: Domenico Andreoli @ 2013-07-25 21:58 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 25, 2013 at 02:37:07PM -0700, Christian Daudt wrote:
> On 13-07-25 01:33 PM, Hauke Mehrtens wrote:
> >On 07/25/2013 12:54 AM, Domenico Andreoli wrote:
> >>On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
> >>>On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
> >>>>On Wednesday, July 24, 2013, Hauke Mehrtens <hauke@hauke-m.de
> >>>><mailto:hauke@hauke-m.de>> wrote:
> >>>>>On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
> >>>>>>On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
> >>>>>>>On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
> >>>>>>>>>diff --git a/arch/arm/mach-bcm53xx/Kconfig
> >>>>b/arch/arm/mach-bcm53xx/Kconfig
> >>>>>>>>>new file mode 100644
> >>>>>>>>>index 0000000..1e16e87
> >>>>>>>>>--- /dev/null
> >>>>>>>>>+++ b/arch/arm/mach-bcm53xx/Kconfig
> >>>>>>>>>@@ -0,0 +1,10 @@
> >>>>>>>>>+config ARCH_BCM53XX
> >>>>>>>>>+ bool "Broadcom BCM47XX / BCM53XX ARM SoC"
> >>>>>>>>So the directory is named mach-bcm53xx, but you also handle BCM47xx
> >>>>>>>>SoCs. This doesn't sound really easy to follow.
> >>>>>>At the time of the BCM281XX merge we considered that such directories
> >>>>would
> >>>>>>mostly contain board files only, being these new entries DT based. Hence
> >>>>>>the choice of mach-bcm to collect all of them.
> >>>>>>
> >>>>>>I think you should then put this stuff there.
> >>>>>So you think I should move the file from
> >>>>>arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
> >>>>yes
> >>>>
> >>>>this looks more comsistent with the actual soc name:
> >>>>arch/arm/mach-bcm/bcm530xx.c
> >>>>
> >>>>but I find also acceptable the complete name of the "parent" soc (as I'm
> >>>>doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
> >>>I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
> >>>have more in common than the vendor name, so I do not think it is a good
> >>>idea to place them all at mach-bcm.
> >>In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
> >>two or more SoCs share can hopefully modelled in a driver and as such
> >>would go in the drivers/ subtree. What's left is really SoC specific and,
> >>again hopefully, very minimal.
> >>
> >>There should not be any SoC so weird to require a whole subdirectory full
> >>of that SoC specific stuff. So grouping everything by vendor name looks
> >>quite appealing to me.
> >>
> >>Sharing the same subdir requires people working in it to talk and find
> >>agreements some more than the sparsely populated subdir did (because there
> >>is not a single maintainer who owns it). I think this is a big advantage
> >>Broadcomers can start with right now.
> >I want to be able to build the BCM5301X SoC without building the current
> >CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ?
> >My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom
> >submenu, but not build any code. Then the list of Broadcom SoCs is
> >opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.
> >
> >
> CONFIG_ARCH_BCM wasn't the best name, but it is there now. We intend
> to upstream the (mobile-team) ARM SoCs going forward, and have them
> be multiplatform and all buildable into a single zImage with the
> ARCH_BCM config option. Which is why this option does not have a
> chip name on it.
> Take ARCH_BCM == Broadcom Mobile team SoCs (I think that's what the
> help on it says).
This solves the double linking issue I had. No need to configure
CONFIG_ARCH_BCM if you are not interested in what it brings.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..230b5d7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
# Machine directory name. This list is sorted alphanumerically
# by CONFIG_* macro name.
machine-$(CONFIG_ARCH_AT91) += at91
-machine-$(CONFIG_ARCH_BCM) += bcm
+machine-y += bcm
machine-$(CONFIG_ARCH_BCM2835) += bcm2835
machine-$(CONFIG_ARCH_CLPS711X) += clps711x
machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx
Regards,
Domenico
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
[not found] ` <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
@ 2013-07-26 0:04 ` Matt Porter
2013-07-26 22:16 ` Christian Daudt
0 siblings, 1 reply; 38+ messages in thread
From: Matt Porter @ 2013-07-26 0:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>:
> > On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> >> 2013/7/23 Matt Porter <matt.porter@linaro.org>:
> >> > On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> >> >> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> >> >> > Hello,
> >> >> >
> >> >> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> >> >> > > > + compatible = "brcm,bcm5301x";
> >> >> > >
> >> >> > > Ok, this was nagging at me before I went on my very long
> vacation. I see
> >> >> > > the "brcm" vendor prefix as a real consistency problem. I noticed
> on the
> >> >> > > bcm281xx/kona family, we have been using "bcm" which is not
> logged in
> >> >> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> >> >> > > already established use of "brcm" before any of the bcm281xx
> support
> >> >> > > came in. Ideally, the vendor prefix should change to "bcm" since
> every
> >> >> > > reference in the family names is BCM. However, if others want the
> least
> >> >> > > amount of churn in making this consistent, we might have to go
> with
> >> >> > > "brcm" across the board.
> >> >> >
> >> >> > I would like to keep "brcm" here because that is what has been
> defined as a
> >> >> > vendor prefix, and is used beyond the scope of the ARM Linux kernel
> support
> >> >> > even within Broadcom. Maybe it was an oversight, or rather a
> mistake to let
> >> >>
> >> >> brcm is the stock ticker. As far as I can search, this is the
> convention
> >> >> for the vendor prefixes.
> >> >
> >> > No, correlation does not equal causation. The fact that some vendor
> >> > prefixes in DT match the stock symbol is by chance of 3-4 character
> name
> >> > being the same...nothing more.
> >>
> >> That was a bad argument as was later explained to me, I won't use that
> >> reason again.
> >
> > I cited the stock ticker only because IIRC it's the reason my initial
> > proposal for bcm has been ditched in favour of brcm when bcm2835 was
> > initially proposed.
> >
> >> > It's pretty easy to see that the "ti" vendor prefix has no relation at
> >> > all to their TXN symbol so that blows that convention out of the water.
> >> > Rather, the prefix is based on somebody's notion of how that vendor's
> >> > part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> >> > never TXN OMAP. :)
> >> >
> >> > For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> >>
> >> It was appropriate before being the "wrong" vendor prefix was
> >> allocated, now that "brcm" has been allocated we should stick to it
> >> because otherwise we will break existing and on-going DT work.
> >
> > I still prefer bcm to brcm and I find enough evidence that bcm would be
> > better in the long term.
> >
> > So if Broadcomers can agree on bcm, now it's still the cheapest time to
> > fix in that direction, later will not be better.
>
> If we are to fix it in stone, once and for all, let's go for the full name
> which would avoid any kind of future confusion (this also seems to be the
> tendency with new vendor prefixes these days). That way we could make
> everyone happy with say: "broadcom,bcm2835". Would that work for everyone?
I really like that.
-Matt
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-26 0:04 ` Matt Porter
@ 2013-07-26 22:16 ` Christian Daudt
2013-07-26 22:29 ` Domenico Andreoli
2013-07-26 22:30 ` Stephen Warren
0 siblings, 2 replies; 38+ messages in thread
From: Christian Daudt @ 2013-07-26 22:16 UTC (permalink / raw)
To: linux-arm-kernel
On 13-07-25 05:04 PM, Matt Porter wrote:
> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
>> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>:
>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
>>>> 2013/7/23 Matt Porter <matt.porter@linaro.org>:
>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
>>>>> It's pretty easy to see that the "ti" vendor prefix has no relation at
>>>>> all to their TXN symbol so that blows that convention out of the water.
>>>>> Rather, the prefix is based on somebody's notion of how that vendor's
>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
>>>>> never TXN OMAP. :)
>>>>>
>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
>>>> It was appropriate before being the "wrong" vendor prefix was
>>>> allocated, now that "brcm" has been allocated we should stick to it
>>>> because otherwise we will break existing and on-going DT work.
>>> I still prefer bcm to brcm and I find enough evidence that bcm would be
>>> better in the long term.
>>>
>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to
>>> fix in that direction, later will not be better.
>> If we are to fix it in stone, once and for all, let's go for the full name
>> which would avoid any kind of future confusion (this also seems to be the
>> tendency with new vendor prefixes these days). That way we could make
>> everyone happy with say: "broadcom,bcm2835". Would that work for everyone?
> I really like that.
>
> -Matt
>
broadcom works for me also.
thanks,
csd
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-26 22:16 ` Christian Daudt
@ 2013-07-26 22:29 ` Domenico Andreoli
2013-07-26 22:30 ` Stephen Warren
1 sibling, 0 replies; 38+ messages in thread
From: Domenico Andreoli @ 2013-07-26 22:29 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 26, 2013 at 03:16:52PM -0700, Christian Daudt wrote:
> On 13-07-25 05:04 PM, Matt Porter wrote:
> >On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> >>2013/7/25 Domenico Andreoli <cavokz@gmail.com>:
> >>>On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> >>>>2013/7/23 Matt Porter <matt.porter@linaro.org>:
> >>>>>On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> >>>>>It's pretty easy to see that the "ti" vendor prefix has no relation at
> >>>>>all to their TXN symbol so that blows that convention out of the water.
> >>>>>Rather, the prefix is based on somebody's notion of how that vendor's
> >>>>>part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> >>>>>never TXN OMAP. :)
> >>>>>
> >>>>>For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> >>>>It was appropriate before being the "wrong" vendor prefix was
> >>>>allocated, now that "brcm" has been allocated we should stick to it
> >>>>because otherwise we will break existing and on-going DT work.
> >>>I still prefer bcm to brcm and I find enough evidence that bcm would be
> >>>better in the long term.
> >>>
> >>>So if Broadcomers can agree on bcm, now it's still the cheapest time to
> >>>fix in that direction, later will not be better.
> >>If we are to fix it in stone, once and for all, let's go for the full name
> >>which would avoid any kind of future confusion (this also seems to be the
> >>tendency with new vendor prefixes these days). That way we could make
> >>everyone happy with say: "broadcom,bcm2835". Would that work for everyone?
> >I really like that.
> >
> >-Matt
> >
> broadcom works for me also.
> thanks,
> csd
seconded
thanks,
Domenico
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-26 22:16 ` Christian Daudt
2013-07-26 22:29 ` Domenico Andreoli
@ 2013-07-26 22:30 ` Stephen Warren
2013-07-29 9:30 ` Mark Rutland
1 sibling, 1 reply; 38+ messages in thread
From: Stephen Warren @ 2013-07-26 22:30 UTC (permalink / raw)
To: linux-arm-kernel
I'm CC'ing in the DT bindings maintainers in case they have any comment.
On 07/26/2013 04:16 PM, Christian Daudt wrote:
> On 13-07-25 05:04 PM, Matt Porter wrote:
>> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
>>> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>:
>>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
>>>>> 2013/7/23 Matt Porter <matt.porter@linaro.org>:
>>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
>>>>>> It's pretty easy to see that the "ti" vendor prefix has no
>>>>>> relation at
>>>>>> all to their TXN symbol so that blows that convention out of the
>>>>>> water.
>>>>>> Rather, the prefix is based on somebody's notion of how that vendor's
>>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
>>>>>> never TXN OMAP. :)
>>>>>>
>>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
>>>>> It was appropriate before being the "wrong" vendor prefix was
>>>>> allocated, now that "brcm" has been allocated we should stick to it
>>>>> because otherwise we will break existing and on-going DT work.
>>>> I still prefer bcm to brcm and I find enough evidence that bcm would be
>>>> better in the long term.
>>>>
>>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to
>>>> fix in that direction, later will not be better.
>>> If we are to fix it in stone, once and for all, let's go for the full
>>> name
>>> which would avoid any kind of future confusion (this also seems to be
>>> the
>>> tendency with new vendor prefixes these days). That way we could make
>>> everyone happy with say: "broadcom,bcm2835". Would that work for
>>> everyone?
>> I really like that.
>>
>> -Matt
>>
> broadcom works for me also.
> thanks,
> csd
I have no strong objection at this point in principle to renaming the
vendor prefix used by the RPi support, although it will cause a bunch of
pointless churn in the drivers to match the new compatible values, and
in the pinctrl bindings for the custom properties there...
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-26 22:30 ` Stephen Warren
@ 2013-07-29 9:30 ` Mark Rutland
2013-07-29 13:20 ` Matt Porter
0 siblings, 1 reply; 38+ messages in thread
From: Mark Rutland @ 2013-07-29 9:30 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 26, 2013 at 11:30:29PM +0100, Stephen Warren wrote:
> I'm CC'ing in the DT bindings maintainers in case they have any comment.
>
> On 07/26/2013 04:16 PM, Christian Daudt wrote:
> > On 13-07-25 05:04 PM, Matt Porter wrote:
> >> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> >>> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>:
> >>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> >>>>> 2013/7/23 Matt Porter <matt.porter@linaro.org>:
> >>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> >>>>>> It's pretty easy to see that the "ti" vendor prefix has no
> >>>>>> relation at
> >>>>>> all to their TXN symbol so that blows that convention out of the
> >>>>>> water.
> >>>>>> Rather, the prefix is based on somebody's notion of how that vendor's
> >>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> >>>>>> never TXN OMAP. :)
> >>>>>>
> >>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> >>>>> It was appropriate before being the "wrong" vendor prefix was
> >>>>> allocated, now that "brcm" has been allocated we should stick to it
> >>>>> because otherwise we will break existing and on-going DT work.
> >>>> I still prefer bcm to brcm and I find enough evidence that bcm would be
> >>>> better in the long term.
> >>>>
> >>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to
> >>>> fix in that direction, later will not be better.
> >>> If we are to fix it in stone, once and for all, let's go for the full
> >>> name
> >>> which would avoid any kind of future confusion (this also seems to be
> >>> the
> >>> tendency with new vendor prefixes these days). That way we could make
> >>> everyone happy with say: "broadcom,bcm2835". Would that work for
> >>> everyone?
> >> I really like that.
> >>
> >> -Matt
> >>
> > broadcom works for me also.
> > thanks,
> > csd
>
> I have no strong objection at this point in principle to renaming the
> vendor prefix used by the RPi support, although it will cause a bunch of
> pointless churn in the drivers to match the new compatible values, and
> in the pinctrl bindings for the custom properties there...
>
I'd be happy to have "broadcom" for all *new* bindings, as it's already
in some bindings alongside "bcm" and "brcm", and is certainly the
clearest of the available options.
However, given the strong feelings of many against breaking existing
dts, we need to support the existing instances of "bcm" and "brcm" in
bindings. This doesn't preclude us also supporting "broadcom,$DEVICE"
alongside the existing "bcm,$DEVICE" and/or "brcm,$DEVICE" for those
that have a strong desire for consistency in future dts, unless there's
a feeling that creates too much churn.
In the end, this is a purely cosmetic change, so we can live with it
as-is at the cost of another entry in an FAQ somewhere.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-29 9:30 ` Mark Rutland
@ 2013-07-29 13:20 ` Matt Porter
2013-07-29 17:06 ` Stephen Warren
0 siblings, 1 reply; 38+ messages in thread
From: Matt Porter @ 2013-07-29 13:20 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote:
> On Fri, Jul 26, 2013 at 11:30:29PM +0100, Stephen Warren wrote:
> > I'm CC'ing in the DT bindings maintainers in case they have any comment.
> >
> > On 07/26/2013 04:16 PM, Christian Daudt wrote:
> > > On 13-07-25 05:04 PM, Matt Porter wrote:
> > >> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> > >>> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>:
> > >>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> > >>>>> 2013/7/23 Matt Porter <matt.porter@linaro.org>:
> > >>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> > >>>>>> It's pretty easy to see that the "ti" vendor prefix has no
> > >>>>>> relation at
> > >>>>>> all to their TXN symbol so that blows that convention out of the
> > >>>>>> water.
> > >>>>>> Rather, the prefix is based on somebody's notion of how that vendor's
> > >>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> > >>>>>> never TXN OMAP. :)
> > >>>>>>
> > >>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> > >>>>> It was appropriate before being the "wrong" vendor prefix was
> > >>>>> allocated, now that "brcm" has been allocated we should stick to it
> > >>>>> because otherwise we will break existing and on-going DT work.
> > >>>> I still prefer bcm to brcm and I find enough evidence that bcm would be
> > >>>> better in the long term.
> > >>>>
> > >>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to
> > >>>> fix in that direction, later will not be better.
> > >>> If we are to fix it in stone, once and for all, let's go for the full
> > >>> name
> > >>> which would avoid any kind of future confusion (this also seems to be
> > >>> the
> > >>> tendency with new vendor prefixes these days). That way we could make
> > >>> everyone happy with say: "broadcom,bcm2835". Would that work for
> > >>> everyone?
> > >> I really like that.
> > >>
> > >> -Matt
> > >>
> > > broadcom works for me also.
> > > thanks,
> > > csd
> >
> > I have no strong objection at this point in principle to renaming the
> > vendor prefix used by the RPi support, although it will cause a bunch of
> > pointless churn in the drivers to match the new compatible values, and
> > in the pinctrl bindings for the custom properties there...
> >
>
> I'd be happy to have "broadcom" for all *new* bindings, as it's already
> in some bindings alongside "bcm" and "brcm", and is certainly the
> clearest of the available options.
>
> However, given the strong feelings of many against breaking existing
> dts, we need to support the existing instances of "bcm" and "brcm" in
Whoa, how would existing dts break? At this instant in time, all the
bindings and dts are still in the kernel tree. A series to address this
make all bindings, drivers, and dts consistent in one shot.
> bindings. This doesn't preclude us also supporting "broadcom,$DEVICE"
> alongside the existing "bcm,$DEVICE" and/or "brcm,$DEVICE" for those
> that have a strong desire for consistency in future dts, unless there's
> a feeling that creates too much churn.
As it stands now, "bcm" is 100% unacceptable. It is not captured in
vendor-prefixes.txt and thus all the drivers/dts using it should have
been rejected. It *has* to be fixed by either 1) adding the additional
prefix to vendor-prefixes.txt 2) changing it to the registered prefix
"brcm" 3) changing to another unified prefix
> In the end, this is a purely cosmetic change, so we can live with it
> as-is at the cost of another entry in an FAQ somewhere.
The only argument I have against this is that DT bindings that went
upstream in the last 6 months or more really should be considered more of
staging quality. They've had little oversight as has been illuminated in
recent events leading to the maintainership change. Since mistakes were
made in keeping to the vision of bindings being specification quality
and set in stone, it makes little sense to me to create this spec filled
with multiple legacy names. Especially at a point where the binding
maintainership and process is just starting to mature.
With that said, we can fix the current broken state of the "bcm"
bindings with a one line patch to vendor-prefixes.txt. If avoiding
churn is the highest priority I'd be happy to do that and just
end this discussion.
-Matt
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-29 13:20 ` Matt Porter
@ 2013-07-29 17:06 ` Stephen Warren
2013-07-30 23:08 ` Christian Daudt
0 siblings, 1 reply; 38+ messages in thread
From: Stephen Warren @ 2013-07-29 17:06 UTC (permalink / raw)
To: linux-arm-kernel
On 07/29/2013 07:20 AM, Matt Porter wrote:
> On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote:
...
>> I'd be happy to have "broadcom" for all *new* bindings, as it's already
>> in some bindings alongside "bcm" and "brcm", and is certainly the
>> clearest of the available options.
>>
>> However, given the strong feelings of many against breaking existing
>> dts, we need to support the existing instances of "bcm" and "brcm" in
>
> Whoa, how would existing dts break? At this instant in time, all the
> bindings and dts are still in the kernel tree. A series to address this
> make all bindings, drivers, and dts consistent in one shot.
While there are some *.dts files in the kernel source tree, that is no
guarantee that:
a) People don't have custom *.dts files that are not in the kernel
source tree, and hence can't be updated by Linux kernel patches.
b) People actually replace their *.dtb when updating their zImage. Since
DT is explicitly supposed to be an ABI, everything is explicitly
supposed to work if they do only update their zImage and not their *.dtb.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
2013-07-29 17:06 ` Stephen Warren
@ 2013-07-30 23:08 ` Christian Daudt
0 siblings, 0 replies; 38+ messages in thread
From: Christian Daudt @ 2013-07-30 23:08 UTC (permalink / raw)
To: linux-arm-kernel
On 13-07-29 10:06 AM, Stephen Warren wrote:
> On 07/29/2013 07:20 AM, Matt Porter wrote:
>> On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote:
> ...
>>> I'd be happy to have "broadcom" for all *new* bindings, as it's already
>>> in some bindings alongside "bcm" and "brcm", and is certainly the
>>> clearest of the available options.
>>>
>>> However, given the strong feelings of many against breaking existing
>>> dts, we need to support the existing instances of "bcm" and "brcm" in
>> Whoa, how would existing dts break? At this instant in time, all the
>> bindings and dts are still in the kernel tree. A series to address this
>> make all bindings, drivers, and dts consistent in one shot.
> While there are some *.dts files in the kernel source tree, that is no
> guarantee that:
>
> a) People don't have custom *.dts files that are not in the kernel
> source tree, and hence can't be updated by Linux kernel patches.
>
> b) People actually replace their *.dtb when updating their zImage. Since
> DT is explicitly supposed to be an ABI, everything is explicitly
> supposed to work if they do only update their zImage and not their *.dtb.
>
In the interest of maintaining compatibility, we've discussed this
internally @ Broadcom and we'll be standardizing on brcm vendor prefix
going forward (at least the 2 teams represented in this thread...).
Given that I am responsible for all of the current offending uses of
"bcm," in dt bindings, and I can assure that switching them at this
point causes no damage to the platforms (as the kernel tree being
upstreamed is not yet being used internally), I'll follow up with a
patch to switch these "bcm," uses into "brcm,".
Going forward, our new drivers will switch to brcm, prior to being
submitted upstream. With that, we can safely remove all vestiges of
"bcm," dt prefix.
Thanks,
csd
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2013-07-30 23:08 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2013-07-16 18:13 ` Hauke Mehrtens
2013-07-16 23:52 ` Matt Porter
2013-07-16 23:44 ` Matt Porter
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 19:05 ` Florian Fainelli
2013-07-24 23:11 ` Domenico Andreoli
[not found] ` <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
2013-07-26 0:04 ` Matt Porter
2013-07-26 22:16 ` Christian Daudt
2013-07-26 22:29 ` Domenico Andreoli
2013-07-26 22:30 ` Stephen Warren
2013-07-29 9:30 ` Mark Rutland
2013-07-29 13:20 ` Matt Porter
2013-07-29 17:06 ` Stephen Warren
2013-07-30 23:08 ` Christian Daudt
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
2013-07-24 0:10 ` Christian Daudt
[not found] ` <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
2013-07-24 19:21 ` Hauke Mehrtens
2013-07-24 22:54 ` Domenico Andreoli
2013-07-25 20:33 ` Hauke Mehrtens
2013-07-25 21:37 ` Christian Daudt
2013-07-25 21:58 ` Domenico Andreoli
2013-07-19 13:03 ` Arnd Bergmann
2013-07-16 15:20 ` Thomas Petazzoni
2013-07-16 15:35 ` Hauke Mehrtens
2013-07-19 1:36 ` Domenico Andreoli
2013-07-23 22:10 ` Hauke Mehrtens
2013-07-16 23:19 ` Russell King - ARM Linux
2013-07-19 2:23 ` Domenico Andreoli
2013-07-23 21:54 ` Hauke Mehrtens
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.