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 autonomous
entities in the system. This includes legacy port-based devices and
host bridges to peripheral buses. 


Platform drivers
~~~~~~~~~~~~~~~~
Drivers for platform devices have typically very simple and
unstructured. Either the device was present at a particular I/O port
and the driver was loaded, or there was not. There was no possibility
of hotplugging or alternative discovery besides probing at a specific
I/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 on
other architectures and on some modern architectures. In most cases,
the drivers are modified to discover the devices at other well-known
ports for the given platform. However, the firmware in these systems
does usually know where exactly these devices reside, and in some
cases, it's the only way of discovering them. 


The Platform Bus
~~~~~~~~~~~~~~~~
A platform bus has been created to deal with these issues. First and
foremost, it groups all the legacy devices under a common bus, and
gives them a common parent if they don't already have one. 

But, besides the organizational benefits, the platform bus can also
accomodate firmware-based enumeration. 


Device Discovery
~~~~~~~~~~~~~~~~
The platform bus has no concept of probing for devices. Devices
discovery is left up to either the legacy drivers or the
firmware. These entities are expected to notify the platform of
devices 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 globally
standard 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 other
platforms. 

Since both PnP IDs and the legacy I/O ports (and other standard I/O
ports for specific devices) have a 1:1 mapping, we map the
platform-specific name or identifier to a generic name (at least
within the scope of the kernel).

For example, a serial driver might find a device at I/O 0x3f8. The
ACPI firmware might also discover a device with PnP ID (_HID)
PNP0501. Both correspond to the same device should be mapped to the
canonical name 'serial'. 

The bus_id field should be a concatenation of the canonical name and
the instance of that type of device. For example, the device at I/O
port 0x3f8 should have a bus_id of "serial0". This places the
responsibility of enumerating devices of a particular type up to the
discovery 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 as
the canonical name of the devices they support. This allows the
platform bus driver to do simple matching with the basic data
structures to determine if a driver supports a certain device. 

For example, a legacy serial driver should have a name of 'serial' and
register itself with the platform bus. 


Driver Binding
~~~~~~~~~~~~~~
Legacy drivers assume they are bound to the device once they start up
and probe an I/O port. Divorcing them from this will be a difficult
process. However, that shouldn't prevent us from impelementing
firmware-based enumeration. 

The firmware should notify the platform bus about devices before the
legacy drivers have had a chance to load. Once the drivers are loaded,
they driver model core will attempt to bind the driver to any
previously-discovered devices. Once that has happened, it will be free
to discover any other devices it pleases.