platform平台总线工作原理

何为平台总线？
(1)相对于usb、pci、i2c等物理总线来说，platform总线是虚拟的、抽象出来的。
(2)CPU与外部通信的2种方式：地址总线式连接和专用接口式连接。平台总线对应地址总线式连接设备，也就是SoC内部集成的各种内部外设。

平台总线下管理的2员大将
1.platform工作体系都定义在drivers/base/platform.c中

2.两个结构体：platform_device和platform_driver
platform_device和platform_driver都在:linux/platform_device.h中。
struct platform_device {
const char * name; // 平台总线下设备的名字
int id;
struct device dev; // 所有设备通用的属性部分
u32 num_resources; // 设备使用到的resource的个数
struct resource * resource; // 设备使用到的资源数组的首地址

const struct platform_device_id	*id_entry;	// 设备ID表

/* arch specific additions */
struct pdev_archdata	archdata;			
// 自留地，用来提供扩展性的

};

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 (*resume)(struct platform_device *); 恢复
struct device_driver driver; // 所有设备共用的一些属性
const struct platform_device_id *id_table; // 设备ID表
};

3.两个接口函数：platform_device_register和platform_driver_register，都定义在drivers/base/platform.c中中。

平台总线体系的工作流程
(1)第一步：系统启动时在bus系统中注册platform
(2)第二步：内核移植的人负责提供platform_device
(3)第三步：写驱动的人负责提供platform_driver
(4)第四步：platform的match函数发现driver和device匹配后，调用driver的probe函数来完成驱动的初始化和安装，然后设备就工作起来了。

platform本身注册：
kernel_init
调用：
do_basic_setup
调用：
driver_init
调用：
platform_bus_init

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);

/* match against the id table first */
if (pdrv->id_table)
	return platform_match_id(pdrv->id_table, pdev) != NULL;

/* fall-back to driver name match */
return (strcmp(pdev->name, drv->name) == 0);

}

static const struct platform_device_id *platform_match_id(
const struct platform_device_id *id,
struct platform_device *pdev)
{
while (id->name[0]) {
if (strcmp(pdev->name, id->name) == 0) {
pdev->id_entry = id;
return id;
}
id++;
}
return NULL;
}
分析：platform_driver 里面会有一个id_table表来记录所有支持的platform_device 。其实都是用name来匹配的。

总线匹配：
(1)每种总线（不光是platform，usb、i2c那些也是）都会带一个match方法，match方法用来对总线下的device和driver进行匹配。理论上每种总线的匹配算法是不同的，但是实际上一般都是看name的。
(2)platform_match函数就是平台总线的匹配方法。该函数的工作方法是：如果有id_table就说明驱动可能支持多个设备，所以这时候要去对比id_table中所有的name，只要找到一个相同的就匹配上了不再找了，如果找完id_table都还没找到就说明每匹配上；如果没有id_table或者每匹配上，那就直接对比device和driver的name，如果匹配上就匹配上了，如果还没匹配上那就匹配失败。

---

以leds-s3c24xx.c为例来分析platform设备和驱动的注册过程
在mach-mini2440.c中有platform_device 的定义：
static struct platform_device mini2440_led1 = {
.name = “s3c24xx_led”,
.id = 1,
.dev = {
.platform_data = &mini2440_led1_pdata,
},
};
static struct platform_device mini2440_led2 = {
.name = “s3c24xx_led”,
.id = 2,
.dev = {
.platform_data = &mini2440_led2_pdata,
},
};
static struct platform_device mini2440_led3 = {
.name = “s3c24xx_led”,
.id = 3,
.dev = {
.platform_data = &mini2440_led3_pdata,
},
};
static struct platform_device mini2440_led4 = {
.name = “s3c24xx_led”,
.id = 4,
.dev = {
.platform_data = &mini2440_led4_pdata,
},
};
static struct platform_device mini2440_led_backlight = {
.name = “s3c24xx_led”,
.id = 5,
.dev = {
.platform_data = &mini2440_led_backlight_pdata,
},
};
分析：
1.有name，match需要的
2.id号码
3.platform_data，这个device的程序，到时候会作为platform_device 到
platform_driver数据的传导者。

我们可以看一下platform_data的定义
static struct s3c24xx_led_platdata mini2440_led1_pdata = {
.name = “led1”,
.gpio = S3C2410_GPB(5),
.flags = S3C24XX_LEDF_ACTLOW | S3C24XX_LEDF_TRISTATE,
.def_trigger = “heartbeat”,
};

static struct s3c24xx_led_platdata mini2440_led2_pdata = {
.name = “led2”,
.gpio = S3C2410_GPB(6),
.flags = S3C24XX_LEDF_ACTLOW | S3C24XX_LEDF_TRISTATE,
.def_trigger = “nand-disk”,
};

static struct s3c24xx_led_platdata mini2440_led3_pdata = {
.name = “led3”,
.gpio = S3C2410_GPB(7),
.flags = S3C24XX_LEDF_ACTLOW | S3C24XX_LEDF_TRISTATE,
.def_trigger = “mmc0”,
};

static struct s3c24xx_led_platdata mini2440_led4_pdata = {
.name = “led4”,
.gpio = S3C2410_GPB(8),
.flags = S3C24XX_LEDF_ACTLOW | S3C24XX_LEDF_TRISTATE,
.def_trigger = “”,
};

static struct s3c24xx_led_platdata mini2440_led_backlight_pdata = {
.name = “backlight”,
.gpio = S3C2410_GPG(4),
.def_trigger = “backlight”,
};
platdata的作用：
(1)platdata其实就是设备注册时提供的设备有关的一些数据（譬如设备对应的gpio、使用到的中断号、设备名称····）
(2)这些数据在设备和驱动match之后，会由设备方转给驱动方。驱动拿到这些数据后，通过这些数据得知设备的具体信息，然后来操作设备。
(3)这样做的好处是：驱动源码中不携带数据，只负责算法（对硬件的操作方法）。现代驱动设计理念就是算法和数据分离，这样最大程度保持驱动的独立性和适应性。

---

我们再看platform_driver部分
static struct platform_driver s3c24xx_led_driver = {
.probe = s3c24xx_led_probe,
.remove = s3c24xx_led_remove,
.driver = {
.name = “s3c24xx_led”,
.owner = THIS_MODULE,
},
};

static int __init s3c24xx_led_init(void)
{
return platform_driver_register(&s3c24xx_led_driver);
}
match函数调用顺序：
platform_driver_register
调用：
driver_register
调用：
bus_add_driver
调用：
driver_attach
调用：
__driver_attach
调用：
driver_match_device
调用：
return drv->bus->match ? drv->bus->match(dev, drv) : 1;
终于找到match函数了。

probe函数的调用：
platform_driver_register
调用：
driver_register
调用：
bus_add_driver
调用：
driver_attach
调用：
__driver_attach
调用：
driver_probe_device
调用：
really_probe
调用：
/首先看总线有没有probe函数，若有则调用，而平台总线没有probe/
if (dev->bus->probe) {
ret = dev->bus->probe(dev);
if (ret)
goto probe_failed;
}
/然后看驱动有没有probe函数，若有则调用，/
else if (drv->probe) {
ret = drv->probe(dev);
if (ret)
goto probe_failed;
}