Linux-driven platform platform bus working principle (i)

5, 5, 4, platform platform bus working principle

5, 5, 4, 1, what is platform bus

(1) Platform bus is different from i²c, USB, SPI, PCI bus, they belong to the physical bus, platform bus is a virtual bus, abstract out, platform bus device does not correspond to the real existence of a device, This kind of bus is not in real physics. For example, I²c has a physical i²c bus, but the platform bus does not physically have such a bus.

(2) CPU and external communication, there are two ways to connect, one is called address bus-type connection, one is called dedicated interface connection, some devices are connected by address bus, CPU we use 32-bit CPU, addressable space has 4G, there is a register, corresponding to a real physical address, and in the Harvard architecture , registers and memory the same address, so the control of these registers can be addressed through the CPU to find and thus write registers, that is, write memory to operate, these methods are for the address bus type of access, but some devices can not be accessed through the address bus type, cannot be linked in a address bus way, such as Nandflash,nandflash and CPUs outside the SOC are not linked through address bus, but are linked through a dedicated NAND interface, There are SD cards are linked through the SD card protocol, as well as USB devices, USB devices through the USB protocol interface, and the CPU to link, these belong to the private interface, dedicated interface and address bus-type devices to access the difference is that address bus-type equipment, in the future to visit, We directly through the address to access the contents of the device can be, such as dm9000 network card, we can directly through the CPU address, to operate the method of the address, like write registers can be manipulated into the dm9000 card registers, because dm9000 is extended to the address bus interface, The address of the register in the dm9000 is connected to the address bus of the CPU via the address map, which is the address bus interface.

(3) The Platform bus device, which is extended to the 32 address bus on the type of equipment, extended to the address bus on the device with platform bus access. The platform bus corresponds to the address bus type of connection device, that is, the SOC internal integration of various internal peripherals, because these internal peripherals, many are extended to the address bus up, then corresponding to the software layer, is the use of platform platform bus way to link access work. In addition to those that are not extended to the CPU address bus, such as i²c devices, SPI devices, USB devices, they use a self-bus, such as the I²c bus, and extended to the CPU address bus on the device, with the platform bus, on the software, Now most of the equipment has been extended to the address bus up, so platform platform bus with a lot of, many devices will be used.

(4) Thinking: Why should I have a platform bus? Further thinking, why do we have the concept of a bus?

Because there are some peripherals he is directly extended to the CPU of the address of the bus link, so this kind of equipment can say there is no bus concept, such as LED, buzzer (timer), this kind is can directly through the address can be accessed, they do not have the concept of bus, do not want to i²c bus, He corresponds to the real presence of the I²C bus equipment, but we can not engage in a bus and no bus, do not unify, because this will feel very messy, you also have to distinguish who has the bus, who does not have a bus, so all the equipment has a bus, the real bus equipment, like i²c equipment, You have the I²C bus you use the rules of the I²c bus to play, but there is no real bus equipment, with the address to access the device, give them a platform bus to connect them to use, so we say the platform bus is virtual.

The concept of the bus is to allow the device and driver under the bus to be managed. Whether it is the virtual bus or the real bus, they have devices and drivers, they need to be managed, so there is the concept of the bus, because the bus in Linux, the following two branches, one is a device branch, a drive branch, device and driver have names, The bus uses the name to match the device and the driver to manage, because the light has no drive can not work, the light has the drive and no equipment can not work, but there will be a lot of equipment, the driver will have more, can not be disorganized management, so there is a bus to manage, the same bus is a class of equipment, The device under the platform bus is the device that expands to the CPU address bus, the driver of these devices is the following. Platform bus and other bus work is not very different, because the platform bus is used for reference and other bus to achieve, so we now only take the platform bus to analyze, the same reason and other I²c bus

5.5.4.2, the two generals under the platform bus

(1) Platform work system is defined in/drivers/base/ PLATFORM.C, the file in the base does not need us to move the code, is written by the kernel of a basic architecture, PLATFORM.C is platform implementation principle, he as a mechanism in the kernel, he is also by the kernel personnel implementation. The realization of his own we just need to understand, understand it can be, do not need to write, we just use him, how to use him to write platform equipment and platform equipment corresponding to the driver. The purpose of the bus is to manage the device and drive, so he has two branches below, one is the device and the other is the driver, so we study the bus, which is to study how he manages the devices and drives underneath him. We learn is the drive, is the system in the last device, then the corresponding driver and this device corresponds to, this is the purpose of our learning drive. So we have to study how the devices and drivers under the bus are written and how they find each other to work.

(2) Two structures: Platform_device and Platform_driver, one is the device structure of the platform bus, the other is the driving structure of the platform bus. A device structure body platform_device, is the platform bus under a specific abstraction out of the device, the structure of the type defined variables, each defined by the variable, is a device in the platform bus, platform_ Driver The structure type defines each variable, is the platform bus under each drive, has several platform bus's device to define several platform_device variables, has several platform bus's drive to define several platform_driver variables

(3) Two interface functions: Platform_device_register and Platform_driver_register.

After using Platform_device and platform_driver to define the corresponding variables of the device and driver, we use these two interface functions to register the defined device and the driver respectively, and two are registered, and the rest will not need us to control.

