Understanding the Linux family from a demand perspective: bus, device and driver

I became a blog expert after finishing the original embedded Linux Series blog post, now launched to let more readers benefit.

"Understanding the Linux series from a demand perspective: bus, device, and drive" is a methodological article on how to learn embedded Linux systems, and the beginning of understanding Linux system software from the perspective of demand, expecting this series of articles to be the benchmark for learning Embedded Linux in the future!

This is the author's well-written experience summary, I hope that embedded Linux learners to understand carefully, read a few times also no harm.

I. Software, object-oriented, software framework

Software is to solve the real problem, the object-oriented software thinking is an effective way to solve the general problems of the abstract method, and the software framework refers to the object-oriented thinking to solve a particular field of problems and specifically designed a set of effective solutions.

In general, java/c++ programming reflects object-oriented software thinking, while QT like the Android framework, Windows MFC, and Linux represent the software framework of the application layer. The problems that the application framework solves include application message processing, UI control display and processing, resource management, and so on. The benefit of the software framework is that the framework will do 80% of the development effort for you to solve a domain problem, and you only need to complete 20% of the development effort.

The various subsystems on the Linux platform, such as device driver model, input subsystem, I²C bus, frame buffer drive and so on, belong to the software framework, which is a kind of software solution designed for the specific hardware system requirements with object-oriented thinking, and has been verified by multi-platform for a long time. In a strict sense, it is more appropriate to classify subsystems into software abstraction components, and the software framework behaves as a set of interactions between an abstract component and its component instances. Software frameworks and software components are features that address the problem of feature areas and can be highly reusable designs.

Linux system is based on C language development, C language in textbooks will be considered as the process language. In fact, object-oriented is only a kind of software thinking, not limited to a language, but c++/java in the womb (compiler) has been supported, and C language through the struct data structure and function pointers can do a good job of object-oriented abstraction. Linux system is absolutely the use of C language for object-oriented programming pedigree, everywhere permeated with the brilliance of software art!

Second, understanding the software requirements is a prerequisite for learning good software framework

For learning, software requirements (the problem that software solves) and software frameworks already exist. But learners tend to focus only on software frameworks, because the ultimate goal of learning is to master the software framework and use it to solve their own problems. For general knowledge communicators (such as school teachers, institutional trainers, textbooks or web documents), it is often a focus on interpreting the composition and principles of the software framework.

In fact, for a software framework with a code volume of tens of thousands of or even hundreds of thousands of lines of code, learning Principles and code is not a good thing to start with. This approach is much like trying to derive the software requirements from the learning comprehension of the software framework, there are too many unknowns to contact the source code, the understanding process will be very painful, often feel very confused.

I think it will be more effective to understand the requirements in depth and to understand the software framework.

Even when it reaches a certain level, knowing the requirements, it is entirely possible to guess the implementation of the software framework.

Third, the software requirements of Linux system

For software requirements, the most easily linked to a specific business needs, such as the 12306 ticketing business and so on. Linux is an operating system, what are the software requirements of the operating system? The operating system is designed to provide a good interface to the application layer for bus device driver management, memory management, file management, process management and so on. Bus device driver Management is the topic we are going to talk about today. Linux platform has a variety of subsystems, a variety of bus, various drivers, Linux system management of them is the composition of software framework. To understand the existing framework of Linux, we need to be clear about the problems it solves, that is, what hardware devices they manage, what are the characteristics of those devices, and how they are accessed.

It can be said that in-depth understanding of the hardware system is a good understanding of the Linux Bus device driver Framework premise! From the object-oriented point of view, we need to find out what the physical hardware is, and how the corresponding software objects are expressed.

The following elaboration will focus on software requirements as a basis for future analysis frameworks.

Iv. bus, drive, equipment

1. Bus

The bus represents the same kind of equipment need to comply with the work sequence, the different bus for the physical level of the requirements are not the same, for each bit of the level to maintain the width is not the same, and the bus passed on the command will have its own format constraints. such as I²c bus, USB bus, PCI bus and so on. Taking the I²c bus as an example, different i²c devices are connected on the same set of i²c buses.

2. Equipment

The device represents the real, specific physical device, which is represented by the device's unique parameter properties on the software. An i²c slave connected to an I²C bus has a device address that identifies itself, and the address of the device determines whether the command sent by the main device responds to it.

3. Drive

