Linux device Driven Development-platform device driver Application Example Analysis __linux

http://blog.csdn.net/zqixiao_09/article/details/50888795

We have learned the theoretical knowledge of platform devices in front of Linux device driver development--platform device driver, the following will be an example to delve into our learning.

first, the platform driven work process

Platform model-driven programming requires the implementation of Platform_device (device) and platform_driver (drive) registration on platform (virtual bus) , Match , bind to each other, and then do the corresponding application for a common character device, in short, if you are writing a platform driver based on the character device, in the case of following and implementing the specific interface of the platform bus that drives the device, The core of the character device is the core structure: Cdev, File_operations (he contains the Operation function interface), dev_t (device number), equipment file (/dev), etc., because the character driver written by the platform mechanism, its essence is character-driven.

We want to remember that the platform drive is just a layer of platform_driver in the character device-driven coat shell.

In general, a platform bus is already initialized and mounted in the 2.6 kernel in the Sysfs file system. So when we write platform model drivers, we need to do two jobs:

A--Implement platform drive

B--Implement platform equipment

However, many other small tasks need to be implemented in the implementation of these two tasks, which are described later. The core architecture of the platform model-driven implementation process is simple, as follows:

Platform Drive model three objects:platform bus ,platform device ,platform Drive .

Platform bus corresponding to the kernel structure: struct bus_type--> It contains the most critical function: match (note that this piece is completed by the kernel, we do not participate)

Platform device corresponding to the kernel structure: struct platform_device--> registration: platform_device_register (unregister)

Platform drive corresponding kernel structure: struct platform_driver--> registration: platform_driver_register (unregister)

What is the specific platform-driven process of work?

When a device (or driver) registers, it will cause the bus to call its own match function to find out whether the current platform bus has a driver (or device) that matches the name of the device (or driver) and, if it exists, binds the two sides;

If the device is registered first, the driver has not yet registered, then when the device is registered on the bus, it will not match the driver with the same name, and then when the driver is registered on the bus, the bus will immediately match the device and driver with the same name as the binding, and then call the probe function in the driver. and so on;

If the driver is first registered, the same as the device driver will match the failure, matching failure will cause its probe function is not called, but to wait until the device registration is successful and matching the binding will not be invoked.

Second, the implementation of platform drive and equipment detailed process

1, think about the problem.

Before you analyze platform, consider the following questions:

A-why use the platform drive. No platform drive, okay?

B--What are the benefits of introducing the platform concept in device drivers.

Now do not answer, read the following analysis will be clear, followed by a summary.

2. Platform_device Structural body VS platform_driver structure

The two structures describe the device and the driver, respectively. Let's look at the concrete structure contrast

Device (Hardware part): Interrupt number, register, DMA etc                    PLATFORM_DEVICE structure	driver (software part)                           p Latform_driver structure
struct platform_device {     const char    * Name       Name     int        id;     bool        id_auto;     struct device     Dev ; The   hardware module must contain the structure     u32         num_ Resources ;         resource number      struct resource    * Resource        &NBSP resources   Networking     const struct platform_ device_id    * Id_entry ;     /* arch specific additions */    struct  pdev_archdata    archdata; };	struct platform_driver {     int  (* probe ) (struct  platform_device *);    &NBSP calls the function     int  (* remove ) after the hardware and software match succeeds (struct platform_device *);      Hardware Uninstall calls this function     void  (*shutdown) (struct  platform_device *);     int  (*suspend) (struct platform_device *, pm_message_t state);     int  (*resume) (struct platform_device *);     struct device_driver  driver ; All drivers in the kernel must contain the structure      const struct platform_device_id * id_table ;  ;
Device instance: static struct Platform_device hello_device= {. Name = "BigBang",. id =-1,. dev.release = Hello_release, };	Driver instance: static struct Platform_driver hello_driver= {. Driver.name = "BigBang",. Probe = Hello_probe,. Remove = Hello_remove,};

As mentioned earlier, the process of implementing the platform model is the matching process of the bus to the device and the driver. For example, like a blind date, the bus is matchmaker, equipment is the man, drive is the woman:

A--matchmaker (bus) is responsible for the man (equipment) and the woman (driver) of the matchmaking;

B--The Man (the woman) found matchmaker, said I came to register, to see if there is a suitable girl (man)- equipment or driver registration ;

C-Matchmaker at this time need to see if there is no ( Name field ) matching Girl (man)-matchfunction matches to see whether the name is the same;

D-If the case is not right, tell the man (the woman) there is no suitable object, wait, don't rush to do things--equipment and drive will wait until the match is successful;

E--finally met the match of the eight, then marry Bai. Get married, the man told the woman, I have how much deposit, where my house, where the money put and so on ( struct resource *resource), the woman said yes, so go to the house to take money, to buy food for the man, to buy their own clothes, cosmetics, jewelry and so on ( Int (*probe) (struct Platform_device *) matches the first function after successful driver execution), of course if a man runs off with a third ( device uninstall ), the woman will not continue to stay ( Int (* Remove) (struct Platform_device *)).

3. Equipment Resource Structure Body

There is an important member in the struct Platform_device structure struct resource *resource [CPP] view plain copy struct resource {RE  source_size_t start;   Resource start address resource_size_t end;             Resource End Address const char *name;   unsigned long flags;   Distinction is the resource of what type of struct resource *parent, *sibling, *child;      }; #define IORESOURCE_MEM 0x00000200 #define IORESOURCE_IRQ 0x00000400

Flags refer to the types of resources, and we often use IORESOURCE_MEM and IORESOURCE_IRQ. The meaning of start and end will change with flags, as

A--when the flags are Ioresource_mem , start and end represent the starting address and the ending value of the memory occupied by the Platform_device respectively;

B--When the flags are IORESOURCE_IRQ , start and end represent the starting address and the ending value of the interrupt number used by the Platform_device;

Let's look at an example: [CPP] view plain copy static struct resource beep_resource[] = {[0] = {&nbs