做Linux方面也有三個多月了，對程式碼中的有些結構一直不是很明白，比如platform_device與platform_driver一直分不清關係。在網上搜了下，做個總結。兩者的工作順序是先定義platform_device -> 註冊 platform_device->，再定義 platform_driver-> 註冊 platform_driver。

 （1）platform_device裝置的註冊過程必須在相應裝置驅動載入之前被呼叫，因為驅動註冊時需要匹配核心中所以已註冊的裝置名。platform_device 是在系統啟動時在init.c 裡的s3c_arch_init() 函式裡進行註冊的。這個函式申明為arch_initcall(s3c_arch_init); 會在系統初始化階段被呼叫。arch_initcall 的優先順序高於module_init，所以會在Platform 驅動註冊之前呼叫。現在核心中不是採用arch_initcall(s3c_arch_init) 註冊platform_device 結構體而是通過.init_machine成員將其儲存在arch_initcall(customize_machine)等待呼叫（在mach-smdk6410.c中定義的MACHINE_START到MACHINE_END）；其實質是一樣的均放在.initcall3.init等待呼叫。之後再定義結構體struct platform_driver，在驅動初始化函式中呼叫函式platform_driver_register() 註冊 platform_driver。詳細過程描述如下：

      Linux從2.6版本開始引入了platform這個概念，在開發底層驅動程式時，首先要確認的就是裝置的資源資訊，在2.6核心中將每個裝置的資源用結構platform_device來描述，該結構體定義在kernel/include/linux/platform_device.h中，

struct platform_device

{
      const char * name;
      u32  id;
      struct device dev;
      u32  num_resources;
      struct resource * resource;
};

 

該結構一個重要的元素是resource，該元素存入了最為重要的裝置資源資訊，定義在kernel/include/linux/ioport.h中，
比如：

struct resource 

{
       const char *name;
       unsigned long start, end;
       unsigned long flags;
       struct resource *parent, *sibling, *child;
};

例項如：

static struct resource s3c_usb_resource[] = {
 [0] = {
       .start = S3C_PA_USBHOST,
       .end   = S3C_PA_USBHOST + S3C_SZ_USBHOST - 1,
       .flags = IORESOURCE_MEM,
     },
 [1] = {
       .start = IRQ_UHOST,
       .end   = IRQ_UHOST,
       .flags = IORESOURCE_IRQ,
     }
};

 

以上是6410的USB  HOST分配的資源資訊。第1組描述了這個usb host裝置所佔用的匯流排地址範圍，起始地址和大小由硬體決定，IORESOURCE_MEM表示第1組描述的是記憶體型別的資源資訊；第2組描述了這個usb host裝置的中斷號，也由硬體設定，IORESOURCE_IRQ表示第2組描述的是中斷資源資訊。裝置驅動會根據flags來獲取相應的資源資訊。

      有了resource資訊，就可以定義platform_device了：

struct platform_device s3c_device_usb = {
         .name    = "s3c2410-ohci",  //s3c6410-usb
         .id    = -1,
         .num_resources   = ARRAY_SIZE(s3c_usb_resource),
         .resource   = s3c_usb_resource,
         .dev              = {
                 .dma_mask = &s3c_device_usb_dmamask,
                 .coherent_dma_mask = 0xffffffffUL
             }
};

有了platform_device就可以呼叫函式platform_add_devices向系統中新增該裝置了。系統中的裝置資源都可以採用這種方式列舉在一起，然後成一個指標陣列，如：

static struct platform_device *smdk6410_devices[] __initdata = {

......

 &s3c_device_usbgadget,
 &s3c_device_usb,  //jeff add.

......

}

然後在6410的初始化函式smdk6410_machine_init（）中執行：

platform_add_devices(smdk6410_devices, ARRAY_SIZE(smdk6410_devices));將所有的device新增進系統。platform_add_devices的好處在於它是一次性的執行多個platform_device_register。

（2） 至於驅動程式需要實現結構體struct platform_driver，也定義在kernel/include/linux/platform_device.h中：

struct platform_driver {
      int (*probe)(struct platform_device *);
      int (*remove)(struct platform_device *);
      void (*shutdown)(struct platform_device *);
      int (*suspend)(struct platform_device *, pm_message_t state);
      int (*suspend_late)(struct platform_device *, pm_message_t state);
      int (*resume_early)(struct platform_device *);
      int (*resume)(struct platform_device *);
      struct pm_ext_ops *pm;
      struct device_driver driver;
};

則該處的USB HOST實現是：

