summaryrefslogtreecommitdiff
path: root/Documentation/devicetree/bindings
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/devicetree/bindings')
-rw-r--r--Documentation/devicetree/bindings/arm/atmel-at91.txt8
-rw-r--r--Documentation/devicetree/bindings/leds/register-bit-led.txt99
-rw-r--r--Documentation/devicetree/bindings/mailbox/omap-mailbox.txt108
-rw-r--r--Documentation/devicetree/bindings/rtc/sun6i-rtc.txt17
-rw-r--r--Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt111
-rw-r--r--Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt232
6 files changed, 568 insertions, 7 deletions
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index 4949e805f7fc..562cda9d86d9 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -98,8 +98,8 @@ RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91rm9200-sdramc",
"atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
+ "atmel,sama5d3-ddramc",
- reg: Should contain registers location and length
- For at91sam9263 and at91sam9g45 you must specify 2 entries.
Examples:
@@ -108,12 +108,6 @@ Examples:
reg = <0xffffe800 0x200>;
};
- ramc0: ramc@ffffe400 {
- compatible = "atmel,at91sam9g45-ddramc";
- reg = <0xffffe400 0x200
- 0xffffe600 0x200>;
- };
-
SHDWC Shutdown Controller
required properties:
diff --git a/Documentation/devicetree/bindings/leds/register-bit-led.txt b/Documentation/devicetree/bindings/leds/register-bit-led.txt
new file mode 100644
index 000000000000..379cefdc0bda
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/register-bit-led.txt
@@ -0,0 +1,99 @@
+Device Tree Bindings for Register Bit LEDs
+
+Register bit leds are used with syscon multifunctional devices
+where single bits in a certain register can turn on/off a
+single LED. The register bit LEDs appear as children to the
+syscon device, with the proper compatible string. For the
+syscon bindings see:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Each LED is represented as a sub-node of the syscon device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+
+Required properties:
+- compatible : must be "register-bit-led"
+- offset : register offset to the register controlling this LED
+- mask : bit mask for the bit controlling this LED in the register
+ typically 0x01, 0x02, 0x04 ...
+
+Optional properties:
+- label : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- default-state: (optional) The initial state of the LED. Valid
+ values are "on", "off", and "keep". If the LED is already on or off
+ and the default-state property is set the to same value, then no
+ glitch should be produced where the LED momentarily turns off (or
+ on). The "keep" setting will keep the LED at whatever its current
+ state is, without producing a glitch. The default is off if this
+ property is not present.
+
+Example:
+
+syscon: syscon@10000000 {
+ compatible = "arm,realview-pb1176-syscon", "syscon";
+ reg = <0x10000000 0x1000>;
+
+ led@08.0 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "versatile:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ led@08.1 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x02>;
+ label = "versatile:1";
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ led@08.2 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x04>;
+ label = "versatile:2";
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+ led@08.3 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x08>;
+ label = "versatile:3";
+ default-state = "off";
+ };
+ led@08.4 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x10>;
+ label = "versatile:4";
+ default-state = "off";
+ };
+ led@08.5 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x20>;
+ label = "versatile:5";
+ default-state = "off";
+ };
+ led@08.6 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x40>;
+ label = "versatile:6";
+ default-state = "off";
+ };
+ led@08.7 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x80>;
+ label = "versatile:7";
+ default-state = "off";
+ };
+};
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 000000000000..48edc4b92afb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,108 @@
+OMAP2+ Mailbox Driver
+=====================
+
+The OMAP mailbox hardware facilitates communication between different processors
+using a queued mailbox interrupt mechanism. The IP block is external to the
+various processor subsystems and is connected on an interconnect bus. The
+communication is achieved through a set of registers for message storage and
+interrupt configuration registers.
+
+Each mailbox IP block has a certain number of h/w fifo queues and output
+interrupt lines. An output interrupt line is routed to an interrupt controller
+within a processor subsystem, and there can be more than one line going to a
+specific processor's interrupt controller. The interrupt line connections are
+fixed for an instance and are dictated by the IP integration into the SoC
+(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is
+programmable through a set of interrupt configuration registers, and have a rx
+and tx interrupt source per h/w fifo. Communication between different processors
+is achieved through the appropriate programming of the rx and tx interrupt
+sources on the appropriate interrupt lines.
+
+The number of h/w fifo queues and interrupt lines dictate the usable registers.
+All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP
+instance. DRA7xx has multiple instances with different number of h/w fifo queues
+and interrupt lines between different instances. The interrupt lines can also be
+routed to different processor sub-systems on DRA7xx as they are routed through
+the Crossbar, a kind of interrupt router/multiplexer.
+
+Mailbox Device Node:
+====================
+A Mailbox device node is used to represent a Mailbox IP instance within a SoC.
+The sub-mailboxes are represented as child nodes of this parent node.
+
+Required properties:
+--------------------
+- compatible: Should be one of the following,
+ "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs
+ "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs
+ "ti,omap4-mailbox" for OMAP44xx, OMAP54xx, AM33xx,
+ AM43xx and DRA7xx SoCs
+- reg: Contains the mailbox register address range (base
+ address and length)
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the OMAP device uses
+- ti,hwmods: Name of the hwmod associated with the mailbox
+- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
+ device can interrupt
+- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block
+
+Child Nodes:
+============
+A child node is used for representing the actual sub-mailbox device that is
+used for the communication between the host processor and a remote processor.
+Each child node should have a unique node name across all the different
+mailbox device nodes.
+
+Required properties:
+--------------------
+- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo
+- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo
+
+Sub-mailbox Descriptor Data
+---------------------------
+Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of
+data that represent the following:
+ Cell #1 (fifo_id) - mailbox fifo id used either for transmitting
+ (ti,mbox-tx) or for receiving (ti,mbox-rx)
+ Cell #2 (irq_id) - irq identifier index number to use from the parent's
+ interrupts data. Should be 0 for most of the cases, a
+ positive index value is seen only on mailboxes that have
+ multiple interrupt lines connected to the MPU processor.
+ Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
+ associated with generating a tx/rx fifo interrupt.
+
+Example:
+--------
+
+/* OMAP4 */
+mailbox: mailbox@4a0f4000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x4a0f4000 0x200>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <3>;
+ ti,mbox-num-fifos = <8>;
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <1 0 0>;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <2 0 0>;
+ };
+};
+
+/* AM33xx */
+mailbox: mailbox@480C8000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x480C8000 0x200>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <8>;
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt b/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
new file mode 100644
index 000000000000..f007e428a1ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
@@ -0,0 +1,17 @@
+* sun6i Real Time Clock
+
+RTC controller for the Allwinner A31
+
+Required properties:
+- compatible : Should be "allwinner,sun6i-a31-rtc"
+- reg : physical base address of the controller and length of
+ memory mapped region.
+- interrupts : IRQ lines for the RTC alarm 0 and alarm 1, in that order.
+
+Example:
+
+rtc: rtc@01f00000 {
+ compatible = "allwinner,sun6i-a31-rtc";
+ reg = <0x01f00000 0x54>;
+ interrupts = <0 40 4>, <0 41 4>;
+};
diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt
new file mode 100644
index 000000000000..337c4ea5c57b
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-dma.txt
@@ -0,0 +1,111 @@
+Keystone Navigator DMA Controller
+
+This document explains the device tree bindings for the packet dma
+on keystone devices. The Keystone Navigator DMA driver sets up the dma
+channels and flows for the QMSS(Queue Manager SubSystem) who triggers
+the actual data movements across clients using destination queues. Every
+client modules like NETCP(Network Coprocessor), SRIO(Serial Rapid IO),
+CRYPTO Engines etc has its own instance of dma hardware. QMSS has also
+an internal packet DMA module which is used as an infrastructure DMA
+with zero copy.
+
+Navigator DMA cloud layout:
+ ------------------
+ | Navigator DMAs |
+ ------------------
+ |
+ |-> DMA instance #0
+ |
+ |-> DMA instance #1
+ .
+ .
+ |
+ |-> DMA instance #n
+
+Navigator DMA properties:
+Required properties:
+ - compatible: Should be "ti,keystone-navigator-dma"
+ - clocks: phandle to dma instances clocks. The clock handles can be as
+ many as the dma instances. The order should be maintained as per
+ the dma instances.
+ - ti,navigator-cloud-address: Should contain base address for the multi-core
+ navigator cloud and number of addresses depends on SOC integration
+ configuration.. Navigator cloud global address needs to be programmed
+ into DMA and the DMA uses it as the physical addresses to reach queue
+ managers. Note that these addresses though points to queue managers,
+ they are relevant only from DMA perspective. The QMSS may not choose to
+ use them since it has a different address space view to reach all
+ its components.
+
+DMA instance properties:
+Required properties:
+ - reg: Should contain register location and length of the following dma
+ register regions. Register regions should be specified in the following
+ order.
+ - Global control register region (global).
+ - Tx DMA channel configuration register region (txchan).
+ - Rx DMA channel configuration register region (rxchan).
+ - Tx DMA channel Scheduler configuration register region (txsched).
+ - Rx DMA flow configuration register region (rxflow).
+
+Optional properties:
+ - reg-names: Names for the register regions.
+ - ti,enable-all: Enable all DMA channels vs clients opening specific channels
+ what they need. This property is useful for the userspace fast path
+ case where the linux drivers enables the channels used by userland
+ stack.
+ - ti,loop-back: To loopback Tx streaming I/F to Rx streaming I/F. Used for
+ infrastructure transfers.
+ - ti,rx-retry-timeout: Number of dma cycles to wait before retry on buffer
+ starvation.
+
+Example:
+
+ knav_dmas: knav_dmas@0 {
+ compatible = "ti,keystone-navigator-dma";
+ clocks = <&papllclk>, <&clkxge>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,navigator-cloud-address = <0x23a80000 0x23a90000
+ 0x23aa0000 0x23ab0000>;
+
+ dma_gbe: dma_gbe@0 {
+ reg = <0x2004000 0x100>,
+ <0x2004400 0x120>,
+ <0x2004800 0x300>,
+ <0x2004c00 0x120>,
+ <0x2005000 0x400>;
+ reg-names = "global", "txchan", "rxchan",
+ "txsched", "rxflow";
+ };
+
+ dma_xgbe: dma_xgbe@0 {
+ reg = <0x2fa1000 0x100>,
+ <0x2fa1400 0x200>,
+ <0x2fa1800 0x200>,
+ <0x2fa1c00 0x200>,
+ <0x2fa2000 0x400>;
+ reg-names = "global", "txchan", "rxchan",
+ "txsched", "rxflow";
+ };
+ };
+
+Navigator DMA client:
+Required properties:
+ - ti,navigator-dmas: List of one or more DMA specifiers, each consisting of
+ - A phandle pointing to DMA instance node
+ - A DMA channel number as a phandle arg.
+ - ti,navigator-dma-names: Contains dma channel name for each DMA specifier in
+ the 'ti,navigator-dmas' property.
+
+Example:
+
+ netcp: netcp@2090000 {
+ ..
+ ti,navigator-dmas = <&dma_gbe 22>,
+ <&dma_gbe 23>,
+ <&dma_gbe 8>;
+ ti,navigator-dma-names = "netrx0", "netrx1", "nettx";
+ ..
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
new file mode 100644
index 000000000000..d8e8cdb733f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -0,0 +1,232 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+
+Required properties:
+- compatible : Must be "ti,keystone-navigator-qmss";
+- clocks : phandle to the reference clock for this device.
+- queue-range : <start number> total range of queue numbers for the device.
+- linkram0 : <address size> for internal link ram, where size is the total
+ link ram entries.
+- linkram1 : <address size> for external link ram, where size is the total
+ external link ram entries. If the address is specified as "0"
+ driver will allocate memory.
+- qmgrs : child node describing the individual queue managers on the
+ SoC. On keystone 1 devices there should be only one node.
+ On keystone 2 devices there can be more than 1 node.
+ -- managed-queues : the actual queues managed by each queue manager
+ instance, specified as <"base queue #" "# of queues">.
+ -- reg : Address and size of the register set for the device.
+ Register regions should be specified in the following
+ order
+ - Queue Peek region.
+ - Queue status RAM.
+ - Queue configuration region.
+ - Descriptor memory setup region.
+ - Queue Management/Queue Proxy region for queue Push.
+ - Queue Management/Queue Proxy region for queue Pop.
+- queue-pools : child node classifying the queue ranges into pools.
+ Queue ranges are grouped into 3 type of pools:
+ - qpend : pool of qpend(interruptible) queues
+ - general-purpose : pool of general queues, primarly used
+ as free descriptor queues or the
+ transmit DMA queues.
+ - accumulator : pool of queues on PDSP accumulator channel
+ Each range can have the following properties:
+ -- qrange : number of queues to use per queue range, specified as
+ <"base queue #" "# of queues">.
+ -- interrupts : Optional property to specify the interrupt mapping
+ for interruptible queues. The driver additionaly sets
+ the interrupt affinity hint based on the cpu mask.
+ -- qalloc-by-id : Optional property to specify that the queues in this
+ range can only be allocated by queue id.
+ -- accumulator : Accumulator channel specification. Any of the PDSPs in
+ QMSS can be loaded with the accumulator firmware. The
+ accumulator firmware’s job is to poll a select number of
+ queues looking for descriptors that have been pushed
+ into them. Descriptors are popped from the queue and
+ placed in a buffer provided by the host. When the list
+ becomes full or a programmed time period expires, the
+ accumulator triggers an interrupt to the host to read
+ the buffer for descriptor information. This firmware
+ comes in 16, 32, and 48 channel builds. Each of these
+ channels can be configured to monitor 32 contiguous
+ queues. Accumulator channel property is specified as:
+ <pdsp-id, channel, entries, pacing mode, latency>
+ pdsp-id : QMSS PDSP running accumulator firmware
+ on which the channel has to be
+ configured
+ channel : Accumulator channel number
+ entries : Size of the accumulator descriptor list
+ pacing mode : Interrupt pacing mode
+ 0 : None, i.e interrupt on list full only
+ 1 : Time delay since last interrupt
+ 2 : Time delay since first new packet
+ 3 : Time delay since last new packet
+ latency : time to delay the interrupt, specified
+ in microseconds.
+ -- multi-queue : Optional property to specify that the channel has to
+ monitor upto 32 queues starting at the base queue #.
+- descriptor-regions : child node describing the memory regions for keystone
+ navigator packet DMA descriptors. The memory for
+ descriptors will be allocated by the driver.
+ -- id : region number in QMSS.
+ -- region-spec : specifies the number of descriptors in the
+ region, specified as
+ <"# of descriptors" "descriptor size">.
+ -- link-index : start index, i.e. index of the first
+ descriptor in the region.
+
+Optional properties:
+- dma-coherent : Present if DMA operations are coherent.
+- pdsps : child node describing the PDSP configuration.
+ -- firmware : firmware to be loaded on the PDSP.
+ -- id : the qmss pdsp that will run the firmware.
+ -- reg : Address and size of the register set for the PDSP.
+ Register regions should be specified in the following
+ order
+ - PDSP internal RAM region.
+ - PDSP control/status region registers.
+ - QMSS interrupt distributor registers.
+ - PDSP command interface region.
+
+Example:
+
+qmss: qmss@2a40000 {
+ compatible = "ti,keystone-qmss";
+ dma-coherent;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&chipclk13>;
+ ranges;
+ queue-range = <0 0x4000>;
+ linkram0 = <0x100000 0x8000>;
+ linkram1 = <0x0 0x10000>;
+
+ qmgrs {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ qmgr0 {
+ managed-queues = <0 0x2000>;
+ reg = <0x2a40000 0x20000>,
+ <0x2a06000 0x400>,
+ <0x2a02000 0x1000>,
+ <0x2a03000 0x1000>,
+ <0x23a80000 0x20000>,
+ <0x2a80000 0x20000>;
+ };
+
+ qmgr1 {
+ managed-queues = <0x2000 0x2000>;
+ reg = <0x2a60000 0x20000>,
+ <0x2a06400 0x400>,
+ <0x2a04000 0x1000>,
+ <0x2a05000 0x1000>,
+ <0x23aa0000 0x20000>,
+ <0x2aa0000 0x20000>;
+ };
+ };
+ queue-pools {
+ qpend {
+ qpend-0 {
+ qrange = <658 8>;
+ interrupts =<0 40 0xf04 0 41 0xf04 0 42 0xf04
+ 0 43 0xf04 0 44 0xf04 0 45 0xf04
+ 0 46 0xf04 0 47 0xf04>;
+ };
+ qpend-1 {
+ qrange = <8704 16>;
+ interrupts = <0 48 0xf04 0 49 0xf04 0 50 0xf04
+ 0 51 0xf04 0 52 0xf04 0 53 0xf04
+ 0 54 0xf04 0 55 0xf04 0 56 0xf04
+ 0 57 0xf04 0 58 0xf04 0 59 0xf04
+ 0 60 0xf04 0 61 0xf04 0 62 0xf04
+ 0 63 0xf04>;
+ qalloc-by-id;
+ };
+ qpend-2 {
+ qrange = <8720 16>;
+ interrupts = <0 64 0xf04 0 65 0xf04 0 66 0xf04
+ 0 59 0xf04 0 68 0xf04 0 69 0xf04
+ 0 70 0xf04 0 71 0xf04 0 72 0xf04
+ 0 73 0xf04 0 74 0xf04 0 75 0xf04
+ 0 76 0xf04 0 77 0xf04 0 78 0xf04
+ 0 79 0xf04>;
+ };
+ };
+ general-purpose {
+ gp-0 {
+ qrange = <4000 64>;
+ };
+ netcp-tx {
+ qrange = <640 9>;
+ qalloc-by-id;
+ };
+ };
+ accumulator {
+ acc-0 {
+ qrange = <128 32>;
+ accumulator = <0 36 16 2 50>;
+ interrupts = <0 215 0xf01>;
+ multi-queue;
+ qalloc-by-id;
+ };
+ acc-1 {
+ qrange = <160 32>;
+ accumulator = <0 37 16 2 50>;
+ interrupts = <0 216 0xf01>;
+ multi-queue;
+ };
+ acc-2 {
+ qrange = <192 32>;
+ accumulator = <0 38 16 2 50>;
+ interrupts = <0 217 0xf01>;
+ multi-queue;
+ };
+ acc-3 {
+ qrange = <224 32>;
+ accumulator = <0 39 16 2 50>;
+ interrupts = <0 218 0xf01>;
+ multi-queue;
+ };
+ };
+ };
+ descriptor-regions {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ region-12 {
+ id = <12>;
+ region-spec = <8192 128>; /* num_desc desc_size */
+ link-index = <0x4000>;
+ };
+ };
+ pdsps {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ pdsp0@0x2a10000 {
+ firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
+ reg = <0x2a10000 0x1000>,
+ <0x2a0f000 0x100>,
+ <0x2a0c000 0x3c8>,
+ <0x2a20000 0x4000>;
+ id = <0>;
+ };
+ };
+}; /* qmss */