[RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

Hi everyone,

This is an experimental set of patches for populating the flattened
device tree (fdt) data from the actual set of qdevs in the platform.
I'm not expecting this to get merged anytime soon, but I wanted to get
it out there to solicit comments.  My target for this is testing
device tree support on ARM.

The approach is by no means final, and there are still a number of
details to work out, but I've got it working well with the versatile
platform and I've got the kernel using fdt data to bind against the
smc91x device driver.  I'll be posting my associated kernel patches
real-soon-now.

This series is based on Jeremy Kerr's device tree branch found here:

git://kernel.ubuntu.com/jk/dt/qemu.git

Cheers,
g.

---

Grant Likely (7):
      devicetree: Add fdt_populate hook to smc91x device
      devicetree: Add fdt_populate hook to pl011 device
      devicetree: Add helper to register devices with an fdt_populate hook
      devicetree: Add sysbus fdt populate hooks.
      devicetree: add helper for determining IRQ properties in the device tree
      devicetree: auto-populate the device tree with qdev data
      devicetree: Add 8k instead of double dtb size when reserving extra memory


 device_tree.c  |    4 +-
 hw/arm_boot.c  |    3 +
 hw/pl011.c     |   29 ++++++++++--
 hw/qdev.c      |  139 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h      |    9 ++++
 hw/smc91c111.c |   20 ++++++++
 hw/sysbus.c    |  107 +++++++++++++++++++++++++++++++++++++++++++
 hw/sysbus.h    |    4 ++
 8 files changed, 309 insertions(+), 6 deletions(-)

-- 
Signature

[Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

Hi everyone,

This is an experimental set of patches for populating the flattened
device tree (fdt) data from the actual set of qdevs in the platform.
I'm not expecting this to get merged anytime soon, but I wanted to get
it out there to solicit comments.  My target for this is testing
device tree support on ARM.

The approach is by no means final, and there are still a number of
details to work out, but I've got it working well with the versatile
platform and I've got the kernel using fdt data to bind against the
smc91x device driver.  I'll be posting my associated kernel patches
real-soon-now.

This series is based on Jeremy Kerr's device tree branch found here:

git://kernel.ubuntu.com/jk/dt/qemu.git

Cheers,
g.

---

Grant Likely (7):
      devicetree: Add fdt_populate hook to smc91x device
      devicetree: Add fdt_populate hook to pl011 device
      devicetree: Add helper to register devices with an fdt_populate hook
      devicetree: Add sysbus fdt populate hooks.
      devicetree: add helper for determining IRQ properties in the device tree
      devicetree: auto-populate the device tree with qdev data
      devicetree: Add 8k instead of double dtb size when reserving extra memory


 device_tree.c  |    4 +-
 hw/arm_boot.c  |    3 +
 hw/pl011.c     |   29 ++++++++++--
 hw/qdev.c      |  139 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h      |    9 ++++
 hw/smc91c111.c |   20 ++++++++
 hw/sysbus.c    |  107 +++++++++++++++++++++++++++++++++++++++++++
 hw/sysbus.h    |    4 ++
 8 files changed, 309 insertions(+), 6 deletions(-)

-- 
Signature

[RFC PATCH 1/7] devicetree: Add 8k instead of double dtb size when reserving extra memory

[Grant Likely]

If a small 'seed' dtb file is loaded into qemu and then heavily modified
(say for runtime population of all the device nodes), then 2x the dtb
size turns out not to be very much.

This patch changes the device tree loading code to add a fixed 8k of
additional space to the dtb buffer.

Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---

 device_tree.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/device_tree.c b/device_tree.c
index 426a631..bad4810 100644
--- a/device_tree.c
+++ b/device_tree.c
@@ -41,8 +41,8 @@ void *load_device_tree(const char *filename_path, int *sizep)
         goto fail;
     }
 
-    /* Expand to 2x size to give enough room for manipulation.  */
-    dt_size *= 2;
+    /* Expand size to give enough room for manipulation.  */
+    dt_size += 8 * 1024;
     /* First allocate space in qemu for device tree */
     fdt = qemu_mallocz(dt_size);

[Qemu-devel] [RFC PATCH 1/7] devicetree: Add 8k instead of double dtb size when reserving extra memory

[Grant Likely]

If a small 'seed' dtb file is loaded into qemu and then heavily modified
(say for runtime population of all the device nodes), then 2x the dtb
size turns out not to be very much.

This patch changes the device tree loading code to add a fixed 8k of
additional space to the dtb buffer.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 device_tree.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/device_tree.c b/device_tree.c
index 426a631..bad4810 100644
--- a/device_tree.c
+++ b/device_tree.c
@@ -41,8 +41,8 @@ void *load_device_tree(const char *filename_path, int *sizep)
         goto fail;
     }
 
-    /* Expand to 2x size to give enough room for manipulation.  */
-    dt_size *= 2;
+    /* Expand size to give enough room for manipulation.  */
+    dt_size += 8 * 1024;
     /* First allocate space in qemu for device tree */
     fdt = qemu_mallocz(dt_size);
 

Re: [Qemu-devel] [RFC PATCH 1/7] devicetree: Add 8k instead of double dtb size when reserving extra memory

[Paul Brook]

> If a small 'seed' dtb file is loaded into qemu and then heavily modified
> (say for runtime population of all the device nodes), then 2x the dtb
> size turns out not to be very much.
> 
> This patch changes the device tree loading code to add a fixed 8k of
> additional space to the dtb buffer.

In that case you almost certainly want double+8k. Or have the calleee tell you 
how much they're expecting to grow the tree.

Paul

Re: [Qemu-devel] [RFC PATCH 1/7] devicetree: Add 8k instead of double dtb size when reserving extra memory

[Paul Brook]

> If a small 'seed' dtb file is loaded into qemu and then heavily modified
> (say for runtime population of all the device nodes), then 2x the dtb
> size turns out not to be very much.
> 
> This patch changes the device tree loading code to add a fixed 8k of
> additional space to the dtb buffer.

In that case you almost certainly want double+8k. Or have the calleee tell you 
how much they're expecting to grow the tree.

Paul

Re: [Qemu-devel] [RFC PATCH 1/7] devicetree: Add 8k instead of double dtb size when reserving extra memory

[Grant Likely]

On Fri, Apr 9, 2010 at 6:00 AM, Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> wrote:
>> If a small 'seed' dtb file is loaded into qemu and then heavily modified
>> (say for runtime population of all the device nodes), then 2x the dtb
>> size turns out not to be very much.
>>
>> This patch changes the device tree loading code to add a fixed 8k of
>> additional space to the dtb buffer.
>
> In that case you almost certainly want double+8k. Or have the calleee tell you
> how much they're expecting to grow the tree.

Good point.  I think I like the latter option.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [Qemu-devel] [RFC PATCH 1/7] devicetree: Add 8k instead of double dtb size when reserving extra memory

[Grant Likely]

On Fri, Apr 9, 2010 at 6:00 AM, Paul Brook <paul@codesourcery.com> wrote:
>> If a small 'seed' dtb file is loaded into qemu and then heavily modified
>> (say for runtime population of all the device nodes), then 2x the dtb
>> size turns out not to be very much.
>>
>> This patch changes the device tree loading code to add a fixed 8k of
>> additional space to the dtb buffer.
>
> In that case you almost certainly want double+8k. Or have the calleee tell you
> how much they're expecting to grow the tree.

Good point.  I think I like the latter option.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[RFC PATCH 2/7] devicetree: auto-populate the device tree with qdev data

[Grant Likely]

This patch adds hooks to the qemu device model to auto-generate device
tree nodes from the registered qemu devices, and calls the device tree
populate hook when booting ARM platforms.

Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---

 hw/arm_boot.c |    3 ++
 hw/qdev.c     |   91 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h     |    8 +++++
 3 files changed, 102 insertions(+), 0 deletions(-)

diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 740a446..33c7356 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -13,6 +13,7 @@
 #include "sysemu.h"
 #include "loader.h"
 #include "elf.h"
+#include "qdev.h"
 
 #ifdef CONFIG_FDT
 #include "device_tree.h"
@@ -211,6 +212,8 @@ static int load_dtb(target_phys_addr_t addr, struct arm_boot_info *binfo)
     }
     qemu_free(filename);
 
