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.