Shulou(Shulou.com)06/01 Report--

This article shows you how to analyze the encounter between Linux devices and drivers. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

A development board

This section takes a look at how devices and drivers are bound together with a detailed explanation of the device information set. The so-called device information collection is to find their own peripheral information according to different peripherals. We know that a complete development board has CPU and various controllers (such as I2C controller, SPI controller, DMA controller, etc.), CPU and controller can be collectively referred to as SOC, in addition to a variety of peripheral IP, such as LCD, HDMI, SD, CAMERA, etc., as shown below:

We see that a development board has a lot of equipment, how are these devices deployed layer by layer? How are devices and drivers bound? We enter the topic of this section with these questions.

Deployment of equipment at all levels

When the kernel starts, the device tree is expanded layer by layer to find the device. The device tree is also called the device tree because the structure of the device in the kernel is like a tree, spreading outward from the root layer by layer. For a more vivid understanding, look at a picture:

In the big circle is what we often call soc, which includes CPU and various controllers A, B, I2C, SPI,soc with peripherals E and F. There are specific buses outside the IP, such as I2C bus and SPI bus, and the corresponding I2C devices and SPI devices are hung on their respective buses, but there is only a system bus inside the soc and there is no specific bus.

The first section talks about the principle of bus, device and driver model, that is, any driver is connected with the device through the corresponding bus, so although there is no specific bus inside the soc, the kernel finds the controller one by one through the virtual bus platform, which also follows the design concept of high cohesion and low coupling of the kernel. Let's explore how devices are deployed layer by layer in the order of platform devices, i2C devices, and spi devices.

1. Deploy the platform Devic

In the image above, you can see the simple-bus marked in red font. These are the buses that connect all kinds of controllers. In the kernel, it is the platform bus, and the mounted devices are platform devices. Let's take a look at how the platform device is deployed.

Remember in the previous section that there was a callback function called init_machine () during kernel initialization? If you register this function in the board-level file, the function will be called when the system starts. If it is not defined, it will expand the device hanging under "simple-bus" by calling of_platform_populate (), as shown in figure (located in kernel/arch/arm/kernel/setup.c,kernel/drivers/of/platform.c):

This expands the nodes under the simple-bus into platform devices one by one.

two。 Deploy i2C device

Experienced partners know that the i2c_register_adapter () function will definitely be called when writing i2C controllers, and the implementation of this function is as follows (kernel/drivers/i2c/i2c-core.c):

At the end of the registration function, there is a function of_i2c_register_devices (adap), which is implemented as follows:

The of_i2c_register_devices () function traverses the nodes under the controller, and then registers the devices under the I2C controller through the of_i2c_register_device () function.

3. Deploy the spi Devic

The registration of spi devices is the same as i2C devices, traversing the devices under the spi node under the spi controller, and then registering through the corresponding registration function, but it is different from the api interface registered by i2C. Let's take a look at the specific code (kernel/drivers/spi/spi.c):

When registering a spi controller through spi_register_master, it traverses the devices under the spi bus through of_register_spi_devices to register. This completes the registration of the spi device.

Deployment of equipment at all levels

It is believed that we should understand that the hardware information of the device is obtained from the device tree, such as register address, interrupt number, clock and so on. Next, let's take a look at how this information is recorded in the device tree in preparation for the next section of the hands-on custom development board.

1.reg register

Let's first look at the soc description information in the device tree. The red label represents the register address expressed by several data quantities, and the green label represents the register space size expressed by several data quantities. The meaning in the figure is that the base address of the interrupt controller is 0xfec00000 and the space size is 0x1000. If the value of address-cells is 2, it requires two orders of magnitude to represent the base address, for example, if the register is 64 bits, it needs two orders of magnitude, each representing a 32-bit number.

2.ranges value range

Ranges represents the translation of local addresses to parent addresses. If ranges is empty, it represents a 1:1 mapping with cpu, and if there is no range, it means it is not a memory area.

The above content is how to analyze the encounter between Linux devices and drivers. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.