Linux device-driven platform bus practice session (III)

1, in the Platform bus practice link in one and two, respectively, the LED Platform_driver and Platform_device initially completed, next see Platform_device and platform_driver simultaneously exist effect, Is the LED platform device has been registered to the kernel, and in the root file system Ismod loaded on the LED platform bus driver. See what happens to Platform_device and Platform_driver, depending on the logic of the Platform platform bus, because we've registered the Platform_device of the LEDs in the kernel, At this time we only need to load the LED platform_driver, according to the device and the driver logic, when the LED driver loading, will execute that ismod when the corresponding function, will be led Platform_driver Register, This time in the platform bus led Platform_device and Platform_driver have been registered to the platform bus, then the match function will be based on the device and the name of the driver to match the device and drive, when the LED device and driver match, The driver's probe function is executed, we add a print message to the probe function in the current incomplete led driver code, the probe function code is as follows

static int why_led_probe (struct platform_device *dev) {int ret = -1;PRINTK (kern_info "why_led_probe\n");//led1// Populate the struct Led_classdev type we want to register Myled1.name = "led1";//The name of the LED file in the future sys/class/leds/directory. LEDs this directory in LED-CLASS.C the kernel to help us achieve good, myled1.brightness = 255;myled1.brightness_set = whyx210_led1_set;// Go to the LED driver frame to provide us with the LED registration function Led_classdev_register go to register the driver//in LED-CLASS.C int led_classdev_register (struct device *parent, struct Led_classdev *led_cdev) ret = Led_classdev_register (NULL, &myled1); if (Ret < 0) {PRINTK (kern_err "Led_ Classdev_register errro\n "); return ret;} return 0;}

In the first sentence of the code to add print information, print the name of the probe function, next we can verify that when the platform_device of the LED in the kernel, when we load the LED platform_driver, is not through the Platform bus match function with the device and the driver name will be matched and execute the driver code of the probe function, if the probe function is executed, then the probe function start printing information will certainly print out.

After booting the system, loading the LED's Platform_driver driver module, the print information is actually printed in the console, and one more why_ in the/sys/bus/platform/driver/why_led/directory Led.1 directory, stating our name for the Why_led platform bus driver matching on a device, the name of this device is called Why_led.1, is that we have registered to the bus under the LED1 device.

Because the probe function was executed, the function in the probe

ret = Led_classdev_register (NULL, &myled1);

The registration function will be executed, because the execution succeeds, so in the/sys/class/leds/directory we will see a led1 such a directory, the name of this directory is we populate MYLED1 this structure when the name,led1 directory has a brightness, is the myled1 structure of the brightness, to represent the brightness of the LED, our MYLED1 structure has a member function Brightness_set binding is Whyx210_led1_set function, whyx210_led1_ The set function is as follows

static void Whyx210_led1_set (struct Led_classdev *led_cdev, enum led_brightness value) {//PRINTK (Kern_info whyx210_led _set\n "); Writel (0x11111111, Gpj0con), if (value = = Led_off) {//user input 0 o'clock off the corresponding user input is echo 0 > Brightnesswritel (READL ( Gpj0dat) | (1 << 3), gpj0dat);} else if (value = = Led_full) {//user input 255 light corresponds to user input is echo 255 > Brightnesswritel (READL (Gpj0dat) & ~ (1 << 3), Gpj0da T);//This operation keeps other bit values unchanged}}

When we call echo 0 or echo 1 o'clock in the/sys/class/leds/led1/brightness file, this function of the sand surface is called to manipulate the brightness of the led1. When echo 0 or Echo 1 is to this brightness file, 0 or 1 will be passed in as the parameter value of the function above. thereby controlling the hardware.

This time to echo brightness file, it is really possible to control the brightness of the LED, but this time our driver is not perfect, because we drive in the probe function of the LED data is written dead, including name, the corresponding operation function, and the corresponding PIN number of the LED, These things in our probe function is written dead, so our driver code is not good, we want to take advantage of the probe function of the Platform_device type parameter, the device variable to get to the device variable platform_data, From this data to know what the Gpio number of this led device, what is the name of the LED, and other data, so from the LED device can be achieved and this led driver matching, the execution of the probe function is real-time access to the device data, Then populate the MYLED1 struct variable to register the class. This is flexible and has generality.

We need to define in the probe function the type of struct variable that we use to populate the device data when we write the LED device, get the platform_data part of the variable of the Platform_device type of the probe function, and get the data part of the LED device. , and then register in the probe function, the myled member value is not the use of the write dead led name, but through the platform_data to get name and then register, so that real-time matching real-time registration.

Static int why_led_probe (Struct platform_device *dev) {int ret = -1;struct  s5pv210_led_platdata *pdata = dev->platform_data;    // Get a match on the data portion of the device//fill in the struct body of the Struct led_classdev type we want to register myled.name = pdata->name; // The name of the LED device on the current match myled.brightness = 255;myled.brightness_set = whyx210_led1_set;// This myled Brightness_set method binding can not actually be fixed whyx210_led1_set this method, because we                                               // The driver and equipment matching is not fixed is led1, it is possible that the LED2 device is also matched with this driver, the total can not led2                                               //How to use the method of led1//To call the LED registration function provided for us in the LEDs driver frame led_classdev_ Register to register the drive//Int led_classdev_register in LED-CLASS.C (struct device *parent, struct  Led_classdev *led_cdev) Ret = led_classdev_register (null, &myled);if  (ret  < 0) &NBSP;{PRINTK (kern_err  "led_classdev_register errro\n"); Return ret;} return 0;}

The above code mentions in the comments about Myled's Birghtness_set method binding that this function cannot be written to death, so it should be solved with other design logic ideas. The next blog is saying.

This article from "Whylinux" blog, declined reprint!

Linux device-driven platform bus practice session (III)