【总结】设备树对platform平台设备驱动带来的变化

最新推荐文章于 2024-08-13 16:35:42 发布

【星星之火】

最新推荐文章于 2024-08-13 16:35:42 发布

阅读量5.2k

点赞数 13

分类专栏： tiny4412之linux学习 tiny4412-linux4.x及设备树学习

本文链接：https://blog.csdn.net/fengyuwuzu0519/article/details/74375086

版权

tiny4412-linux4.x及设备树学习同时被 2 个专栏收录

7 篇文章 16 订阅

订阅专栏

tiny4412之linux学习

6 篇文章 4 订阅

订阅专栏

最初我们学习设备树的时候，第一个例子是按键中断，其采用了设备树的方式。我们以此为例分析设备树引入对platform平台驱动的改变。

tiny4412学习(四)之移植linux-设备树（1）设备树基础知识及GPIO中断：http://blog.csdn.net/fengyuwuzu0519/article/details/74177978

一、改变与不变

（1）platform_driver的入口函数，仍采用platform_driver_register注册（不变）

static int __init int_demo_init(void)  
{  
    int ret;  
  
    ret = platform_driver_register(&int_demo_driver);  
    if (ret)  
        printk(KERN_ERR "int demo: probe failed: %d\n", ret);  
  
    return ret;  
}  
module_init(int_demo_init);

（2）平台驱动：稍微的变化，多了of_match_table成员

static struct platform_driver int_demo_driver = {  
    .driver        = {  
        .name      = "interrupt_demo",  
        .of_match_table    = of_match_ptr(int_demo_dt_ids),  
    },  
    .probe         = int_demo_probe,  
    .remove        = int_demo_remove,  
};

（3）匹配方式的变化：

如果没有引入设备树，还需要定义类似以下文件来匹配

	static struct resource s3c_int_resource[] = {  
	    xxx；
	};  
	struct platform_device s3c_device_rtc = {  
	    .name       = "interrupt_demo",  
	    .id     = -1,  
	    .num_resources  = ARRAY_SIZE(s3c_int_resource),  
     .resource   = s3c_int_resource,  
	};

在Common-smdk.c (linux-3.4.2\arch\arm\mach-s3c24xx)里

static struct platform_device __initdata *smdk_devs[] = {
	&s3c_device_nand,
	&smdk_led4,
	&smdk_led5,
	&smdk_led6,
	&smdk_led7,
};
//内核初始化时添加相应设备
platform_add_devices(smdk_devs, ARRAY_SIZE(smdk_devs));

没有引入设备树之前，我们采用设备名字匹配的方式，当platform_driver_register的时候，会去匹配一个名字为"interrupt_demo"的设备，如果找到同名设备则调用probe函数。由于设备树的引入，被硬编码在arch/arm/plat-xxx和arch/arm/mach-xxx，比如板上的platform设备、resource、i2c_board_info、spi_board_info以及各种硬件的platform_data将不存在。那么这些设备信息在哪里，什么时候被add进内核，platform_driver如何匹配platform_device呢？答案是设备信息存在设备树中，设备树加载的时候被转换成设备结构体。platform不在像以前那样匹配设备名字，而是匹配驱动中的.compatible与设备树中相应节点的compatible属性是否一致，且不区分大小写。一致则调用probe函数。下面我们就来详细分析为什么是这样。

static const struct of_device_id int_demo_dt_ids[] = {  
    { .compatible = "tiny4412,interrupt_demo", },  
    {},  
};  
  
MODULE_DEVICE_TABLE(of, int_demo_dt_ids);  
  
static struct platform_driver int_demo_driver = {  
    .driver        = {  
        .name      = "interrupt_demo",  
        .of_match_table    = of_match_ptr(int_demo_dt_ids),  
    },  
    .probe         = int_demo_probe,  
    .remove        = int_demo_remove,  
};  
  
static int __init int_demo_init(void)  
{  
    int ret;  
  
    ret = platform_driver_register(&int_demo_driver);  
    if (ret)  
        printk(KERN_ERR "int demo: probe failed: %d\n", ret);  
  
    return ret;  
}  
module_init(int_demo_init);

完整代码见：http://blog.csdn.net/fengyuwuzu0519/article/details/74177978。

二、详细分析platform_match的过程

1、函数调用流程：

去内核里查看，便可发现一层一层是这么调用的。

platform_match-->of_driver_match_device-->of_match_device-->of_match_node-->of_device_is_compatible-->of_get_property/of_compat_cmp-->strcasecmp((s1), (s2))

我们发现最后是在比较字符串内容一否一致，所以我们只需要分析这几个方法的成员列表，看到底比较的是哪两个字符串即可。

2、方法分析

platform_driver_register，首先调用到如下匹配函数。

platform_match(device,device_driver)

device：猜测是设备树构建的

device_driver：被platform_driver封装，就是我们的int_demo_driver

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

	/* Attempt an OF style match first */
	if (of_driver_match_device(dev, drv))
		return 1;

	/* Then try to match against the id table */
	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);
}

of_driver_match_device（device，device_driver）

static inline int of_driver_match_device(struct device *dev,
					 const struct device_driver *drv)
{
	return of_match_device(drv->of_match_table, dev) != NULL;
}

of_match_device(of_device_id,device)

of_device_id：device_driver>of_match_table=of_match_ptr(int_demo_dt_ids)：这个不就是我们在驱动里面定义的of_match_table成员

device：猜测是设备树构建的

const struct of_device_id *of_match_device(const struct of_device_id *matches,
					   const struct device *dev)
{
	if ((!matches) || (!dev->of_node))
		return NULL;
	return of_match_node(matches, dev->of_node);
}

