第一课:设备树的引入与体验

第04节_总线设备驱动模型

总线驱动模型是为了解决什么问题呢？

• 使用之前的驱动模型，编写一个led驱动程序，如果需要修改gpio引脚，则需要修改驱动源码，重新编译驱动文件，假如驱动放在内核中，则需要重新编译内核

bus总线是虚拟的概念，并非硬件，dev注册设置某个结构体，这个设备也就是平台设备

    struct platform_device {
	const char	*name;
	int		id;
	bool		id_auto;
	struct device	dev;
	u32		num_resources;
	/*resource 里面确定使用那些资源*/
	struct resource	*resource;

	const struct platform_device_id	*id_entry;
	char *driver_override; /* Driver name to force a match */

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

	/* arch specific additions */
	struct pdev_archdata	archdata;
	};

drv那面定义platform_driver 去注册

    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;
    	bool prevent_deferred_probe;
    };

设备和驱动如何进行通信呢？

• 通过bus进行匹配 platform_match函数确定(dev,drv)若匹配则调用drv中的probe函数

    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_match是如何判断dev drv是匹配的？

判断方法是比较dev 和drv 各自的name来进行匹配

• 平台设备platform_device这面有name
• platform_driver这面有 driver （里面含有name） 还有id_table（包含 name driver_data）
• id_table里面的内容表示所支持一个或多个的设备名

