Add support for generic BCM SoC chipsets

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.

Hi Christian,

Quoted 4 lines · 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

Quoted 8 lines

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

Quoted 16 lines · Florian Fainelli

Hi Christian,

Quoted 4 lines · 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

Quoted 8 lines

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.

Quoted 8 lines

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.

On Sun, Nov 11, 2012 at 7:53 AM, Florian Fainelli <[email protected] <mailto:[email protected]>> 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.

Quoted 4 lines

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.

Quoted 10 lines · Stephen Warren

Quoted 4 lines

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.

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.

Quoted 12 lines · Arnd Bergmann

Quoted 10 lines · Stephen Warren

Quoted 4 lines

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.

Quoted 5 lines

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?

Quoted 3 lines

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.

Quoted 13 lines · Domenico Andreoli

Quoted 12 lines · Arnd Bergmann

Quoted 10 lines · Stephen Warren

Quoted 4 lines

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.

Quoted 8 lines

Quoted 5 lines

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'.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 32 lines · Arnd Bergmann

Quoted 11 lines · Domenico Andreoli

Quoted 10 lines · Arnd Bergmann

Quoted 9 lines · Stephen Warren

Quoted 4 lines

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.

Quoted 7 lines

Quoted 5 lines

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'.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 4 lines

Quoted 1 line

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.

On 12-11-12 09:15 AM, Stephen Warren wrote:

Quoted 4 lines

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.

arch/arm/mach-bcm/board_bcm.c line 19

Quoted 6 lines · Christian Daudt

arch/arm/mach-bcm/board_bcm.c new file +6 -0

+#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.

arch/arm/boot/dts/Makefile dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb \ · line 20

Quoted 9 lines · 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

arch/arm/boot/dts/Makefile +1 -0

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

I think that needs to be renamed too.

arch/arm/boot/dts/bcm281xx.dtsi line 18

Quoted 5 lines

arch/arm/boot/dts/bcm281xx.dtsi +3 -0

+/ {
+	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?

arch/arm/boot/dts/bcm281xx.dtsi line 35

Quoted 2 lines

arch/arm/boot/dts/bcm281xx.dtsi +2 -0

+	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.

arch/arm/mach-bcm/Kconfig line 17

Quoted 4 lines

arch/arm/mach-bcm/Kconfig +3 -0

+	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.

arch/arm/mach-bcm/board_bcm.c line 50

Quoted 2 lines

arch/arm/mach-bcm/board_bcm.c +1 -0

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

I think that needs to be updated too.