+    qdev_fdt_populate(fdt);
+
     rc = qemu_devtree_setprop(fdt, "/memory", "reg", mem_reg_property,
                                sizeof(mem_reg_property));
     if (rc < 0)
diff --git a/hw/qdev.c b/hw/qdev.c
index d19d531..b177c3d 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -748,3 +748,94 @@ void do_device_del(Monitor *mon, const QDict *qdict)
     }
     qdev_unplug(dev);
 }
+
+#ifdef CONFIG_FDT
+#include <libfdt.h>
+static int qbus_fdt_add_bus(void *fdt, BusState *bus, int dev_offset);
+static int qdev_fdt_add_device(void *fdt, DeviceState *dev, int bus_offset)
+{
+    BusState *child;
+    int dev_offset, rc;
+    char name[sizeof(dev->info->name) + 9];
+    static int unique = 0;
+
+    sprintf(name, "%s@%x", dev->info->name, unique++);
+    dev_offset = fdt_add_subnode(fdt, bus_offset, name);
+    if (dev_offset < 0) {
+        qemu_error("Couldn't add FDT node for device %s\n", dev->info->name);
+        return dev_offset;
+    }
+
+    rc = fdt_setprop_cell(fdt, dev_offset, "phandle", (uint64_t)dev);
+    if (rc < 0) {
+        qemu_error("Could not add phandle property to device %s\n",
+                   dev->info->name);
+        return rc;
+    }
+
+    if (dev->info->fdt_populate) {
+        int rc = dev->info->fdt_populate(dev, fdt, dev_offset);
+        if (rc < 0) {
+            qemu_error("dev->info->fdt_populate() failed on %s\n",
+                       dev->info->name);
+            return rc;
+        }
+    }
+
+    QLIST_FOREACH(child, &dev->child_bus, sibling) {
+        int rc = qbus_fdt_add_bus(fdt, child, dev_offset);
+        if (rc < 0) {
+            qemu_error("qbus_fdt_add_bus() failed on dev:%s bus:%s\n",
+                       dev->info->name, child->info->name);
+            return rc;
+        }
+    }
+
+    return dev_offset;
+}
+
+static int qbus_fdt_add_bus(void *fdt, BusState *bus, int dev_offset)
+{
+    struct DeviceState *dev;
+    int bus_offset;
+
+    bus_offset = fdt_add_subnode(fdt, dev_offset, bus->name);
+    if (bus_offset < 0) {
+        qemu_error("Couldn't add FDT node for bus %s\n", bus->name);
+        return bus_offset;
+    }
+
+    if (bus->info->fdt_populate) {
+        int rc = bus->info->fdt_populate(bus, fdt, bus_offset);
+        if (rc < 0) {
+            qemu_error("bus->info->fdt_populate() failed on %s\n",
+                       bus->info->name);
+            return rc;
+        }
+    }
+
+    QLIST_FOREACH(dev, &bus->children, sibling) {
+        int rc = qdev_fdt_add_device(fdt, dev, bus_offset);
+        if (rc < 0) {
+            qemu_error("qbus_fdt_add_device() failed on bus:%s dev:%s\n",
+                       bus->info->name, dev->info->name);
+            return rc;
+        }
+    }
+
+    return bus_offset;
+}
+
+int qdev_fdt_populate(void *fdt)
+{
+    int offset = fdt_path_offset(fdt, "/");
+    if (offset < 0)
+        return offset;
+
+    if (main_system_bus)
+        qbus_fdt_add_bus(fdt, main_system_bus, offset);
+
+    return offset;
+}
+#endif /* CONFIG_FDT */
+
diff --git a/hw/qdev.h b/hw/qdev.h
index 41642ee..d549d43 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -43,10 +43,12 @@ struct DeviceState {
 };
 
 typedef void (*bus_dev_printfn)(Monitor *mon, DeviceState *dev, int indent);
+typedef int (*bus_fdt_populatefn)(BusState *bus, void *fdt, int offset);
 struct BusInfo {
     const char *name;
     size_t size;
     bus_dev_printfn print_dev;
+    bus_fdt_populatefn fdt_populate;
     Property *props;
 };
 
@@ -119,6 +121,7 @@ BusState *qdev_get_child_bus(DeviceState *dev, const char *name);
 typedef int (*qdev_initfn)(DeviceState *dev, DeviceInfo *info);
 typedef int (*qdev_event)(DeviceState *dev);
 typedef void (*qdev_resetfn)(DeviceState *dev);
+typedef int (*qdev_fdt_populatefn)(DeviceState *dev, void *fdt, int offset);
 
 struct DeviceInfo {
     const char *name;
@@ -130,6 +133,7 @@ struct DeviceInfo {
 
     /* callbacks */
     qdev_resetfn reset;
+    qdev_fdt_populatefn fdt_populate;
 
     /* device state */
     const VMStateDescription *vmsd;
@@ -272,4 +276,8 @@ void qdev_prop_set_compat(DeviceState *dev);
 /* This is a nasty hack to allow passing a NULL bus to qdev_create.  */
 extern struct BusInfo system_bus_info;
 
+#ifdef CONFIG_FDT
+int qdev_fdt_populate(void *fdt);
+#endif
+
 #endif

[Qemu-devel] [RFC PATCH 2/7] devicetree: auto-populate the device tree with qdev data

[Grant Likely]

This patch adds hooks to the qemu device model to auto-generate device
tree nodes from the registered qemu devices, and calls the device tree
populate hook when booting ARM platforms.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 hw/arm_boot.c |    3 ++
 hw/qdev.c     |   91 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h     |    8 +++++
 3 files changed, 102 insertions(+), 0 deletions(-)

diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 740a446..33c7356 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -13,6 +13,7 @@
 #include "sysemu.h"
 #include "loader.h"
 #include "elf.h"
+#include "qdev.h"
 
 #ifdef CONFIG_FDT
 #include "device_tree.h"
@@ -211,6 +212,8 @@ static int load_dtb(target_phys_addr_t addr, struct arm_boot_info *binfo)
     }
     qemu_free(filename);
 
+    qdev_fdt_populate(fdt);
+
     rc = qemu_devtree_setprop(fdt, "/memory", "reg", mem_reg_property,
                                sizeof(mem_reg_property));
     if (rc < 0)
diff --git a/hw/qdev.c b/hw/qdev.c
index d19d531..b177c3d 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -748,3 +748,94 @@ void do_device_del(Monitor *mon, const QDict *qdict)
     }
     qdev_unplug(dev);
 }
+
+#ifdef CONFIG_FDT
+#include <libfdt.h>
+static int qbus_fdt_add_bus(void *fdt, BusState *bus, int dev_offset);
+static int qdev_fdt_add_device(void *fdt, DeviceState *dev, int bus_offset)
+{
+    BusState *child;
+    int dev_offset, rc;
+    char name[sizeof(dev->info->name) + 9];
+    static int unique = 0;
+
+    sprintf(name, "%s@%x", dev->info->name, unique++);
+    dev_offset = fdt_add_subnode(fdt, bus_offset, name);
+    if (dev_offset < 0) {
+        qemu_error("Couldn't add FDT node for device %s\n", dev->info->name);
+        return dev_offset;
+    }
+
+    rc = fdt_setprop_cell(fdt, dev_offset, "phandle", (uint64_t)dev);
+    if (rc < 0) {
+        qemu_error("Could not add phandle property to device %s\n",
+                   dev->info->name);
+        return rc;
+    }
+
+    if (dev->info->fdt_populate) {
+        int rc = dev->info->fdt_populate(dev, fdt, dev_offset);
+        if (rc < 0) {
+            qemu_error("dev->info->fdt_populate() failed on %s\n",
+                       dev->info->name);
+            return rc;
+        }
+    }
+
+    QLIST_FOREACH(child, &dev->child_bus, sibling) {
+        int rc = qbus_fdt_add_bus(fdt, child, dev_offset);
+        if (rc < 0) {
+            qemu_error("qbus_fdt_add_bus() failed on dev:%s bus:%s\n",
+                       dev->info->name, child->info->name);
+            return rc;
+        }
+    }
+
+    return dev_offset;
+}
+
+static int qbus_fdt_add_bus(void *fdt, BusState *bus, int dev_offset)
+{
+    struct DeviceState *dev;
+    int bus_offset;
+
+    bus_offset = fdt_add_subnode(fdt, dev_offset, bus->name);
+    if (bus_offset < 0) {
+        qemu_error("Couldn't add FDT node for bus %s\n", bus->name);
+        return bus_offset;
+    }
+
+    if (bus->info->fdt_populate) {
+        int rc = bus->info->fdt_populate(bus, fdt, bus_offset);
+        if (rc < 0) {
+            qemu_error("bus->info->fdt_populate() failed on %s\n",
+                       bus->info->name);
+            return rc;
+        }
+    }
+
+    QLIST_FOREACH(dev, &bus->children, sibling) {
+        int rc = qdev_fdt_add_device(fdt, dev, bus_offset);
+        if (rc < 0) {
+            qemu_error("qbus_fdt_add_device() failed on bus:%s dev:%s\n",
+                       bus->info->name, dev->info->name);
+            return rc;
+        }
+    }
+
+    return bus_offset;
+}
+
+int qdev_fdt_populate(void *fdt)
+{
+    int offset = fdt_path_offset(fdt, "/");
+    if (offset < 0)
+        return offset;
+
+    if (main_system_bus)
+        qbus_fdt_add_bus(fdt, main_system_bus, offset);
+
+    return offset;
+}
+#endif /* CONFIG_FDT */
+
diff --git a/hw/qdev.h b/hw/qdev.h
index 41642ee..d549d43 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -43,10 +43,12 @@ struct DeviceState {
 };
 
 typedef void (*bus_dev_printfn)(Monitor *mon, DeviceState *dev, int indent);
