Led subsystem analysis

Before writing, first look at a picture:

Last time I talked about the LED driver, Linux itself also carries the LED driver, which is out of the platform, that is, the LED subsystem. the operation is very simple. but its essence is not so easy, studied a night, finally understood the function of one of the files, machine led-class.c files. share it now.

In fact, the LED driver is located in the kernel driver/LEDs directory. core files are: led-class.c leds-s3c24xx.c, leds-gpio.c. first look at one of the files led-core.c files.

At first glance, we can see that the relationship with the class cannot be detached. What is the role of the class? What is the so-called class first? A group of devices are abstracted out of common characteristics. in fact, the leds-gpio.c and leds-s3c24xx.c functions are almost the same, the two are tied, they have a common function is implemented in the class. in general, the function of implementing led-class.c files is to first create a LEDs class, then create a device node under this class, and finally download several property files created on this device node. the leds_init (void) function is used to create a class. In this class, a device node is created, an attribute file is created under the node, and the property file is read and written.

Now let's take a look at the first one, that is, loading the file through init. The first sentence is also the core sentence, that is, creating a LEDs class, and assigning the function return value to led_cdev-> Dev, that is, led_cdev-> Dev = class_create (this_module, "LEDs"). This will generate a file under the Sys directory, that is, the name of the LEDs class file. The first parameter specifies the module to which the file belongs, the second device name is specified.

In the following example, is_err (LEDs-class) is used to determine whether LEDs-class is correctly generated. the next step is the function pointer. leds_class-> suspend = led_suspend and so on are function pointers, all of which have specific function implementations. suspend () is called when the device is sleeping, and resume () is called when the device is restored. the first suspend () function is actually called the brightness_set (led_cdev, 0) function, so let's talk about this function. this function is a member of the data structure led_classdev. It points to a function. Where does it point? In the leds-gpio.c at that time, pointing to the gpio_led_set function, in fact, the implementation is the level variable value. and in the leds-s3c24xx.c is almost. in general, the power supply is to assign a value to level when the device is suspended. If the value is 0 or 1, it depends on your active_low choice. now let's talk about resume (), which is actually the same as above. Finally, we use led_cdev-> brightness to assign a value to level. here, the leds_init function is OK. Finally, the eds_init will be initialized at system startup through subsys_initcall (leds_init.

To sum up, the leds_init function will be called when the system starts. the implemented function is to generate the LEDs class directory under the sys/class directory, and execute the brightness_set (led_cdev, *) function during suspension and recovery.

The led_classdev_register function is left behind.

As mentioned above, several files are generated. The first one is the device node. The first sentence of this function

led_cdev->dev = device_create(leds_class, parent, 0, led_cdev, "%s", led_cdev->name);

Function prototype

device_create(struct class *class, struct device *parent,dev_t devt, void *drvdata, const char *fmt, ...),

Look at the code implementation. One major function is Dev = device_create_vargs (class, parent, devt, drvdata, FMT, vargs), which is to generate a device node under the corresponding directory, first, let's take a look at the meaning of each parameter. The first parameter specifies the class of the device to be created, and the second parameter is the parent device of the device. If not, it is null, the third parameter is the device number, the fourth parameter is the device name, and the fifth parameter is the device number. let's take a look at the real parameter, the first real parameter leds_class. Where does this happen? In the previous leds_init function, the set-up class returns the value. Therefore, the device file node is established in the previous LEDs class.

The next sentence is also crucial. The device_create_file function adds the attribute file and several files, so we can add one of them.

Dev_attr_brightness. Where can this attribute be implemented? There are device_attr (brightness, 0644, led_brightness_show, led_brightness_store) on the top. The following two parameters implement read and write operations on the property file. Both operations have specific function implementations. specifically, the kernel will automatically call led_brightness_show when the cat command is used to read the attribute file. similarly, use the echo command to call the led_brightness_store function. Now let's see where these files are stored.

Split the code first.

int led_classdev_register(struct device *parent, struct led_classdev *led_cdev){led_cdev->dev = device_create(leds_class, parent, 0, led_cdev,     "%s", led_cdev->name);rc = device_create_file(led_cdev->dev, &dev_attr_brightness);}

In fact, this function is exported using export_symbol_gpl (led_classdev_register), called in the leds-gpio.c and leds-s3c24xx.c.

Let's take a look at the led_classdev_register function. There is a call in the leds-gpio.c, the following detection function

gpio_led_probe(struct platform_device *pdev)

Call

ret = create_gpio_led(&pdata->leds[i], &leds_data[i],  &pdev->dev, pdata->gpio_blink_set);

View

create_gpio_led(const struct gpio_led *template,struct gpio_led_data *led_dat, struct device *parent,int (*blink_set)(unsigned, unsigned long *, unsigned long *))

We can see that it calls ret = led_classdev_register (parent, & led_dat-> cdev );

We have discussed how to create a device node. we mainly look at Parent pointing to pdev-> Dev. because pdev is a platform device, it is related to the platform device. pdev-> Dev corresponds to the device under the platform device. so, for the device name of the device node, tracking the leds-gpio.c code, you know that the cdev in the leds-gpio.c corresponds to the above led_cdev

Led_dat-> cdev. Name = template-> name; // In the creat_gpio_led Function

The template corresponds to pdata-> LEDs [I].

struct gpio_led_platform_data *pdata = pdev->dev.platform_data;

In short, it is in the gpio_led_probe function that gets the platform information platform_data as a parameter passed to the template parameter of the creat_gpio_led function, and finally paid to led_dat-> cdev. name through this parameter.

Therefore, the name of the created dev node is determined by the information of your platform device.

Now let's take a look at where to generate the property file and look at the function.

device_create_file(led_cdev->dev, &dev_attr_brightness);

It mainly depends on the parameter led_cdev-> Dev, and where it points to. In fact, it is the return value when the device node is set up. You can refer to the above. therefore, an attribute file is created under the device node directory. Of course, the subsequent attribute files are the same.

Said here, the led-class.c is over, the remaining did not talk about the function or is the attribute Read and Write function, or is to uninstall the function, for the attribute file to the next part of the transplant will be explained. to sum up, for general classes, use class_creat to add your class, create a device file under the class directory in device_creat, and create an attribute file under the device node to perform operations on the device, however, this operation is generally read/write, which is implemented by command.

Well, the above meters Oh according to that figure shows in the class to establish four device nodes: led0-led4, each device node under the Property file, which has a brigtness, execute commands to this file. Cat reads data and echo writes data. For example, when Echo 1> brightness is executed on my board, the first light is on. when Echo 0> brightness is executed, the first light is not on. for the reason why the light is on and what will go off, we will explain in the LED porting article.

But here is still a problem: I have only four device nodes in the platform device, but how can there be eight led0-led4, to be resolved ..........................................

Next, the difference leds-gpio.c (leds-s3c24xx.c and leds_gpio.c) is the same, the code page is almost, which is mainly the platform model, that is, what hardware resources to store the kernel, how to store, then how can we get it .......

This article from: http://blog.csdn.net/shiyi_2012/article/details/7456165

Led subsystem analysis