| Message ID | 1352645834-10173-1-git-send-email-csd@broadcom.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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 >
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.
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.
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
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.
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
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
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.
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@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.
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
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
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@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. >
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.
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@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@3ff00100 { + compatible = "arm,cortex-a9-gic"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x3ff01000 0x1000>, + <0x3ff00100 0x100>; + }; + + uart@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
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