[PATCH v2] Add support for generic BCM SoC chipsets

[PATCH v2] Add support for generic BCM SoC chipsets

[Christian Daudt]

In order to start upstreaming Broadcom SoC support, create
a starting hierarchy, arch and dts files.
The first support SoC family that is planned is the
BCM281XX (BCM28145/28150/28155/28160) family of dual A9 mobile SoC cores
This code is just the skeleton code for get the machine upstreamed. It
has been made MULTIPLATFORM compatible.
Next steps
----------
Upstream a basic set of drivers - sufficient for a console boot to
ramdisk. These will includer timer, gpio, i2c drivers.
After this basic set, we will proceed with a more comprehensive set
of drivers for the 281XX SoC family.

v2 patch mods
--------
 - Remove l2x0_of_init call as there were problems with the code.
   A separate patch will be submitted with cache init code
 - Rename capri files and refs to bcm281xx-based names
 - Add bcm281xx binding doc
 - various misc cleanups

Signed-off-by: Christian Daudt <csd@broadcom.com>
---
 .../devicetree/bindings/arm/bcm/bcm281xx.txt       |    8 ++
 arch/arm/Kconfig                                   |    2 +
 arch/arm/Makefile                                  |    1 +
 arch/arm/boot/dts/Makefile                         |    1 +
 arch/arm/boot/dts/bcm28160-brt.dts                 |   30 +++++
 arch/arm/boot/dts/bcm281xx.dtsi                    |   50 +++++++++
 arch/arm/configs/bcm_defconfig                     |  114 ++++++++++++++++++++
 arch/arm/mach-bcm/Kconfig                          |   18 +++
 arch/arm/mach-bcm/Makefile                         |   13 +++
 arch/arm/mach-bcm/board_bcm.c                      |   58 ++++++++++
 10 files changed, 295 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt
 create mode 100644 arch/arm/boot/dts/bcm28160-brt.dts
 create mode 100644 arch/arm/boot/dts/bcm281xx.dtsi
 create mode 100644 arch/arm/configs/bcm_defconfig
 create mode 100644 arch/arm/mach-bcm/Kconfig
 create mode 100644 arch/arm/mach-bcm/Makefile
 create mode 100644 arch/arm/mach-bcm/board_bcm.c

diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt b/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt
new file mode 100644
index 0000000..c47200f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt
@@ -0,0 +1,8 @@
+Broadcom BCM281XX device tree bindings
+-------------------------------------------
+
+Boards with the bcm281xx SoC family shall have the following properties:
+
+Required root node property:
+
+compatible = "bcm,bcm281xx";
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ade7e92..3da77ba 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1022,6 +1022,8 @@ source "arch/arm/mach-mvebu/Kconfig"
 
 source "arch/arm/mach-at91/Kconfig"
 
+source "arch/arm/mach-bcm/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5f914fc..8523fdb 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -137,6 +137,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_AT91)		+= at91
+machine-$(CONFIG_ARCH_BCM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..25d347a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb \
 	usb_a9263.dtb \
 	usb_a9g20.dtb
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_BCM) += capri-brt.dtb
 dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
 	dove-cubox.dtb \
 	dove-dove-db.dtb