The drive represents the way and the process of operating the equipment. For an application, the application open opens the device, and then the read accesses the device, and the driver is the specific process of how to implement the access. The main driver consists of two parts, the first is the control register of the SOC programming, according to the bus output timing and command, the successful interaction with peripheral devices; the second is to process the data obtained in the first step and provide the application layer with data in a specific format.

A. The driving process of different bus devices is not the same, this is easy to understand, USB mouse driver and i²c EEPROM read timing is certainly not the same, access timing generation and control is also part of the drive.

B. Device drivers for different device types on the same bus are not the same. such as the I²c capacitive screen device, for reading read is in the datasheet specified address to read the x and Y coordinates of the touch point, and the read operation of the I²c EEPROM is to read the contents of the storage, the two devices datasheet is not the same, the drive nature is not the same.

C. Device drivers for similar devices of the same type of bus may also be different. For example, for touch screens, TSC2003 only supports single touch, while ft5x06 supports multi-touch. When you get the touch coordinates, the former only needs to get the data of one point, and the latter needs to get the data that is currently several points and then read the coordinates of all the points.

Hardware resources such as GPIO and interrupts are typically used in driver operations, such as SDA and SCL, which are connected to the specific two gpio pins of the SOC chip, while I²c reads and writes generally in the form of interrupt control (the query reads and writes are done relatively inefficient, wasting CPU). If we are directly programmed in the driver for the specific pin, then this driver's platform portability is poor, because different product designs may pin differently. Therefore, in order to improve the portability of the drive, Linux will be used to drive the use of GPIO and interrupt resources stripped to the device to manage. That is, the device contains its own device properties and also includes the resources it uses to connect to the SOC. The drive focuses on the processes and methods of operation.

 

4. The bus

1th refers to the bus is only the physical meaning of the expression, the bus is in the industry to develop standards, clearly specify the format of the timing. In the 3rd, we talked about the generation and control of timing at the software level, which is driven by the driver. So we're going to think about what the bus's responsibilities are at the software level.

  the

Bus is primarily responsible for managing devices and drivers at the software level.

 

A. To make the system aware of its existence, the device needs to register itself with the bus; Similarly, drivers need to register themselves with the bus to make the system aware of their existence. Devices and buses must be initialized to know what kind of bus they are, and i²c devices and drivers cannot register with the USB bus.

 

B. Multiple devices and multiple drivers are registered on the same bus, how does the device find the driver that is best for them, or how does the driver find the device it supports? The bus is also responsible for this, the bus is like a matchmaker, responsible for the device and drive in the strings. The device will present itself to the bus driver conditions (the simplest and most accurate is to specify the name of the other party), and the driver will inform the bus to support the condition of the device (usually model ID, etc., the simplest can also be the name of the device). When the device is registered, the bus will traverse the driver registered on it, find the most suitable driver for the device, and then fill in the structure member of the device; When the driver registers, the bus will also traverse the device that is registered on it, find its supported devices (can be multiple, the relationship between the driver and the device is 1:n), And populate the driver's support list with the device. We call the bus the behavior of the strings as match. Once you've got the line, the interactive matchmaker between the device and the driver is no good.

 

C. Bus after matching device and driver to consider a problem, the device corresponding to the software data structure represents the static information, the real physical device is not necessarily normal at this time, so the driver needs to detect whether the device is normal. We call this behavior probe, as for how to detect, that is the drive to know what to do, the bus just command it. So we can guess that there is such logic in the management code of the bus:

 

If (Match (device, driver) = = OK)

Driver->probe ();

 

5. Further talk about the drive

Assuming the device is working properly, the probe succeeds, which means that the application can access the device through the driver. Is this actually the case? Think carefully about what is missing. What does the application layer access to operate this device? Do you remember that? The first article of the "Embedded Penguin ring" in our public, "Linux character device driver profiling", has clearly analyzed the development and access process for Linux character device drivers, and at the outset mentions how the application accesses the device:

int fd = open ("Device file name");

Read (FD, buf, Len);

Write (FD, buf, Len);

In this application will be involved in driving two problems, one is the device file name from, and the other is the application layer open, read and write corresponding to drive which interfaces, how to correspond. These are the problems that drive to solve.

A. After the bus is matched to the device and driver, the driver detects that the device is normal, and the driver is ready for the application layer to send it, but if the device file name is not created, the application does not know where to start. Therefore, it is the most appropriate time to create the device file immediately after the driver probe probe is successful. It can successfully create the corresponding device file in the/dev directory through the Sysfs file system, the Uevent event notification mechanism, and the background application service Mdev program.

