dts 内核展开平台设备

The trick is that the kernel starts at the root of the tree and looks

332 for nodes that have a 'compatible' property. First, it is generally

333 assumed that any node with a 'compatible' property represents a device

334 of some kind, and second, it can be assumed that any node at the root

335 of the tree is either directly attached to the processor bus, or is a

336 miscellaneous system device that cannot be 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

340 Why is using a platform_device for these nodes a safe assumption?

341 Well, for the way that Linux models devices, just about all bus_types

342 assume that its devices are children of a bus controller. For

343 example, each i2c_client is a child of an i2c_master. Each spi_device

344 is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The

345 same hierarchy is also found in the DT, where I2C device nodes only

346 ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB,

347 etc. The only devices which do not require a specific type of parent

348 device are platform_devices (and amba_devices, but more on that

349 later), which will happily live at the base of the Linux /sys/devices

350 tree. Therefore, if a DT node is at the root of the tree, 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 of devices at the root of the tree. The

355 parameters are all NULL because when starting from the root of the

356 tree, there is no need to provide a starting node (the first NULL), a

357 parent struct device (the last NULL), and we're not using a match

358 table (yet). For a board that only needs to register devices,

359 .init_machine() can be completely empty except for the

360 of_platform_populate() call.

361

362 In the Tegra example, this accounts for the /soc and /sound nodes, but

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 be registered by the parent's device driver at

366 driver .probe() time. So, an i2c bus device driver will register a

367 i2c_client for each child node, an SPI bus driver will register

368 its spi_device children, and similarly for other bus_types.

369 According to that model, a driver could be written that binds to the

370 SoC node and simply registers platform_devices for each of its

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 is a common pattern, and the

378 device tree support code reflects that and makes the above example

379 simpler. The second argument to of_platform_populate() is an

380 of_device_id table, and any node that matches an entry in that table

381 will also get its 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 property

391 meaning a simple memory mapped bus, so the of_platform_populate() code

392 could be written to just assume simple-bus compatible nodes will

393 always be traversed. However, we pass it in as an argument so that

394 board support code can always override the default behaviour.

395

396 [Need to add discussion of adding i2c/spi/etc child devices]

参考of_platform_populate函数可以发现，第一层有compatible属性的的节点都会被创建平台设备，

若该节点符合of_default_bus_match_table，则该节点的子节点也会被创建平台设备。