diff --git a/arch/arm/boot/dts/bcm28160-brt.dts b/arch/arm/boot/dts/bcm28160-brt.dts
new file mode 100644
index 0000000..1d0a217
--- /dev/null
+++ b/arch/arm/boot/dts/bcm28160-brt.dts
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2012 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+/include/ "bcm281xx.dtsi"
+
+/ {
+	model = "BCM28160 BRT board";
+	compatible = "bcm,bcm28160-brt", "bcm,bcm281xx";
+
+	memory {
+		reg = <0x80000000 0x40000000>; /* 1 GB */
+	};
+
+	uart at 3e000000 {
+		status = "okay";
+	};
+
+};
diff --git a/arch/arm/boot/dts/bcm281xx.dtsi b/arch/arm/boot/dts/bcm281xx.dtsi
new file mode 100644
index 0000000..e82713e
--- /dev/null
+++ b/arch/arm/boot/dts/bcm281xx.dtsi
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2012 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "BCM281xx SoC";
+	compatible = "bcm,bcm281xx";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8";
+	};
+
+	gic: interrupt-controller at 3ff00100 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x3ff01000 0x1000>,
+		      <0x3ff00100 0x100>;
+	};
+
+	uart at 3e000000 {
+		compatible = "snps,dw-apb-uart";
+		status = "disabled";
+		reg = <0x3e000000 0x1000>;
+		clock-frequency = <13000000>;
+		interrupts = <0x0 67 0x4>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+	};
+
+	L2: l2-cache {
+		    compatible = "arm,pl310-cache";
+		    reg = <0x3ff20000 0x1000>;
+		    cache-unified;
+		    cache-level = <2>;
+	};
+};
diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
new file mode 100644
index 0000000..e3bf2d6
--- /dev/null
+++ b/arch/arm/configs/bcm_defconfig
@@ -0,0 +1,114 @@
+CONFIG_EXPERIMENTAL=y
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=19
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_RESOURCE_COUNTERS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_BLK_CGROUP=y
+CONFIG_NAMESPACES=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_EFI_PARTITION=y
+CONFIG_ARCH_BCM=y
+CONFIG_ARM_THUMBEE=y
+CONFIG_ARM_ERRATA_743622=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+# CONFIG_COMPACTION is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=ttyS0,115200n8 mem=128M"
+CONFIG_CPU_IDLE=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_PM_RUNTIME=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_PROC_DEVICETREE=y
+# CONFIG_BLK_DEV is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_SCAN_ASYNC=y
+CONFIG_INPUT_FF_MEMLESS=y
+CONFIG_INPUT_JOYDEV=y
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_UINPUT=y
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_8250_RSA=y
+CONFIG_SERIAL_8250_DW=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+# CONFIG_HWMON is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_FB=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_FUSE_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_CONFIGFS_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_PRINTK_TIME=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=110
+CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_LL=y
+CONFIG_CRC_CCITT=y
+CONFIG_CRC_T10DIF=y
+CONFIG_CRC_ITU_T=y
+CONFIG_CRC7=y
+CONFIG_XZ_DEC=y
+CONFIG_AVERAGE=y
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
new file mode 100644
index 0000000..8c1393a
--- /dev/null
+++ b/arch/arm/mach-bcm/Kconfig
@@ -0,0 +1,18 @@
+config ARCH_BCM
+	bool "Broadcom SoC" if ARCH_MULTI_V7
+	depends on MMU
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_ERRATA_754322
+	select ARM_ERRATA_764369 if SMP
+	select ARM_GIC
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_GPIO
+	select GENERIC_TIME
+	select GPIO_BCM
+	select SPARSE_IRQ
+	select TICK_ONESHOT
+	help
+	  This enables support for system based on Broadcom SoCs.
+          It currently supports BCM28145/28150/28155/28160 chips.
+
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
new file mode 100644
index 0000000..bbf4122
--- /dev/null
+++ b/arch/arm/mach-bcm/Makefile
@@ -0,0 +1,13 @@
+#
+# Copyright (C) 2012 Broadcom Corporation
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation version 2.
+#
+# This program is distributed "as is" WITHOUT ANY WARRANTY of any
+# kind, whether express or implied; without even the implied warranty
+# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+obj-$(CONFIG_ARCH_BCM) := board_bcm.o
diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c
new file mode 100644
index 0000000..5afabab
--- /dev/null
+++ b/arch/arm/mach-bcm/board_bcm.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2012 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <asm/io.h>
+
+#include <asm/mach/arch.h>
+#include <asm/hardware/gic.h>
+
+#include <asm/mach/time.h>
+
+static const struct of_device_id irq_match[] = {
+	{.compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+	{}
+};
+
+static void timer_init(void)
+{
+}
+
+static struct sys_timer timer = {
+	.init = timer_init,
+};
+
+static void __init init_irq(void)
+{
+	of_irq_init(irq_match);
+}
+
+static void __init board_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL,
+		&platform_bus);
+}
+
+static const char * const capri_dt_compat[] = { "bcm,capri", NULL, };
+
+DT_MACHINE_START(CAPRI_DT, "Broadcom Application Processor")
+	.init_irq = init_irq,
+	.timer = &timer,
+	.init_machine = board_init,
+	.dt_compat = capri_dt_compat,
+	.handle_irq = gic_handle_irq,
+MACHINE_END
-- 
1.7.1