+typedef int (*bus_fdt_populatefn)(BusState *bus, void *fdt, int offset);
 struct BusInfo {
     const char *name;
     size_t size;
     bus_dev_printfn print_dev;
+    bus_fdt_populatefn fdt_populate;
     Property *props;
 };
 
@@ -119,6 +121,7 @@ BusState *qdev_get_child_bus(DeviceState *dev, const char *name);
 typedef int (*qdev_initfn)(DeviceState *dev, DeviceInfo *info);
 typedef int (*qdev_event)(DeviceState *dev);
 typedef void (*qdev_resetfn)(DeviceState *dev);
+typedef int (*qdev_fdt_populatefn)(DeviceState *dev, void *fdt, int offset);
 
 struct DeviceInfo {
     const char *name;
@@ -130,6 +133,7 @@ struct DeviceInfo {
 
     /* callbacks */
     qdev_resetfn reset;
+    qdev_fdt_populatefn fdt_populate;
 
     /* device state */
     const VMStateDescription *vmsd;
@@ -272,4 +276,8 @@ void qdev_prop_set_compat(DeviceState *dev);
 /* This is a nasty hack to allow passing a NULL bus to qdev_create.  */
 extern struct BusInfo system_bus_info;
 
+#ifdef CONFIG_FDT
+int qdev_fdt_populate(void *fdt);
+#endif
+
 #endif

[RFC PATCH 3/7] devicetree: add helper for determining IRQ properties in the device tree

[Grant Likely]

This patch adds the qbus_fdt_irq_to_number() helper to determine the
interrupt number and phandle needed for adding the interrupts property
to a device node in the device tree.

Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---

 hw/qdev.c |   48 ++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h |    1 +
 2 files changed, 49 insertions(+), 0 deletions(-)

diff --git a/hw/qdev.c b/hw/qdev.c
index b177c3d..ed68a70 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -751,6 +751,54 @@ void do_device_del(Monitor *mon, const QDict *qdict)
 
 #ifdef CONFIG_FDT
 #include <libfdt.h>
+/* Iterate over entire device list looking for the interrupt parent */
+static int __qbus_fdt_irq_to_number(qemu_irq irq, BusState *bus,
+                                    uint32_t *phandle);
+static int __qbus_fdt_irq_to_number_dev(qemu_irq irq, DeviceState *dev,
+                                        uint32_t *phandle)
+{
+    BusState *child;
+    int rc, i;
+
+    for (i = 0; i < dev->num_gpio_in; i++) {
+        if (irq == qdev_get_gpio_in(dev, i)) {
+            if (phandle)
+                *phandle = (uint64_t)dev;
+            return i;
+        }
+    }
+
+    QLIST_FOREACH(child, &dev->child_bus, sibling) {
+        rc = __qbus_fdt_irq_to_number(irq, child, phandle);
+        if (rc >= 0)
+            return rc;
+    }
+
+    return -1;
+}
+
+static int __qbus_fdt_irq_to_number(qemu_irq irq, BusState *bus,
+                                    uint32_t *phandle)
+{
+    struct DeviceState *dev;
+    int rc;
+
+    QLIST_FOREACH(dev, &bus->children, sibling) {
+        rc = __qbus_fdt_irq_to_number_dev(irq, dev, phandle);
+        if (rc >= 0)
+            return rc;
+    }
+
+    return -1;
+}
+
+int qbus_fdt_irq_to_number(qemu_irq irq, uint32_t *phandle)
+{
+    return __qbus_fdt_irq_to_number(irq, main_system_bus, phandle);
+}
+
+
+
 static int qbus_fdt_add_bus(void *fdt, BusState *bus, int dev_offset);
 static int qdev_fdt_add_device(void *fdt, DeviceState *dev, int bus_offset)
 {
diff --git a/hw/qdev.h b/hw/qdev.h
index d549d43..84544c7 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -277,6 +277,7 @@ void qdev_prop_set_compat(DeviceState *dev);
 extern struct BusInfo system_bus_info;
 
 #ifdef CONFIG_FDT
+int qbus_fdt_irq_to_number(qemu_irq irq, uint32_t *phandle);
 int qdev_fdt_populate(void *fdt);
 #endif

[Qemu-devel] [RFC PATCH 3/7] devicetree: add helper for determining IRQ properties in the device tree

[Grant Likely]

This patch adds the qbus_fdt_irq_to_number() helper to determine the
interrupt number and phandle needed for adding the interrupts property
to a device node in the device tree.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 hw/qdev.c |   48 ++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h |    1 +
 2 files changed, 49 insertions(+), 0 deletions(-)

diff --git a/hw/qdev.c b/hw/qdev.c
index b177c3d..ed68a70 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -751,6 +751,54 @@ void do_device_del(Monitor *mon, const QDict *qdict)
 
 #ifdef CONFIG_FDT
 #include <libfdt.h>
+/* Iterate over entire device list looking for the interrupt parent */
+static int __qbus_fdt_irq_to_number(qemu_irq irq, BusState *bus,
+                                    uint32_t *phandle);
+static int __qbus_fdt_irq_to_number_dev(qemu_irq irq, DeviceState *dev,
+                                        uint32_t *phandle)
+{
+    BusState *child;
+    int rc, i;
+
+    for (i = 0; i < dev->num_gpio_in; i++) {
+        if (irq == qdev_get_gpio_in(dev, i)) {
+            if (phandle)
+                *phandle = (uint64_t)dev;
+            return i;
+        }
+    }
+
+    QLIST_FOREACH(child, &dev->child_bus, sibling) {
+        rc = __qbus_fdt_irq_to_number(irq, child, phandle);
+        if (rc >= 0)
+            return rc;
+    }
+
+    return -1;
+}
+
+static int __qbus_fdt_irq_to_number(qemu_irq irq, BusState *bus,
+                                    uint32_t *phandle)
+{
+    struct DeviceState *dev;
+    int rc;
+
+    QLIST_FOREACH(dev, &bus->children, sibling) {
+        rc = __qbus_fdt_irq_to_number_dev(irq, dev, phandle);
+        if (rc >= 0)
+            return rc;
+    }
+
+    return -1;
+}
+
+int qbus_fdt_irq_to_number(qemu_irq irq, uint32_t *phandle)
+{
+    return __qbus_fdt_irq_to_number(irq, main_system_bus, phandle);
+}
+
+
+
 static int qbus_fdt_add_bus(void *fdt, BusState *bus, int dev_offset);
 static int qdev_fdt_add_device(void *fdt, DeviceState *dev, int bus_offset)
 {
diff --git a/hw/qdev.h b/hw/qdev.h
index d549d43..84544c7 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -277,6 +277,7 @@ void qdev_prop_set_compat(DeviceState *dev);
 extern struct BusInfo system_bus_info;
 
 #ifdef CONFIG_FDT
+int qbus_fdt_irq_to_number(qemu_irq irq, uint32_t *phandle);
 int qdev_fdt_populate(void *fdt);
 #endif
 

[RFC PATCH 4/7] devicetree: Add sysbus fdt populate hooks.

[Grant Likely]

This patch adds sysbus specific fdt_populate hooks to fill sysbus
device nodes with 'reg' and 'interrupts' properties, and to
provide 'ranges' properties for correct address translations.

Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---

 hw/sysbus.c |   92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/sysbus.h |    2 +
 2 files changed, 94 insertions(+), 0 deletions(-)

diff --git a/hw/sysbus.c b/hw/sysbus.c
index 1f7f138..861572f 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -22,11 +22,16 @@
 #include "monitor.h"
 
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static int sysbus_fdt_populate_node(DeviceState *dev, void *fdt, int offset);
+static int sysbus_fdt_populate_bus(BusState *bus, void *fdt, int offset);
 
 struct BusInfo system_bus_info = {
     .name       = "System",
     .size       = sizeof(BusState),
     .print_dev  = sysbus_dev_print,
+#ifdef CONFIG_FDT
+    .fdt_populate = sysbus_fdt_populate_bus,
+#endif /* CONFIG_FDT */
 };
 
 void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq)
@@ -115,6 +120,7 @@ static int sysbus_device_init(DeviceState *dev, DeviceInfo *base)
 void sysbus_register_withprop(SysBusDeviceInfo *info)
 {
     info->qdev.init = sysbus_device_init;
+    info->qdev.fdt_populate = sysbus_fdt_populate_node;
     info->qdev.bus_info = &system_bus_info;
 
     assert(info->qdev.size >= sizeof(SysBusDevice));
@@ -170,3 +176,89 @@ static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
                        indent, "", s->mmio[i].addr, s->mmio[i].size);
     }
 }
+
+#ifdef CONFIG_FDT
+#include <libfdt.h>
+static int sysbus_fdt_populate_bus(BusState *bus, void *fdt, int offset)
+{
+    int rc;
+
+    rc = fdt_setprop_string(fdt, offset, "compatible", "simple-bus");
+    if (rc < 0)
+        return rc;
+
+    rc = fdt_setprop_cell(fdt, offset, "#address-cells", 1);
+    if (rc < 0)
+        return rc;
+    rc = fdt_setprop_cell(fdt, offset, "#size-cells", 1);
+    if (rc < 0)
+        return rc;
+    rc = fdt_setprop(fdt, offset, "ranges", NULL, 0);
+    if (rc < 0)
+        return rc;
+    return 0;
+}
+
+static int sysbus_fdt_populate_node(DeviceState *dev, void *fdt, int offset)
+{
+    SysBusDevice *s = sysbus_from_qdev(dev);
+    SysBusDeviceInfo *info = container_of(dev->info, SysBusDeviceInfo, qdev);
+
+    uint32_t reg_data[s->num_mmio * 2]; /* one cell each address and size */
+    uint32_t irq_data[s->num_irq];
+    uint32_t *pos;
+    uint32_t phandle;
+    int i, rc;
+
+    /* Create 'reg' property */
+    pos = reg_data;
+    for (i = 0; i < s->num_mmio; i++) {
+        /* By convention, the name is appended with '@<first reg addr>' */
+        if (i == 0) {
+            char n[sizeof(dev->info->name) + 10];
+            sprintf(n, "%s@%x", dev->info->name, (uint32_t)s->mmio[i].addr);
+            rc = fdt_set_name(fdt, offset, n);
+            if (rc < 0)
+                return rc;
+        }
+        *pos++ = cpu_to_be32(s->mmio[i].addr);
+        *pos++ = cpu_to_be32(s->mmio[i].size);
+    }
+    rc = fdt_setprop(fdt, offset, "reg", reg_data, sizeof(reg_data));
+    if (rc < 0)
+        return rc;
+
+    /* Is this an interrupt controller? */
+    if (dev->num_gpio_in) {
+        rc = fdt_setprop(fdt, offset, "interrupt-controller", NULL, 0);
+        if (rc < 0)
+            return rc;
+        rc = fdt_setprop_cell(fdt, offset, "#interrupt-cells", 1);
+        if (rc < 0)
+            return rc;
+    }
+
+    /* Create 'interrupts' property */
+    phandle = 0;
+    pos = irq_data;
+    for (i = 0; i < s->num_irq; i++) {
+        *pos++ = cpu_to_be32(qbus_fdt_irq_to_number(*s->irqp[i], &phandle));
+    }
+    if (phandle) {
+        rc = fdt_setprop_cell(fdt, offset, "interrupt-parent", phandle);
+        if (rc < 0)
+            return rc;
+        rc = fdt_setprop(fdt, offset, "interrupts", irq_data, sizeof(irq_data));
+        if (rc < 0)
+            return rc;
+    }
+
+    if (info->fdt_populate) {
+        rc = info->fdt_populate(s, fdt, offset);
+        if (rc < 0)
+            return rc;
+    }
+
+    return 0;
+}
+#endif /* CONFIG_FDT */
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 1a8f289..2c43191 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -26,6 +26,7 @@ struct SysBusDevice {
 };
 
 typedef int (*sysbus_initfn)(SysBusDevice *dev);
+typedef int (*sysbus_fdt_populatefn)(SysBusDevice *dev, void *fdt, int node_offset);
 
 /* Macros to compensate for lack of type inheritance in C.  */
 #define sysbus_from_qdev(dev) ((SysBusDevice *)(dev))
@@ -34,6 +35,7 @@ typedef int (*sysbus_initfn)(SysBusDevice *dev);
 typedef struct {
     DeviceInfo qdev;
     sysbus_initfn init;
+    sysbus_fdt_populatefn fdt_populate;
 } SysBusDeviceInfo;
 
 void sysbus_register_dev(const char *name, size_t size, sysbus_initfn init);

[Qemu-devel] [RFC PATCH 4/7] devicetree: Add sysbus fdt populate hooks.

[Grant Likely]

This patch adds sysbus specific fdt_populate hooks to fill sysbus
device nodes with 'reg' and 'interrupts' properties, and to
provide 'ranges' properties for correct address translations.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 hw/sysbus.c |   92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/sysbus.h |    2 +
 2 files changed, 94 insertions(+), 0 deletions(-)

diff --git a/hw/sysbus.c b/hw/sysbus.c
index 1f7f138..861572f 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -22,11 +22,16 @@
 #include "monitor.h"
 
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static int sysbus_fdt_populate_node(DeviceState *dev, void *fdt, int offset);
+static int sysbus_fdt_populate_bus(BusState *bus, void *fdt, int offset);
 
 struct BusInfo system_bus_info = {
     .name       = "System",
     .size       = sizeof(BusState),
     .print_dev  = sysbus_dev_print,
+#ifdef CONFIG_FDT
+    .fdt_populate = sysbus_fdt_populate_bus,
+#endif /* CONFIG_FDT */
 };
 
 void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq)
