From 5de1540b7bc4c23470f86add1e517be41e7fefe2 Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 21 Jun 2011 10:59:34 -0600 Subject: drivers/amba: create devices from device tree Add a function to create amba_devices (i.e. primecell peripherals) from device tree nodes. The device tree scanning is done by the of_platform_populate() function which can call of_amba_device_create based on a match table entry. Nodes with a "arm,primecell-periphid" property can override the h/w peripheral id value. Based on the original work by Jeremy Kerr. Signed-off-by: Jeremy Kerr Acked-by: Linus Walleij Signed-off-by: Rob Herring Reviewed-by: Arnd Bergmann [grant.likely: add Jeremy's original s-o-b line, changes from review comments, and moved all code to drivers/of/platform.c] Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/arm/primecell.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/primecell.txt (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Documentation/devicetree/bindings/arm/primecell.txt new file mode 100644 index 00000000000..1d5d7a870ec --- /dev/null +++ b/Documentation/devicetree/bindings/arm/primecell.txt @@ -0,0 +1,21 @@ +* ARM Primecell Peripherals + +ARM, Ltd. Primecell peripherals have a standard id register that can be used to +identify the peripheral type, vendor, and revision. This value can be used for +driver matching. + +Required properties: + +- compatible : should be a specific value for peripheral and "arm,primecell" + +Optional properties: + +- arm,primecell-periphid : Value to override the h/w value with + +Example: + +serial@fff36000 { + compatible = "arm,pl011", "arm,primecell"; + arm,primecell-periphid = <0x00341011>; +}; + -- cgit v1.2.3 From 61ab1a90d81b5b8a53fc221a3665715c61614fb7 Mon Sep 17 00:00:00 2001 From: Jamie Iles Date: Mon, 27 Jun 2011 13:32:33 +0100 Subject: dt: document the of_serial bindings The of_serial bindings can be used to register a number of serial devices. Document this binding with all of the others. v3: remove device-type and clarify used-by-rtas Signed-off-by: Jamie Iles Acked-by: Arnd Bergmann Signed-off-by: Grant Likely --- .../devicetree/bindings/tty/serial/of-serial.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/tty/serial/of-serial.txt (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/tty/serial/of-serial.txt new file mode 100644 index 00000000000..35e53ae85ee --- /dev/null +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt @@ -0,0 +1,33 @@ +* UART (Universal Asynchronous Receiver/Transmitter) + +Required properties: +- compatible : one of: + - "ns8250" + - "ns16450" + - "ns16550a" + - "ns16550" + - "ns16750" + - "ns16850" + - "nvidia,tegra250-uart" + - "ibm,qpace-nwp-serial" + - "serial" if the port type is unknown. +- reg : offset and length of the register set for the device. +- interrupts : should contain uart interrupt. +- clock-frequency : the input clock frequency for the UART. + +Optional properties: +- current-speed : the current active speed of the UART. +- reg-offset : offset to apply to the mapbase from the start of the registers. +- reg-shift : quantity to shift the register offsets by. +- used-by-rtas : set to indicate that the port is in use by the OpenFirmware + RTAS and should not be registered. + +Example: + + uart@80230000 { + compatible = "ns8250"; + reg = <0x80230000 0x100>; + clock-frequency = <3686400>; + interrupts = <10>; + reg-shift = <2>; + }; -- cgit v1.2.3 From 7423734e19e7e0a90e3379152eacca2647f4377e Mon Sep 17 00:00:00 2001 From: Jamie Iles Date: Mon, 27 Jun 2011 13:32:34 +0100 Subject: tty: of_serial: support for 32 bit accesses Some platforms e.g. TI Davinci require 32-bit accesses to the UARTs. The of_serial driver currently registers all UARTs as UPIO_MEM. Add a new attribute "reg-io-width" to allow the port to be registered with different IO width requirements. Acked-by: Alan Cox Signed-off-by: Jamie Iles Signed-off-by: Grant Likely --- .../devicetree/bindings/tty/serial/of-serial.txt | 3 +++ drivers/tty/serial/of_serial.c | 17 +++++++++++++++++ 2 files changed, 20 insertions(+) (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/tty/serial/of-serial.txt index 35e53ae85ee..337a7e51fac 100644 --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt @@ -19,6 +19,9 @@ Optional properties: - current-speed : the current active speed of the UART. - reg-offset : offset to apply to the mapbase from the start of the registers. - reg-shift : quantity to shift the register offsets by. +- reg-io-width : the size (in bytes) of the IO accesses that should be + performed on the device. There are some systems that require 32-bit + accesses to the UART (e.g. TI davinci). - used-by-rtas : set to indicate that the port is in use by the OpenFirmware RTAS and should not be registered. diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c index c911b2419ab..36038ed8f09 100644 --- a/drivers/tty/serial/of_serial.c +++ b/drivers/tty/serial/of_serial.c @@ -65,6 +65,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev, port->irq = irq_of_parse_and_map(np, 0); port->iotype = UPIO_MEM; + prop = of_get_property(np, "reg-io-width", &prop_size); + if (prop && (prop_size == sizeof(u32))) { + switch (be32_to_cpup(prop)) { + case 1: + port->iotype = UPIO_MEM; + break; + case 4: + port->iotype = UPIO_MEM32; + break; + default: + dev_warn(&ofdev->dev, + "unsupported io width (%d bytes)\n", + be32_to_cpup(prop)); + return -EINVAL; + } + } + port->type = type; port->uartclk = be32_to_cpup(clk); port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP -- cgit v1.2.3 From 5a9ebe959967b7d3579de2a53d5df470fe0c7f22 Mon Sep 17 00:00:00 2001 From: Kim Phillips Date: Thu, 7 Jul 2011 14:43:12 -0500 Subject: dt: bindings: move SEC node under new crypto/ Since technically it's not powerpc arch-specific. Also rename it sec2 to differentiate it from its incompatible successor, the SEC 4. Signed-off-by: Kim Phillips Signed-off-by: Grant Likely --- .../devicetree/bindings/crypto/fsl-sec2.txt | 68 ++++++++++++++++++++++ .../devicetree/bindings/powerpc/fsl/sec.txt | 68 ---------------------- 2 files changed, 68 insertions(+), 68 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/fsl-sec2.txt delete mode 100644 Documentation/devicetree/bindings/powerpc/fsl/sec.txt (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt new file mode 100644 index 00000000000..38988ef1336 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt @@ -0,0 +1,68 @@ +Freescale SoC SEC Security Engines versions 2.x-3.x + +Required properties: + +- compatible : Should contain entries for this and backward compatible + SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" +- reg : Offset and length of the register set for the device +- interrupts : the SEC's interrupt number +- fsl,num-channels : An integer representing the number of channels + available. +- fsl,channel-fifo-len : An integer representing the number of + descriptor pointers each channel fetch fifo can hold. +- fsl,exec-units-mask : The bitmask representing what execution units + (EUs) are available. It's a single 32-bit cell. EU information + should be encoded following the SEC's Descriptor Header Dword + EU_SEL0 field documentation, i.e. as follows: + + bit 0 = reserved - should be 0 + bit 1 = set if SEC has the ARC4 EU (AFEU) + bit 2 = set if SEC has the DES/3DES EU (DEU) + bit 3 = set if SEC has the message digest EU (MDEU/MDEU-A) + bit 4 = set if SEC has the random number generator EU (RNG) + bit 5 = set if SEC has the public key EU (PKEU) + bit 6 = set if SEC has the AES EU (AESU) + bit 7 = set if SEC has the Kasumi EU (KEU) + bit 8 = set if SEC has the CRC EU (CRCU) + bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B) + +remaining bits are reserved for future SEC EUs. + +- fsl,descriptor-types-mask : The bitmask representing what descriptors + are available. It's a single 32-bit cell. Descriptor type information + should be encoded following the SEC's Descriptor Header Dword DESC_TYPE + field documentation, i.e. as follows: + + bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type + bit 1 = set if SEC supports the ipsec_esp descriptor type + bit 2 = set if SEC supports the common_nonsnoop desc. type + bit 3 = set if SEC supports the 802.11i AES ccmp desc. type + bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type + bit 5 = set if SEC supports the srtp descriptor type + bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type + bit 7 = set if SEC supports the pkeu_assemble descriptor type + bit 8 = set if SEC supports the aesu_key_expand_output desc.type + bit 9 = set if SEC supports the pkeu_ptmul descriptor type + bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type + bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type + + ..and so on and so forth. + +Optional properties: + +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + +Example: + + /* MPC8548E */ + crypto@30000 { + compatible = "fsl,sec2.1", "fsl,sec2.0"; + reg = <0x30000 0x10000>; + interrupts = <29 2>; + interrupt-parent = <&mpic>; + fsl,num-channels = <4>; + fsl,channel-fifo-len = <24>; + fsl,exec-units-mask = <0xfe>; + fsl,descriptor-types-mask = <0x12b0ebf>; + }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/sec.txt b/Documentation/devicetree/bindings/powerpc/fsl/sec.txt deleted file mode 100644 index 2b6f2d45c45..00000000000 --- a/Documentation/devicetree/bindings/powerpc/fsl/sec.txt +++ /dev/null @@ -1,68 +0,0 @@ -Freescale SoC SEC Security Engines - -Required properties: - -- compatible : Should contain entries for this and backward compatible - SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" -- reg : Offset and length of the register set for the device -- interrupts : the SEC's interrupt number -- fsl,num-channels : An integer representing the number of channels - available. -- fsl,channel-fifo-len : An integer representing the number of - descriptor pointers each channel fetch fifo can hold. -- fsl,exec-units-mask : The bitmask representing what execution units - (EUs) are available. It's a single 32-bit cell. EU information - should be encoded following the SEC's Descriptor Header Dword - EU_SEL0 field documentation, i.e. as follows: - - bit 0 = reserved - should be 0 - bit 1 = set if SEC has the ARC4 EU (AFEU) - bit 2 = set if SEC has the DES/3DES EU (DEU) - bit 3 = set if SEC has the message digest EU (MDEU/MDEU-A) - bit 4 = set if SEC has the random number generator EU (RNG) - bit 5 = set if SEC has the public key EU (PKEU) - bit 6 = set if SEC has the AES EU (AESU) - bit 7 = set if SEC has the Kasumi EU (KEU) - bit 8 = set if SEC has the CRC EU (CRCU) - bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B) - -remaining bits are reserved for future SEC EUs. - -- fsl,descriptor-types-mask : The bitmask representing what descriptors - are available. It's a single 32-bit cell. Descriptor type information - should be encoded following the SEC's Descriptor Header Dword DESC_TYPE - field documentation, i.e. as follows: - - bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type - bit 1 = set if SEC supports the ipsec_esp descriptor type - bit 2 = set if SEC supports the common_nonsnoop desc. type - bit 3 = set if SEC supports the 802.11i AES ccmp desc. type - bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type - bit 5 = set if SEC supports the srtp descriptor type - bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type - bit 7 = set if SEC supports the pkeu_assemble descriptor type - bit 8 = set if SEC supports the aesu_key_expand_output desc.type - bit 9 = set if SEC supports the pkeu_ptmul descriptor type - bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type - bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type - - ..and so on and so forth. - -Optional properties: - -- interrupt-parent : the phandle for the interrupt controller that - services interrupts for this device. - -Example: - - /* MPC8548E */ - crypto@30000 { - compatible = "fsl,sec2.1", "fsl,sec2.0"; - reg = <0x30000 0x10000>; - interrupts = <29 2>; - interrupt-parent = <&mpic>; - fsl,num-channels = <4>; - fsl,channel-fifo-len = <24>; - fsl,exec-units-mask = <0xfe>; - fsl,descriptor-types-mask = <0x12b0ebf>; - }; -- cgit v1.2.3 From 2e39e5be1ddf9fc5fbe84fe7ae3e035bb07845e5 Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 5 Jul 2011 23:42:36 -0600 Subject: tty/serial: Add devicetree support for nVidia Tegra serial ports Acked-by: Greg Kroah-Hartman Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/tty/serial/of-serial.txt | 2 +- drivers/tty/serial/of_serial.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/tty/serial/of-serial.txt index 337a7e51fac..b8b27b0aca1 100644 --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt @@ -8,7 +8,7 @@ Required properties: - "ns16550" - "ns16750" - "ns16850" - - "nvidia,tegra250-uart" + - "nvidia,tegra20-uart" - "ibm,qpace-nwp-serial" - "serial" if the port type is unknown. - reg : offset and length of the register set for the device. diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c index dbfbfda2753..e58cece6f44 100644 --- a/drivers/tty/serial/of_serial.c +++ b/drivers/tty/serial/of_serial.c @@ -181,6 +181,7 @@ static struct of_device_id __devinitdata of_platform_serial_table[] = { { .compatible = "ns16550", .data = (void *)PORT_16550, }, { .compatible = "ns16750", .data = (void *)PORT_16750, }, { .compatible = "ns16850", .data = (void *)PORT_16850, }, + { .compatible = "nvidia,tegra20-uart", .data = (void *)PORT_TEGRA, }, #ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL { .compatible = "ibm,qpace-nwp-serial", .data = (void *)PORT_NWPSERIAL, }, -- cgit v1.2.3 From d329974b2f274e5331c5383e33b15229f935035e Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 5 Jul 2011 23:42:30 -0600 Subject: arm/versatile: Add device tree support For testing the dt work, define a dt-enabled versatile platform. This patch adds a new versatile platform for when using the device tree. Add platform and amba devices are discovered and registered by parsing the device tree. Clocks and initial io mappings are still configured statically. This patch still depends on some static platform_data for a few devices which is passed via the auxdata structure to of_platform_populate(), but it is a viable starting point until the drivers can get all configuration data out of the device tree. Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/arm/arm-boards | 20 +++ .../devicetree/bindings/i2c/arm-versatile.txt | 10 ++ .../devicetree/bindings/mtd/arm-versatile.txt | 8 + .../devicetree/bindings/net/smsc-lan91c111.txt | 10 ++ arch/arm/boot/dts/versatile-ab.dts | 192 +++++++++++++++++++++ arch/arm/boot/dts/versatile-pb.dts | 48 ++++++ arch/arm/mach-versatile/Kconfig | 8 + arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/core.c | 61 +++++++ arch/arm/mach-versatile/core.h | 2 + arch/arm/mach-versatile/versatile_dt.c | 51 ++++++ 11 files changed, 411 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm-boards create mode 100644 Documentation/devicetree/bindings/i2c/arm-versatile.txt create mode 100644 Documentation/devicetree/bindings/mtd/arm-versatile.txt create mode 100644 Documentation/devicetree/bindings/net/smsc-lan91c111.txt create mode 100644 arch/arm/boot/dts/versatile-ab.dts create mode 100644 arch/arm/boot/dts/versatile-pb.dts create mode 100644 arch/arm/mach-versatile/versatile_dt.c (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards new file mode 100644 index 00000000000..91f26148af7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm-boards @@ -0,0 +1,20 @@ +ARM Versatile Application and Platform Baseboards +------------------------------------------------- +ARM's development hardware platform with connectors for customizable +core tiles. The hardware configuration of the Versatile boards is +highly customizable. + +Required properties (in root node): + compatible = "arm,versatile-ab"; /* Application baseboard */ + compatible = "arm,versatile-pb"; /* Platform baseboard */ + +Interrupt controllers: +- VIC required properties: + compatible = "arm,versatile-vic"; + interrupt-controller; + #interrupt-cells = <1>; + +- SIC required properties: + compatible = "arm,versatile-sic"; + interrupt-controller; + #interrupt-cells = <1>; diff --git a/Documentation/devicetree/bindings/i2c/arm-versatile.txt b/Documentation/devicetree/bindings/i2c/arm-versatile.txt new file mode 100644 index 00000000000..361d31c51b6 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/arm-versatile.txt @@ -0,0 +1,10 @@ +i2c Controller on ARM Versatile platform: + +Required properties: +- compatible : Must be "arm,versatile-i2c"; +- reg +- #address-cells = <1>; +- #size-cells = <0>; + +Optional properties: +- Child nodes conforming to i2c bus binding diff --git a/Documentation/devicetree/bindings/mtd/arm-versatile.txt b/Documentation/devicetree/bindings/mtd/arm-versatile.txt new file mode 100644 index 00000000000..476845db94d --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/arm-versatile.txt @@ -0,0 +1,8 @@ +Flash device on ARM Versatile board + +Required properties: +- compatible : must be "arm,versatile-flash"; +- bank-width : width in bytes of flash interface. + +Optional properties: +- Subnode partition map from mtd flash binding diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt new file mode 100644 index 00000000000..953049b4248 --- /dev/null +++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt @@ -0,0 +1,10 @@ +SMSC LAN91c111 Ethernet mac + +Required properties: +- compatible = "smsc,lan91c111"; +- reg : physical address and size of registers +- interrupts : interrupt connection + +Optional properties: +- phy-device : phandle to Ethernet phy +- local-mac-address : Ethernet mac address to use diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts new file mode 100644 index 00000000000..0b32925f214 --- /dev/null +++ b/arch/arm/boot/dts/versatile-ab.dts @@ -0,0 +1,192 @@ +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + model = "ARM Versatile AB"; + compatible = "arm,versatile-ab"; + #address-cells = <1>; + #size-cells = <1>; + interrupt-parent = <&vic>; + + aliases { + serial0 = &uart0; + serial1 = &uart1; + serial2 = &uart2; + i2c0 = &i2c0; + }; + + memory { + reg = <0x0 0x08000000>; + }; + + flash@34000000 { + compatible = "arm,versatile-flash"; + reg = <0x34000000 0x4000000>; + bank-width = <4>; + }; + + i2c0: i2c@10002000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "arm,versatile-i2c"; + reg = <0x10002000 0x1000>; + + rtc@68 { + compatible = "dallas,ds1338"; + reg = <0x68>; + }; + }; + + net@10010000 { + compatible = "smsc,lan91c111"; + reg = <0x10010000 0x10000>; + interrupts = <25>; + }; + + lcd@10008000 { + compatible = "arm,versatile-lcd"; + reg = <0x10008000 0x1000>; + }; + + amba { + compatible = "arm,amba-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + vic: intc@10140000 { + compatible = "arm,versatile-vic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x10140000 0x1000>; + }; + + sic: intc@10003000 { + compatible = "arm,versatile-sic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x10003000 0x1000>; + interrupt-parent = <&vic>; + interrupts = <31>; /* Cascaded to vic */ + }; + + dma@10130000 { + compatible = "arm,pl081", "arm,primecell"; + reg = <0x10130000 0x1000>; + interrupts = <17>; + }; + + uart0: uart@101f1000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x101f1000 0x1000>; + interrupts = <12>; + }; + + uart1: uart@101f2000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x101f2000 0x1000>; + interrupts = <13>; + }; + + uart2: uart@101f3000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x101f3000 0x1000>; + interrupts = <14>; + }; + + smc@10100000 { + compatible = "arm,primecell"; + reg = <0x10100000 0x1000>; + }; + + mpmc@10110000 { + compatible = "arm,primecell"; + reg = <0x10110000 0x1000>; + }; + + display@10120000 { + compatible = "arm,pl110", "arm,primecell"; + reg = <0x10120000 0x1000>; + interrupts = <16>; + }; + + sctl@101e0000 { + compatible = "arm,primecell"; + reg = <0x101e0000 0x1000>; + }; + + watchdog@101e1000 { + compatible = "arm,primecell"; + reg = <0x101e1000 0x1000>; + interrupts = <0>; + }; + + gpio0: gpio@101e4000 { + compatible = "arm,pl061", "arm,primecell"; + reg = <0x101e4000 0x1000>; + gpio-controller; + interrupts = <6>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio1: gpio@101e5000 { + compatible = "arm,pl061", "arm,primecell"; + reg = <0x101e5000 0x1000>; + interrupts = <7>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + rtc@101e8000 { + compatible = "arm,pl030", "arm,primecell"; + reg = <0x101e8000 0x1000>; + interrupts = <10>; + }; + + sci@101f0000 { + compatible = "arm,primecell"; + reg = <0x101f0000 0x1000>; + interrupts = <15>; + }; + + ssp@101f4000 { + compatible = "arm,pl022", "arm,primecell"; + reg = <0x101f4000 0x1000>; + interrupts = <11>; + }; + + fpga { + compatible = "arm,versatile-fpga", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x10000000 0x10000>; + + aaci@4000 { + compatible = "arm,primecell"; + reg = <0x4000 0x1000>; + interrupts = <24>; + }; + mmc@5000 { + compatible = "arm,primecell"; + reg = < 0x5000 0x1000>; + interrupts = <22>; + }; + kmi@6000 { + compatible = "arm,pl050", "arm,primecell"; + reg = <0x6000 0x1000>; + interrupt-parent = <&sic>; + interrupts = <3>; + }; + kmi@7000 { + compatible = "arm,pl050", "arm,primecell"; + reg = <0x7000 0x1000>; + interrupt-parent = <&sic>; + interrupts = <4>; + }; + }; + }; +}; diff --git a/arch/arm/boot/dts/versatile-pb.dts b/arch/arm/boot/dts/versatile-pb.dts new file mode 100644 index 00000000000..8a614e39800 --- /dev/null +++ b/arch/arm/boot/dts/versatile-pb.dts @@ -0,0 +1,48 @@ +/include/ "versatile-ab.dts" + +/ { + model = "ARM Versatile PB"; + compatible = "arm,versatile-pb"; + + amba { + gpio2: gpio@101e6000 { + compatible = "arm,pl061", "arm,primecell"; + reg = <0x101e6000 0x1000>; + interrupts = <8>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio3: gpio@101e7000 { + compatible = "arm,pl061", "arm,primecell"; + reg = <0x101e7000 0x1000>; + interrupts = <9>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + fpga { + uart@9000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x9000 0x1000>; + interrupt-parent = <&sic>; + interrupts = <6>; + }; + sci@a000 { + compatible = "arm,primecell"; + reg = <0xa000 0x1000>; + interrupt-parent = <&sic>; + interrupts = <5>; + }; + mmc@b000 { + compatible = "arm,primecell"; + reg = <0xb000 0x1000>; + interrupts = <23>; + }; + }; + }; +}; diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig index 9cdec5aa04a..c1f38f6625b 100644 --- a/arch/arm/mach-versatile/Kconfig +++ b/arch/arm/mach-versatile/Kconfig @@ -17,4 +17,12 @@ config MACH_VERSATILE_AB Include support for the ARM(R) Versatile Application Baseboard for the ARM926EJ-S. +config MACH_VERSATILE_DT + bool "Support Versatile platform from device tree" + select USE_OF + select CPU_ARM926T + help + Include support for the ARM(R) Versatile/PB platform, + using the device tree for discovery + endmenu diff --git a/arch/arm/mach-versatile/Makefile b/arch/arm/mach-versatile/Makefile index 97cf4d831b0..81fa3fe25e1 100644 --- a/arch/arm/mach-versatile/Makefile +++ b/arch/arm/mach-versatile/Makefile @@ -5,4 +5,5 @@ obj-y := core.o obj-$(CONFIG_ARCH_VERSATILE_PB) += versatile_pb.o obj-$(CONFIG_MACH_VERSATILE_AB) += versatile_ab.o +obj-$(CONFIG_MACH_VERSATILE_DT) += versatile_dt.o obj-$(CONFIG_PCI) += pci.o diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c index 0c99cf076c6..4770dcd0986 100644 --- a/arch/arm/mach-versatile/core.c +++ b/arch/arm/mach-versatile/core.c @@ -24,6 +24,8 @@ #include #include #include +#include +#include #include #include #include @@ -83,13 +85,26 @@ static struct fpga_irq_data sic_irq = { #define PIC_MASK 0 #endif +/* Lookup table for finding a DT node that represents the vic instance */ +static const struct of_device_id vic_of_match[] __initconst = { + { .compatible = "arm,versatile-vic", }, + {} +}; + +static const struct of_device_id sic_of_match[] __initconst = { + { .compatible = "arm,versatile-sic", }, + {} +}; + void __init versatile_init_irq(void) { vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0); + irq_domain_generate_simple(vic_of_match, VERSATILE_VIC_BASE, IRQ_VIC_START); writel(~0, VA_SIC_BASE + SIC_IRQ_ENABLE_CLEAR); fpga_irq_init(IRQ_VICSOURCE31, ~PIC_MASK, &sic_irq); + irq_domain_generate_simple(sic_of_match, VERSATILE_SIC_BASE, IRQ_SIC_START); /* * Interrupts on secondary controller from 0 to 8 are routed to @@ -646,6 +661,52 @@ static struct amba_device *amba_devs[] __initdata = { &kmi1_device, }; +#ifdef CONFIG_OF +/* + * Lookup table for attaching a specific name and platform_data pointer to + * devices as they get created by of_platform_populate(). Ideally this table + * would not exist, but the current clock implementation depends on some devices + * having a specific name. + */ +struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = { + OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_KMI0_BASE, "fpga:06", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_KMI1_BASE, "fpga:07", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART3_BASE, "fpga:09", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", NULL), + + OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART0_BASE, "dev:f1", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART1_BASE, "dev:f2", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART2_BASE, "dev:f3", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_SSP_BASE, "dev:f4", NULL), + +#if 0 + /* + * These entries are unnecessary because no clocks referencing + * them. I've left them in for now as place holders in case + * any of them need to be added back, but they should be + * removed before actually committing this patch. --gcl + */ + OF_DEV_AUXDATA("arm,primecell", VERSATILE_AACI_BASE, "fpga:04", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCI1_BASE, "fpga:0a", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_SMC_BASE, "dev:00", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_MPMC_BASE, "dev:10", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_DMAC_BASE, "dev:30", NULL), + + OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCTL_BASE, "dev:e0", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_WATCHDOG_BASE, "dev:e1", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO0_BASE, "dev:e4", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO1_BASE, "dev:e5", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO2_BASE, "dev:e6", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO3_BASE, "dev:e7", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_RTC_BASE, "dev:e8", NULL), + OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCI_BASE, "dev:f0", NULL), +#endif + {} +}; +#endif + #ifdef CONFIG_LEDS #define VA_LEDS_BASE (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_LED_OFFSET) diff --git a/arch/arm/mach-versatile/core.h b/arch/arm/mach-versatile/core.h index fd6404e5d78..70b155512f0 100644 --- a/arch/arm/mach-versatile/core.h +++ b/arch/arm/mach-versatile/core.h @@ -23,6 +23,7 @@ #define __ASM_ARCH_VERSATILE_H #include +#include extern void __init versatile_init(void); extern void __init versatile_init_early(void); @@ -30,6 +31,7 @@ extern void __init versatile_init_irq(void); extern void __init versatile_map_io(void); extern struct sys_timer versatile_timer; extern unsigned int mmc_status(struct device *dev); +extern struct of_dev_auxdata versatile_auxdata_lookup[]; #define AMBA_DEVICE(name,busid,base,plat) \ static struct amba_device name##_device = { \ diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c new file mode 100644 index 00000000000..54e037c090f --- /dev/null +++ b/arch/arm/mach-versatile/versatile_dt.c @@ -0,0 +1,51 @@ +/* + * Versatile board support using the device tree + * + * Copyright (C) 2010 Secret Lab Technologies Ltd. + * Copyright (C) 2009 Jeremy Kerr + * Copyright (C) 2004 ARM Limited + * Copyright (C) 2000 Deep Blue Solutions Ltd + * + * 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; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include + +#include "core.h" + +static void __init versatile_dt_init(void) +{ + of_platform_populate(NULL, of_default_bus_match_table, + versatile_auxdata_lookup, NULL); +} + +static const char *versatile_dt_match[] __initconst = { + "arm,versatile-ab", + "arm,versatile-pb", + NULL, +}; + +DT_MACHINE_START(VERSATILE_PB, "ARM-Versatile (Device Tree Support)") + .map_io = versatile_map_io, + .init_early = versatile_init_early, + .init_irq = versatile_init_irq, + .timer = &versatile_timer, + .init_machine = versatile_dt_init, + .dt_compat = versatile_dt_match, +MACHINE_END -- cgit v1.2.3 From a07204853d80debf593108d9812a4856cc856667 Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 19 Jul 2011 17:09:43 -0600 Subject: Devicetree: Expand on ARM Primecell binding documentation Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/arm/primecell.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Documentation/devicetree/bindings/arm/primecell.txt index 1d5d7a870ec..951ca46789d 100644 --- a/Documentation/devicetree/bindings/arm/primecell.txt +++ b/Documentation/devicetree/bindings/arm/primecell.txt @@ -6,7 +6,9 @@ driver matching. Required properties: -- compatible : should be a specific value for peripheral and "arm,primecell" +- compatible : should be a specific name for the peripheral and + "arm,primecell". The specific name will match the ARM + engineering name for the logic block in the form: "arm,pl???" Optional properties: -- cgit v1.2.3 From 5ec93cccf0ad25d6dffe64ff326b604a241d787b Mon Sep 17 00:00:00 2001 From: Thomas Abraham Date: Tue, 5 Jul 2011 23:42:32 -0600 Subject: arm/dt: Add basic device tree support for smdkv310 board Enable basic device tree support for Exynos4 smdkv310 board. Signed-off-by: Thomas Abraham Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/arm/samsung.txt | 9 +++++++++ arch/arm/boot/dts/exynos4-smdkv310.dts | 11 +++++++++++ arch/arm/mach-exynos4/mach-smdkv310.c | 6 ++++++ 3 files changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/samsung.txt create mode 100644 arch/arm/boot/dts/exynos4-smdkv310.dts (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/arm/samsung.txt b/Documentation/devicetree/bindings/arm/samsung.txt new file mode 100644 index 00000000000..594cb97e3d8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung.txt @@ -0,0 +1,9 @@ +Samsung Exynos4 S5PV310 SoC based SMDKV310 eval board + + SMDKV310 eval board is based on S5PV310 SoC which belongs to + Samsung's Exynos4 family of application processors. + +Required root node properties: + - compatible = "samsung,smdkv310","samsung,s5pv310" + (a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board. + (b) "samsung,s5pv310" - for boards based on S5PV310 SoC. diff --git a/arch/arm/boot/dts/exynos4-smdkv310.dts b/arch/arm/boot/dts/exynos4-smdkv310.dts new file mode 100644 index 00000000000..dd6c80a7ffc --- /dev/null +++ b/arch/arm/boot/dts/exynos4-smdkv310.dts @@ -0,0 +1,11 @@ +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + model = "Samsung Exynos4 SMDKV310 eval board"; + compatible = "samsung,smdkv310", "samsung,s5pv310"; + + memory { + reg = <0x40000000 0x08000000>; + }; +}; diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c index edd814110da..13b4bb733ef 100644 --- a/arch/arm/mach-exynos4/mach-smdkv310.c +++ b/arch/arm/mach-exynos4/mach-smdkv310.c @@ -233,6 +233,11 @@ static void __init smdkv310_machine_init(void) platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices)); } +static char const *smdkv310_dt_compat[] __initdata = { + "samsung,smdkv310", + NULL +}; + MACHINE_START(SMDKV310, "SMDKV310") /* Maintainer: Kukjin Kim */ /* Maintainer: Changhwan Youn */ @@ -241,4 +246,5 @@ MACHINE_START(SMDKV310, "SMDKV310") .map_io = smdkv310_map_io, .init_machine = smdkv310_machine_init, .timer = &exynos4_timer, + .dt_compat = smdkv310_dt_compat, MACHINE_END -- cgit v1.2.3 From 3810c04f4abbed255c7a8858d700f11a4ee65ec2 Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 5 Jul 2011 23:42:33 -0600 Subject: arm/dt: Add basic device tree support for mx51 and mx53 boards This patch add support for the Genesi Efika MX Smarttop and Smartbook, the Freescale mx51 babbage board, and the Freescale mx53 loco board Signed-off-by: Jason Liu Signed-off-by: Grant Likely --- .../devicetree/bindings/arm/freescale.txt | 7 +++++++ Documentation/devicetree/bindings/arm/genesi.txt | 8 ++++++++ arch/arm/boot/dts/genesi-efikamx.dts | 22 ++++++++++++++++++++++ arch/arm/boot/dts/genesi-efikasb.dts | 22 ++++++++++++++++++++++ arch/arm/boot/dts/mx51-babbage.dts | 22 ++++++++++++++++++++++ arch/arm/boot/dts/mx53-loco.dts | 22 ++++++++++++++++++++++ arch/arm/mach-mx5/board-mx51_babbage.c | 6 ++++++ arch/arm/mach-mx5/board-mx51_efikamx.c | 6 ++++++ arch/arm/mach-mx5/board-mx51_efikasb.c | 6 ++++++ arch/arm/mach-mx5/board-mx53_loco.c | 5 +++++ 10 files changed, 126 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/freescale.txt create mode 100644 Documentation/devicetree/bindings/arm/genesi.txt create mode 100644 arch/arm/boot/dts/genesi-efikamx.dts create mode 100644 arch/arm/boot/dts/genesi-efikasb.dts create mode 100644 arch/arm/boot/dts/mx51-babbage.dts create mode 100644 arch/arm/boot/dts/mx53-loco.dts (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/arm/freescale.txt b/Documentation/devicetree/bindings/arm/freescale.txt new file mode 100644 index 00000000000..8c52102b225 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/freescale.txt @@ -0,0 +1,7 @@ +mx51 "Babbage" evalutation board +Required root node properties: + - compatible = "fsl,mx51-babbage", "fsl,mx51"; + +mx53 "Loco" evaluation board +Required root node properties: + - compatible = "fsl,mx53-loco", "fsl,mx53"; diff --git a/Documentation/devicetree/bindings/arm/genesi.txt b/Documentation/devicetree/bindings/arm/genesi.txt new file mode 100644 index 00000000000..b353489acd4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/genesi.txt @@ -0,0 +1,8 @@ +Genesi EfikaMX based on Freescale mx51 +Required root node properties: + - compatible = "genesi,efikamx", "fsl,mx51"; + +Genesi EfikaMX Smartbook based on Freescale mx51 +Required root node properties: + - compatible = "genesi,efikasb", "fsl,mx51"; + diff --git a/arch/arm/boot/dts/genesi-efikamx.dts b/arch/arm/boot/dts/genesi-efikamx.dts new file mode 100644 index 00000000000..e81ffcc8443 --- /dev/null +++ b/arch/arm/boot/dts/genesi-efikamx.dts @@ -0,0 +1,22 @@ +/* + * Copyright 2011 Linaro Ltd. + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + model = "Genesi EfikaMX nettop"; + compatible = "genesi,efikamx", "fsl,mx51"; + + memory { + reg = <0x90000000 0x20000000>; + }; +}; diff --git a/arch/arm/boot/dts/genesi-efikasb.dts b/arch/arm/boot/dts/genesi-efikasb.dts new file mode 100644 index 00000000000..9fda6ae314e --- /dev/null +++ b/arch/arm/boot/dts/genesi-efikasb.dts @@ -0,0 +1,22 @@ +/* + * Copyright 2011 Linaro Ltd. + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + model = "Genesi Efika Smartbook"; + compatible = "genesi,efikasb", "fsl,mx51"; + + memory { + reg = <0x90000000 0x20000000>; + }; +}; diff --git a/arch/arm/boot/dts/mx51-babbage.dts b/arch/arm/boot/dts/mx51-babbage.dts new file mode 100644 index 00000000000..e5e9c8913d0 --- /dev/null +++ b/arch/arm/boot/dts/mx51-babbage.dts @@ -0,0 +1,22 @@ +/* + * Copyright 2011 Linaro Ltd. + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + model = "Freescale i.MX51 Babbage"; + compatible = "fsl,mx51-babbage", "fsl,mx51"; + + memory { + reg = <0x90000000 0x20000000>; + }; +}; diff --git a/arch/arm/boot/dts/mx53-loco.dts b/arch/arm/boot/dts/mx53-loco.dts new file mode 100644 index 00000000000..8426c620614 --- /dev/null +++ b/arch/arm/boot/dts/mx53-loco.dts @@ -0,0 +1,22 @@ +/* + * Copyright 2011 Linaro Ltd. + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +/dts-v1/; +/include/ "skeleton.dtsi" + +/ { + model = "Freescale i.MX53 LOCO"; + compatible = "fsl,mx53-loco", "fsl,mx53"; + + memory { + reg = <0x70000000 0x40000000>; + }; +}; diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c index c7b3fabf50f..d508e5ea54b 100644 --- a/arch/arm/mach-mx5/board-mx51_babbage.c +++ b/arch/arm/mach-mx5/board-mx51_babbage.c @@ -392,6 +392,11 @@ static struct sys_timer mx51_babbage_timer = { .init = mx51_babbage_timer_init, }; +static const char *mx51_babbage_dt_match[] __initdata = { + "fsl,mx51-babbage", + NULL +}; + MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") /* Maintainer: Amit Kucheria */ .boot_params = MX51_PHYS_OFFSET + 0x100, @@ -400,4 +405,5 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") .init_irq = mx51_init_irq, .timer = &mx51_babbage_timer, .init_machine = mx51_babbage_init, + .dt_compat = mx51_babbage_dt_match, MACHINE_END diff --git a/arch/arm/mach-mx5/board-mx51_efikamx.c b/arch/arm/mach-mx5/board-mx51_efikamx.c index 6e362315291..7b07179a09d 100644 --- a/arch/arm/mach-mx5/board-mx51_efikamx.c +++ b/arch/arm/mach-mx5/board-mx51_efikamx.c @@ -283,6 +283,11 @@ static struct sys_timer mx51_efikamx_timer = { .init = mx51_efikamx_timer_init, }; +static const char *mx51_efikamx_dt_match[] __initdata = { + "genesi,efikamx", + NULL +}; + MACHINE_START(MX51_EFIKAMX, "Genesi EfikaMX nettop") /* Maintainer: Amit Kucheria */ .boot_params = MX51_PHYS_OFFSET + 0x100, @@ -291,4 +296,5 @@ MACHINE_START(MX51_EFIKAMX, "Genesi EfikaMX nettop") .init_irq = mx51_init_irq, .timer = &mx51_efikamx_timer, .init_machine = mx51_efikamx_init, + .dt_compat = mx51_efikamx_dt_match, MACHINE_END diff --git a/arch/arm/mach-mx5/board-mx51_efikasb.c b/arch/arm/mach-mx5/board-mx51_efikasb.c index 474fc6e4c6d..e90dcd58135 100644 --- a/arch/arm/mach-mx5/board-mx51_efikasb.c +++ b/arch/arm/mach-mx5/board-mx51_efikasb.c @@ -270,6 +270,11 @@ static struct sys_timer mx51_efikasb_timer = { .init = mx51_efikasb_timer_init, }; +static const char *mx51_efikasb_dt_match[] __initdata = { + "genesi,efikasb", + NULL +}; + MACHINE_START(MX51_EFIKASB, "Genesi Efika Smartbook") .boot_params = MX51_PHYS_OFFSET + 0x100, .map_io = mx51_map_io, @@ -277,4 +282,5 @@ MACHINE_START(MX51_EFIKASB, "Genesi Efika Smartbook") .init_irq = mx51_init_irq, .init_machine = efikasb_board_init, .timer = &mx51_efikasb_timer, + .dt_compat = mx51_efikasb_dt_match, MACHINE_END diff --git a/arch/arm/mach-mx5/board-mx53_loco.c b/arch/arm/mach-mx5/board-mx53_loco.c index 1b947e8c9c0..bead01802fb 100644 --- a/arch/arm/mach-mx5/board-mx53_loco.c +++ b/arch/arm/mach-mx5/board-mx53_loco.c @@ -249,10 +249,15 @@ static struct sys_timer mx53_loco_timer = { .init = mx53_loco_timer_init, }; +static const char *mx53_loco_dt_match[] __initdata = { + "fsl,mx53-loco", + NULL +}; MACHINE_START(MX53_LOCO, "Freescale MX53 LOCO Board") .map_io = mx53_map_io, .init_early = imx53_init_early, .init_irq = mx53_init_irq, .timer = &mx53_loco_timer, .init_machine = mx53_loco_board_init, + .dt_compat = mx53_loco_dt_match, MACHINE_END -- cgit v1.2.3 From a73ae32efe00fa627e0dc9fed2b134307960c78c Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 5 Jul 2011 23:42:39 -0600 Subject: gpio/dt: Refine GPIO device tree binding Allow for multiple named gpio properties Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/gpio/gpio.txt | 46 ++++++++++++++++++++----- 1 file changed, 37 insertions(+), 9 deletions(-) (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index edaa84d288a..4e16ba4feab 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -4,17 +4,45 @@ Specifying GPIO information for devices 1) gpios property ----------------- -Nodes that makes use of GPIOs should define them using `gpios' property, -format of which is: <&gpio-controller1-phandle gpio1-specifier - &gpio-controller2-phandle gpio2-specifier - 0 /* holes are permitted, means no GPIO 3 */ - &gpio-controller4-phandle gpio4-specifier - ...>; +Nodes that makes use of GPIOs should specify them using one or more +properties, each containing a 'gpio-list': -Note that gpio-specifier length is controller dependent. + gpio-list ::= [gpio-list] + single-gpio ::= + gpio-phandle : phandle to gpio controller node + gpio-specifier : Array of #gpio-cells specifying specific gpio + (controller specific) + +GPIO properties should be named "[-]gpios". Exact +meaning of each gpios property must be documented in the device tree +binding for each device. + +For example, the following could be used to describe gpios pins to use +as chip select lines; with chip selects 0, 1 and 3 populated, and chip +select 2 left empty: + + gpio1: gpio1 { + gpio-controller + #gpio-cells = <2>; + }; + gpio2: gpio2 { + gpio-controller + #gpio-cells = <1>; + }; + [...] + chipsel-gpios = <&gpio1 12 0>, + <&gpio1 13 0>, + <0>, /* holes are permitted, means no GPIO 2 */ + <&gpio2 2>; + +Note that gpio-specifier length is controller dependent. In the +above example, &gpio1 uses 2 cells to specify a gpio, while &gpio2 +only uses one. gpio-specifier may encode: bank, pin position inside the bank, whether pin is open-drain and whether pin is logically inverted. +Exact meaning of each specifier cell is controller specific, and must +be documented in the device tree binding for the device. Example of the node using GPIOs: @@ -28,8 +56,8 @@ and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller. 2) gpio-controller nodes ------------------------ -Every GPIO controller node must have #gpio-cells property defined, -this information will be used to translate gpio-specifiers. +Every GPIO controller node must both an empty "gpio-controller" +property, and have #gpio-cells contain the size of the gpio-specifier. Example of two SOC GPIO banks defined as gpio-controller nodes: -- cgit v1.2.3 From 359ece7ae3a0e3640b6f40dd8caa85cf2aec7aac Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 5 Jul 2011 23:44:23 -0600 Subject: gpio/tegra: add devicetree support Add support for decoding gpios from the device tree Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/gpio/gpio_nvidia.txt | 7 +++++++ arch/arm/mach-tegra/gpio.c | 10 ++++++++++ 2 files changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio_nvidia.txt (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt b/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt new file mode 100644 index 00000000000..64aac39e6ed --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt @@ -0,0 +1,7 @@ +NVIDIA Tegra 2 GPIO controller + +Required properties: +- compatible : "nvidia,tegra20-gpio" +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters (currently unused). +- gpio-controller : Marks the device node as a GPIO controller. diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c index 919d6383773..747eb40e8af 100644 --- a/arch/arm/mach-tegra/gpio.c +++ b/arch/arm/mach-tegra/gpio.c @@ -23,6 +23,7 @@ #include #include +#include #include @@ -340,6 +341,15 @@ static int __init tegra_gpio_init(void) } } +#ifdef CONFIG_OF_GPIO + /* + * This isn't ideal, but it gets things hooked up until this + * driver is converted into a platform_device + */ + tegra_gpio_chip.of_node = of_find_compatible_node(NULL, NULL, + "nvidia,tegra20-gpio"); +#endif /* CONFIG_OF_GPIO */ + gpiochip_add(&tegra_gpio_chip); for (i = INT_GPIO_BASE; i < (INT_GPIO_BASE + TEGRA_NR_GPIOS); i++) { -- cgit v1.2.3 From 3dbcc08accc9900c750f17e6c38643f814127bf7 Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 5 Jul 2011 23:45:36 -0600 Subject: spi/tegra: add devicetree support Allow the tegra spi driver to obtain populate the spi bus with devices from the device tree. Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/spi/spi_nvidia.txt | 5 +++++ drivers/spi/spi_tegra.c | 12 ++++++++++++ 2 files changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi_nvidia.txt (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/bindings/spi/spi_nvidia.txt b/Documentation/devicetree/bindings/spi/spi_nvidia.txt new file mode 100644 index 00000000000..6b9e5189669 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi_nvidia.txt @@ -0,0 +1,5 @@ +NVIDIA Tegra 2 SPI device + +Required properties: +- compatible : should be "nvidia,tegra20-spi". +- gpios : should specify GPIOs used for chipselect. diff --git a/drivers/spi/spi_tegra.c b/drivers/spi/spi_tegra.c index 6c3aa6ecaad..b0e3586d1e1 100644 --- a/drivers/spi/spi_tegra.c +++ b/drivers/spi/spi_tegra.c @@ -546,6 +546,7 @@ static int __init spi_tegra_probe(struct platform_device *pdev) tspi->rx_dma_req.req_sel = spi_tegra_req_sels[pdev->id]; tspi->rx_dma_req.dev = tspi; + master->dev.of_node = pdev->dev.of_node; ret = spi_register_master(master); if (ret < 0) @@ -595,10 +596,21 @@ static int __devexit spi_tegra_remove(struct platform_device *pdev) MODULE_ALIAS("platform:spi_tegra"); +#ifdef CONFIG_OF +static struct of_device_id spi_tegra_of_match_table[] __devinitdata = { + { .compatible = "nvidia,tegra20-spi", }, + {} +}; +MODULE_DEVICE_TABLE(of, spi_tegra_of_match_table); +#else /* CONFIG_OF */ +#define spi_tegra_of_match_table NULL +#endif /* CONFIG_OF */ + static struct platform_driver spi_tegra_driver = { .driver = { .name = "spi_tegra", .owner = THIS_MODULE, + .of_match_table = spi_tegra_of_match_table, }, .remove = __devexit_p(spi_tegra_remove), }; -- cgit v1.2.3 From 5049b88232de6414144f4cf0f4510227afd0098e Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 21 Jun 2011 10:53:47 -0600 Subject: dt: Linux dt usage model documentation v2: 2nd draft - Editorial cleanups from Randy Dunlap Signed-off-by: Grant Likely --- Documentation/devicetree/usage-model | 403 +++++++++++++++++++++++++++++++++++ 1 file changed, 403 insertions(+) create mode 100644 Documentation/devicetree/usage-model (limited to 'Documentation/devicetree') diff --git a/Documentation/devicetree/usage-model b/Documentation/devicetree/usage-model new file mode 100644 index 00000000000..45e03b8dd04 --- /dev/null +++ b/Documentation/devicetree/usage-model @@ -0,0 +1,403 @@ +Linux and the Device Tree +The Linux usage model for device tree data + +Author: Grant Likely + +This article describes how Linux uses the device tree. An overview of +the device tree data format can be found at the Device Tree Usage +page on devicetree.org. + + + All the cool architectures are using device tree. I want to + use device tree too! + +The "Open Firmware Device Tree", or simply Device Tree (DT), is a data +structure and language for describing hardware. More specifically, it +is a description of hardware that is readable by an operating system +so that the operating system doesn't need to hard code details of the +machine. + +Structurally, the DT is a tree, or acyclic graph with named nodes, and +nodes may have an arbitrary number of named properties encapsulating +arbitrary data. A mechanism also exists to create arbitrary +links from one node to another outside of the natural tree structure. + +Conceptually, a common set of usage conventions, called 'bindings', +is defined for how data should appear in the tree to describe typical +hardware characteristics including data busses, interrupt lines, GPIO +connections, and peripheral devices. + +As much as possible, hardware is described using existing bindings to +maximize use of existing support code, but since property and node +names are simply text strings, it is easy to extend existing bindings +or create new ones by defining new nodes and properties. + +

History

+The DT was originally created by Open Firmware as part of the +communication method for passing data from Open Firmware to a client +program (like to an operating system). An operating system used the +Device Tree to discover the topology of the hardware at runtime, and +thereby support a majority of available hardware without hard coded +information (assuming drivers were available for all devices). + +Since Open Firmware is commonly used on PowerPC and SPARC platforms, +the Linux support for those architectures has for a long time used the +Device Tree. + +In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit +and 64-bit support, the decision was made to require DT support on all +powerpc platforms, regardless of whether or not they used Open +Firmware. To do this, a DT representation called the Flattened Device +Tree (FDT) was created which could be passed to the kernel as a binary +blob without requiring a real Open Firmware implementation. U-Boot, +kexec, and other bootloaders were modified to support both passing a +Device Tree Binary (dtb) and to modify a dtb at boot time. + +Some time later, FDT infrastructure was generalized to be usable by +all architectures. At the time of this writing, 6 mainlined +architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1 +out of mainline (nios) have some level of DT support. + +

Data Model

+If you haven't already read the +href="http://devicetree.org/Device_Tree_Usage">Device Tree Usage +page, then go read it now. It's okay, I'll wait.... + +

High Level View

+The most important thing to understand is that the DT is simply a data +structure that describes the hardware. There is nothing magical about +it, and it doesn't magically make all hardware configuration problems +go away. What it does do is provide a language for decoupling the +hardware configuration from the board and device driver support in the +Linux kernel (or any other operating system for that matter). Using +it allows board and device support to become data driven; to make +setup decisions based on data passed into the kernel instead of on +per-machine hard coded selections. + +Ideally, data driven platform setup should result in less code +duplication and make it easier to support a wide range of hardware +with a single kernel image. + +Linux uses DT data for three major purposes: +1) platform identification, +2) runtime configuration, and +3) device population. + +

Platform Identification

+First and foremost, the kernel will use data in the DT to identify the +specific machine. In a perfect world, the specific platform shouldn't +matter to the kernel because all platform details would be described +perfectly by the device tree in a consistent and reliable manner. +Hardware is not perfect though, and so the kernel must identify the +machine during early boot so that it has the opportunity to run +machine-specific fixups. + +In the majority of cases, the machine identity is irrelevant, and the +kernel will instead select setup code based on the machine's core +CPU or SoC. On ARM for example, setup_arch() in +arch/arm/kernel/setup.c will call setup_machine_fdt() in +arch/arm/kernel/devicetree.c which searches through the machine_desc +table and selects the machine_desc which best matches the device tree +data. It determines the best match by looking at the 'compatible' +property in the root device tree node, and comparing it with the +dt_compat list in struct machine_desc. + +The 'compatible' property contains a sorted list of strings starting +with the exact name of the machine, followed by an optional list of +boards it is compatible with sorted from most compatible to least. For +example, the root compatible properties for the TI BeagleBoard and its +successor, the BeagleBoard xM board might look like: + + compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3"; + compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3"; + +Where "ti,omap3-beagleboard-xm" specifies the exact model, it also +claims that it compatible with the OMAP 3450 SoC, and the omap3 family +of SoCs in general. You'll notice that the list is sorted from most +specific (exact board) to least specific (SoC family). + +Astute readers might point out that the Beagle xM could also claim +compatibility with the original Beagle board. However, one should be +cautioned about doing so at the board level since there is typically a +high level of change from one board to another, even within the same +product line, and it is hard to nail down exactly what is meant when one +board claims to be compatible with another. For the top level, it is +better to err on the side of caution and not claim one board is +compatible with another. The notable exception would be when one +board is a carrier for another, such as a CPU module attached to a +carrier board. + +One more note on compatible values. Any string used in a compatible +property must be documented as to what it indicates. Add +documentation for compatible strings in Documentation/devicetree/bindings. + +Again on ARM, for each machine_desc, the kernel looks to see if +any of the dt_compat list entries appear in the compatible property. +If one does, then that machine_desc is a candidate for driving the +machine. After searching the entire table of machine_descs, +setup_machine_fdt() returns the 'most compatible' machine_desc based +on which entry in the compatible property each machine_desc matches +against. If no matching machine_desc is found, then it returns NULL. + +The reasoning behind this scheme is the observation that in the majority +of cases, a single machine_desc can support a large number of boards +if they all use the same SoC, or same family of SoCs. However, +invariably there will be some exceptions where a specific board will +require special setup code that is not useful in the generic case. +Special cases could be handled by explicitly checking for the +troublesome board(s) in generic setup code, but doing so very quickly +becomes ugly and/or unmaintainable if it is more than just a couple of +cases. + +Instead, the compatible list allows a generic machine_desc to provide +support for a wide common set of boards by specifying "less +compatible" value in the dt_compat list. In the example above, +generic board support can claim compatibility with "ti,omap3" or +"ti,omap3450". If a bug was discovered on the original beagleboard +that required special workaround code during early boot, then a new +machine_desc could be added which implements the workarounds and only +matches on "ti,omap3-beagleboard". + +PowerPC uses a slightly different scheme where it calls the .probe() +hook from each machine_desc, and the first one returning TRUE is used. +However, this approach does not take into account the priority of the +compatible list, and probably should be avoided for new architecture +support. + +

Runtime configuration

+In most cases, a DT will be the sole method of communicating data from +firmware to the kernel, so also gets used to pass in runtime and +configuration data like the kernel parameters string and the location +of an initrd image. + +Most of this data is contained in the /chosen node, and when booting +Linux it will look something like this: + + chosen { + bootargs = "console=ttyS0,115200 loglevel=8"; + initrd-start = <0xc8000000>; + initrd-end = <0xc8200000>; + }; + +The bootargs property contains the kernel arguments, and the initrd-* +properties define the address and size of an initrd blob. The +chosen node may also optionally contain an arbitrary number of +additional properties for platform-specific configuration data. + +During early boot, the architecture setup code calls of_scan_flat_dt() +several times with different helper callbacks to parse device tree +data before paging is setup. The of_scan_flat_dt() code scans through +the device tree and uses the helpers to extract information required +during early boot. Typically the early_init_dt_scan_chosen() helper +is used to parse the chosen node including kernel parameters, +early_init_dt_scan_root() to initialize the DT address space model, +and early_init_dt_scan_memory() to determine the size and +location of usable RAM. + +On ARM, the function setup_machine_fdt() is responsible for early +scanning of the device tree after selecting the correct machine_desc +that supports the board. + +

Device population

+After the board has been identified, and after the early configuration data +has been parsed, then kernel initialization can proceed in the normal +way. At some point in this process, unflatten_device_tree() is called +to convert the data into a more efficient runtime representation. +This is also when machine-specific setup hooks will get called, like +the machine_desc .init_early(), .init_irq() and .init_machine() hooks +on ARM. The remainder of this section uses examples from the ARM +implementation, but all architectures will do pretty much the same +thing when using a DT. + +As can be guessed by the names, .init_early() is used for any machine- +specific setup that needs to be executed early in the boot process, +and .init_irq() is used to set up interrupt handling. Using a DT +doesn't materially change the behaviour of either of these functions. +If a DT is provided, then both .init_early() and .init_irq() are able +to call any of the DT query functions (of_* in include/linux/of*.h) to +get additional data about the platform. + +The most interesting hook in the DT context is .init_machine() which +is primarily responsible for populating the Linux device model with +data about the platform. Historically this has been implemented on +embedded platforms by defining a set of static clock structures, +platform_devices, and other data in the board support .c file, and +registering it en-masse in .init_machine(). When DT is used, then +instead of hard coding static devices for each platform, the list of +devices can be obtained by parsing the DT, and allocating device +structures dynamically. + +The simplest case is when .init_machine() is only responsible for +registering a block of platform_devices. A platform_device is a concept +used by Linux for memory or I/O mapped devices which cannot be detected +by hardware, and for 'composite' or 'virtual' devices (more on those +later). While there is no 'platform device' terminology for the DT, +platform devices roughly correspond to device nodes at the root of the +tree and children of simple memory mapped bus nodes. + +About now is a good time to lay out an example. Here is part of the +device tree for the NVIDIA Tegra board. + +/{ + compatible = "nvidia,harmony", "nvidia,tegra20"; + #address-cells = <1>; + #size-cells = <1>; + interrupt-parent = <&intc>; + + chosen { }; + aliases { }; + + memory { + device_type = "memory"; + reg = <0x00000000 0x40000000>; + }; + + soc { + compatible = "nvidia,tegra20-soc", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + intc: interrupt-controller@50041000 { + compatible = "nvidia,tegra20-gic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >; + }; + + serial@70006300 { + compatible = "nvidia,tegra20-uart"; + reg = <0x70006300 0x100>; + interrupts = <122>; + }; + + i2s-1: i2s@70002800 { + compatible = "nvidia,tegra20-i2s"; + reg = <0x70002800 0x100>; + interrupts = <77>; + codec = <&wm8903>; + }; + + i2c@7000c000 { + compatible = "nvidia,tegra20-i2c"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x7000c000 0x100>; + interrupts = <70>; + + wm8903: codec@1a { + compatible = "wlf,wm8903"; + reg = <0x1a>; + interrupts = <347>; + }; + }; + }; + + sound { + compatible = "nvidia,harmony-sound"; + i2s-controller = <&i2s-1>; + i2s-codec = <&wm8903>; + }; +}; + +At .machine_init() time, Tegra board support code will need to look at +this DT and decide which nodes to create platform_devices for. +However, looking at the tree, it is not immediately obvious what kind +of device each node represents, or even if a node represents a device +at all. The /chosen, /aliases, and /memory nodes are informational +nodes that don't describe devices (although arguably memory could be +considered a device). The children of the /soc node are memory mapped +devices, but the codec@1a is an i2c device, and the sound node +represents not a device, but rather how other devices are connected +together to create the audio subsystem. I know what each device is +because I'm familiar with the board design, but how does the kernel +know what to do with each node? + +The trick is that the kernel starts at the root of the tree and looks +for nodes that have a 'compatible' property. First, it is generally +assumed that any node with a 'compatible' property represents a device +of some kind, and second, it can be assumed that any node at the root +of the tree is either directly attached to the processor bus, or is a +miscellaneous system device that cannot be described any other way. +For each of these nodes, Linux allocates and registers a +platform_device, which in turn may get bound to a platform_driver. + +Why is using a platform_device for these nodes a safe assumption? +Well, for the way that Linux models devices, just about all bus_types +assume that its devices are children of a bus controller. For +example, each i2c_client is a child of an i2c_master. Each spi_device +is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The +same hierarchy is also found in the DT, where I2C device nodes only +ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB, +etc. The only devices which do not require a specific type of parent +device are platform_devices (and amba_devices, but more on that +later), which will happily live at the base of the Linux /sys/devices +tree. Therefore, if a DT node is at the root of the tree, then it +really probably is best registered as a platform_device. + +Linux board support code calls of_platform_populate(NULL, NULL, NULL) +to kick off discovery of devices at the root of the tree. The +parameters are all NULL because when starting from the root of the +tree, there is no need to provide a starting node (the first NULL), a +parent struct device (the last NULL), and we're not using a match +table (yet). For a board that only needs to register devices, +.init_machine() can be completely empty except for the +of_platform_populate() call. + +In the Tegra example, this accounts for the /soc and /sound nodes, but +what about the children of the SoC node? Shouldn't they be registered +as platform devices too? For Linux DT support, the generic behaviour +is for child devices to be registered by the parent's device driver at +driver .probe() time. So, an i2c bus device driver will register a +i2c_client for each child node, an SPI bus driver will register +its spi_device children, and similarly for other bus_types. +According to that model, a driver could be written that binds to the +SoC node and simply registers platform_devices for each of its +children. The board support code would allocate and register an SoC +device, an SoC device driver would bind to the SoC device, and +register platform_devices for /soc/interrupt-controller, /soc/serial, +/soc/i2s, and /soc/i2c in its .probe() hook. Easy, right? Although +it is a lot of mucking about for just registering platform devices. + +It turns out that registering children of certain platform_devices as +more platform_devices is a common pattern, and the device tree support +code reflects that. The second argument to of_platform_populate() is +an of_device_id table, and any node that matches an entry in that +table will also get its child nodes registered. In the tegra case, +the code can look something like this: + +static struct of_device_id harmony_bus_ids[] __initdata = { + { .compatible = "simple-bus", }, + {} +}; + +static void __init harmony_init_machine(void) +{ + /* ... */ + of_platform_populate(NULL, harmony_bus_ids, NULL); +} + +"simple-bus" is defined in the ePAPR 1.0 specification as a property +meaning a simple memory mapped bus, so the of_platform_populate() code +could be written to just assume simple-bus compatible nodes will +always be traversed. However, we pass it in as an argument so that +board support code can always override the default behaviour. + +

Appendix A: AMBA devices

+ +ARM Primecells are a certain kind of device attached to the ARM AMBA +bus which include some support for hardware detection and power +management. In Linux, struct amba_device and the amba_bus_type is +used to represent Primecell devices. However, the fiddly bit is that +not all devices on an AMBA bus are Primecells, and for Linux it is +typical for both amba_device and platform_device instances to be +siblings of the same bus segment. + +When using the DT, this creates problems for of_platform_populate() +because it must decide whether to register each node as either a +platform_device or an amba_device. This unfortunately complicates the +device creation model a little bit, but the solution turns out not to +be too invasive. If a node is compatible with "arm,amba-primecell", then +of_platform_populate() will register it as an amba_device instead of a +platform_device. -- cgit v1.2.3