[PATCH v2] Add support for generic BCM SoC chipsets

[Florian Fainelli]

Hi Christian,

On Sunday 11 November 2012 06:57:14 Christian Daudt wrote:
> In order to start upstreaming Broadcom SoC support, create
> a starting hierarchy, arch and dts files.
> The first support SoC family that is planned is the
> BCM281XX (BCM28145/28150/28155/28160) family of dual A9 mobile SoC cores
> This code is just the skeleton code for get the machine upstreamed. It
> has been made MULTIPLATFORM compatible.
> Next steps
> ----------
> Upstream a basic set of drivers - sufficient for a console boot to
> ramdisk. These will includer timer, gpio, i2c drivers.
> After this basic set, we will proceed with a more comprehensive set
> of drivers for the 281XX SoC family.

Would not it make more sense to use mach-bcm281xx as a directory name instead
of mach-bcm which sounds a tad too generic? This would also make it consistent
with Domenico's mach-bcm47xx and the existing bcm47xx and bcm63xx MIPS-based
SoC support.
-- 
Florian

[PATCH v2] Add support for generic BCM SoC chipsets

[Christian Daudt]

On Sun, Nov 11, 2012 at 7:53 AM, Florian Fainelli <florian@openwrt.org>wrote:

> Hi Christian,
>
> On Sunday 11 November 2012 06:57:14 Christian Daudt wrote:
> > In order to start upstreaming Broadcom SoC support, create
> > a starting hierarchy, arch and dts files.
> > The first support SoC family that is planned is the
> > BCM281XX (BCM28145/28150/28155/28160) family of dual A9 mobile SoC cores
> > This code is just the skeleton code for get the machine upstreamed. It
> > has been made MULTIPLATFORM compatible.
> > Next steps
> > ----------
> > Upstream a basic set of drivers - sufficient for a console boot to
> > ramdisk. These will includer timer, gpio, i2c drivers.
> > After this basic set, we will proceed with a more comprehensive set
> > of drivers for the 281XX SoC family.
>
> Would not it make more sense to use mach-bcm281xx as a directory name
> instead
> of mach-bcm which sounds a tad too generic? This would also make it
> consistent
> with Domenico's mach-bcm47xx and the existing bcm47xx and bcm63xx
> MIPS-based
> SoC support.
>

I'm following the other mobile ARM SoCs which all have a single mach-
directory for various families of chips (mach-tegra, mach-omap2, etc...).
Plus the intent is to have a single set of mach files that works across bcm
SoCs, so it is preferable to keep it in a single mach-bcm.

 thanks,
  csd



> --
> Florian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121111/24d6e94c/attachment-0001.html>

[PATCH v2] Add support for generic BCM SoC chipsets

[Florian Fainelli]

On Sunday 11 November 2012 09:32:13 Christian Daudt wrote:
> On Sun, Nov 11, 2012 at 7:53 AM, Florian Fainelli <florian@openwrt.org>wrote:
> 
> > Hi Christian,
> >
> > On Sunday 11 November 2012 06:57:14 Christian Daudt wrote:
> > > In order to start upstreaming Broadcom SoC support, create
> > > a starting hierarchy, arch and dts files.
> > > The first support SoC family that is planned is the
> > > BCM281XX (BCM28145/28150/28155/28160) family of dual A9 mobile SoC cores
> > > This code is just the skeleton code for get the machine upstreamed. It
> > > has been made MULTIPLATFORM compatible.
> > > Next steps
> > > ----------
> > > Upstream a basic set of drivers - sufficient for a console boot to
> > > ramdisk. These will includer timer, gpio, i2c drivers.
> > > After this basic set, we will proceed with a more comprehensive set
> > > of drivers for the 281XX SoC family.
> >
> > Would not it make more sense to use mach-bcm281xx as a directory name
> > instead
> > of mach-bcm which sounds a tad too generic? This would also make it
> > consistent
> > with Domenico's mach-bcm47xx and the existing bcm47xx and bcm63xx
> > MIPS-based
> > SoC support.
> >
> 
> I'm following the other mobile ARM SoCs which all have a single mach-
> directory for various families of chips (mach-tegra, mach-omap2, etc...).
> Plus the intent is to have a single set of mach files that works across bcm
> SoCs, so it is preferable to keep it in a single mach-bcm.

