| Message ID | 1352391196-9984-1-git-send-email-csd@broadcom.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11/08/2012 09:13 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) 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. Christian, Is the intent for this to support other BCM SoCs in the future, such as the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico Andreoli recently sent patches for? It'd be awesome if Broadcom could provide MMC and USB drivers for the bcm2835 for example. > arch/arm/boot/dts/capri-brt.dts | 32 +++++++++++ > arch/arm/boot/dts/capri.dtsi | 50 +++++++++++++++++ What does the name "capri" refer to? I assume it's a code-name for the SoC/series. My inclination is that naming those files bcm28145.dtsi and bcm28145-brt.dts (or 28150/28155 as appropriate) might be a little more obvious to people unfamiliar with the code-names. > diff --git a/arch/arm/boot/dts/capri-brt.dts b/arch/arm/boot/dts/capri-brt.dts > +/ { > + model = "Capri BRT board"; > + compatible = "bcm,capri"; The individual board file's compatible property should contain both a board-specific value and the generic SoC value. This allows the SoC support in the kernel to match on the generic SoC compatible value, yet still allow the kernel to match the board-specific value in case any quirks are required. For example, compatible = "bcm,brt", "bcm,capri"; (assuming that "brt" is the full board name) > + interrupt-parent = <&gic>; That's already in capri.dtsi; there's no advantage to repeating it. > + memory { > + device_type = "memory"; That property already exists in skeleton.dtsi, which is included via capri.dtsi. > diff --git a/arch/arm/boot/dts/capri.dtsi b/arch/arm/boot/dts/capri.dtsi > + gic: interrupt-controller@3ff00100 { > + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; The commit description says it's an A9 not an A15. > + uart@3e000000 { > + compatible = "snps,dw-apb-uart"; You probably want to include SoC-specific compatible values for all the IP blocks too. There need to be device tree bindings written to describe to contents of all these device-tree files; see Documentation/devicetree/bindings/. > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig > +config ARCH_BCM > + bool "Broadcom SoC" if ARCH_MULTI_V7 > + depends on MMU > + select CPU_V7 > + select ARM_GIC > + select GENERIC_GPIO > + select GPIO_BCM > + select ARCH_REQUIRE_GPIOLIB > + select GENERIC_TIME > + select GENERIC_CLOCKEVENTS > + select TICK_ONESHOT > + select ARM_ERRATA_754322 > + select ARM_ERRATA_764369 if SMP > + select SPARSE_IRQ Those select statements should be alphabetically sorted. > diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c > + > + > + > + > + Nit: A couple of instances of multiple newlines, but not a big deal.
Hi Christian, On Thu, Nov 08, 2012 at 08:24:33PM -0700, Stephen Warren wrote: > On 11/08/2012 09:13 AM, Christian Daudt wrote: > > In order to start upstreaming Broadcom SoC support, create > > a starting hierarchy, arch and dts files. > > Glad to know that Broadcom is interested in mainline :) > > The first support SoC family that is planned is the > > BCM281XX (BCM28145/28150/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. > > Is the intent for this to support other BCM SoCs in the future, such as > the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico > Andreoli recently sent patches for? It'd be awesome if Broadcom could > provide MMC and USB drivers for the bcm2835 for example. I'd love to see published some more documentation as well. Regards, Domenico
On 12-11-08 07:24 PM, Stephen Warren wrote: > On 11/08/2012 09:13 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) 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. > Christian, > > Is the intent for this to support other BCM SoCs in the future, such as > the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico > Andreoli recently sent patches for? It'd be awesome if Broadcom could > provide MMC and USB drivers for the bcm2835 for example. Yes and no :) The intent is to support other BCM SoCs in the future, but Broadcom has a fair number of ARM based SoCs. My primary focus is on the ones from my group within Broadcom (mobile SoCs), but the plan is to bring in others as feasible, and collaborate with other upstreaming work being done for BCM SoCs. As for bcm2835 MMC and USB, we will be upstreaming MMC and USB bcm281xx as part of this effort and while I haven't checked the bcm2835 guts (it comes from a different team within Broadcom) I suspect it might share the same IP blocks, which would make it fairly easy to extend our work to add 2835 support. Stay tuned ! >> arch/arm/boot/dts/capri-brt.dts | 32 +++++++++++ >> arch/arm/boot/dts/capri.dtsi | 50 +++++++++++++++++ > What does the name "capri" refer to? I assume it's a code-name for the > SoC/series. My inclination is that naming those files bcm28145.dtsi and > bcm28145-brt.dts (or 28150/28155 as appropriate) might be a little more > obvious to people unfamiliar with the code-names. Yes, capri is a code name. I've gone back and forth on this one. I think I'll change it to bcm281xx.dtsi and bcm28160-brt.dts, which then refers to the family for the dtsi and the specific chip for the dts. >> diff --git a/arch/arm/boot/dts/capri-brt.dts b/arch/arm/boot/dts/capri-brt.dts >> +/ { >> + model = "Capri BRT board"; >> + compatible = "bcm,capri"; > The individual board file's compatible property should contain both a > board-specific value and the generic SoC value. This allows the SoC > support in the kernel to match on the generic SoC compatible value, yet > still allow the kernel to match the board-specific value in case any > quirks are required. For example, > > compatible = "bcm,brt", "bcm,capri"; > > (assuming that "brt" is the full board name) I will change this based on the above convention i.e.: compatible = "bcm, bcm28160-brt", "bcm, bcm281xx"; >> + interrupt-parent =<&gic>; > That's already in capri.dtsi; there's no advantage to repeating it. ok, removed. >> + memory { >> + device_type = "memory"; > That property already exists in skeleton.dtsi, which is included via > capri.dtsi. ok, removed. >> diff --git a/arch/arm/boot/dts/capri.dtsi b/arch/arm/boot/dts/capri.dtsi >> + gic: interrupt-controller@3ff00100 { >> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > The commit description says it's an A9 not an A15. changed. >> + uart@3e000000 { >> + compatible = "snps,dw-apb-uart"; > You probably want to include SoC-specific compatible values for all the > IP blocks too. I don't follow this part. Do you mean to replace that line with something like 'compatible = "snps,sw-apb-uart", "bcm, bcm28x11-uart"' ? If so, I don't think that that is necessary - right now there is nothing BCM specific about this. > There need to be device tree bindings written to describe to contents of > all these device-tree files; see Documentation/devicetree/bindings/. Added a bcm281xx description. >> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig >> +config ARCH_BCM >> + bool "Broadcom SoC" if ARCH_MULTI_V7 >> + depends on MMU >> + select CPU_V7 >> + select ARM_GIC >> + select GENERIC_GPIO >> + select GPIO_BCM >> + select ARCH_REQUIRE_GPIOLIB >> + select GENERIC_TIME >> + select GENERIC_CLOCKEVENTS >> + select TICK_ONESHOT >> + select ARM_ERRATA_754322 >> + select ARM_ERRATA_764369 if SMP >> + select SPARSE_IRQ > Those select statements should be alphabetically sorted. done >> diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c >> + >> + >> + >> + >> + > Nit: A couple of instances of multiple newlines, but not a big deal. > done. thanks, csd
On 11/11/2012 06:34 AM, Christian Daudt wrote: > On 12-11-08 07:24 PM, Stephen Warren wrote: >> On 11/08/2012 09:13 AM, Christian Daudt wrote: >>> + uart@3e000000 { >>> + compatible = "snps,dw-apb-uart"; >> >> You probably want to include SoC-specific compatible values for all the >> IP blocks too. > > I don't follow this part. Do you mean to replace that line with > something like 'compatible = "snps,sw-apb-uart", "bcm, bcm28x11-uart"' ? > If so, I don't think that that is necessary - right now there is nothing > BCM specific about this. I would expect: compatible = "bcm,bcm28x11-uart", "snps,sw-apb-uart"; The device-tree convention is for the compatible value to always include a specific representation of the exact instance of the HW first (i.e. "bcm,bcm28x11-uart"), and then also describe any base value that the HW is compatible with, or describes the IP block that was instantiated (i.e. "snps,sw-apb-uart"). While the first more-specific value may not be strictly required to make the code work from the start, it is required so that if in the future it is discovered that the HW needs some unexpected quirk or workaround in the driver, the compatible property (for any old device tree that was loaded onto the HW previously) already includes the required value to indicate the specific HW, and hence allow the workaround to be applied.
On 11/11/2012 06:34 AM, Christian Daudt wrote: > On 12-11-08 07:24 PM, Stephen Warren wrote: ... >> Is the intent for this to support other BCM SoCs in the future, such as >> the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico >> Andreoli recently sent patches for? It'd be awesome if Broadcom could >> provide MMC and USB drivers for the bcm2835 for example. > > Yes and no :) The intent is to support other BCM SoCs in the future, but > Broadcom has a fair number of ARM based SoCs. My primary focus is on the > ones from my group within Broadcom (mobile SoCs), but the plan is to > bring in others as feasible, and collaborate with other upstreaming work > being done for BCM SoCs. > > As for bcm2835 MMC and USB, we will be upstreaming MMC and USB bcm281xx > as part of this effort and while I haven't checked the bcm2835 guts (it > comes from a different team within Broadcom) I suspect it might share > the same IP blocks, which would make it fairly easy to extend our work > to add 2835 support. Stay tuned ! So, the bcm2835/Raspberry Pi port is at the stage where MMC and/or USB drivers would be the next useful thing to upstream. However, in order to use those blocks, we should really get communication with the VideoCore working in order to ensure that power and clocks to those modules are configured and enabled. This begs a few questions * Do all/most Broadcom SoCs have a VideoCore. * If so, does the VC typically have complete control over the clock and power/reset trees? Or, are you planning to control these aspects from Linux on the SoCs you're working on upstreaming? If so, is there publicly accessible documentation for your SoC, and is it possible to release similar docs for the 2835? * If the VC controls this, how standardized is the communication mechanism with the VC; do all SoCs have the same mailbox HW, use the same format for the messages passed through the mailbox, and for mailbox channels where the message is a pointer to the message buffer, do they use the same format for that message buffer? I note that the earlier Raspberry Pi firmwares didn't include support for the so-called "property mailbox" channel[1]; it was added in later firmwares. So I assume this is something custom for the Raspberry Pi. That'd be a pity since this message format fixed some nasty issues with the other non-property mailbox messages, at least for power control... Overall, I'm wondering whether the Raspberry Pi upstreaming efforts should just hold off completely until you've got more of the BCM11351/... stuff upstream and simply add that to the Raspberry Pi DT, or whether this aspect won't be re-usable at all. If there isn't any commonality now in the VC firmware responsibilities and/or message formats, would it be possible to create some kind of standard interface to the firmware, and builds of the firmware that implement that, for upstreaming purposes? [1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface Thanks for any information!
On 12-12-04 07:35 PM, Stephen Warren wrote: > On 11/11/2012 06:34 AM, Christian Daudt wrote: >> On 12-11-08 07:24 PM, Stephen Warren wrote: > ... >>> Is the intent for this to support other BCM SoCs in the future, such as >>> the bcm2835 in the Raspberry Pi, and the mach-bcm476x which Domenico >>> Andreoli recently sent patches for? It'd be awesome if Broadcom could >>> provide MMC and USB drivers for the bcm2835 for example. >> Yes and no :) The intent is to support other BCM SoCs in the future, but >> Broadcom has a fair number of ARM based SoCs. My primary focus is on the >> ones from my group within Broadcom (mobile SoCs), but the plan is to >> bring in others as feasible, and collaborate with other upstreaming work >> being done for BCM SoCs. >> >> As for bcm2835 MMC and USB, we will be upstreaming MMC and USB bcm281xx >> as part of this effort and while I haven't checked the bcm2835 guts (it >> comes from a different team within Broadcom) I suspect it might share >> the same IP blocks, which would make it fairly easy to extend our work >> to add 2835 support. Stay tuned ! > So, the bcm2835/Raspberry Pi port is at the stage where MMC and/or USB > drivers would be the next useful thing to upstream. However, in order to > use those blocks, we should really get communication with the VideoCore > working in order to ensure that power and clocks to those modules are > configured and enabled. Cool. I've started a rewrite of our sdhci driver for upstreaming. > > This begs a few questions > > * Do all/most Broadcom SoCs have a VideoCore. The mobile ones yes, there are a few different versions of videocore. But I'm pretty sure that the version in bcm2835 is identical or almost identical to the version in the mobile SoCs I'm upstreaming. > > * If so, does the VC typically have complete control over the clock and > power/reset trees? Or, are you planning to control these aspects from > Linux on the SoCs you're working on upstreaming? If so, is there > publicly accessible documentation for your SoC, and is it possible to > release similar docs for the 2835? As far as I know, the bcm2835 design in which the videocore has control over the SoC is unique to that model. No other Broadcom SoCs follow that design - or at least none of the mobile SoCs that I work on. As for documentation, there is no publicly available doc on the soc I'm working on. I don't know the state of the 2835 documentation - that comes from a different group within Broadcom. > * If the VC controls this, how standardized is the communication > mechanism with the VC; do all SoCs have the same mailbox HW, use the > same format for the messages passed through the mailbox, and for mailbox > channels where the message is a pointer to the message buffer, do they > use the same format for that message buffer? > > I note that the earlier Raspberry Pi firmwares didn't include support > for the so-called "property mailbox" channel[1]; it was added in later > firmwares. So I assume this is something custom for the Raspberry Pi. > That'd be a pity since this message format fixed some nasty issues with > the other non-property mailbox messages, at least for power control... As I mentioned above, the 2835 architecture does not follow the design used on the mobile SoCs. It is unique as far as I know. The mobile SoCs I'm upstreaming boot from the ARM core and the videcore does, well, video stuff :) My (very vague) understanding of the 2835 is that it boots from videocore, and the videocore retains a number of responsibilities. > Overall, I'm wondering whether the Raspberry Pi upstreaming efforts > should just hold off completely until you've got more of the > BCM11351/... stuff upstream and simply add that to the Raspberry Pi DT, > or whether this aspect won't be re-usable at all. It is hard to say at this point what the commonality is - I honestly am not that familiar with the 2835. I do suspect that a number of drivers will be similar in that they start from common IP blocks, but they are connected differently in the different SoCs and thus the drivers won't be identical. But it's just a suspicion at this point. I have purchased a few Raspberry PIs for my team so that we can familiarize ourselves a bit more with it though :) I think that once we have a basic working set upstreamed (basic clocks, emmc/sd, gpio, and a couple of others), we can then take a look at the 2835 as to how applicable what we've upstreamed is for it. I can't give you a timeframe for this though so I don't know if you want to wait for it or not. > If there isn't any commonality now in the VC firmware responsibilities > and/or message formats, would it be possible to create some kind of > standard interface to the firmware, and builds of the firmware that > implement that, for upstreaming purposes? I'll try to understand better the 2835 in the next few weeks so I can provide more meaningful responses. Maybe it'll be my Christmas reading material... Cheers, csd > [1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface > > Thanks for any information! >
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/capri-brt.dts b/arch/arm/boot/dts/capri-brt.dts new file mode 100644 index 0000000..5db7335 --- /dev/null +++ b/arch/arm/boot/dts/capri-brt.dts @@ -0,0 +1,32 @@ +/* + * 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/ "capri.dtsi" + +/ { + model = "Capri BRT board"; + compatible = "bcm,capri"; + interrupt-parent = <&gic>; + + memory { + device_type = "memory"; + reg = <0x80000000 0x40000000>; /* 1 GB */ + }; + + uart@3e000000 { + status = "okay"; + }; + +}; diff --git a/arch/arm/boot/dts/capri.dtsi b/arch/arm/boot/dts/capri.dtsi new file mode 100644 index 0000000..895a928 --- /dev/null +++ b/arch/arm/boot/dts/capri.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 = "Capri SoC"; + compatible = "bcm,capri"; + interrupt-parent = <&gic>; + + chosen { + bootargs = "console=ttyS0,115200n8"; + }; + + gic: interrupt-controller@3ff00100 { + compatible = "arm,cortex-a15-gic", "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..d53b48c --- /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 CPU_V7 + select ARM_GIC + select GENERIC_GPIO + select GPIO_BCM + select ARCH_REQUIRE_GPIOLIB + select GENERIC_TIME + select GENERIC_CLOCKEVENTS + select TICK_ONESHOT + select ARM_ERRATA_754322 + select ARM_ERRATA_764369 if SMP + select SPARSE_IRQ + help + This enables support for system based on Broadcom SoCs. + It currently supports BCM28145/28150/28155 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..a8165a5 --- /dev/null +++ b/arch/arm/mach-bcm/board_bcm.c @@ -0,0 +1,66 @@ +/* + * 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/hardware/cache-l2x0.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) +{ + l2x0_of_init(0x78450000, 0xC200ffff); + + /* TODO: Add call to secure monitor to actually enable L2 */ + + 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