platform总线、设备与驱动

platform平台设备驱动是基于设备总线驱动模型的，它只不过是将 device 进一步封装成为 platform_device，将 device_driver 进一步封装成为 platform_device_driver,前面已经分析过设备总线驱动模型，关于device 与 device_driver 的注册过程以及它们在sysfs文件系统中的层次关系就不在分析，本文重点分析platform平台设备驱动与设备总线驱动模型相比较新增添的那些东西。

在Linux 2.6 的设备驱动模型中，关心总线、设备和驱动3个实体，总线将设备和驱动绑定。在系统每注册一个设备的时候，会寻找与之匹配的驱动；相反的，在系统每注册一个驱动的时候，会寻找与之匹配的设备，而匹配由总线完成。

一个现实的Linux设备和驱动通常都需要挂接在一种总线上，对于本身依附于PCI、USB、I2C、SPI等的设备而言，这自然不是问题，但是在嵌入式系统里面，SoC系统中集成的独立的外设控制器、挂接在SoC内存空间的外设等确不依附于此类总线。基于这一背景，Linux发明了一种虚拟的总线，称为platform总线，相应的设备称为platform_device，而驱动成为 platform_driver。

注意，所谓的platform_device并不是与字符设备、块设备和网络设备并列的概念，而是Linux系统提供的一种附加手段，例如，在 S3C6410处理器中，把内部集成的I2C、RTC、SPI、LCD、看门狗等控制器都归纳为platform_device，而它们本身就是字符设备。

基于Platform总线的驱动开发流程如下：
a -- 定义初始化platform bus //已由内核完成
b -- 定义各种platform devices
c -- 注册各种platform devices
d -- 定义相关platform driver
e -- 注册相关platform driver
f -- probe()中操作相关设备

 

1、平台相关结构 --- platform_device结构体

struct platform_device {
const char *name;/* 平台设备的名称，该名称在设备注册时，会拷贝到dev.init_name中。该名称最终会与platform_driver的id_table匹配*/
int id; //设备id，用于给插入给该总线并且具有相同name的设备编号，如果这个名字的设备只有一个的话填-1。
bool id_auto;
struct device dev;//真正的设备，通过 container_of ,就能找到整个platform_device ，访问其它成员，如后面要提到的 resource
u32 num_resources;// 设备所使用各类资源数量
struct resource *resource;//定义平台设备的资源，该设备的资源描述，由struct resource（include/linux/ioport.h）结构抽象。

const struct platform_device_id *id_entry;

/* MFD cell pointer */
struct mfd_cell *mfd_cell;

/* arch specific additions */
struct pdev_archdata archdata;
};
resource结构体也是描述platform_device的一个重要结构体 该元素存入了最为重要的设备资源信息
在Linux中，系统资源包括I/O、Memory、Register、IRQ、DMA、Bus等多种类型。这些资源大多具有独占性，不允许多个设备同时使用，因此Linux内核提供了一些API，用于分配、管理这些资源。 
    当某个设备需要使用某些资源时，只需利用struct resource组织这些资源（如名称、类型、起始、结束地址等），并保存在该设备的resource指针中即可。然后在设备probe时，设备需求会调用资源管理接口，分配、使用这些资源。而内核的资源管理逻辑，可以判断这些资源是否已被使用、是否可被使用等等。

struct resource {
resource_size_t start;
resource_size_t end;
const char *name;
unsigned long flags;
struct resource *parent, *sibling, *child;
};
我们通常关心start，end，flags。它们分别标明了资源的开始值，结束值和类型，flags可以为IORESOURCE_IO,IORESOURCE_MEM,IORESOURCE_IRQ,IORESOURCE_DMA等，start,end的含义会随着flags变更，如当flags为IORESOURCE_MEM时，start,end分别表示该platform_device占据的内存的开始地址和结束地址；当flags为,IORESOURCE_IRQ时，start,end分别表示该platform_device使用的中断号的开始值和结束值，如果只使用了1个中断号，开始和结束值相同。对于同种类型的资源而言，可以有多份，例如某设备占据了两个内存区域，则可以定义两个IORESOURCE_MEM资源。

对resource的定义也通常在BSP的板文件中进行，而在具体的设备驱动中通过platform_get_resource()这样的API来获取，此API的原型为：
struct resource *platform_get_resource(struct platform_device *dev， unsigned int type,unsigned int num)
例如在\arch\arm\mach-at91\Board-sam9261ek.c板文件中为DM9000网卡定义了如下的resource
static struct resource at91sam9261_dm9000_resource[] = {
[0] = {
.start = AT91_CHIPSELECT_2,
.end = AT91_CHIPSELECT_2 + 3,
.flags = IORESOURCE_MEM
},
[1] = {
.start = AT91_CHIPSELECT_2 + 0x44,
.end = AT91_CHIPSELECT_2 + 0xFF,
.flags = IORESOURCE_MEM
},
[2] = {
.start = AT91_PIN_PC11,
.end = AT91_PIN_PC11,
.flags = IORESOURCE_IRQ
}
};
在DM9000网卡驱动中则是通过如下办法拿到这3份资源
db->addr_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
db->data_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
db->irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
对于irq而言platform_get_resource()还有一个进行了封装的变体platform_get_irq(),
api原型是
int platform_get_irq(struct platform_device *dev, unsigned int num)
{
struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);
return r ? r->start : -ENXIO;
}
实际上这个函数也是调用platform_get_resource(dev, IORESOURCE_IRQ, num)来获取资源

设备除了可以在BSP中定义资源以外，还可以附加一些数据信息，因为对设备的硬件描述除了中断，内存等标准资源以外，可能还会有一些配置信息，这些配置信息也依赖于板，不适宜直接放置在设备驱动上，因此，platform也提供了platform_data的支持，例如对于dm9000