The trick is this kernel starts at the root and looks
332 for nodes the have a ' compatible ' property. The It is generally
333 assumed that the any node with a ' compatible ' property represents a device
334 of some kind, and second, it can be assumed so any node at the root
335 of the ' the ' of the ' either directly attached to the ' processor bus, or is a
336 Miscellaneous System device that cannot is described any other way.
337 for each of these nodes, Linux allocates and registers a
338 Platform_device, which in turn may get bound to a platform_driver.
339
Why is using a platform_device for nodes a safe assumption?
341, for the way, Linux models devices, just about all bus_types
342 assume that it devices are children of a bus controller. For
343 example, each i2c_client was a child of the i2c_master. Each spi_device
344 is a child of the SPI bus. Similarly for USB, PCI, Mdio, etc. The
345 same hierarchy is also found in the DT, where I2C device
346 ever appear as children of a I2C bus node. Ditto for SPI, Mdio, USB,
347 etc. The only devices which does not require a specific type of parent
348 device are platform_devices (and amba_devices, but more in that
349 later), which'll happily live at the base of the Linux/sys/devices
The tree. Therefore, if a DT node is at the root, then it
351 really probably is best registered as a platform_device.
352
353 Linux Board Support code calls of_platform_populate (NULL, NULL, NULL, NULL)
354 to kick off Discovery's devices at the root. The
355 parameters are all NULL because when starting from the root of the
356 tree, there are no need to provide a starting node (the-a
357 Parent struct Device (the last NULL), and we ' re not using a match
358 table (yet). For a board which is needs to register devices,
359. Init_machine () can is completely empty except for the
360 of_platform_populate () call.
361
362 in the Tegra example, this accounts for THE/SOC and/sound, nodes
363 What about the children of the SoC node? Shouldn ' t they be registered
364 as platform devices too? For Linux DT support, the generic behaviour
365 is for child devices to being registered by the parent's device driver at
366 driver. Probe () time. So, a I2C bus device driver'll register a
367 i2c_client for each child node, a SPI bus driver'll register
368 its spi_device children, and similarly for the other bus_types.
369 According to that model, a driver could is written that binds to the
370 SoC node and simply registers platform_devices for each of the
371 children. The Board support Code would allocate and register an SoC
372 device, a (theoretical) SOC device driver could bind to the SOC device,
373 and register Platform_devices For/soc/interrupt-controller,/soc/serial,
374/SOC/I2S, AND/SOC/I2C in its. Probe () hook. Easy, right?
375
376 Actually, it turns out that registering children of some
377 Platform_devices As more platform_devices are a common pattern, and the
378 Device tree Support code reflects and makes the above example
379 simpler. The second argument to Of_platform_populate () was an
380 of_device_id table, and any node that matches a entry in that table
381 would also get it child nodes registered. In the Tegra case, the code
382 can look something like this:
383
384 static void __init harmony_init_machine (void)
385 {
386/* ... * *
387 of_platform_populate (NULL, of_default_bus_match_table, NULL, NULL);
388}
389
390 "Simple-bus" is defined in the EPAPR 1.0 specification as a
391 meaning a simple memory mapped bus, so the of_platform_populate () code
392 could is written to just assume simple-bus compatible nodes would
393 always be traversed. However, we pass it in as a argument so
394 Board support code can always override the default behaviour.
395
396 [Need to add discussion of adding i2c/spi/etc child devices]
The reference of_platform_populate function can be found that the first layer of nodes with compatible properties will be created platform devices,
If the node conforms to of_default_bus_match_table, the node's child nodes are also created as platform devices.
