| Message ID | 1352843517-31328-1-git-send-email-csd@broadcom.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11/13/2012 02:51 PM, 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 (BCM11130/11140/11351/28145/28155) 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. Sorry for the slow review... > diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt b/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt > +Required root node property: > + > +compatible = "bcm,bcm281xx"; Hmm. I still tend to think we should list the specific SoC rather than the family here, but I guess if you're sure there won't be any SW compatibility between the different SoCs in the series, this is fine. > diff --git a/arch/arm/boot/dts/bcm281xx.dtsi b/arch/arm/boot/dts/bcm281xx.dtsi > + uart@3e000000 { > + compatible = "snps,dw-apb-uart", "bcm,bcm281xx-sw-apb-uart"; The most specific value should be first, so swap those two entries. > 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 the 'BCM281XX' family, which includes > + BCM11130, BCM1140, BCM11351, BCM28145 and Should that be 11140 rather than 1140? Aside from that, Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
On Fri, Nov 16, 2012 at 8:10 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 11/13/2012 02:51 PM, 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 (BCM11130/11140/11351/28145/28155) 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. > > Sorry for the slow review... > no worries. >> diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt b/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt > >> +Required root node property: >> + >> +compatible = "bcm,bcm281xx"; > > Hmm. I still tend to think we should list the specific SoC rather than > the family here, but I guess if you're sure there won't be any SW > compatibility between the different SoCs in the series, this is fine. > right now I expect to be able to use the family thoughout, so I'll stick to it. >> diff --git a/arch/arm/boot/dts/bcm281xx.dtsi b/arch/arm/boot/dts/bcm281xx.dtsi > >> + uart@3e000000 { >> + compatible = "snps,dw-apb-uart", "bcm,bcm281xx-sw-apb-uart"; > > The most specific value should be first, so swap those two entries. > ok. done >> 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 the 'BCM281XX' family, which includes >> + BCM11130, BCM1140, BCM11351, BCM28145 and > > Should that be 11140 rather than 1140? yes. that's a typo. corrected. > > Aside from that, > Reviewed-by: Stephen Warren <swarren@wwwdotorg.org> thanks for reviewing it ! csd
On Saturday 17 November 2012, Christian Daudt wrote: > >> diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt b/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt > > > >> +Required root node property: > >> + > >> +compatible = "bcm,bcm281xx"; > > > > Hmm. I still tend to think we should list the specific SoC rather than > > the family here, but I guess if you're sure there won't be any SW > > compatibility between the different SoCs in the series, this is fine. > > > > right now I expect to be able to use the family thoughout, so I'll stick to it. > But that's not how the compatible property is supposed to work: Each compatible value should refer to a specific property, and not include wildcards. If you have one driver (or platform file in this case) that can deal with a whole family of devices, the normal solution is to list the name of the oldest part in the compatible string as the most generic part, and then list the name of the new part as the specific one. Arnd
On Sat, Nov 17, 2012 at 9:21 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Saturday 17 November 2012, Christian Daudt wrote: > > >> diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt > b/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt > > > > > >> +Required root node property: > > >> + > > >> +compatible = "bcm,bcm281xx"; > > > > > > Hmm. I still tend to think we should list the specific SoC rather than > > > the family here, but I guess if you're sure there won't be any SW > > > compatibility between the different SoCs in the series, this is fine. > > > > > > > right now I expect to be able to use the family thoughout, so I'll stick > to it. > > > > But that's not how the compatible property is supposed to work: Each > compatible > value should refer to a specific property, and not include wildcards. > If you have one driver (or platform file in this case) that can deal with > a whole family of devices, the normal solution is to list the name of the > oldest > part in the compatible string as the most generic part, and then list the > name of the new part as the specific one. > > At that point doesn't the 'oldest part' become the wildcard ? I'm not very attached to names, so I'm ok changing bcm281xx above to bcm11351, which happens to be the first chip I'm submitting a board for. But then bcm11351 will just become 'the chip name used to represent the family' right ? I had followed the fact that omap does use omap5 in omap5.dtsi - and afaik tegra2 and tegra3 are family names, not chip models, and are used in dtsi. But then again a bunch of chip models are used to represent the families too... Let me know if you want me to submit a modified patchset. Shouldn't take me more than 5 minutes anyways :) Thanks, csd
On Saturday 17 November 2012, Christian Daudt wrote: > > At that point doesn't the 'oldest part' become the wildcard ? I'm not > very attached to names, so I'm ok changing bcm281xx above to bcm11351, > which happens to be the first chip I'm submitting a board for. But then > bcm11351 will just become 'the chip name used to represent the family' > right ? I had followed the fact that omap does use omap5 in omap5.dtsi - > and afaik tegra2 and tegra3 are family names, not chip models, and are used > in dtsi. But then again a bunch of chip models are used to represent the > families too... > Let me know if you want me to submit a modified patchset. Shouldn't take > me more than 5 minutes anyways :) I think in a lot of cases, we just list all the possible parts specifically since we already know them, especially when supporting a new one requires changing code already. Using bcm11351 as the name for the family sounds reasonable to me when the other ones are derived from that, and the other option is to just list all the ones that are out there already in the source code match table. For future SoCs, you can then decide whether you want to change the code to add the new number or just list one of the existing parts as backwards compatible for the new device tree file if that allows you to support it without other code changes. Please pick one of the two options and resubmit. Arnd
On Sat, Nov 17, 2012 at 10:04 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Saturday 17 November 2012, Christian Daudt wrote: > > > At that point doesn't the 'oldest part' become the wildcard ? I'm not > > very attached to names, so I'm ok changing bcm281xx above to bcm11351, > > which happens to be the first chip I'm submitting a board for. But then > > bcm11351 will just become 'the chip name used to represent the family' > > right ? I had followed the fact that omap does use omap5 in omap5.dtsi - > > and afaik tegra2 and tegra3 are family names, not chip models, and are > used > > in dtsi. But then again a bunch of chip models are used to represent the > > families too... > > Let me know if you want me to submit a modified patchset. Shouldn't take > > me more than 5 minutes anyways :) > > I think in a lot of cases, we just list all the possible parts specifically > since we already know them, especially when supporting a new one requires > changing code already. > > Using bcm11351 as the name for the family sounds reasonable to me when > the other ones are derived from that, and the other option is to just > list all the ones that are out there already in the source code match > table. For future SoCs, you can then decide whether you want to change > the code to add the new number or just list one of the existing parts > as backwards compatible for the new device tree file if that allows > you to support it without other code changes. > > Please pick one of the two options and resubmit. > ok. resubmitting shortly with bcm11351. thanks, csd
On Sat, Nov 17, 2012 at 3:39 PM, Christian Daudt <cdaudt@gmail.com> wrote: > > > On Sat, Nov 17, 2012 at 10:04 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Saturday 17 November 2012, Christian Daudt wrote: >> > > At that point doesn't the 'oldest part' become the wildcard ? I'm not >> > very attached to names, so I'm ok changing bcm281xx above to bcm11351, >> > which happens to be the first chip I'm submitting a board for. But then >> > bcm11351 will just become 'the chip name used to represent the family' >> > right ? I had followed the fact that omap does use omap5 in omap5.dtsi - >> > and afaik tegra2 and tegra3 are family names, not chip models, and are >> > used >> > in dtsi. But then again a bunch of chip models are used to represent the >> > families too... >> > Let me know if you want me to submit a modified patchset. Shouldn't >> > take >> > me more than 5 minutes anyways :) >> >> I think in a lot of cases, we just list all the possible parts >> specifically >> since we already know them, especially when supporting a new one requires >> changing code already. >> >> Using bcm11351 as the name for the family sounds reasonable to me when >> the other ones are derived from that, and the other option is to just >> list all the ones that are out there already in the source code match >> table. For future SoCs, you can then decide whether you want to change >> the code to add the new number or just list one of the existing parts >> as backwards compatible for the new device tree file if that allows >> you to support it without other code changes. >> >> Please pick one of the two options and resubmit. > > ok. resubmitting shortly with bcm11351. > On an administrative question: Stephen sent me a reviewed-by that effectively applied to V4 of the patch. I dropped it for V5 as this is not the exact patchset that he reviewed. Is the expected procedure that new versions of patches carry previous reviewed-by or not ? I could not find any reference to that in the submittingpatches doc thanks, csd
Christian Daudt <cdaudt@gmail.com> wrote: >and afaik tegra2 and tegra3 are family names, not chip models, and are used >in dtsi. But then again a bunch of chip models are used to represent the families too... >Let me know if you want me to submit a modified patchset. Shouldn't take >me more than 5 minutes anyways :) From a software perspective at least, all Tegra2x are the exact same chip, same for Tegra3. Sorry if this email is borked; trying out list email on my tablet for the first time.
On Sunday 18 November 2012, Christian Daudt wrote: > On an administrative question: Stephen sent me a reviewed-by that > effectively applied to V4 of the patch. I dropped it for V5 as this is > not the exact patchset that he reviewed. Is the expected procedure > that new versions of patches carry previous reviewed-by or not ? I > could not find any reference to that in the submittingpatches doc Usually you should keep the reviewed-by tag as you only make small changes to other comments. If you do substantial changes, best ask the reviewers to look at the new version as well. Arnd
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..6b3392b 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) += bcm11351-brt.dtb dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \ dove-cubox.dtb \ dove-dove-db.dtb diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts new file mode 100644 index 0000000..d9379d0 --- /dev/null +++ b/arch/arm/boot/dts/bcm11351-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 = "BCM11351 BRT board"; + compatible = "bcm,bcm11351-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..6ec9fe4 --- /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", "bcm,bcm281xx-sw-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..18ae21c --- /dev/null +++ b/arch/arm/mach-bcm/Kconfig @@ -0,0 +1,19 @@ +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 the 'BCM281XX' family, which includes + BCM11130, BCM1140, BCM11351, BCM28145 and + BCM28155 variants. 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..c303582 --- /dev/null +++ b/arch/arm/mach-bcm/board_bcm.c @@ -0,0 +1,57 @@ +/* + * 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/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 bcm281xx_dt_compat[] = { "bcm,bcm281xx", NULL, }; + +DT_MACHINE_START(BCM281XX_DT, "Broadcom Application Processor") + .init_irq = init_irq, + .timer = &timer, + .init_machine = board_init, + .dt_compat = bcm281xx_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 (BCM11130/11140/11351/28145/28155) 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 v3 patch mods ------------- - Remove extra #include lines - Remove remaining references to capri - dt uart chipset string added - cleaned up chip # references 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/bcm11351-brt.dts | 30 +++++ arch/arm/boot/dts/bcm281xx.dtsi | 50 +++++++++ arch/arm/configs/bcm_defconfig | 114 ++++++++++++++++++++ arch/arm/mach-bcm/Kconfig | 19 ++++ arch/arm/mach-bcm/Makefile | 13 +++ arch/arm/mach-bcm/board_bcm.c | 57 ++++++++++ 10 files changed, 295 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt create mode 100644 arch/arm/boot/dts/bcm11351-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