@@ -115,6 +120,7 @@ static int sysbus_device_init(DeviceState *dev, DeviceInfo *base)
 void sysbus_register_withprop(SysBusDeviceInfo *info)
 {
     info->qdev.init = sysbus_device_init;
+    info->qdev.fdt_populate = sysbus_fdt_populate_node;
     info->qdev.bus_info = &system_bus_info;
 
     assert(info->qdev.size >= sizeof(SysBusDevice));
@@ -170,3 +176,89 @@ static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
                        indent, "", s->mmio[i].addr, s->mmio[i].size);
     }
 }
+
+#ifdef CONFIG_FDT
+#include <libfdt.h>
+static int sysbus_fdt_populate_bus(BusState *bus, void *fdt, int offset)
+{
+    int rc;
+
+    rc = fdt_setprop_string(fdt, offset, "compatible", "simple-bus");
+    if (rc < 0)
+        return rc;
+
+    rc = fdt_setprop_cell(fdt, offset, "#address-cells", 1);
+    if (rc < 0)
+        return rc;
+    rc = fdt_setprop_cell(fdt, offset, "#size-cells", 1);
+    if (rc < 0)
+        return rc;
+    rc = fdt_setprop(fdt, offset, "ranges", NULL, 0);
+    if (rc < 0)
+        return rc;
+    return 0;
+}
+
+static int sysbus_fdt_populate_node(DeviceState *dev, void *fdt, int offset)
+{
+    SysBusDevice *s = sysbus_from_qdev(dev);
+    SysBusDeviceInfo *info = container_of(dev->info, SysBusDeviceInfo, qdev);
+
+    uint32_t reg_data[s->num_mmio * 2]; /* one cell each address and size */
+    uint32_t irq_data[s->num_irq];
+    uint32_t *pos;
+    uint32_t phandle;
+    int i, rc;
+
+    /* Create 'reg' property */
+    pos = reg_data;
+    for (i = 0; i < s->num_mmio; i++) {
+        /* By convention, the name is appended with '@<first reg addr>' */
+        if (i == 0) {
+            char n[sizeof(dev->info->name) + 10];
+            sprintf(n, "%s@%x", dev->info->name, (uint32_t)s->mmio[i].addr);
+            rc = fdt_set_name(fdt, offset, n);
+            if (rc < 0)
+                return rc;
+        }
+        *pos++ = cpu_to_be32(s->mmio[i].addr);
+        *pos++ = cpu_to_be32(s->mmio[i].size);
+    }
+    rc = fdt_setprop(fdt, offset, "reg", reg_data, sizeof(reg_data));
+    if (rc < 0)
+        return rc;
+
+    /* Is this an interrupt controller? */
+    if (dev->num_gpio_in) {
+        rc = fdt_setprop(fdt, offset, "interrupt-controller", NULL, 0);
+        if (rc < 0)
+            return rc;
+        rc = fdt_setprop_cell(fdt, offset, "#interrupt-cells", 1);
+        if (rc < 0)
+            return rc;
+    }
+
+    /* Create 'interrupts' property */
+    phandle = 0;
+    pos = irq_data;
+    for (i = 0; i < s->num_irq; i++) {
+        *pos++ = cpu_to_be32(qbus_fdt_irq_to_number(*s->irqp[i], &phandle));
+    }
+    if (phandle) {
+        rc = fdt_setprop_cell(fdt, offset, "interrupt-parent", phandle);
+        if (rc < 0)
+            return rc;
+        rc = fdt_setprop(fdt, offset, "interrupts", irq_data, sizeof(irq_data));
+        if (rc < 0)
+            return rc;
+    }
+
+    if (info->fdt_populate) {
+        rc = info->fdt_populate(s, fdt, offset);
+        if (rc < 0)
+            return rc;
+    }
+
+    return 0;
+}
+#endif /* CONFIG_FDT */
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 1a8f289..2c43191 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -26,6 +26,7 @@ struct SysBusDevice {
 };
 
 typedef int (*sysbus_initfn)(SysBusDevice *dev);