Let's start by analyzing the Platform_device structure:

struct Platform_device {

const char *name; //platform bus under the name of the device

int ID;

BOOL Id_auto;

struct deviceDev; Some of the parts of the properties that are common to each device are included in this structure, so a struct device structure is required for each Platform_device platform bus.

U32 num_resources; //The number of resource used by the device, what is called resource? Resource is a kind of resource, in the kernel is a limited number of things are called resources, such as the interrupt number, the interrupt is a resource in the IO, for example, which part of the IO address, the general resources here are IO and interrupt number

struct resource *resource; //An exact resource, such as an IO with a memory address range is a resource, such as an interrupt number corresponding to a resource, a memory address is the scope of resources, they all by this

Represents the structure of the resource to be defined, so we define a resource to use the resources defined as an array of resources, the resource array contains a lot of elements, each element is a resource, are

A struct variable of type resource, such as a struct within a device Resurce three, is a struct resource array with three elements, the first element may

Represents the interrupt number used by this device, the second element is the memory address he uses, the third element is the Gpio number, and how much, in short, this STRUVT resource is used to record the current

What resources are used for the device, because each device may have more than one resource, so each device internally defines a struct-resource-type structure pointer, which is a resource array

And Num_resouces is the number of resources used, he is struct resource type of struct pointer, array of elements.

So struct resource *resource is the first address of the resource array used by this device. Num_resource is the number of resources, can be seen as an index of the array, the two elements added up

It tells us the first address of the resource array and the number of elements in the resource array, so we can take all the contents of this resource array, because you know the first address and array elements

Number, why is it defined as two, a pointer to the number of elements of the array, an array of pointers to the first address, rather than directly defining a struct array, that is because of the defect of the array, cannot

Know the number of elements in the array beforehand, if the number of elements must be written to die the next time you need to re-change, so defined as two separate form, will compensate for this problem

const struct PLATFORM_DEVICE_ID *id_entry; //This is also an array, in order to save memory, do not let platform_device occupy too much memory, so the use of pointers to point to the way, rather than directly using the way the array

Device ID table for the same series of different device models, such as NAND this series of products, may release 5 of the 10 kinds of NAND, but their difference is not big,

Just the size is different, but the operation is the same, for the driver, a driver can operate the 5 Nandflash, but we also want to know what the 5 is going on,

/So a platform_device_id is used as a Device ID table, which is an array that contains many ID numbers, and when driven, it is based on the ID number and name in the ID table.

Match, as this is used for the same series of products, the product is only slightly different, and these different nuances are represented by this ID table, which is very clear in Nandflash.

/* MFD cell pointer */

struct Mfd_cell *mfd_cell;

/* Arch Specific additions */

struct Pdev_archdata archdata; ////private plots, leave us with our own, you can put something unique to the device here, to provide extensibility, because it is possible that your device is a unique, so you can let yourself

To extend

};

Because a platform_device corresponds to a device under a specific platform bus, there must be a struct device, which is an abstraction of the device, a piece of information that is common to all devices, So none of the devices need to have a struct device structure because of the part that he has in common with the device.

In analyzing the PLATFORM_DRIVER structure:

struct Platform_driver {

Int (*probe) (struct platform_device *); //drive detection function, when our driver finds a device, the driver calls this probe function to try to detect if this device is the device that I drive.

How to know this device is not my driver to control it, very simple, write a simple communication with this device code on the line (generally

is to write the initialization code for this device), see if this device has any feedback

Information, the feedback information is correct, I know this device is not my driver to control, similar to Insmod when the corresponding function, similar to the device initialization operation

Can be seen as the installation of the device. But first, the device that is the current driver can be detected, and the device is initialized.

Int (*remove) (struct platform_device *); //used to remove a device, remove the device supported by the current driver, similar to uninstalling the device, the device is not visible in the system at this time

void (*shutdown) (struct platform_device *); //Shut down a device and let a work stop control, at which point this device can be seen in the system.

Int (*suspend) (struct Platform_device *, pm_message_t State); //suspend a device, such as power management, temporarily suspend a device, such as the system into standby, you need to

The device is suspended.

Int (*resume) (struct platform_device *); //Resume a suspended state, and when the system standby state is over, use this function to restore the suspended state of the device. The wake function.

struct Device_driver driver; //All device drivers share some of the attributes, which are the abstractions in the driver's kernel-driven framework, the previous note was recorded

const struct PLATFORM_DEVICE_ID *id_table; ///Device ID table, because a driver may have knowledge of multiple devices, such as NAND drive, NAND a driver may support multiple devices, then you need to support those devices

All written to this driver ID table, in the future as long as the ID in the Device ID table corresponds to the ID in this Driver ID table, you can use this driver to operate

};

This platform_driver is the bus corresponding to the driver of the template, the function of those pointers in the future to point to those functions, is that we write the driver, to write the function, the function is written, the function pointer to the written function, and then call the registration

Use the interface function to register this well-populated platform_driver structure.

This article from "Whylinux" blog, declined reprint!

Linux-driven platform platform bus working principle (i)