Platform设备驱动

一、platform 驱动的工作过程

platform模型驱动编程，需要实现platform_device(设备)与platform_driver（驱动）在platform(虚拟总线)上的注册、匹配，相互绑定，然后再做为一个普通的字符设备进行相应的应用，总之如果编写的是基于字符设备的platform驱动，在遵循并实现platform总线上驱动与设备的特定接口的情况下，最核心的还是字符设备的核心结构：cdev、 file_operations（他包含的操作函数接口）、dev_t(设备号)、设备文件（/dev）等，因为用platform机制编写的字符驱动，它的本质是字符驱动。

我们要记住，platform 驱动只是在字符设备驱动外套一层platform_driver 的外壳。

在一般情况下，2.6内核中已经初始化并挂载了一条platform总线在sysfs文件系统中。那么我们编写platform模型驱动时，需要完成两个工作：

实现platform驱动

实现platform设备

然而在实现这两个工作的过程中还需要实现其他的很多小工作，在后面介绍。platform模型驱动的实现过程核心架构就很简单，如下所示：

platform驱动模型三个对象：platform总线、platform设备、platform驱动。

platform总线对应的内核结构：struct bus_type–>它包含的最关键的函数：match() (要注意的是，这块由内核完成，我们不参与)

platform设备对应的内核结构：struct platform_device–>注册：platform_device_register(unregister)

platform驱动对应的内核结构：struct platform_driver–>注册：platform_driver_register(unregister)

那具体platform驱动的工作过程是什么呢：

设备(或驱动)注册的时候，都会引发总线调用自己的match函数来寻找目前platform总线是否挂载有与该设备(或驱动)名字匹配的驱动（或设备），如果存在则将双方绑定；

如果先注册设备，驱动还没有注册，那么设备在被注册到总线上时，将不会匹配到与自己同名的驱动，然后在驱动注册到总线上时，因为设备已注册，那么总线会立即匹配与绑定这时的同名的设备与驱动，再调用驱动中的probe函数等；

如果是驱动先注册，同设备驱动一样先会匹配失败，匹配失败将导致它的probe函数暂不调用，而是要等到设备注册成功并与自己匹配绑定后才会调用。

二、platform_device 结构体 VS platform_driver 结构体

这两个结构体分别描述了设备和驱动，二者有什么关系呢？先看一下具体结构体对比：

前面提到，实现platform模型的过程就是总线对设备和驱动的匹配过程。打个比方，就好比相亲，总线是红娘，设备是男方，驱动是女方：

红娘（总线）负责男方（设备）和女方（驱动）的撮合；
男方（女方）找到红娘，说我来登记一下，看有没有合适的姑娘（汉子）—— 设备或驱动的注册；
红娘这时候就需要看看有没有八字（二者的name 字段）匹配的姑娘（汉子）——match 函数进行匹配，看name是否相同；
如果八字不合，就告诉男方（女方）没有合适的对象，先等着，别急着乱做事 —— 设备和驱动会等待，直到匹配成功；
终于遇到八字匹配的了，那就结婚呗！接完婚，男方就向女方交代，我有多少存款，我的房子在哪，钱放在哪等等（ struct resource *resource），女方说好啊，于是去房子里拿钱，去给男方买菜啦，给自己买衣服、化妆品、首饰啊等等（int (*probe)(struct platform_device ***) 匹配成功后驱动执行的第一个函数），当然如果男的跟小三跑了（设备卸载），女方也不会继续待下去的（ **int (*remove)(struct platform_device *)）。

三、设备资源结构体

在struct platform_device 结构体中有一重要成员 struct resource *resource。

struct resource 
{
	resource_size_t start;  资源起始地址   
	resource_size_t end;   资源结束地址
	const char *name;      
	unsigned long flags;   区分是资源什么类型的
	struct resource *parent, *sibling, *child;
};

flags 指资源类型，我们常用的是 IORESOURCE_MEM、IORESOURCE_IRQ 这两种。start 和 end 的含义会随着 flags而变更，如

flags为IORESOURCE_MEM 时，start 、end 分别表示该platform_device占据的内存的开始地址和结束值；

flags为 IORESOURCE_IRQ 时，start 、end 分别表示该platform_device使用的中断号的开始地址和结束值；

下面看一个实例：

static struct  resource beep_resource[] =
{
	[0] = {
        	.start = 0x114000a0,
		.end = 0x114000a0+0x4,
        	.flags = IORESOURCE_MEM,
	},
	[1] = {
        	.start = 0x139D0000,
        	.end = 0x139D0000+0x14,
        	.flags = IORESOURCE_MEM,
	},
};

四、将字符设备添加到 platform的driver中

前面我们提到platform 驱动只是在字符设备驱动外套一层platform_driver 的外壳，下面我们看一下添加的过程：

static struct file_operations hello_ops=
{
	.open = hello_open,
	.release = hello_release,
	.unlocked_ioctl = hello_ioctl,
};
static int hello_remove(struct platform_device *pdev)
{
	注销分配的各种资源
}
static int hello_probe(struct platform_device *pdev)
{
	1.申请设备号
	2.cdev初始化注册,&hello_ops
	3.从pdev读出硬件资源
	4.对硬件资源初始化，ioremap，request_irq( )
}
static int hello_init(void)
{
	只注册 platform_driver
}
static void hello_exit(void)
{
	只注销 platform_driver
}

可以看到，模块加载和卸载函数仅仅通过paltform_driver_register()、paltform_driver_unregister() 函数进行 platform_driver 的注册和注销，而原先注册和注销字符设备的工作已经被移交到 platform_driver 的 probe() 和 remove() 成员函数中。

五、platform是如何匹配device和driver

这时就该总线出场了，系统为platform总线定义了一个bus_type 的实例platform_bus_type，其定义如下：

struct bus_type platform_bus_type = {
	.name        = "platform",
	.dev_groups    = platform_dev_groups,
	.match        = platform_match,
	.uevent        = platform_uevent,
	.pm        = &platform_dev_pm_ops,
};

其又是怎样工作的呢？在platform.c (e:\linux-3.14-fs4412\drivers\base) 31577 2014/3/31 中可以看到

__platform_driver_register（）
{
	drv->driver.bus = &platform_bus_type;     536行
}

在 platform_bus_type 中调用了platform_match：

static int platform_match(struct device *dev, struct device_driver *drv)
{
	struct platform_device *pdev = to_platform_device(dev);
	struct platform_driver *pdrv = to_platform_driver(drv);
	匹配设备树信息，如果有设备树，就调用 of_driver_match_device() 函数进行匹配
	if (of_driver_match_device(dev, drv))
		return 1;
	匹配id_table
	if (pdrv->id_table)
		return platform_match_id(pdrv->id_table, pdev) != NULL;
	最基本匹配规则
	return (strcmp(pdev->name, drv->name) == 0);
}

六、解决问题

为什么要用 platform 驱动？不用platform驱动可以吗？

设备驱动中引入platform 概念有什么好处？

引入platform模型符合Linux 设备模型 —— 总线、设备、驱动，设备模型中配套的sysfs节点都可以用，方便我们的开发；当然你也可以选择不用，不过就失去了一些platform带来的便利；

设备驱动中引入platform 概念，隔离BSP和驱动。在BSP中定义platform设备和设备使用的资源、设备的具体匹配信息，而在驱动中，只需要通过API去获取资源和数据，做到了板相关代码和驱动代码的分离，使得驱动具有更好的可扩展性和跨平台性。

Platform设备驱动