B. The driver to provide the application layer open, read, write, IOCTL and other operations of the corresponding interface, and these interfaces to the system to prepare (register) themselves, or the system does not know how to call the driver, because in the above description from the beginning to the end is the device, drive and bus three things in the opera, they with the system , the strict meaning is with the Linux virtual file system and the device file system has not established the relationship. The driver is to include the following steps:

B1. Device to provide the interface defined by the struct file_operation structure:

struct File_operations {

Int (*open) (struct inode *, struct file *);

Int (*ioctl) (struct inode *, struct file *, ...);

ssize_t (*read) (struct file *, char __user *,...);

ssize_t (*write) (struct file *, const char __user *, ...);

...}

These interfaces will correspond to device access operations on the application tier. In these interfaces, it will perform its own operational tasks according to the requirements mentioned in the 3rd.

B2. The normal access process for the application layer is a specific device-driven operation, such as virtual file system operations, application-layer operations, and so on. The virtual file system VFS system already exists, the specific file system operation for the character device is very simple, we think is the character device file system Devfs, at this time the character device driver to do is to be their own struct file_operations to DEVFS registration, The corresponding character device driver is the Cdev_add function. The detailed analysis process can refer to "Linux character device driver profiling".

So we can imagine that there is a probe interface in the structure that drives the driver, the driver wants to implement this interface, and the work that this probe interface is going to accomplish includes:

Driver->probe ()

I. Detection equipment is normal

Ii.cdev_add (struct file_operations) Register operation interface

Iii. device_create () Creating a device file

6. Continue talking about Drive

When you are ready to do the above, wait for the application to access the operation. Through the entire process of open in the Linux character device driver profiling, to the end of the call to the specific driver open, next we will explain what the interfaces in the device-driven struct file_operations do. We pick a few main ones to say, the rest can be imagined.

A.open is typically driven by initialization, which may include initialization of the hardware and initialization of the software. When we talked about drivers in the 3rd, we stated that in order for the driver to be more portable, resources such as the specific GPIO and IRQ interrupts used to drive the driver process would be included in the property content of device devices. The Gpio and IRQ identifiers of the device data structure interrupts are then derived from the physical address definition of the SOC datasheet. We all know that Linux will use the MMU Memory Management unit of the SOC to manage its own memory when running, it will divide the memory into two parts, kernel space (3g-4g) and user space (0-3G), both of which are virtual linear address spaces, that is, the corresponding address space after the program compiles the link. The virtual address space needs to be mapped to the actual physical memory space through the MMU and page tables to eventually access resources such as physical memory and physical IO. While the drive operating hardware is in kernel space, the following operations are mainly included in the Open function:

A1. Access to resources such as GPIO and IRQ through the system-provided resource acquisition interface

A2. Mapping Gpio and IRQ from physical address space to virtual address space in 3G-4G through the Ioremap interface

A3. Set GPIO and IRQ-related registers according to the specific control specifications.

The above-initialized action may appear in the code that drives the probe probe, and the open interface can do nothing.

B. Read: Driven open if successful, the entire access process has been successfully more than half, because the open process is long and complex enough. Read simply finds the file structure of the owning process from the FD file handle of the user space and then finds the File_operations->read, which is the drive's read interface. Then according to the external network equipment specifications and the bus time to operate, to achieve the purpose of the read device. Write as well.

C. The IOCTL is generally a parameter setting for the device.

I recommend the following original articles, to help readers system, a comprehensive understanding of embedded Linux system architecture and drive development!

Understand the Linux series related blog posts from a demand perspective:

1. Linux character device driver profiling

2. Creation and Mdev of Linux device files

3. Character device driver Word, platform device driver, device driver model, SYSFS relationship

4. Linux modular mechanism and Module_init

5. Linux Interrupt Complete analysis

6. One of the Linux input subsystem analysis: Software hierarchy

7. Full network for the most clear and detailed analysis of the Linux input subsystem

8. The analysis of subsystems such as framebuffer, I²c and MTD are introduced successively

Public number: Embedded Penguin ring

1. Loyal to the Linux source code, hundred percent original.

2. From the first line of power up code, the first line of the system code, the first line of code, the application of the first line of code, in-depth explanation of the embedded software life cycle.
3 from the requirements, from the architectural perspective.

Understanding the Linux family from a demand perspective: bus, device and driver