of_match_node(of_device_id,device_node)

of_device_id：of_match_ptr(int_demo_dt_ids)

device_node：device->of_node（设备树完成了of_node的初始化）继续：

const struct of_device_id *of_match_node(const struct of_device_id *matches,
					 const struct device_node *node)
{
	if (!matches)
		return NULL;

	while (matches->name[0] || matches->type[0] || matches->compatible[0]) {
		int match = 1;
		if (matches->name[0])
			match &= node->name
				&& !strcmp(matches->name, node->name);
		if (matches->type[0])
			match &= node->type
				&& !strcmp(matches->type, node->type);
		if (matches->compatible[0])
			match &= of_device_is_compatible(node,
						matches->compatible);
		if (match)
			return matches;
		matches++;
	}
	return NULL;
}

of_device_is_compatible(device_node,char *compat)=of_device_is_compatible（device_node，“tiny4412,interrupt_demo”）

device_node：device->of_node（设备树完成了of_node的初始化）

char *compat:of_device_id->compatible=tiny4412,interrupt_demo

到此我们已经可以发现，现在是在和驱动里面定义的of_device_id结构体的compatible成员做对比，那么是谁和它对比呢？我们继续看下一个函数：

int of_device_is_compatible(const struct device_node *device,
		const char *compat)
{
	const char* cp;
	int cplen, l;

	cp = of_get_property(device, "compatible", &cplen);
	if (cp == NULL)
		return 0;
	while (cplen > 0) {
		if (of_compat_cmp(cp, compat, strlen(compat)) == 0)
			return 1;
		l = strlen(cp) + 1;
		cp += l;
		cplen -= l;
	}

	return 0;
}

cp = of_get_property(device_node,"compatible", &cplen)

device_node：device->of_node（设备树完成了of_node的初始化）

设备树加载的时候构建了device设备，被初始化了of_node成员，现在我们根据of_node去获取节点对应的compatible属性。cp就等于设备树里我们定义的节点的compatible属性值。如上函数of_device_is_compatible，则对比了设备树中节点的compatible与我们定义的是否存在名字一致的设备。存在则返回1；

const void *of_get_property(const struct device_node *np, const char *name,
			 int *lenp)
{
	struct property *pp = of_find_property(np, name, lenp);

	return pp ? pp->value : NULL;
}

of_compat_cmp：忽略大小写比较字符串。

#define of_compat_cmp(s1, s2, l)strcasecmp((s1), (s2))

3、相关结构体

（1）device Device.h (linux-3.4.2\include\linux)

struct device {
	struct device		*parent;

	struct device_private	*p;

	struct kobject kobj;
	const char		*init_name; /* initial name of the device */
	const struct device_type *type;

	struct mutex		mutex;	/* mutex to synchronize calls to
					 * its driver.
					 */

	struct bus_type	*bus;		/* type of bus device is on */
	struct device_driver *driver;	/* which driver has allocated this
					   device */
	void		*platform_data;	/* Platform specific data, device
					   core doesn't touch it */
	struct dev_pm_info	power;
	struct dev_pm_domain	*pm_domain;

#ifdef CONFIG_NUMA
	int		numa_node;	/* NUMA node this device is close to */
#endif
	u64		*dma_mask;	/* dma mask (if dma'able device) */
	u64		coherent_dma_mask;/* Like dma_mask, but for
					     alloc_coherent mappings as
					     not all hardware supports
					     64 bit addresses for consistent
					     allocations such descriptors. */

	struct device_dma_parameters *dma_parms;

	struct list_head	dma_pools;	/* dma pools (if dma'ble) */

	struct dma_coherent_mem	*dma_mem; /* internal for coherent mem
					     override */
	/* arch specific additions */
	struct dev_archdata	archdata;

	struct device_node	*of_node; /* associated device tree node */

	dev_t			devt;	/* dev_t, creates the sysfs "dev" */
	u32			id;	/* device instance */

	spinlock_t		devres_lock;
	struct list_head	devres_head;

	struct klist_node	knode_class;
	struct class		*class;
	const struct attribute_group **groups;	/* optional groups */

	void	(*release)(struct device *dev);
};

（2）device_driver Device.h (linux-3.4.2\include\linux)

struct device_driver {
	const char		*name;
	struct bus_type		*bus;

	struct module		*owner;
	const char		*mod_name;	/* used for built-in modules */

	bool suppress_bind_attrs;	/* disables bind/unbind via sysfs */

	const struct of_device_id	*of_match_table;

	int (*probe) (struct device *dev);
	int (*remove) (struct device *dev);
	void (*shutdown) (struct device *dev);
	int (*suspend) (struct device *dev, pm_message_t state);
	int (*resume) (struct device *dev);
	const struct attribute_group **groups;

	const struct dev_pm_ops *pm;

	struct driver_private *p;
};

三、总结

到此我们知道了。是在比较驱动中我们定义的of_device_id类型的结构体里面的compatible名字与设备树节点的compatible来决定是否执行probe函数。我们并没有初始化platform_device，这些是内核加载设备树的时候帮我们完成的，并且根据设备树节点初始化了of_node成员，我们可以根据of_node找到节点对应的成员属性。即设备树加载之后，内核会自动把设备树节点转换成 platform_device这种格式，同时把名字放到of_node这个地方。

还有一点我们上面用到的结构体是device，和device_driver，为什么不是我们定义的platform_device和platform_driver呢？其实platform是对device的一层封装，查看源码我们就可以发现函数调用流程：

platform_device--》device platform_device_register --》device_add
platform_driver--》device_driver platform_driver_register--》device_register
所以platform是对struct device和struct device_driver的封装。

对于device和device_driver我们后面再来分析。