+typedef int (*sysbus_fdt_populatefn)(SysBusDevice *dev, void *fdt, int node_offset);
 
 /* Macros to compensate for lack of type inheritance in C.  */
 #define sysbus_from_qdev(dev) ((SysBusDevice *)(dev))
@@ -34,6 +35,7 @@ typedef int (*sysbus_initfn)(SysBusDevice *dev);
 typedef struct {
     DeviceInfo qdev;
     sysbus_initfn init;
+    sysbus_fdt_populatefn fdt_populate;
 } SysBusDeviceInfo;
 
 void sysbus_register_dev(const char *name, size_t size, sysbus_initfn init);

[RFC PATCH 5/7] devicetree: Add helper to register devices with an fdt_populate hook

[Grant Likely]

This patch allows simple registration of devices to include a
device tree node populate function.

Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---

 hw/sysbus.c |   15 +++++++++++++++
 hw/sysbus.h |    2 ++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/hw/sysbus.c b/hw/sysbus.c
index 861572f..c63deef 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -138,6 +138,21 @@ void sysbus_register_dev(const char *name, size_t size, sysbus_initfn init)
     sysbus_register_withprop(info);
 }
 
+#if defined(CONFIG_FDT)
+void sysbus_register_dev_fdt(const char *name, size_t size, sysbus_initfn init,
+                             sysbus_fdt_populatefn fdt_populate)
+{
+    SysBusDeviceInfo *info;
+
+    info = qemu_mallocz(sizeof(*info));
+    info->qdev.name = qemu_strdup(name);
+    info->qdev.size = size;
+    info->init = init;
+    info->fdt_populate = fdt_populate;
+    sysbus_register_withprop(info);
+}
+#endif
+
 DeviceState *sysbus_create_varargs(const char *name,
                                    target_phys_addr_t addr, ...)
 {
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 2c43191..3e20494 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -39,6 +39,8 @@ typedef struct {
 } SysBusDeviceInfo;
 
 void sysbus_register_dev(const char *name, size_t size, sysbus_initfn init);
+void sysbus_register_dev_fdt(const char *name, size_t size, sysbus_initfn init,
+                             sysbus_fdt_populatefn fdt_populate);
 void sysbus_register_withprop(SysBusDeviceInfo *info);
 void *sysbus_new(void);
 void sysbus_init_mmio(SysBusDevice *dev, target_phys_addr_t size, int iofunc);

[Qemu-devel] [RFC PATCH 5/7] devicetree: Add helper to register devices with an fdt_populate hook

[Grant Likely]

This patch allows simple registration of devices to include a
device tree node populate function.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 hw/sysbus.c |   15 +++++++++++++++
 hw/sysbus.h |    2 ++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/hw/sysbus.c b/hw/sysbus.c
index 861572f..c63deef 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -138,6 +138,21 @@ void sysbus_register_dev(const char *name, size_t size, sysbus_initfn init)
     sysbus_register_withprop(info);
 }
 
+#if defined(CONFIG_FDT)
+void sysbus_register_dev_fdt(const char *name, size_t size, sysbus_initfn init,
+                             sysbus_fdt_populatefn fdt_populate)
+{
+    SysBusDeviceInfo *info;
+
+    info = qemu_mallocz(sizeof(*info));
+    info->qdev.name = qemu_strdup(name);
+    info->qdev.size = size;
+    info->init = init;
+    info->fdt_populate = fdt_populate;
+    sysbus_register_withprop(info);
+}
+#endif
+
 DeviceState *sysbus_create_varargs(const char *name,
                                    target_phys_addr_t addr, ...)
 {
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 2c43191..3e20494 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -39,6 +39,8 @@ typedef struct {
 } SysBusDeviceInfo;
 
 void sysbus_register_dev(const char *name, size_t size, sysbus_initfn init);
+void sysbus_register_dev_fdt(const char *name, size_t size, sysbus_initfn init,
+                             sysbus_fdt_populatefn fdt_populate);
 void sysbus_register_withprop(SysBusDeviceInfo *info);
 void *sysbus_new(void);
 void sysbus_init_mmio(SysBusDevice *dev, target_phys_addr_t size, int iofunc);

[RFC PATCH 6/7] devicetree: Add fdt_populate hook to pl011 device

[Grant Likely]

Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---

 hw/pl011.c |   29 +++++++++++++++++++++++++----
 1 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/hw/pl011.c b/hw/pl011.c
index 81de91e..efc06d2 100644
--- a/hw/pl011.c
+++ b/hw/pl011.c
@@ -286,6 +286,27 @@ static int pl011_load(QEMUFile *f, void *opaque, int version_id)
     return 0;
 }
 
+#ifdef CONFIG_FDT
+#include <libfdt.h>
+static int pl011_fdt_populate(SysBusDevice *dev, void *fdt, int offset)
+{
+    pl011_state *s = FROM_SYSBUS(pl011_state, dev);
+    int rc;
+
+    rc = fdt_setprop_string(fdt, offset, "compatible", "arm,amba-device");
+    if (rc < 0)
+        return rc;
+
+    rc = fdt_setprop(fdt, offset, "arm,amba-deviceid", s->id, sizeof(s->id));
+    if (rc < 0)
+        return rc;
+
+    return 0;
+}
+#else
+#define pl011_fdt_populate NULL
+#endif
+
 static int pl011_init(SysBusDevice *dev, const unsigned char *id)
 {
     int iomemtype;
@@ -322,10 +343,10 @@ static int pl011_init_luminary(SysBusDevice *dev)
 
 static void pl011_register_devices(void)
 {
-    sysbus_register_dev("pl011", sizeof(pl011_state),
-                        pl011_init_arm);
-    sysbus_register_dev("pl011_luminary", sizeof(pl011_state),
-                        pl011_init_luminary);
+    sysbus_register_dev_fdt("pl011", sizeof(pl011_state),
+                            pl011_init_arm, pl011_fdt_populate);
+    sysbus_register_dev_fdt("pl011_luminary", sizeof(pl011_state),
+                            pl011_init_luminary, pl011_fdt_populate);
 }
 
 device_init(pl011_register_devices)

[Qemu-devel] [RFC PATCH 6/7] devicetree: Add fdt_populate hook to pl011 device

[Grant Likely]

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 hw/pl011.c |   29 +++++++++++++++++++++++++----
 1 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/hw/pl011.c b/hw/pl011.c
index 81de91e..efc06d2 100644
--- a/hw/pl011.c
+++ b/hw/pl011.c
@@ -286,6 +286,27 @@ static int pl011_load(QEMUFile *f, void *opaque, int version_id)
     return 0;
 }
 
