perty. 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 of 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
> +it's 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 it's
> +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 it's .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 it's 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.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
