Linux subsystem series-PCI

If you are free these days, simply sort out the PCI items. For PCI, the "PCI things" of fudan_abc hero is the best. Here we will make some preparations based on some work notes and take a look at the general framework for memo.

0, Background

1. PCI driver structure

2. PCI driver implementation

3. About PCI Core

------------------------------------------------------------------------------

0, Background

PCI, a bus standard that existed more than a decade ago, has a long history of vitality. Although there are many extensions based on PCI, devices that comply with PCI standards are still everywhere. There are two possible reasons: the PCI bus standard greatly reduces the difficulty and complexity of writing hardware device drivers; the Linux Driver Model abstracts the drivers of PCI devices, further reducing the difficulty of PCI drivers. In addition to individual commercial purposes, the design considers end users or developers. The market will surely return you a great deal ,:)

Before analyzing or writing a PCI driver, you must understand the whole picture of the PCI system on the computer. Most of the following articles refer to fudan_abc:

The structure of PCI involves the concept of bridge. The so-called bridge is used to connect multiple PCI bus or PCI bus to ISA and other bus. Host bridge is a special one in various bridges. It connects the CPU and PCI bus 0 and is integrated into the North Bridge we often call (the North Bridge and the south bridge are also called the chipset, north Bridge is the closest to the CPU in the chipset ). After understanding host bridge, let's take a look at PCI bus0, which is the primary PCI bus and the primary PCI bus. There may also be PCI bus1 and PCI bus2, but PCI bus0 must exist. A system can have multiple PCI bus, the connection between these PCI bus depends on another bridge, PCI-PCI bridge. Through the PCI-PCI bridge, the whole PCI system constitutes a hierarchical tree structure, these trees are like the hub is the same as the USB device, PCI-PCI bridge and other various bridges are also PCI devices. Each PCI bus can support 32 PCI devices, and each device can support 8 more functions. The so-called devices generally refer to the specific cards, devices, and chips on the PCI bus, each PCI Card can have several functional modules that share the same PCI Card. Logically, each functional module is a logical device.

After understanding the structure of the PCI system, the concept of bus enumeration comes again:

According to the specification, each PCI device has such a table, that is, the so-called configuration register. The corresponding driver compilation must depend on this table. Some of the contents in this table are solidified in the chip of the PCI device, and access to the PCI device is required. However, in the first place, only the PCI bus0 can be accessed. Other PCI buses and devices are still unknown. To make these unknown known, you need to enumerate the bus. During system boot, for the PCI subsystem, there will first be a phase of bus enumeration, scanning from PCI bus0, when a device is a PCI-PCI bridge, it specifies a new bus number, for example, 1, so that PCI bus1 will have it, and you can continue scanning. If you encounter another PCI device, record it, until all the PCI-PCI bridges and PCI devices are aired to form the system's PCI tree.

1. PCI driver structure

The drivers of PCI devices are generally divided into two layers. The bottom layer is the Linux PCI core subsystem, and the upper layer is based on the specific chip.

2. Implementation of PCI driver

A complete PCI driver must complete the following tasks:

1) define a table of devices supported by the driver

Static const struct pci_device_id listen 64x_pci_tbl [] = {
{Pci_vdevice (CMD, pci_device_id_0000_643), 0 },
{Pci_vdevice (CMD, pci_device_id_0000_646), 1 },
{Pci_vdevice (CMD, pci_device_id_0000_648), 2 },
{Pci_vdevice (CMD, pci_device_id_0000_649), 3 },
{0 ,},
};

2) during compilation, the driver will use the module_device_table macro to pass the list to build system (not kernel)

When we make module_install, the contents of this table will be translated into the content of a database of module and installed on the user side.

When the system discovers a new PCI device, the PCI core sends a notification to the kernel, which then forwards the notification to the listener (udev) of the User-layer notifications through the uevents mechanism. Udev parses the device information of the notification from the uevent and calls modprobe. Then, modprobe analyzes modules. Alias based on the information and installs the corresponding modules.

3) use the PCI core API: pci_register_device () to register the device information.

4) The PCI core scans for matching drivers based on the registered device information. If found, the PCI core calls the probe function to allow the driver to obtain control of the PCI device.

 

3. About PCI Core

Linux engineers abstract PCI-related operations unrelated to the platform/chip to form the PCI core subsystem. In addition to some PCI-related APIs, this subsystem can also conveniently and quickly register the driver to the kernel in a way that complies with the Linux device model specifications.

Needless to say, all used products say:

1) maintain the same external interface as possible to increase the portability of your driver.

2) Use/sysfs to provide some common interfaces to the user side to facilitate management and debugging.

3) Enable udev to automatically create nodes in the/dev directory for the PCI device and load the required module.