+#ifdef CONFIG_FDT
+#include <libfdt.h>
+static int pl011_fdt_populate(SysBusDevice *dev, void *fdt, int offset)
+{
+    pl011_state *s = FROM_SYSBUS(pl011_state, dev);
+    int rc;
+
+    rc = fdt_setprop_string(fdt, offset, "compatible", "arm,amba-device");
+    if (rc < 0)
+        return rc;
+
+    rc = fdt_setprop(fdt, offset, "arm,amba-deviceid", s->id, sizeof(s->id));
+    if (rc < 0)
+        return rc;
+
+    return 0;
+}
+#else
+#define pl011_fdt_populate NULL
+#endif
+
 static int pl011_init(SysBusDevice *dev, const unsigned char *id)
 {
     int iomemtype;
@@ -322,10 +343,10 @@ static int pl011_init_luminary(SysBusDevice *dev)
 
 static void pl011_register_devices(void)
 {
-    sysbus_register_dev("pl011", sizeof(pl011_state),
-                        pl011_init_arm);
-    sysbus_register_dev("pl011_luminary", sizeof(pl011_state),
-                        pl011_init_luminary);
+    sysbus_register_dev_fdt("pl011", sizeof(pl011_state),
+                            pl011_init_arm, pl011_fdt_populate);
+    sysbus_register_dev_fdt("pl011_luminary", sizeof(pl011_state),
+                            pl011_init_luminary, pl011_fdt_populate);
 }
 
 device_init(pl011_register_devices)

[RFC PATCH 7/7] devicetree: Add fdt_populate hook to smc91x device

[Grant Likely]

Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---

 hw/smc91c111.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/hw/smc91c111.c b/hw/smc91c111.c
index b7398c9..300d209 100644
--- a/hw/smc91c111.c
+++ b/hw/smc91c111.c
@@ -721,8 +721,28 @@ static int smc91c111_init1(SysBusDevice *dev)
     return 0;
 }
 
+#ifdef CONFIG_FDT
+#include <libfdt.h>
+static int smc91c111_fdt_populate(SysBusDevice *dev, void *fdt, int offset)
+{
+    smc91c111_state *s = FROM_SYSBUS(smc91c111_state, dev);
+    int rc;
+
+    rc = fdt_setprop_string(fdt, offset, "compatible", "smc,91c111");
+    if (rc < 0)
+        return rc;
+
+    rc = fdt_setprop(fdt, offset, "local-mac-address", s->conf.macaddr.a,
+                     sizeof(s->conf.macaddr.a));
+    return 0;
+}
+#endif
+
 static SysBusDeviceInfo smc91c111_info = {
     .init = smc91c111_init1,
+#ifdef CONFIG_FDT
+    .fdt_populate = smc91c111_fdt_populate,
+#endif
     .qdev.name  = "smc91c111",
     .qdev.size  = sizeof(smc91c111_state),
     .qdev.props = (Property[]) {

[Qemu-devel] [RFC PATCH 7/7] devicetree: Add fdt_populate hook to smc91x device

[Grant Likely]

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 hw/smc91c111.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/hw/smc91c111.c b/hw/smc91c111.c
index b7398c9..300d209 100644
--- a/hw/smc91c111.c
+++ b/hw/smc91c111.c
@@ -721,8 +721,28 @@ static int smc91c111_init1(SysBusDevice *dev)
     return 0;
 }
 
+#ifdef CONFIG_FDT
+#include <libfdt.h>
+static int smc91c111_fdt_populate(SysBusDevice *dev, void *fdt, int offset)
+{
+    smc91c111_state *s = FROM_SYSBUS(smc91c111_state, dev);
+    int rc;
+
+    rc = fdt_setprop_string(fdt, offset, "compatible", "smc,91c111");
+    if (rc < 0)
+        return rc;
+
+    rc = fdt_setprop(fdt, offset, "local-mac-address", s->conf.macaddr.a,
+                     sizeof(s->conf.macaddr.a));
+    return 0;
+}
+#endif
+
 static SysBusDeviceInfo smc91c111_info = {
     .init = smc91c111_init1,
+#ifdef CONFIG_FDT
+    .fdt_populate = smc91c111_fdt_populate,
+#endif
     .qdev.name  = "smc91c111",
     .qdev.size  = sizeof(smc91c111_state),
     .qdev.props = (Property[]) {

Re: [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Jeremy Kerr]

Hi Grant,

> This is an experimental set of patches for populating the flattened
> device tree (fdt) data from the actual set of qdevs in the platform.

Neat. I've pulled these into my qemu tree, and have updated it to the current 
qemu master branch too (only a minor change, as qemu_error has been removed).

Could you try out the new branch to see if it all works for you?

Cheers,


Jeremy

[Qemu-devel] Re: [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Jeremy Kerr]

Hi Grant,

> This is an experimental set of patches for populating the flattened
> device tree (fdt) data from the actual set of qdevs in the platform.

Neat. I've pulled these into my qemu tree, and have updated it to the current 
qemu master branch too (only a minor change, as qemu_error has been removed).

Could you try out the new branch to see if it all works for you?

Cheers,


Jeremy

Re: [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

On Wed, Apr 7, 2010 at 1:01 AM, Jeremy Kerr <jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> Hi Grant,
>
>> This is an experimental set of patches for populating the flattened
>> device tree (fdt) data from the actual set of qdevs in the platform.
>
> Neat. I've pulled these into my qemu tree, and have updated it to the current
> qemu master branch too (only a minor change, as qemu_error has been removed).
>
> Could you try out the new branch to see if it all works for you?

Mostly, but had to fix my sprintf handling because I had a buffer
overflow.  I'll send a followup patch.

g.

[Qemu-devel] Re: [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

On Wed, Apr 7, 2010 at 1:01 AM, Jeremy Kerr <jeremy.kerr@canonical.com> wrote:
> Hi Grant,
>
>> This is an experimental set of patches for populating the flattened
>> device tree (fdt) data from the actual set of qdevs in the platform.
>
> Neat. I've pulled these into my qemu tree, and have updated it to the current
> qemu master branch too (only a minor change, as qemu_error has been removed).
>
> Could you try out the new branch to see if it all works for you?

Mostly, but had to fix my sprintf handling because I had a buffer
overflow.  I'll send a followup patch.

g.

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Blue Swirl]

On 4/7/10, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> Hi everyone,
>
>  This is an experimental set of patches for populating the flattened
>  device tree (fdt) data from the actual set of qdevs in the platform.
>  I'm not expecting this to get merged anytime soon, but I wanted to get
>  it out there to solicit comments.  My target for this is testing
>  device tree support on ARM.
>
>  The approach is by no means final, and there are still a number of
>  details to work out, but I've got it working well with the versatile
>  platform and I've got the kernel using fdt data to bind against the
>  smc91x device driver.  I'll be posting my associated kernel patches
>  real-soon-now.

It looks like the hook is only used to add some additional properties.
I think a data driven approach (fields in qdev structure) would be
simpler because the handling code would be only in qdev instead of all
devices.

Something like:
static SysBusDeviceInfo smc91c111_info = {
    .init = smc91c111_init1,
    .qdev.name  = "smc91c111",
    .qdev.size  = sizeof(smc91c111_state),
    .qdev.props = (Property[]) {
        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
        DEFINE_PROP_END_OF_LIST(),
    },
    .qdev.fdt_props = (FDTProperty[]) {
        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
conf.macaddr),
        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
        DEFINE_FDT_PROP_END_OF_LIST(),
    }
};

A separate question is whether the properties should be visible to
user, for example shown by "info qdev". If yes, then the FDT
properties should be a special case of qdev properties:
    .qdev.props = (Property[]) {
        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
conf.macaddr),
        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
        DEFINE_PROP_END_OF_LIST(),
    }

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Blue Swirl]

On 4/7/10, Grant Likely <grant.likely@secretlab.ca> wrote:
> Hi everyone,
>
>  This is an experimental set of patches for populating the flattened
>  device tree (fdt) data from the actual set of qdevs in the platform.
>  I'm not expecting this to get merged anytime soon, but I wanted to get
>  it out there to solicit comments.  My target for this is testing
>  device tree support on ARM.
>
>  The approach is by no means final, and there are still a number of
>  details to work out, but I've got it working well with the versatile
>  platform and I've got the kernel using fdt data to bind against the
>  smc91x device driver.  I'll be posting my associated kernel patches
>  real-soon-now.

It looks like the hook is only used to add some additional properties.
I think a data driven approach (fields in qdev structure) would be
simpler because the handling code would be only in qdev instead of all
devices.

Something like:
static SysBusDeviceInfo smc91c111_info = {
    .init = smc91c111_init1,
    .qdev.name  = "smc91c111",
    .qdev.size  = sizeof(smc91c111_state),
    .qdev.props = (Property[]) {
        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
        DEFINE_PROP_END_OF_LIST(),
    },
    .qdev.fdt_props = (FDTProperty[]) {
        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
conf.macaddr),
        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
        DEFINE_FDT_PROP_END_OF_LIST(),
    }
};

