How to use the device tree of linux drivers and how to use the device tree of linux drivers

How to use the device tree of linux drivers and how to use the device tree of linux drivers

The Device Tree describes the hardware from the software perspective, and DTS is the Device Tree source file. DTC is responsible for converting DTS to DTB, and DTB is the binary form of DTS for machine use.

The Device Tree is a tree structure. Each child node except the root node has a unique parent node, which can have subnodes and attributes. Attributes consist of names and values. The Device Tree is just an approximate identifier for software developers to describe hardware. Each device in the system corresponds to a node in the Device Tree.

Driver Analysis Based on platform bus:

In the device driver model, the bus is responsible for binding the device and the driver. When the system registers a device, it looks for a matching driver. On the contrary, when the system registers a driver, it looks for a matching device, the matching is completed by the bus.

1. Platform bus-driven workflow:

1. Provide and register platform_device/device Node

2. Provide and register platform_driver

3. When the mach function in the platform bus constantly matches the driver and device (the old kernel is based on the id and name elements in the driver; the new kernel is based on the compatible in of_match_table)

4. Once the matching is successful, call the probe (probe) function of the driver to officially execute the driver code.

2. Independence and adaptability of the platform bus driver

A platform bus driver can correspond to multiple devices, and device changes do not affect the driver. How is this implemented?

Simply put, this is a mechanism similar to passing parameters. The device transmits the underlying information (such as register information, used interrupt number, and device name) to the driver. The driver code does not need to be changed. You only need to operate the underlying layer according to parameters, adapt to device changes

The modern drive design concept is to separate algorithms and data. The driver source code does not carry data and is only responsible for algorithms (operating methods on hardware). This maximizes the independence and adaptability of the driver.

The specific implementation method is: in the old kernel, platform_device contains a device struct, which contains a void * platform_data. You can store various underlying information in it. When the probe (probe) function of the driver is executed, platform_device will be passed in as a parameter, so that the driver can indirectly obtain the void * platform_data and operate the hardware accordingly; the new kernel stores data directly in the device node attributes, and the driver reads the data in the node through the API:

Old Version device registration:

Driver writing:

Red Line: The parameter information is transmitted to the driver.

3. Bus driver in the new kernel: Device Tree

For the driver itself, the main reason is that the platform device does not need to be registered in mach-xxx, but is directly defined in the device tree as a node. The platform device can be directly defined in the dts root node.

The driver is directly paired with the device node in the Device Tree, and is paired with the device node through the compatible (compatibility) in the device node. The specific method is to define an of_match_table. If the compatible in the table is the same as the compatible in the device node, the probe function is triggered.

For private data of devices, the new kernel does not use plat_data anymore. Instead, it defines various attributes in the node and obtains them using specific APIs in the driver. For details, see the Device Tree.

4. Device Tree Structure:

Basic Structure:

The structure surrounded by {} is called a node, and the/{} at the beginning of dts is called a root node. The standard structure of the node is xxx @ yyy {...}, Xxx is the name of a node,

Yyy is not required, and its value is the Node Address (Register address or other address). For example, in i2c1: i2c @ 021a0000, It is the register base address of an i2c controller,

Rtc: the i2c address of the rtc device in pcf8523 @ 68

Property: Address:

The node address, for example, i2c @ 021a0000. Although it is followed by the address after the name, the formal setting is set in the reg attribute.

For example, reg = <0x021a0000 0x4000>; the format of reg is usually

, 0x021a0000 is the base address of the Register, and 0x4000 is the length.

Property: compatibility:

If a node is a device node, it must have compatible (compatibility), because it will be used as a basis for matching drivers and devices (device nodes), compatible (compatibility) the value can have more than one string to meet different requirements. After the system starts, the cpu information will be determined based on the compatible of the root node and initialized here

Matching of kernel and node:

First, the kernel needs to know the address of the dtb file. This is what uboot tells the kernel. After the kernel knows the address of the dtb file, the driver can obtain the internal information of the device tree through some APIs.

For 3. for kernels later than Version x, platform, i2c, spi, and other devices no longer need to be registered in mach-xxx. The driver will directly match the device node in the Device Tree, the compatible (compatibility) in the device node is used to match the device node.

Set and obtain common attributes:

When you modify or write a driver, you often need to modify the gpio, clock, interrupt, and other parameters. Previously, they were set in device in mach-xxx. Now, you need to set them in the node, then the driver uses a special API to obtain

Attributes are often obtained in the probe function, but before obtaining attributes, it is most important to determine which node triggers the driver. If a driver corresponds to multiple nodes, the driver can

Int of_device_is_compatible (const struct device_node * device, const char * name) to determine whether the current node contains the specified compatible (compatibility)