Your argument does not make sense here, if I follow your point, these
directories should have been named mach-nvidia or mach-ti respectively if I 
follow your convention (you use the vendor name, not a commercial product name)

I do understand your intent, yet you announce support for BCM281xx SoCs, and
one of your dtsi file is bcm281xx.dtsi. At least something like mach-bcmmobile
sounds better to me.

We have had the inclusion of the "socfpga" platform which is already very
badly named because it does not make it clear that it is an Altera platform and
not some generic SoC + FPGA platform.

Anyway, that's just my 2 cents.
-- 
Florian

[PATCH v2] Add support for generic BCM SoC chipsets

[Stephen Warren]

On 11/11/2012 10:32 AM, Christian Daudt wrote:
> 
> 
> On Sun, Nov 11, 2012 at 7:53 AM, Florian Fainelli <florian@openwrt.org
> <mailto:florian@openwrt.org>> wrote:
> 
>     Hi Christian,
> 
>     On Sunday 11 November 2012 06:57:14 Christian Daudt wrote:
>     > In order to start upstreaming Broadcom SoC support, create
>     > a starting hierarchy, arch and dts files.
>     > The first support SoC family that is planned is the
>     > BCM281XX (BCM28145/28150/28155/28160) family of dual A9 mobile SoC
>     cores
>     > This code is just the skeleton code for get the machine upstreamed. It
>     > has been made MULTIPLATFORM compatible.
>     > Next steps
>     > ----------
>     > Upstream a basic set of drivers - sufficient for a console boot to
>     > ramdisk. These will includer timer, gpio, i2c drivers.
>     > After this basic set, we will proceed with a more comprehensive set
>     > of drivers for the 281XX SoC family.
> 
>     Would not it make more sense to use mach-bcm281xx as a directory
>     name instead
>     of mach-bcm which sounds a tad too generic? This would also make it
>     consistent
>     with Domenico's mach-bcm47xx and the existing bcm47xx and bcm63xx
>     MIPS-based
>     SoC support.
> 
> 
> I'm following the other mobile ARM SoCs which all have a single mach-
> directory for various families of chips (mach-tegra, mach-omap2,
> etc...). Plus the intent is to have a single set of mach files that
> works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.

It's quite possible to create one directory now, e.g. mach-bcm281xx, and
then when consolidation with other mach-bcm* happens, merge all those
directories into a single mach-bcm. I would tend to prefer (but only
lightly) using mach-bcm281xx now and then renaming later, unless you
plan on expanding the SoC support in the pretty near future.

[PATCH v2] Add support for generic BCM SoC chipsets

[Arnd Bergmann]

On Sunday 11 November 2012, Stephen Warren wrote:
> > I'm following the other mobile ARM SoCs which all have a single mach-
> > directory for various families of chips (mach-tegra, mach-omap2,
> > etc...). Plus the intent is to have a single set of mach files that
> > works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.
> 
> It's quite possible to create one directory now, e.g. mach-bcm281xx, and
> then when consolidation with other mach-bcm* happens, merge all those
> directories into a single mach-bcm. I would tend to prefer (but only
> lightly) using mach-bcm281xx now and then renaming later, unless you
> plan on expanding the SoC support in the pretty near future.

I think the main question is how many files we expect to see in the
platform directories for each of bcm3528, bcm281xx and bcm476x. Right
now, my feeling is that each of them can be a single file, since most
of the stuff that has traditionally been in mach-* directories is
moving out to drivers now.

If that is the case, having one directory for each platform is a little
silly and we should just stick them all in one place, using the
"mach-bcm" name more as a help for people looking for the code than
an indication of being a single soc family or maintained by the same
person.  We already have some precedent in shmobile, which contains
some platforms that were completely distinct at the time they were
introduced.

