Drive develops reading notes. 0.05 Linux 2.6 Platform device register platform equipment registration 2/2 Total 2 articles

Drive develops reading notes. 0.05 Linux 2.6 Platform device register platform equipment registration 2/2 Total 2 articles

The following excerpt from the Linux source documents:  kernel version 2.6.22
Documentation/driver-model/platform.txt
Found an article: http://blog.csdn.net/yili_xie/article/details/5193609

Device enumeration ~~~~~~~~~~~~~~~~~~ as a rule, platform specific (and often board-specific) Setup code would 84  Register Platform devices:85 int platform_device_register (struct platform_device *pdev);  platform_add_devices int (struct platform_device **pdevs, int ndev); The general rule was to register only those devices that actually exist, and in some cases extra devices might b  E registered. For example, a kernel might is configured to work with an external network adapter that might not the is populated on  All boards, or likewise-to-work with a integrated controller 94 that some boards might not hooks up to any peripherals.   In some cases, boot firmware would export tables describing the devices, that is populated on a given board. Without such tables, often the 98 only if the system Setup code to set up the correct devices are to build a kernel  For a specific target board. Such board-specific Kernels is comMon with embedded and custom systems development. 101 102 In many cases, the memory and IRQ resources associated with the platform 103 device is not enough to let the Devi  Ce ' s driver work. Board Setup Code 104 would often provide additional information using the device ' s platform_data the field to hold addition Al information. 106 107 Embedded Systems frequently need one or more clocks for platform devices, 108 which is normally kept off until th EY ' re actively needed (to save power). 109 System Setup also associates those clocks with the device, so that's calls to Clk_get (&pdev->dev, Clock_ Name) return them as needed. 111 113 Legacy Drivers:device probing, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~, Some Drivers is not fully converted T  o The driver model, because they take in a non-driver role:the driver registers its platform device, rather than 117  Leaving this for system infrastructure. Such drivers can ' t be hotplugged 118 or coldplugged, since those MechanisMs require device creation to is in a 119 different system component than the driver. 121 The only "good" reason-is-handle older system designs which, like 122 original IBM PCs, rely on error-  Prone "probe-the-hardware" models for hardware 123 configuration. Newer systems has largely abandoned that model, with favor of 124 Bus-level support for dynamic configuration (PCI, USB), O  R device tables provided by the boot firmware (e.g. PNPACPI on x86).  There is too many 126 conflicting options about what might is where, and even educated guesses by 127 an operating system 'll is wrong often enough to make trouble.  129 This style of driver is discouraged. If you ' re updating such a driver, the "try to move" device enumeration to a more appropriate location, 131 outsid  E the driver. This would usually be cleanup, since such drivers the tend to already has "normal" modes, such as ones using device nodes That 133 were created by PNP or by platform device setup. 134 135 None, there is some APIs to support such legacy drivers. Avoid 136 using these calls except with such hotplug-deficient drivers. 137 138 struct Platform_device *platform_device_alloc (139 const char *name, int id); 141 You can use Platform_device_alloc () to dynamically allocate a device, which 142 you'll then initialize with Reso Urces and Platform_device_register ().                        143 A Better solution is usually:144 145 struct Platform_device *platform_device_register_simple (146 const char *name, int ID, 147 struct resource *res, unsigned int nres); 148 149 You can use Platform_device_register_simple () as a one-step call to allocate and register a device.

The previous article is about the first type of platform device registration http://www.cnblogs.com/simonlin/p/5933010.html

This article is about

Legacy Drivers:  Device probing

Kernel developers do not recommend this approach, but we use this method to dynamically load platform device modules
There are two functions mentioned in the document.

struct Platform_device *platform_device_alloc (const char *name, int id);

And
struct Platform_device *platform_device_register_simple (const char *name, int id, struct resource *res, unsigned int nres) ;


platform_device_register_simple function definition (DRIVERS/BASE/PLATFORM.C)

struct Platform_device *platform_device_register_simple (char *name, unsigned int id, 374                                                        struct resource *res, unsigned int num) 375{376        struct platform_device *pdev; 377        int retval; 378 379        Pdev = Platform_device_alloc ( Name, id); 380        if (!pdev) {381                retval =-enomem; 382                goto error; 383        } 384 385        if (num) {386                retval = plat Form_device_add_resources (Pdev, res, num); 387                if (retval) 388                        goto error; 389        } 390 391 retval        = Platform_device_add (Pdev); 392        if ( retval) 393                goto Error, 394 395        return pdev; 396 397 error:398        platform_device_put (Pdev); 399        Return Err_ptr (retval); 400}

We found that the original platform_device_register_simple called the Platform_device_alloc

Pdev = Platform_device_alloc (name, id);

and also registered platform equipment.

retval = Platform_device_add (Pdev);


So, we want to dynamically register Platfrom_device just call

The Platform_device_register_simple function can

Input parameters are device name, ID, resource and resource quantity

*      platform_device_register_simple*      @name:  base name of the device we ' re adding*      @id:    Instance ID*      @res: Set of resources that needs to being allocated for the   device*      @num:   number of resources   

Example: DRIVERS/LEDS/LEDS-NET48XX.C
This is an LED platform driver

   1   /* 2 * LEDs driver for Soekris net48xx   3 *   4 * Copyright (C) 2006 Chris Boot <[email prote Cted]>   5 *   6 * Based on LEDS-AMS-DELTA.C 7 * 8 * This program was free software; you can re Distribute it and/or modify 9 * It under the terms of the GNU general public License version 2 as ten * published By the free software Foundation.            one by one *

......

......

......

  net48xx_led_probe static int (struct Platform_device *pdev),        led_classdev_register (& Pdev->dev, &net48xx_error_led);  59}

......

......

......

static int __init net48xx_led_init (void)-------  INT-        ret;  Bayi        Small/* hack, but Scx200_gpio doesn ' t set. Dev if the probe fails *  *        if (!scx200_gpio_ops.de V) {                n-ret =-enodev;  -                goto out;  The        platform_driver_register (&net48xx_led_driver);        if (Ret < 0)-                goto out;        Pdev = Platform_device_register_simple (Drvname,-1, NULL, 0);        if (Is_err (Pdev)) {  94                ret = Ptr_err (Pdev);                Platform_driver_unregister (&net48xx_led_driver);                goto out;  98  out:100        return ret; 101}

......

......

......

It can be seen that the LED platform device is registered in the driver.
and the drive detection function probe registered an LED class device

Note: This function does not provide a way to add platform data.

You can try to manually add the platform data before registering the device, but this method is not validated.

Drive develops reading notes. 0.05 Linux 2.6 Platform device register platform equipment registration 2/2 Total 2 articles