platform device/platform driver/platform bus解釋整理

 

Platform Device and Drivers
從<linux/platform_device.h>我們可以瞭解Platform bus上面的驅動模型介面：platform_device，platform_driver。和PCI和USB這些大結構的匯流排不同，虛擬匯流排Platform bus使用最小結構來整合SOC processer上的各種外設，或者各種“legacy”之間的互聯。

 

Platform device
典型的Platform device是系統中的各種自主裝置，包括各種橋接在外圍匯流排上的port-based device和host，以及各種整合在SOC platform上的控制器。他們都有一個特點，那就是CPU BUS可以直接定址，或者特殊的情況platform_device串連在其他匯流排上，但是它的寄存器是可以被直接定址的。
Platform device有一個名字，用來進行driver的綁定；還有諸如中斷，地址之類的一些資源清單

 

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

Platform drivers
Platform driver滿足標準driver model，對driver的discovery/enumeration是在driver外部進行的，driver提供了probe()和 remove()方法.Platfomr dirvers通過標準模型提供power management和shutdown通知。

 

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 device_driver driver;
};

 

Probe()函數必須驗證指定裝置的硬體是否真的存在，probe()可以使用裝置的資源，包括時鐘，platform_data等，Platform driver可以通過下面的函數完成對驅動的註冊：
int platform_driver_register(struct platform_driver *drv);
一般來說裝置是不能被熱插拔的，所以可以將probe()函數放在init段裡面來節省driver運行時候的記憶體開銷：
int platform_driver_probe(struct platform_driver *drv,
     int (*probe)(struct platform_device *))

 

Device Enumeration
作為一個規則，平台(一般來說是板級)啟動代碼會註冊所有的Platform device：
int platform_device_register(struct platform_device *pdev);
int platform_add_devices(struct platform_device **pdevs, int ndev);
一般來說只會註冊那些實際存在的裝置，不過也存在特殊的情況，比如kernel可能需要與一個不在板子上的外部網路介面卡工作，或者那些不掛在任何匯流排上的控制器。
一般情況下，韌體啟動的過程會輸出一個描述板子上所有存在裝置的表。如果沒有這個表，系統啟動代碼建立正確的裝置的唯一方法就是為一個特定的板子編譯一個kernel。這種board-specific kernel廣泛用在嵌入式和一般系統的開發上。
在大部分情況下，裝置的memory和IRQ資源不足夠讓驅動正常工作。board setup code會用device的platform_data域來為裝置提供一些額外的資源。
嵌入式系統上的裝置會頻繁地使用一個或者多個時鐘，這些時鐘因為節電的原因只有在真正使用的時候才會被開啟，系統在啟動過程中會為裝置分配時鐘，可以通過clk_get(&pdev->dev, clock_name)來獲得需要的時鐘。

 

Legacy Drivers ： Device Probing
一些driver並不會完全遵守標準driver model，這些driver會去註冊自己的platform device，而不是讓系統來完成註冊。這是不值得推
薦的，主要用來相容以前的一些舊裝置。可以通過下面的API來支援這些legacy driver，一般這些API使用在不支援熱插拔的driver上面：
 struct platform_device *platform_device_alloc(
   const char *name, int id);
可以使用platform_device_alloc動態地建立一個裝置，一個更好的方法是，通過下面的函數動態建立一個裝置，並把這個裝置註冊到系統中：
 struct platform_device *platform_device_register_simple(
   const char *name, int id,
   struct resource *res, unsigned int nres);

 

Device Naming and Driver Binding
platform_device.dev.bus_id是一個裝置在匯流排上的名字，它包含兩部分：
  ＊ platform_device.name   裝置名稱字，用來進行driver的匹配
  ＊ platform_device.id     裝置執行個體的標號，如果是-1，表示同樣名字的裝置只有一個