You still have to work out how you want to maintain that directory though,
either just having per-file maintainers, or having multiple people
take responsible for the entire directory.

	Arnd

[PATCH v2] Add support for generic BCM SoC chipsets

[Russell King - ARM Linux]

On Sun, Nov 11, 2012 at 06:57:14AM -0800, Christian Daudt wrote:
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <asm/io.h>

Please use linux/io.h rather than asm/io.h throughout your patch sets.
However, I don't see anything in this file which requires this header,
so it's better off being removed entirely.

[PATCH v2] Add support for generic BCM SoC chipsets

[Domenico Andreoli]

On Mon, Nov 12, 2012 at 03:00:57PM +0000, Arnd Bergmann wrote:
> On Sunday 11 November 2012, Stephen Warren wrote:
> > > I'm following the other mobile ARM SoCs which all have a single mach-
> > > directory for various families of chips (mach-tegra, mach-omap2,
> > > etc...). Plus the intent is to have a single set of mach files that
> > > works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.
> > 
> > It's quite possible to create one directory now, e.g. mach-bcm281xx, and
> > then when consolidation with other mach-bcm* happens, merge all those
> > directories into a single mach-bcm. I would tend to prefer (but only
> > lightly) using mach-bcm281xx now and then renaming later, unless you
> > plan on expanding the SoC support in the pretty near future.
> 
> I think the main question is how many files we expect to see in the
> platform directories for each of bcm3528, bcm281xx and bcm476x. Right
> now, my feeling is that each of them can be a single file, since most
> of the stuff that has traditionally been in mach-* directories is
> moving out to drivers now.

I expect only DT-only stuff will be mainlined so one directory
(plat-brcm?) should be ok, right?

> You still have to work out how you want to maintain that directory though,
> either just having per-file maintainers, or having multiple people
> take responsible for the entire directory.

I'd like to take care of the bcm476x and related drivers unless Broadcom
wants to do it. Let me know in which directory.

Regards,
Domenico

[PATCH v2] Add support for generic BCM SoC chipsets

[Arnd Bergmann]

On Monday 12 November 2012, Domenico Andreoli wrote:
> On Mon, Nov 12, 2012 at 03:00:57PM +0000, Arnd Bergmann wrote:
> > On Sunday 11 November 2012, Stephen Warren wrote:
> > > > I'm following the other mobile ARM SoCs which all have a single mach-
> > > > directory for various families of chips (mach-tegra, mach-omap2,
> > > > etc...). Plus the intent is to have a single set of mach files that
> > > > works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.
> > > 
> > > It's quite possible to create one directory now, e.g. mach-bcm281xx, and
> > > then when consolidation with other mach-bcm* happens, merge all those
> > > directories into a single mach-bcm. I would tend to prefer (but only
> > > lightly) using mach-bcm281xx now and then renaming later, unless you
> > > plan on expanding the SoC support in the pretty near future.
> > 
> > I think the main question is how many files we expect to see in the
> > platform directories for each of bcm3528, bcm281xx and bcm476x. Right
> > now, my feeling is that each of them can be a single file, since most
> > of the stuff that has traditionally been in mach-* directories is
> > moving out to drivers now.
> 
> I expect only DT-only stuff will be mainlined so one directory
> (plat-brcm?) should be ok, right?

Right. The usual naming is to use 'mach-*' for one platform, and 'plat-*'
for stuff that spreads multiple 'mach-*' directories. In this case, the
name I would expect is either 'mach-bcm' as Christian suggested, or
'mach-brcm' if people have strong opinions in favor of that, but not
'plat-brcm'.

> > You still have to work out how you want to maintain that directory though,
> > either just having per-file maintainers, or having multiple people
> > take responsible for the entire directory.
> 
> I'd like to take care of the bcm476x and related drivers unless Broadcom
> wants to do it.

Yes, of course.

> Let me know in which directory.

I'll let you work that out with Stephen and Christian. I think just
'mach-bcm' is sufficent, but I think the three of you should come to
an agreement first.

	Arnd