A separate question is whether the properties should be visible to
user, for example shown by "info qdev". If yes, then the FDT
properties should be a special case of qdev properties:
    .qdev.props = (Property[]) {
        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
conf.macaddr),
        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
        DEFINE_PROP_END_OF_LIST(),
    }

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

Thanks for the comments.  Replies below...

On Wed, Apr 7, 2010 at 1:10 PM, Blue Swirl <blauwirbel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 4/7/10, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>> Hi everyone,
>>
>>  This is an experimental set of patches for populating the flattened
>>  device tree (fdt) data from the actual set of qdevs in the platform.
>>  I'm not expecting this to get merged anytime soon, but I wanted to get
>>  it out there to solicit comments.  My target for this is testing
>>  device tree support on ARM.
>>
>>  The approach is by no means final, and there are still a number of
>>  details to work out, but I've got it working well with the versatile
>>  platform and I've got the kernel using fdt data to bind against the
>>  smc91x device driver.  I'll be posting my associated kernel patches
>>  real-soon-now.
>
> It looks like the hook is only used to add some additional properties.
> I think a data driven approach (fields in qdev structure) would be
> simpler because the handling code would be only in qdev instead of all
> devices.

Hmmm, maybe.  I don't really have a good answer yet as I'm still
experimenting.  It is possible that I'll need more complex behaviour
as I add new kinds of devices or for handling different bus types.
For example, right now I've got code to change the node name for mmio
devices, and that cannot be filled in until the register base is
defined and the best name format may be different for different
busses/devices.  I'm not familiar enough with qemu to know how best to
handle this with properties.

> Something like:
> static SysBusDeviceInfo smc91c111_info = {
>    .init = smc91c111_init1,
>    .qdev.name  = "smc91c111",
>    .qdev.size  = sizeof(smc91c111_state),
>    .qdev.props = (Property[]) {
>        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
>        DEFINE_PROP_END_OF_LIST(),
>    },
>    .qdev.fdt_props = (FDTProperty[]) {
>        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
> conf.macaddr),
>        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
>        DEFINE_FDT_PROP_END_OF_LIST(),
>    }
> };
>
> A separate question is whether the properties should be visible to
> user, for example shown by "info qdev". If yes, then the FDT
> properties should be a special case of qdev properties:
>    .qdev.props = (Property[]) {
>        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
>        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
> conf.macaddr),
>        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
>        DEFINE_PROP_END_OF_LIST(),
>    }

It would certainly be useful to see the device node(s) associated with a qdev.

g.

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

Thanks for the comments.  Replies below...

On Wed, Apr 7, 2010 at 1:10 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 4/7/10, Grant Likely <grant.likely@secretlab.ca> wrote:
>> Hi everyone,
>>
>>  This is an experimental set of patches for populating the flattened
>>  device tree (fdt) data from the actual set of qdevs in the platform.
>>  I'm not expecting this to get merged anytime soon, but I wanted to get
>>  it out there to solicit comments.  My target for this is testing
>>  device tree support on ARM.
>>
>>  The approach is by no means final, and there are still a number of
>>  details to work out, but I've got it working well with the versatile
>>  platform and I've got the kernel using fdt data to bind against the
>>  smc91x device driver.  I'll be posting my associated kernel patches
>>  real-soon-now.
>
> It looks like the hook is only used to add some additional properties.
> I think a data driven approach (fields in qdev structure) would be
> simpler because the handling code would be only in qdev instead of all
> devices.

Hmmm, maybe.  I don't really have a good answer yet as I'm still
experimenting.  It is possible that I'll need more complex behaviour
as I add new kinds of devices or for handling different bus types.
For example, right now I've got code to change the node name for mmio
devices, and that cannot be filled in until the register base is
defined and the best name format may be different for different
busses/devices.  I'm not familiar enough with qemu to know how best to
handle this with properties.

> Something like:
> static SysBusDeviceInfo smc91c111_info = {
>    .init = smc91c111_init1,
>    .qdev.name  = "smc91c111",
>    .qdev.size  = sizeof(smc91c111_state),
>    .qdev.props = (Property[]) {
>        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
>        DEFINE_PROP_END_OF_LIST(),
>    },
>    .qdev.fdt_props = (FDTProperty[]) {
>        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
> conf.macaddr),
>        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
>        DEFINE_FDT_PROP_END_OF_LIST(),
>    }
> };
>
> A separate question is whether the properties should be visible to
> user, for example shown by "info qdev". If yes, then the FDT
> properties should be a special case of qdev properties:
>    .qdev.props = (Property[]) {
>        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
>        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
> conf.macaddr),
>        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
>        DEFINE_PROP_END_OF_LIST(),
>    }

It would certainly be useful to see the device node(s) associated with a qdev.

g.

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Paul Brook]

> Hi everyone,
> 
> This is an experimental set of patches for populating the flattened
> device tree (fdt) data from the actual set of qdevs in the platform.
> I'm not expecting this to get merged anytime soon, but I wanted to get
> it out there to solicit comments.  My target for this is testing
> device tree support on ARM.

I think you need to convert some more interesting machines before it's 
possible to tell whether this is a sane setup. When investigating FDTs for 
creation of machine I found it's easy to invent something that can handle the 
simple integrator/cp board, but it all starts to fall apart when you encounter 
more complicated boards. In particular things like PCI, USB, I2C, etc. and 
strange bus configurations when you have both on-chip and external devices.

Paul

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Paul Brook]

> Hi everyone,
> 
> This is an experimental set of patches for populating the flattened
> device tree (fdt) data from the actual set of qdevs in the platform.
> I'm not expecting this to get merged anytime soon, but I wanted to get
> it out there to solicit comments.  My target for this is testing
> device tree support on ARM.

I think you need to convert some more interesting machines before it's 
possible to tell whether this is a sane setup. When investigating FDTs for 
creation of machine I found it's easy to invent something that can handle the 
simple integrator/cp board, but it all starts to fall apart when you encounter 
more complicated boards. In particular things like PCI, USB, I2C, etc. and 
strange bus configurations when you have both on-chip and external devices.

Paul

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> wrote:
>> Hi everyone,
>>
>> This is an experimental set of patches for populating the flattened
>> device tree (fdt) data from the actual set of qdevs in the platform.
>> I'm not expecting this to get merged anytime soon, but I wanted to get
>> it out there to solicit comments.  My target for this is testing
>> device tree support on ARM.
>
> I think you need to convert some more interesting machines before it's
> possible to tell whether this is a sane setup. When investigating FDTs for
> creation of machine I found it's easy to invent something that can handle the
> simple integrator/cp board, but it all starts to fall apart when you encounter
> more complicated boards. In particular things like PCI, USB, I2C, etc. and
> strange bus configurations when you have both on-chip and external devices.