舉個簡單的例子，name/id是“serial/1”則它的bus_id就是serial.1  如果name/id是“serial/0”則它的bus_id就是serial.0 ,如果它的name/id是“serial/-1”則它的bus_id就是serial。
driver的綁定是通過driver core自動完成的，完成driver和device的匹配後以後會自動執行probe()函數，如果函數執行成功，則driver和device就綁定在一起了，drvier和device匹配的方法有3種：
  ＊ 當一個裝置註冊的時候，他會在匯流排上尋找匹配的driver，platform device一般在系統啟動很早的時候就註冊了
  ＊ 當一個驅動註冊[platform_driver_register()]的時候，他會遍曆所有匯流排上的裝置來尋找匹配，在啟動的過程驅動的註冊一般比較晚，或者在模組載入的時候
  ＊ 當一個驅動註冊[platform_driver_probe()]的時候， 功能上和使用platform_driver_register()是一樣的，唯一的區別是它不能被以後其他的device probe了，也就是說這個driver只能和一個device綁定。

 

 

 

 

 

      Platform device 和 Platform driver實際上是cpu匯流排可以直接定址的裝置和驅動，他們掛載在一個虛擬匯流排platform_bus_type上，是一種bus-specific裝置和驅動。與其他bus-specific驅動比如pci是一樣的。他們都是將device和device_driver加了一個warpper產生，仔細看看platform_device就可以看到它必然包含一個device dev，而platform_driver也一樣，它必然包含一個device_driver driver。
      所有的裝置通過bus_id掛在匯流排上，多個device可以共用一個driver，但是一個device不可以對應多個driver。驅動去註冊時候會根據裝置名稱尋找裝置，沒有裝置會註冊失敗，註冊的過程會通過probe來進行相應資源的申請，以及硬體的初始化，如果probe執行成功，則device和driver的綁定就成功了。裝置註冊的時候同樣會在匯流排上尋找相應的驅動，如果找到他也會試圖綁定，綁定的過程同樣是執行probe。

       把核心相關部分的源碼基本過一遍就瞭解了這種新的驅動管理和註冊機制，可以參照我在資源裡面傳的兩個文檔～～

 

Platform Devices and Drivers~~~~~~~~~~~~~~~~~~~~~~~~~~~~Platform devices~~~~~~~~~~~~~~~~Platform devices are devices that typically appear as autonomousentities in the system. This includes legacy port-based devices andhost bridges to peripheral buses. Platform drivers~~~~~~~~~~~~~~~~Drivers for platform devices have typically very simple andunstructured. Either the device was present at a particular I/O portand the driver was loaded, or there was not. There was no possibilityof hotplugging or alternative discovery besides probing at a specificI/O address and expecting a specific response.Other Architectures, Modern Firmware, and new Platforms~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~These devices are not always at the legacy I/O ports. This is true onother architectures and on some modern architectures. In most cases,the drivers are modified to discover the devices at other well-knownports for the given platform. However, the firmware in these systemsdoes usually know where exactly these devices reside, and in somecases, it's the only way of discovering them. The Platform Bus~~~~~~~~~~~~~~~~A platform bus has been created to deal with these issues. First andforemost, it groups all the legacy devices under a common bus, andgives them a common parent if they don't already have one. But, besides the organizational benefits, the platform bus can alsoaccomodate firmware-based enumeration. Device Discovery~~~~~~~~~~~~~~~~The platform bus has no concept of probing for devices. Devicesdiscovery is left up to either the legacy drivers or thefirmware. These entities are expected to notify the platform ofdevices that it discovers via the bus's add() callback:platform_bus.add(parent,bus_id).Bus IDs~~~~~~~Bus IDs are the canonical name for the device. There is no globallystandard addressing mechanism for legacy devices. In the IA-32 world,we have Pnp IDs to use, as well as the legacy I/O ports. However,neither tell what the device really is or have any meaning on otherplatforms. Since both PnP IDs and the legacy I/O ports (and other standard I/Oports for specific devices) have a 1:1 mapping, we map theplatform-specific name or identifier to a generic name (at leastwithin the scope of the kernel).For example, a serial driver might find a device at I/O 0x3f8. TheACPI firmware might also discover a device with PnP ID (_HID)PNP0501. Both correspond to the same device should be mapped to thecanonical name 'serial'. The bus_id field should be a concatenation of the canonical name andthe instance of that type of device. For example, the device at I/Oport 0x3f8 should have a bus_id of "serial0". This places theresponsibility of enumerating devices of a particular type up to thediscovery mechanism. But, they are the entity that should know best(as opposed to the platform bus driver).Drivers ~~~~~~~Drivers for platform devices should have a name that is the same asthe canonical name of the devices they support. This allows theplatform bus driver to do simple matching with the basic datastructures to determine if a driver supports a certain device. For example, a legacy serial driver should have a name of 'serial' andregister itself with the platform bus. Driver Binding~~~~~~~~~~~~~~Legacy drivers assume they are bound to the device once they start upand probe an I/O port. Divorcing them from this will be a difficultprocess. However, that shouldn't prevent us from impelementingfirmware-based enumeration. The firmware should notify the platform bus about devices before thelegacy drivers have had a chance to load. Once the drivers are loaded,they driver model core will attempt to bind the driver to anypreviously-discovered devices. Once that has happened, it will be freeto discover any other devices it pleases.