基于platform总线的驱动分析

基于platform总线的驱动分析

在设备驱动模型中，总线负责将设备和驱动绑定。在系统每注册一个设备的时候，会寻找与之匹配的驱动；相反的，在系统每注册一个驱动的时候，会寻找与之匹配的设备，而匹配由总线完成。
为什么要有这种匹配机制？难道不是很多余吗？原因详见Linux设备驱动模型与sysfs文末

1.platform总线基本概念

• 设备和驱动若基于设备驱动模型，则它们通常都需要挂接在一种总线上。总线相对于设备和驱动，可谓是“媒人”担当
• 对于本身依附于 USB、 I2C、SPI 等的设备而言，这自然不是问题。但是很多的设备（比如led）实际并不依附于总线，没了“媒人”，设备和驱动怎么产生联系呢？于是内核为这些可怜的设备发明了一种虚拟的总线——platform（平台总线）
• 挂接在platform上的设备和驱动，就称之为platform_device，和platform_driver

2.platform总线驱动工作流程

• 提供并注册platform_device/设备节点
• 提供并注册platform_driver
• 当platform总线内的mach函数会不停的匹配driver和device（老内核是根据driver内的id、name元素；新内核是根据of_match_table中的compatible）
• 一旦匹配成功，则调用driver的probe（探测）函数开始正式执行驱动代码

3.platform总线驱动的独立性和适应性

一个platform总线驱动程序可以对应多个设备，并且设备的变化也不会影响驱动。这是如何实现的呢？

• 简单的说，这是一种类似传参的机制。设备将底层信息（比如寄存器信息、使用到的中断号、设备名称等）传递给驱动，驱动本身代码不用变，只需要根据参数操作底层，便可适应设备的变化
• 现代驱动设计理念就是算法和数据分离，驱动源码中不携带数据，只负责算法（对硬件的操作方法），这样最大程度保持驱动的独立性和适应性
• 具体的实现方法是：老内核中，platform_device包含了一个device结构体，其内部有一个 void *platform_data; 这个有点类似于给用户提供的自留地，用户可以在里面存放各种底层信息。当driver的probe（探测）函数执行时，platform_device会作为参数传进去，这样驱动就能够间接的得到这个 void *platform_data，从而据此操作硬件；新内核则直接在设备节点属性中存放数据，驱动通过API读取节点里的数据

4.老内核下platform总线驱动的编写方法

下面，以led驱动为实例，分析怎么使用platform来写驱动

• 根据上图的流程，首先应该进入mach-xxx.c完成platform设备的注册。
  
  • 第一步：创建适用于我们设备的platform_data类型（为自留地设计一种格式）
  • 第二步：为一个具体设备实例化一个platform_data，用来存放该类设备的底层信息
  • 第三步：创建一个具体platform设备（实例化一个platform_device），并把各种信息和platform_data填充入该设备
  • 第四步：把platform设备丢到专门存放platform_device的数组中，开机时系统会注册数组中所有设备
• 先来看看mach-xxx.c中的情况，如果我们要写新的platform_device，要注意mach-xxx.c内有没有重复功能的。在该mach-xxx.c搜寻“platform”，寻找专门存放platform_device的数组，发现里面并没有led，看来我们要自己从头开始写了

/*sjh_add*/

/*第一步：创建一个适用于我们设备的platform_data类型*/
struct s5pv210_led_platdata {
    unsigned int         gpio;
    unsig