Certainly.  What would be a good (preferably ARM) platform to look at?
 I'm fairly new to working with QEMU, so I'm not very familiar with
the platforms that are available.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook <paul@codesourcery.com> wrote:
>> Hi everyone,
>>
>> This is an experimental set of patches for populating the flattened
>> device tree (fdt) data from the actual set of qdevs in the platform.
>> I'm not expecting this to get merged anytime soon, but I wanted to get
>> it out there to solicit comments.  My target for this is testing
>> device tree support on ARM.
>
> I think you need to convert some more interesting machines before it's
> possible to tell whether this is a sane setup. When investigating FDTs for
> creation of machine I found it's easy to invent something that can handle the
> simple integrator/cp board, but it all starts to fall apart when you encounter
> more complicated boards. In particular things like PCI, USB, I2C, etc. and
> strange bus configurations when you have both on-chip and external devices.

Certainly.  What would be a good (preferably ARM) platform to look at?
 I'm fairly new to working with QEMU, so I'm not very familiar with
the platforms that are available.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Paul Brook]

> On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> wrote:
> >> Hi everyone,
> >>
> >> This is an experimental set of patches for populating the flattened
> >> device tree (fdt) data from the actual set of qdevs in the platform.
> >> I'm not expecting this to get merged anytime soon, but I wanted to get
> >> it out there to solicit comments.  My target for this is testing
> >> device tree support on ARM.
> >
> > I think you need to convert some more interesting machines before it's
> > possible to tell whether this is a sane setup. When investigating FDTs
> > for creation of machine I found it's easy to invent something that can
> > handle the simple integrator/cp board, but it all starts to fall apart
> > when you encounter more complicated boards. In particular things like
> > PCI, USB, I2C, etc. and strange bus configurations when you have both
> > on-chip and external devices.
> 
> Certainly.  What would be a good (preferably ARM) platform to look at?
>  I'm fairly new to working with QEMU, so I'm not very familiar with
> the platforms that are available.

The versatile and readview boards both have PCI. The realview-eb-mpcore in 
particular has entertaining IRQ routing.  The Stellaris boards have various 
devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris 
boards aren't capable of running linux). The musicpal audio device may also be 
interesting as it's connected vi both i2s and gpio based i2c.  All these 
should be fairly well qdev-ified. 

Arguably the most interesting is the PPC boards as we already know what device 
tree we need to generate.  However these haven't been converted to qdev yet, 
and it's unclear how well the 4xx boards work to start with.

Paul

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Paul Brook]

> On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook <paul@codesourcery.com> wrote:
> >> Hi everyone,
> >>
> >> This is an experimental set of patches for populating the flattened
> >> device tree (fdt) data from the actual set of qdevs in the platform.
> >> I'm not expecting this to get merged anytime soon, but I wanted to get
> >> it out there to solicit comments.  My target for this is testing
> >> device tree support on ARM.
> >
> > I think you need to convert some more interesting machines before it's
> > possible to tell whether this is a sane setup. When investigating FDTs
> > for creation of machine I found it's easy to invent something that can
> > handle the simple integrator/cp board, but it all starts to fall apart
> > when you encounter more complicated boards. In particular things like
> > PCI, USB, I2C, etc. and strange bus configurations when you have both
> > on-chip and external devices.
> 
> Certainly.  What would be a good (preferably ARM) platform to look at?
>  I'm fairly new to working with QEMU, so I'm not very familiar with
> the platforms that are available.

The versatile and readview boards both have PCI. The realview-eb-mpcore in 
particular has entertaining IRQ routing.  The Stellaris boards have various 
devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris 
boards aren't capable of running linux). The musicpal audio device may also be 
interesting as it's connected vi both i2s and gpio based i2c.  All these 
should be fairly well qdev-ified. 

Arguably the most interesting is the PPC boards as we already know what device 
tree we need to generate.  However these haven't been converted to qdev yet, 
and it's unclear how well the 4xx boards work to start with.

Paul

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

On Fri, Apr 9, 2010 at 9:57 AM, Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> wrote:
>> On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> wrote:
>> >> Hi everyone,
>> >>
>> >> This is an experimental set of patches for populating the flattened
>> >> device tree (fdt) data from the actual set of qdevs in the platform.
>> >> I'm not expecting this to get merged anytime soon, but I wanted to get
>> >> it out there to solicit comments.  My target for this is testing
>> >> device tree support on ARM.
>> >
>> > I think you need to convert some more interesting machines before it's
>> > possible to tell whether this is a sane setup. When investigating FDTs
>> > for creation of machine I found it's easy to invent something that can
>> > handle the simple integrator/cp board, but it all starts to fall apart
>> > when you encounter more complicated boards. In particular things like
>> > PCI, USB, I2C, etc. and strange bus configurations when you have both
>> > on-chip and external devices.
>>
>> Certainly.  What would be a good (preferably ARM) platform to look at?
>>  I'm fairly new to working with QEMU, so I'm not very familiar with
>> the platforms that are available.
>
> The versatile and readview boards both have PCI.

PCI shouldn't be too hairy.  As long as the PCI bridge node is created
with the right properties for ranges and irq mapping, then the child
devices can be detected by the OS.  Unlike the configuration case, I
don't have to fully populate this part of the tree.  :-D

> The realview-eb-mpcore in
> particular has entertaining IRQ routing.

Fun.  I'll probably look at this first.

>  The Stellaris boards have various
> devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris
> boards aren't capable of running linux).

I'll skip that for now then.

> The musicpal audio device may also be
> interesting as it's connected vi both i2s and gpio based i2c.  All these
> should be fairly well qdev-ified.

This looks like a good candidate too then.  Getting i2c, spi and gpio
sorted out is higher priority for me right now than pci.

> Arguably the most interesting is the PPC boards as we already know what device
> tree we need to generate.  However these haven't been converted to qdev yet,
> and it's unclear how well the 4xx boards work to start with.

:-)

Thanks for the suggestions.  I'll keep you posted on how things go.
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs

[Grant Likely]

On Fri, Apr 9, 2010 at 9:57 AM, Paul Brook <paul@codesourcery.com> wrote:
>> On Fri, Apr 9, 2010 at 6:07 AM, Paul Brook <paul@codesourcery.com> wrote:
>> >> Hi everyone,
>> >>
>> >> This is an experimental set of patches for populating the flattened
>> >> device tree (fdt) data from the actual set of qdevs in the platform.
>> >> I'm not expecting this to get merged anytime soon, but I wanted to get
>> >> it out there to solicit comments.  My target for this is testing
>> >> device tree support on ARM.
>> >
>> > I think you need to convert some more interesting machines before it's
>> > possible to tell whether this is a sane setup. When investigating FDTs
>> > for creation of machine I found it's easy to invent something that can
>> > handle the simple integrator/cp board, but it all starts to fall apart
>> > when you encounter more complicated boards. In particular things like
>> > PCI, USB, I2C, etc. and strange bus configurations when you have both
>> > on-chip and external devices.
>>
>> Certainly.  What would be a good (preferably ARM) platform to look at?
>>  I'm fairly new to working with QEMU, so I'm not very familiar with
>> the platforms that are available.
>
> The versatile and readview boards both have PCI.

PCI shouldn't be too hairy.  As long as the PCI bridge node is created
with the right properties for ranges and irq mapping, then the child
devices can be detected by the OS.  Unlike the configuration case, I
don't have to fully populate this part of the tree.  :-D

> The realview-eb-mpcore in
> particular has entertaining IRQ routing.

Fun.  I'll probably look at this first.

>  The Stellaris boards have various
> devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris
> boards aren't capable of running linux).

I'll skip that for now then.

> The musicpal audio device may also be
> interesting as it's connected vi both i2s and gpio based i2c.  All these
> should be fairly well qdev-ified.

This looks like a good candidate too then.  Getting i2c, spi and gpio
sorted out is higher priority for me right now than pci.

> Arguably the most interesting is the PPC boards as we already know what device
> tree we need to generate.  However these haven't been converted to qdev yet,
> and it's unclear how well the 4xx boards work to start with.

:-)

Thanks for the suggestions.  I'll keep you posted on how things go.
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.