[PATCH v2] Add support for generic BCM SoC chipsets

[Stephen Warren]

On 11/12/2012 10:05 AM, Arnd Bergmann wrote:
> On Monday 12 November 2012, Domenico Andreoli wrote:
>> On Mon, Nov 12, 2012 at 03:00:57PM +0000, Arnd Bergmann wrote:
>>> On Sunday 11 November 2012, Stephen Warren wrote:
>>>>> I'm following the other mobile ARM SoCs which all have a single mach-
>>>>> directory for various families of chips (mach-tegra, mach-omap2,
>>>>> etc...). Plus the intent is to have a single set of mach files that
>>>>> works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.
>>>>
>>>> It's quite possible to create one directory now, e.g. mach-bcm281xx, and
>>>> then when consolidation with other mach-bcm* happens, merge all those
>>>> directories into a single mach-bcm. I would tend to prefer (but only
>>>> lightly) using mach-bcm281xx now and then renaming later, unless you
>>>> plan on expanding the SoC support in the pretty near future.
>>>
>>> I think the main question is how many files we expect to see in the
>>> platform directories for each of bcm3528, bcm281xx and bcm476x. Right
>>> now, my feeling is that each of them can be a single file, since most
>>> of the stuff that has traditionally been in mach-* directories is
>>> moving out to drivers now.
>>
>> I expect only DT-only stuff will be mainlined so one directory
>> (plat-brcm?) should be ok, right?
> 
> Right. The usual naming is to use 'mach-*' for one platform, and 'plat-*'
> for stuff that spreads multiple 'mach-*' directories. In this case, the
> name I would expect is either 'mach-bcm' as Christian suggested, or
> 'mach-brcm' if people have strong opinions in favor of that, but not
> 'plat-brcm'.
> 
>>> You still have to work out how you want to maintain that directory though,
>>> either just having per-file maintainers, or having multiple people
>>> take responsible for the entire directory.
>>
>> I'd like to take care of the bcm476x and related drivers unless Broadcom
>> wants to do it.
> 
> Yes, of course.
> 
>> Let me know in which directory.
> 
> I'll let you work that out with Stephen and Christian. I think just
> 'mach-bcm' is sufficent, but I think the three of you should come to
> an agreement first.

I don't really have too strong of a preference. If the eventual intent
is for the directory to host all ARM Broadcom SoCs, then mach-bcm seems
reasonable.

[PATCH v2] Add support for generic BCM SoC chipsets

[Stephen Warren]

On 11/11/2012 07:57 AM, Christian Daudt wrote:
> In order to start upstreaming Broadcom SoC support, create
> a starting hierarchy, arch and dts files.
> The first support SoC family that is planned is the
> BCM281XX (BCM28145/28150/28155/28160) family of dual A9 mobile SoC cores
> This code is just the skeleton code for get the machine upstreamed. It
> has been made MULTIPLATFORM compatible.
> Next steps

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile

> +dtb-$(CONFIG_ARCH_BCM) += capri-brt.dtb

I think that needs to be renamed too.

> diff --git a/arch/arm/boot/dts/bcm281xx.dtsi b/arch/arm/boot/dts/bcm281xx.dtsi