static int platform_match(struct device *dev, struct device_driver *drv)
{		
	/*省略部分无用代码*/
	/* 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);
}

也就是优先比较 id_table中名字，如果没有则对比driver中名字

• 根据二期视频led代码进行修改

/* 分配/设置/注册一个platform_device */
/*设置资源*/
static struct resource led_resource[] = {
    [0] = {
		/*指明了使用那个引脚*/
        .start = S3C2440_GPF(5),
		/*end并不重要，可以随意指定*/
        .end   = S3C2440_GPF(5),
        .flags = IORESOURCE_MEM,
    },
};

static void led_release(struct device * dev)
{
}


static struct platform_device led_dev = {
    .name         = "myled",
    .id       = -1,
    .num_resources    = ARRAY_SIZE(led_resource),
    .resource     = led_resource,
    .dev = { 
    	.release = led_release, 
	},
};

/*入口函数去注册平台设备*/
static int led_dev_init(void)
{
	platform_device_register(&led_dev);
	return 0;
}
/*出口函数去释放这个平台设备*/
static void led_dev_exit(void)
{
	platform_device_unregister(&led_dev);
}

module_init(led_dev_init);
module_exit(led_dev_exit);

• led_drv驱动文件

static int led_probe(struct platform_device *pdev)
{
	struct resource		*res;

	/* 根据platform_device的资源进行ioremap */
	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
	led_pin = res->start;

	major = register_chrdev(0, "myled", &myled_oprs);

	led_class = class_create(THIS_MODULE, "myled");
	device_create(led_class, NULL, MKDEV(major, 0), NULL, "led"); /* /dev/led */
	
	return 0;
}


struct platform_driver led_drv = {
	.probe		= led_probe,
	.remove		= led_remove,
	.driver		= {
		.name	= "myled",
	}
};


static int myled_init(void)
{
	platform_driver_register(&led_drv);
	return 0;
}

static void myled_exit(void)
{
	platform_driver_unregister(&led_drv);
}

Makefile文件

KERN_DIR = /work/system/linux-4.19-rc3

all:
	make -C $(KERN_DIR) M=`pwd` modules 

clean:
	make -C $(KERN_DIR) M=`pwd` modules clean
	rm -rf modules.order

obj-m	+= led_drv.o
obj-m	+= led_dev.o

执行测试程序

如果我需要更换一个led 则只需要修改 led_dev led_resource结构体中的引脚即可

static struct resource led_resource[] = {
    [0] = {
        .start = S3C2440_GPF(6),
        .end   = S3C2440_GPF(6),
        .flags = IORESOURCE_MEM,
    },
};

设备和驱动的匹配是如何完成的？

• dev这面有设备链表
• drv这面也有驱动的结构体链表
• 通过match函数进行对比，如果相同，则调用drv中的probe函数

第05节_使用设备树时对应的驱动编程

• 本节介绍怎么使用设备树怎么编写对应的驱动程序
• 只是平台设备的构建区别，以前构造平台设备是在.c文件中，使用设备树构造设备节点原本不存在，需要在dts文件中构造节点，节点中含有资源
• dts被编译成dtb文件传给内核，内核会处理解析dtb文件得到device_node结构体，之后变成platform_device结构体，里面含有资源（资源来自dts文件）

• 我们定义的led设备节点

    	led {
    		compatible = "jz2440_led";
    		reg = <S3C2410_GPF(5) 1>;
    	};

• 以后就使用compatible找到内核支持这个设备节点的平台driver reg = <S3C2410_GPF(5) 1>; 就是寄存器地址的映射
  

修改好后编译 设备树文件 make dtb

拷贝到tftp文件夹，开发板启动

• 进入 /sys/devices/platform 目录查看是否有5005.led平台设备文件夹

• 查看 reg 的地址，这里面是以大字节须来描述这些值的

• 这个属性有8个字节，对应两个数值
  • 第一个值S3C2410_GPF(5)是我们的起始地址，对应 #define S3C2410_GPF(_nr) ((5<<16) + (_nr))
  • 第二个值1 本意是指寄存器的大小

如何去写平台驱动？ 通过bus总线去匹配设备驱动 在 platform_match函数中，通过

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

进入 of_device.h中

/**
 * of_driver_match_device - Tell if a driver's of_match_table matches a device.
 * @drv: the device_driver structure to test
 * @dev: the device structure to match against
 */
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_table结构体

include\linux\mod_devicetable.h

/*
 * Struct used for matching a device
 */
struct of_device_id {
	char	name[32];
	char	type[32];
	char	compatible[128];
	const void *data;
};

• compatible 也就是从dts得到的platform_device里有compatible 属性，两者进行对比，一样就表示匹配
• 写led驱动，修改led_drv.c
• 添加

static const struct of_device_id of_match_leds[] = {
	{ .compatible = "jz2440_led", .data = NULL },
	{ /* sentinel */ }
};

• 修改

struct platform_driver led_drv = {
	.probe		= led_probe,
	.remove		= led_remove,
	.driver		= {
		.name	= "myled",
		.of_match_table = of_match_leds, /* 能支持哪些来自于dts的platform_device */
	}
};

• 修改Makefile并编译

• 如果修改灯怎么办？
  • 直接修改设备树中的led设备节点

    	led {
    		compatible = "jz2440_led";
    		reg = <S3C2410_GPF(6) 1>;
    	};

上传编译，直接使用新的dtb文件

我们使用另外一种方法指定引脚

	led {
		compatible = "jz2440_led";
		pin = <S3C2410_GPF(5)>;
	};

修改led_drv中的probe函数

在of.h中找到获取of属性的函数 of_property_read_s32

static int led_probe(struct platform_device *pdev)
{
	struct resource		*res;

	/* 根据platform_device的资源进行ioremap */
	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
	if (res) {
		led_pin = res->start;
	}
	else {
		/* 获得pin属性 */
		of_property_read_s32(pdev->dev.of_node, "pin", &led_pin);
	}

	if (!led_pin) 
	{
		printk("can not get pin for led\n");
		return -EINVAL;
	}
		

	major = register_chrdev(0, "myled", &myled_oprs);

	led_class = class_create(THIS_MODULE, "myled");
	device_create(led_class, NULL, MKDEV(major, 0), NULL, "led"); /* /dev/led */
	
	return 0;
}

• 从新编译设备树 和led驱动文件

在platform_device结构体中的struct device dev;中对于dts生成的platform_device这里含有of_node

of_node中含有属性，这取决于设备树，比如compatible属性 让后注册/配置/file_operation

第06节_只想使用设备树不想深入研究怎么办

寄希望于写驱动程序的人，提供了文档/示例/程序写得好适配性强
根据之前写的设备树

   	led {
   		compatible = "jz2440_led";
   		reg = <S3C2410_GPF(6) 1>;
   	};

led { compatible = "jz2440_led"; pin = <S3C2410_GPF(5)>; };

可以通过reg指定引脚也可以通过pin指定引脚，我们在设备树中如何指定引脚完全取决于驱动程序 既可以获取pin属性值也可以获取reg属性值

	/* 根据platform_device的资源进行ioremap */
	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
	if (res) {
		led_pin = res->start;
	}
	else {
		/* 获得pin属性 */
		of_property_read_s32(pdev->dev.of_node, "pin", &led_pin);
	}

	if (!led_pin) 
	{
		printk("can not get pin for led\n");
		return -EINVAL;
	}

我们通过驱动程序再次验证了设备树的属性完全却决于写驱动程序的人
commpatible属性必须是 jz2440_led 才可以和驱动匹配成功

我们写驱动的人应该写一个文档，告诉写应用程序的人设备树的节点应该怎么编写

对于内核自带的驱动文件，对应的设备树的文档一般放在Documentation\devicetree\bindings目录中,里面有各种架构的说明文档以及各种协议的说明文档， 这些驱动都能在 drivers 目录下找到对应的驱动程序. 比如查看Documentation\devicetree\bindings\arm\samsung\exynos-chipid.txt里面的内容如下

 SAMSUNG Exynos SoCs Chipid driver.
 Required properties:（必须填写的内容）
 - compatible : Should at least contain "samsung,exynos4210-chipid".
 - reg: offset and length of the register set
 Example:
	chipid@10000000 {
		compatible = "samsung,exynos4210-chipid";
		reg = <0x10000000 0x100>;
	};

我们自己写的驱动说明文档自然没有适配到内核中去，所以只能期盼商家给你提供相应的说明文档

参考同类型单板的设备树文件 进入 arch\arm\boot\dts 目录下里面是各种单板的设备树文件 比如

am335x-boneblack.dts和am335x-boneblack-wireless.dts

发现多了wifi的信息,通过对比设备树文件，我们可以看出怎么写wifi设备节点,就知道如何添加设备节点.

网上搜索 实在不行就研究驱动源码 一个好的驱动程序，它会尽量确定所用资源，只把不能确定的资源留给设备树，让设备树来指定。