static struct platform_driver ohci_hcd_s3c2410_driver = {
     .probe  = ohci_hcd_s3c2410_drv_probe,
     .remove  = ohci_hcd_s3c2410_drv_remove,
     .shutdown = usb_hcd_platform_shutdown,
     /*.suspend = ohci_hcd_s3c2410_drv_suspend, */
     /*.resume = ohci_hcd_s3c2410_drv_resume, */
     .driver  = {
          .owner = THIS_MODULE,
          .name = "s3c2410-ohci",
        },
};

      在驅動初始化（ohci-hcd.c的1124行）函式中呼叫函式platform_driver_register()註冊該platform_driver，需要注意的是s3c_device_usb結構中name元素和ohci_hcd_s3c2410_driver 結構中driver.name必須是相同的，這樣在platform_driver_register()註冊時會對所有已註冊的platform_device中元素的name和當前註冊的platform_driver的driver.name進行比較，只有找到具備相同名稱的platform_device存在後，platform_driver才能註冊成功。當註冊成功時會呼叫platform_driver結構元素probe函式指標，這裡就是ohci_hcd_s3c2410_drv_probe開始探測載入。platform driver中的函式都是以platform device作為引數進入。

（3）為什麼兩個name的名字必須匹配才能實現device和driver的繫結？（1）在核心初始化時kernel_init()->do_basic_setup()->driver_init()->platform_bus_init()初始化platform_bus(虛擬匯流排)；（2）設備註冊的時候platform_device_register()->platform_device_add()->(pdev->dev.bus = &platform_bus_type)把裝置掛在虛擬的platform bus下；（3）驅動註冊的時候platform_driver_register()->driver_register()->bus_add_driver()->driver_attach()->bus_for_each_dev()，對每個掛在虛擬的platform bus的裝置作__driver_attach()->driver_probe_device()，判斷drv->bus->match()是否存在並且是否執行成功，此時通過指標執行platform_match，比較strncmp(pdev->name, drv->name, BUS_ID_SIZE)，如果相符就呼叫really_probe（實際就是執行的相應裝置的platform_driver->probe(platform_device)，注意platform_drv_probe的_dev引數是由bus_for_each_dev的next_device獲得）開始真正的探測載入，如果probe成功則繫結該裝置到該驅動。

      當進入probe函式後，需要獲取裝置的資源資訊，根據引數type所指定型別，例如IORESOURCE_MEM，來分別獲取指定的資源。
struct resource * platform_get_resource(struct platform_device *dev, unsigned int type, unsigned int num);當然，也可以固定資源型別，如獲取資源中的中斷號：struct int platform_get_irq(struct platform_device *dev, unsigned int num);

      probe函式一般完成硬體裝置使能，struct resource的獲取以及虛擬地址的動態對映和具體型別裝置的註冊（因為平臺裝置只是一種虛擬的裝置型別);remove函式完成硬體裝置的關閉，struct resource以及虛擬地址的動態對映的釋放和具體型別裝置的登出。只要和核心本身執行依賴性不大的外圍裝置 ( 換句話說只要不在核心執行所需的一個最小系統之內的裝置 ), 相對獨立的擁有各自獨自的資源 (addresses and IRQs) ，都可以用platform_driver 實現。如：lcd,usb,uart 等，都可以用platfrom_driver 寫，而timer,irq等最小系統之內的裝置則最好不用platfrom_driver 機制，實際上核心實現也是這樣的。

====================i2c驅動是如何probe的==================

 （1）在新加I2c裝置驅動時，i2C的device和driver是如何掛載到一起的？即probe是如何開始的，也會有如上類似的關聯。比如struct i2c_device_id,struct i2c_driver,i2c_add_driver,i2c_register_board_info，詳情見 http://blog.csdn.net/lanmanck/article/details/7836734，簡單明瞭。

（2）xxxxx_probe（struct i2c_client *, const struct i2c_device_id *）函式中兩個形參又是哪裡來的呢？參見http://bbs.csdn.net/topics/350096754

（3）4.4的i2c驅動可否在安卓6.0的系統中使用？答案是可以的。4.4的I2C裝置多用i2c_register_board_info來註冊，但在6.0上多用dts來關聯。有種簡單的辦法把4.4的驅動如何在6.0上使用，在i2c_init中起始位置用i2c_register_board_info來註冊上即可。

====================spi驅動是如何probe的==================

       對於具體的某個裝置驅動，有spi_register_driver註冊struct spi_driver結構變數，這裡面有spi_driver的id_table的name，還有spi_driver的driver的name，他們會在spi_match_device中與modalias進行字串匹配。