> +/ {
> +	model = "BCM281xx SoC";
> +	compatible = "bcm,bcm281xx";

I think this should list the specific SoC rather than (or perhaps in
addition to) a wildcard.

Out of curiosity though, what kind of differences exist between the
various SoCs this wildcard is intended to cover;
bcm28145/28150/28155/28160? Are they simply package/pinout differences,
or something more involved?

> +	uart at 3e000000 {
> +		compatible = "snps,dw-apb-uart";

As I mentioned in my earlier reply, I think this should indicate the
specific instantiation of the IP too; something like
bcm,bcm28160-dw-apb-uart.

> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig

> +	help
> +	  This enables support for system based on Broadcom SoCs.
> +          It currently supports BCM28145/28150/28155/28160 chips.

The indentation looks a little odd there.

> diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c

> +static const char * const capri_dt_compat[] = { "bcm,capri", NULL, };

I think that needs to be updated too.

[PATCH v2] Add support for generic BCM SoC chipsets

[Christian Daudt]

On 12-11-12 09:15 AM, Stephen Warren wrote:
> On 11/12/2012 10:05 AM, Arnd Bergmann wrote:
>> On Monday 12 November 2012, Domenico Andreoli wrote:
>>> On Mon, Nov 12, 2012 at 03:00:57PM +0000, Arnd Bergmann wrote:
>>>> On Sunday 11 November 2012, Stephen Warren wrote:
>>>>>> I'm following the other mobile ARM SoCs which all have a single mach-
>>>>>> directory for various families of chips (mach-tegra, mach-omap2,
>>>>>> etc...). Plus the intent is to have a single set of mach files that
>>>>>> works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.
>>>>> It's quite possible to create one directory now, e.g. mach-bcm281xx, and
>>>>> then when consolidation with other mach-bcm* happens, merge all those
>>>>> directories into a single mach-bcm. I would tend to prefer (but only
>>>>> lightly) using mach-bcm281xx now and then renaming later, unless you
>>>>> plan on expanding the SoC support in the pretty near future.
>>>> I think the main question is how many files we expect to see in the
>>>> platform directories for each of bcm3528, bcm281xx and bcm476x. Right
>>>> now, my feeling is that each of them can be a single file, since most
>>>> of the stuff that has traditionally been in mach-* directories is
>>>> moving out to drivers now.
>>> I expect only DT-only stuff will be mainlined so one directory
>>> (plat-brcm?) should be ok, right?
>> Right. The usual naming is to use 'mach-*' for one platform, and 'plat-*'
>> for stuff that spreads multiple 'mach-*' directories. In this case, the
>> name I would expect is either 'mach-bcm' as Christian suggested, or
>> 'mach-brcm' if people have strong opinions in favor of that, but not
>> 'plat-brcm'.
>>
>>>> You still have to work out how you want to maintain that directory though,
>>>> either just having per-file maintainers, or having multiple people
>>>> take responsible for the entire directory.
>>> I'd like to take care of the bcm476x and related drivers unless Broadcom
>>> wants to do it.
>> Yes, of course.
>>
>>> Let me know in which directory.
>> I'll let you work that out with Stephen and Christian. I think just
>> 'mach-bcm' is sufficent, but I think the three of you should come to
>> an agreement first.
> I don't really have too strong of a preference. If the eventual intent
> is for the directory to host all ARM Broadcom SoCs, then mach-bcm seems
> reasonable.
>
Ok, sounds like sticking to mach-bcm has sufficient acks. What I was 
thinking of doing is, once mach-bcm had been introduced, to propose to 
pull in the 476x and 2835 into also, to do some consolidation. And have 
the separate files can keep separate owners - we'd just have Kconfig + 
Makefile shared most likely.
  Or not. Ultimately I don't mind keeping 2835 and 476x as separate 
mach- either. Those are v6 SoCs, and at this point I have no plans on 
working on mobile v6 SoCs, only v7 onwards. So we can also say that 
mach-bcm is for v7+ SoCs and v6 SoCs keep their existing mach- dirs for now.
  I personally have no strong preference either, just went with mach-bcm 
because, as Arnd mentioned, going forward these are going to be mostly 
empty dirs if we stick to one dir per chipset family. So unless there 
are strong objections, I'll just stick to mach-bcm for my patches, and 
if Stephen and/or Domenico want to consolidate into a single dir later, 
we can do that. If not, we can stick to these 3 dirs.

  Thanks,
    csd

[PATCH v2] Add support for generic BCM SoC chipsets

[Christian Daudt]

On 12-11-12 07:17 AM, Russell King - ARM Linux wrote:
> On Sun, Nov 11, 2012 at 06:57:14AM -0800, Christian Daudt wrote:
>> +#include <linux/of_irq.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/init.h>
>> +#include <linux/device.h>
>> +#include <linux/platform_device.h>
>> +#include <asm/io.h>
> Please use linux/io.h rather than asm/io.h throughout your patch sets.
> However, I don't see anything in this file which requires this header,
> so it's better off being removed entirely.
>
that will be required later, but you're right. It is not being used at 
this point so I've removed it.
  thanks,
    csd

[PATCH v2] Add support for generic BCM SoC chipsets

[Christian Daudt]

On 12-11-12 08:45 PM, Stephen Warren wrote:
> On 11/11/2012 07:57 AM, Christian Daudt wrote:
>> In order to start upstreaming Broadcom SoC support, create
>> a starting hierarchy, arch and dts files.
>> The first support SoC family that is planned is the
>> BCM281XX (BCM28145/28150/28155/28160) family of dual A9 mobile SoC cores
>> This code is just the skeleton code for get the machine upstreamed. It
>> has been made MULTIPLATFORM compatible.
>> Next steps
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> +dtb-$(CONFIG_ARCH_BCM) += capri-brt.dtb
> I think that needs to be renamed too.
done
>
>> diff --git a/arch/arm/boot/dts/bcm281xx.dtsi b/arch/arm/boot/dts/bcm281xx.dtsi
>> +/ {
>> +	model = "BCM281xx SoC";
>> +	compatible = "bcm,bcm281xx";
> I think this should list the specific SoC rather than (or perhaps in
> addition to) a wildcard.
The idea here is that bcm281xx contains the family-wide definitions, and 
once there are multiple boards that use the same specific chip then I'd 
create a chip-specific dtsi file. So eventually it'd be:
bcm281xx.dtsi - for the family

bcm28145.dtsi
bcm28155.dtsi
... for chip-specific

and
bcm28160-brt.dts
... for board specific.

But to simplify I'm just starting with bcm281xx and bcm28160-brt


> Out of curiosity though, what kind of differences exist between the
> various SoCs this wildcard is intended to cover;
> bcm28145/28150/28155/28160? Are they simply package/pinout differences,
> or something more involved?
It mostly revolves around single or dual memory controller, and POP or 
external DDR. I've only used internal names prior to upstreaming, and it 
turns out that my understanding of the numbering is not quite right, so 
I'll be adjusting the patchset a bit before sending the next version out.

>> +	uart at 3e000000 {
>> +		compatible = "snps,dw-apb-uart";
> As I mentioned in my earlier reply, I think this should indicate the
> specific instantiation of the IP too; something like
> bcm,bcm28160-dw-apb-uart.
ok. added.
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> +	help
>> +	  This enables support for system based on Broadcom SoCs.
>> +          It currently supports BCM28145/28150/28155/28160 chips.
> The indentation looks a little odd there.
fixed.

>> diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c
>> +static const char * const capri_dt_compat[] = { "bcm,capri", NULL, };
> I think that needs to be updated too.
fixed.
>

[PATCH v2] Add support for generic BCM SoC chipsets

[Domenico Andreoli]

On Tue, Nov 13, 2012 at 09:53:36AM -0800, Christian Daudt wrote:
> On 12-11-12 09:15 AM, Stephen Warren wrote:
...
> >I don't really have too strong of a preference. If the eventual intent
> >is for the directory to host all ARM Broadcom SoCs, then mach-bcm seems
> >reasonable.
> >
> Ok, sounds like sticking to mach-bcm has sufficient acks. What I was
> thinking of doing is, once mach-bcm had been introduced, to propose
> to pull in the 476x and 2835 into also, to do some consolidation.
> And have the separate files can keep separate owners - we'd just
> have Kconfig + Makefile shared most likely.

ok also for me

>  Or not. Ultimately I don't mind keeping 2835 and 476x as separate
> mach- either. Those are v6 SoCs, and at this point I have no plans
> on working on mobile v6 SoCs, only v7 onwards. So we can also say
> that mach-bcm is for v7+ SoCs and v6 SoCs keep their existing mach-
> dirs for now.

bcm476x is a non-existent directory yet so I'll be happy to switch to
mach-bcm at the next round (*).

thanks,
Domenico

(*) I'm a bit late with it because I've been distracted by a crazy way
to track kernel regressions I'm hacking on.  it's an experiment to test
a few ideas: http://filibusta.crema.unimi.it/~cavok/kbts/. early comments
are very welcome.