《领航者ZYNQ之嵌入式Linux开发指南_V2.0》第三十七章 platform驱动

正点原子运营 · 发表于 2022-3-21 15:19:50

1）实验平台：正点原子领航者V2FPGA开发板
2) 章节摘自【正点原子】《领航者ZYNQ之FPGA开发指南 V2.0》
3）购买链接:https://detail.tmall.com/item.htm?id=609032204975
4）全套实验源码+手册+视频下载地址：[url=http://www.openedv.com/docs/boards/fpga/zdyz_linhanz(V2).html]http://www.openedv.com/docs/boards/fpga/zdyz_linhanz(V2).html
5）正点原子官方B站：https://space.bilibili.com/394620890
6）正点原子FPGA技术交流QQ群:712557122

第三十七章 platform设备驱动实验

   我们在前面几章编写的设备驱动都非常的简单，都是对IO进行最简单的读写操作。像I2C、SPI、LCD等这些复杂外设的驱动就不能这么去写了，Linux系统要考虑到驱动的可重用性，因此提出了驱动的分离与分层这样的软件思路，在这个思路下诞生了我们将来最常打交道的platform设备驱动，也叫做平台设备驱动。本章我们就来学习一下Linux下的驱动分离与分层，以及platform框架下的设备驱动该如何编写。

   1.1Linux驱动的分离与分层
1.1.1驱动的分隔与分离
   对于Linux这样一个成熟、庞大、复杂的操作系统，代码的重用性非常重要，否则的话就会在Linux内核中存在大量无意义的重复代码。尤其是驱动程序，因为驱动程序占用了Linux内核代码量的大头，如果不对驱动程序加以管理，任由重复的代码肆意增加，那么用不了多久Linux内核的文件数量就庞大到无法接受的地步。
   假如现在有三个平台A、B和C，这三个平台(这里的平台说的是SOC)上都有MPU6050这个I2C接口的六轴传感器，按照我们写裸机I2C驱动的时候的思路，每个平台都有一个MPU6050的驱动，因此编写出来的最简单的驱动框架如图 37.1.1所示：

图 37.1.1 传统的I2C设备驱动

从图 37.1.1可以看出，每种平台下都有一个主机驱动和设备驱动，主机驱动肯定是必须要的，毕竟不同的平台其I2C控制器不同。但是右侧的设备驱动就没必要每个平台都写一个，因为不管对于那个SOC来说，MPU6050都是一样，通过I2C接口读写数据就行了，只需要一个MPU6050的驱动程序即可。如果再来几个I2C设备，比如AT24C02、FT5206(电容触摸屏)等，如果按照图 37.1.1中的写法，那么设备端的驱动将会重复的编写好几次。显然在Linux驱动程序中这种写法是不推荐的，最好的做法就是每个平台的I2C控制器都提供一个统一的接口(也叫做主机驱动)，每个设备的话也只提供一个驱动程序(设备驱动)，每个设备通过统一的I2C接口驱动来访问，这样就可以大大简化驱动文件，比如图 37.1.1中三种平台下的MPU6050驱动框架就可以简化为图 37.1.2所示：

图 37.1.2 改进后的设备驱动

实际的I2C驱动设备肯定有很多种，不止MPU6050这一个，那么实际的驱动架构如图 37.1.3所示：

图 37.1.3 分隔后的驱动框架

这个就是驱动的分隔，也就是将主机驱动和设备驱动分隔开来，比如I2C、SPI等等都会采用驱动分隔的方式来简化驱动的开发。在实际的驱动开发中，一般I2C主机控制器驱动已经由半导体厂家编写好了，而设备驱动一般也由设备器件的厂家编写好了，我们只需要提供设备信息即可，比如I2C设备的话提供设备连接到了哪个I2C接口上，I2C的速度是多少等等。相当于将设备信息从设备驱动中剥离开来，驱动使用标准方法去获取到设备信息(比如从设备树中获取到设备信息)，然后根据获取到的设备信息来初始化设备。这样就相当于驱动只负责驱动，设备只负责设备，想办法将两者进行匹配即可。这个就是Linux中的总线(bus)、驱动(driver)和设备(device)模型，也就是常说的驱动分离。总线就是驱动和设备信息的月老，负责给两者牵线搭桥，如图 37.1.4所示：

图 37.1.4 Linux总线、驱动和设备模式

   当我们向系统注册一个驱动的时候，总线就会在右侧的设备中查找，看看有没有与之匹配的设备，如果有的话就将两者联系起来。同样的，当向系统中注册一个设备的时候，总线就会在左侧的驱动中查找看有没有与之匹配的设备，有的话也联系起来。Linux内核中大量的驱动程序都采用总线、驱动和设备模式，我们一会要重点讲解的platform驱动就是这一思想下的产物。
1.1.2驱动的分层
   上一小节讲了驱动的分隔与分离，本节我们来简单看一下驱动的分层，大家应该听说过网络的7层模型，不同的层负责不同的内容。同样的，Linux下的驱动往往也是分层的，分层的目的也是为了在不同的层处理不同的内容。以其他书籍或者资料常常使用到的input(输入子系统，后面会有专门的章节详细的讲解)为例，简单介绍一下驱动的分层。input子系统负责管理所有跟输入有关的驱动，包括键盘、鼠标、触摸等，最底层的就是设备原始驱动，负责获取输入设备的原始值，获取到的输入事件上报给input核心层。input核心层会处理各种IO模型，并且提供file_operations操作集合。我们在编写输入设备驱动的时候只需要处理好输入事件的上报即可，至于如何处理这些上报的输入事件那是上层去考虑的，我们不用管。可以看出借助分层模型可以极大的简化我们的驱动编写，对于驱动编写来说非常的友好。
   1.2platform平台驱动模型简介
   前面我们讲了设备驱动的分离，并且引出了总线(bus)、驱动(driver)和设备(device)模型，比如I2C、SPI、USB等总线。但是在SOC中有些外设是没有总线这个概念的，但是又要使用总线、驱动和设备模型该怎么办呢？为了解决此问题，Linux提出了platform这个虚拟总线，相应的就有platform_driver和platform_device。
1.2.1platform总线
   Linux系统内核使用bus_type结构体表示总线，此结构体定义在文件include/linux/device.h，bus_type结构体内容如下：

1. 示例代码 37.2.1 bus_type结构体代码段
2. 110 struct bus_type {
3. 111 const char *name; // 总线名字
4. 112 const char *dev_name;
5. 113 struct device *dev_root;
6. 114 const struct attribute_group **bus_groups; // 总线属性
7. 115 const struct attribute_group **dev_groups; // 该总线下的设备对应的属性
8. 116 const struct attribute_group **drv_groups; // 该总线下的驱动对应的属性
9. 117
10. 118 int (*match)(struct device *dev, struct device_driver *drv);
11. 119 int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
12. 120 int (*probe)(struct device *dev);
13. 121 int (*remove)(struct device *dev);
14. 122 void (*shutdown)(struct device *dev);
15. 123
16. 124 int (*online)(struct device *dev);
17. 125 int (*offline)(struct device *dev);
18. 126
19. 127 int (*suspend)(struct device *dev, pm_message_t state);
20. 128 int (*resume)(struct device *dev);
21. 129
22. 130 int (*num_vf)(struct device *dev);
23. 131
24. 132 const struct dev_pm_ops *pm;
25. 133
26. 134 const struct iommu_ops *iommu_ops;
27. 135
28. 136 struct subsys_private *p;
29. 137 struct lock_class_key lock_key;
30. 138 };
复制代码

第118行，match函数，此函数很重要，单词match的意思就是“匹配、相配”，因此此函数就是完成设备和驱动之间匹配的，总线就是使用match函数来根据注册的设备来查找对应的驱动，或者根据注册的驱动来查找相应的设备，因此每一条总线都必须实现此函数。match函数有两个参数：dev和drv，这两个参数分别为device和device_driver类型，也就是设备和驱动。
platform总线是bus_type的一个具体实例，定义在文件drivers/base/platform.c，platform总线定义如下：

1. 示例代码 37.2.2 platform总线实例
2. 1140 struct bus_type platform_bus_type = {
3. 1141 .name = "platform",
4. 1142 .dev_groups = platform_dev_groups,
5. 1143 .match = platform_match,
6. 1144 .uevent = platform_uevent,
7. 1145 .pm = &platform_dev_pm_ops,
8. 1146 };
复制代码

platform_bus_type就是platform平台总线，其中platform_match就是匹配函数。我们来看一下驱动和设备是如何匹配的，platform_match函数定义在文件drivers/base/platform.c中，函数内容如下所示：

1. 示例代码 37.2.3 platform总线platform_match函数
2. 965 static int platform_match(struct device *dev, struct device_driver *drv)
3. 966 {
4. 967 struct platform_device *pdev = to_platform_device(dev);
5. 968 struct platform_driver *pdrv = to_platform_driver(drv);
6. 969
7. 970 /* When driver_override is set, only bind to the matching driver */
8. 971 if (pdev->driver_override)
9. 972 return !strcmp(pdev->driver_override, drv->name);
10. 973
11. 974 /* Attempt an OF style match first */
12. 975 if (of_driver_match_device(dev, drv))
13. 976 return 1;
14. 977
15. 978 /* Then try ACPI style match */
16. 979 if (acpi_driver_match_device(dev, drv))
17. 980 return 1;
18. 981
19. 982 /* Then try to match against the id table */
20. 983 if (pdrv->id_table)
21. 984 return platform_match_id(pdrv->id_table, pdev) != NULL;
22. 985
23. 986 /* fall-back to driver name match */
24. 987 return (strcmp(pdev->name, drv->name) == 0);
25. 988 }
复制代码

   驱动和设备的匹配有四种方法，我们依次来看一下：
   第975~976行，第一种匹配方式，OF类型的匹配，也就是设备树采用的匹配方式，of_driver_match_device函数定义在文件include/linux/of_device.h中。device_driver结构体(表示设备驱动)中有个名为of_match_table的成员变量，此成员变量保存着驱动的compatible匹配表，设备树中的每个设备节点的compatible属性会和of_match_table表中的所有成员比较，查看是否有相同的条目，如果有的话就表示设备和此驱动匹配，设备和驱动匹配成功以后probe函数就会执行。
   第979~980行，第二种匹配方式，ACPI匹配方式。
   第983~984行，第三种匹配方式，id_table匹配，每个platform_driver结构体有一个id_table成员变量，顾名思义，保存了很多id信息。这些id信息存放着这个platformd驱动所支持的驱动类型。
   第987行，第四种匹配方式，如果第三种匹配方式的id_table不存在的话就直接比较驱动和设备的name字段，看看是不是相等，如果相等的话就匹配成功。
   对于支持设备树的Linux内核版本，一般设备驱动为了兼容性都支持设备树和无设备树两种匹配方式。也就是第一种匹配方式一般都会存在，第三种和第四种只要存在一种就可以，一般用的最多的还是第四种，也就是直接比较驱动和设备的name字段，毕竟这种方式最简单了。
1.2.2platform驱动
   platform_driver结构体表示platform驱动，此结构体定义在文件include/linux/platform_device.h中，内容如下：

1. 示例代码 37.2.4 platform_driver结构体
2. 180 struct platform_driver {
3. 181 int (*probe)(struct platform_device *);
4. 182 int (*remove)(struct platform_device *);
5. 183 void (*shutdown)(struct platform_device *);
6. 184 int (*suspend)(struct platform_device *, pm_message_t state);
7. 185 int (*resume)(struct platform_device *);
8. 186 struct device_driver driver;
9. 187 const struct platform_device_id *id_table;
10. 188 bool prevent_deferred_probe;
11. 189 };
复制代码

   第181行，probe函数，当驱动与设备匹配成功以后probe函数就会执行，非常重要的函数！一般驱动的提供者会编写，如果自己要编写一个全新的驱动，那么probe就需要自行实现。
   第186行，driver成员，为device_driver结构体变量，Linux内核里面大量使用到了面向对象的思维，device_driver相当于基类，提供了最基础的驱动框架。plaform_driver继承了这个基类，然后在此基础上又添加了一些特有的成员变量。
   第187行，id_table表，也就是我们上一小节讲解platform总线匹配驱动和设备的时候采用的第三种方法，id_table是个表(也就是数组)，每个元素的类型为platform_device_id，platform_device_id结构体内容如下：

1. 示例代码 37.2.5 platform_device_id结构体
2. 1 struct platform_device_id {
3. 2 char name[PLATFORM_NAME_SIZE];
4. 3 kernel_ulong_t driver_data;
5. 4 };
复制代码

device_driver结构体定义在include/linux/device.h，device_driver结构体内容如下：

1. 示例代码 37.2.6 device_driver结构体
2. 266 struct device_driver {
3. 267 const char *name;
4. 268 struct bus_type *bus;
5. 269
6. 270 struct module *owner;
7. 271 const char *mod_name; /* used for built-in modules */
8. 272
9. 273 bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
10. 274 enum probe_type probe_type;
11. 275
12. 276 const struct of_device_id *of_match_table;
13. 277 const struct acpi_device_id *acpi_match_table;
14. 278
15. 279 int (*probe) (struct device *dev);
16. 280 int (*remove) (struct device *dev);
17. 281 void (*shutdown) (struct device *dev);
18. 282 int (*suspend) (struct device *dev, pm_message_t state);
19. 283 int (*resume) (struct device *dev);
20. 284 const struct attribute_group **groups;
21. 285
22. 286 const struct dev_pm_ops *pm;
23. 287
24. 288 struct driver_private *p;
25. 289 };
复制代码

第276行，of_match_table就是采用设备树的时候驱动使用的匹配表，同样是数组，每个匹配项都为of_device_id结构体类型，此结构体定义在文件include/linux/mod_devicetable.h中，内容如下：

1. 示例代码 37.2.7 of_device_id结构体
2. 235 struct of_device_id {
3. 236 char name[32];
4. 237 char type[32];
5. 238 char compatible[128];
6. 239 const void *data;
7. 240 };
复制代码

   第238行的compatible非常重要，因为对于设备树而言，就是通过设备节点的compatible属性值和of_match_table中每个项目的compatible成员变量进行比较，如果有相等的就表示设备和此驱动匹配成功。
   在编写platform驱动的时候，首先定义一个platform_driver结构体变量，然后实现结构体中的各个成员变量，重点是实现匹配方法以及probe函数。当驱动和设备匹配成功以后probe函数就会执行，具体的驱动程序在probe函数里面编写，比如字符设备驱动等等。
   当我们定义并初始化好platform_driver结构体变量以后，需要在驱动入口函数里面调用platform_driver_register函数向Linux内核注册一个platform驱动，platform_driver_register函数原型如下所示：

1. int platform_driver_register (struct platform_driver *driver)
复制代码

   函数参数和返回值含义如下：
   driver：要注册的platform驱动。
   返回值：负数，失败；0，成功。
   还需要在驱动卸载函数中通过platform_driver_unregister函数卸载platform驱动，platform_driver_unregister函数原型如下：

1. void platform_driver_unregister(struct platform_driver *drv)
复制代码

   函数参数和返回值含义如下：
   drv：要卸载的platform驱动。
   返回值：无。
   platform驱动框架如下所示：

1. 示例代码 37.2.8 platform驱动框架使用示例
2. 1 /* 设备结构体 */
3. 2 struct xxx_dev{
4. 3 struct cdev cdev;
5. 4 /* 设备结构体其他具体内容 */
6. 5 };
7. 6
8. 7 struct xxx_dev xxxdev; /* 定义个设备结构体变量 */
9. 8
10. 9 static int xxx_open(struct inode *inode, struct file *filp)
11. 10 {
12. 11 /* 函数具体内容 */
13. 12 return 0;
14. 13 }
15. 14
16. 15 static ssize_t xxx_write(struct file *filp, const char __user *buf,
17. 16 size_t cnt, loff_t *offt)
18. 17 {
19. 18 /* 函数具体内容 */
20. 19 return 0;
21. 20 }
22. 21
23. 22 /*
24. 23 * 字符设备驱动操作集
25. 24 */
26. 25 static struct file_operations xxx_fops = {
27. 26 .owner = THIS_MODULE,
28. 27 .open = xxx_open,
29. 28 .write = xxx_write,
30. 29 };
31. 30
32. 31 /*
33. 32 * platform驱动的probe函数
34. 33 * 驱动与设备匹配成功以后此函数就会执行
35. 34 */
36. 35 static int xxx_probe(struct platform_device *dev)
37. 36 {
38. 37 ......
39. 38 cdev_init(&xxxdev.cdev, &xxx_fops); /* 注册字符设备驱动 */
40. 39 /* 函数具体内容 */
41. 40 return 0;
42. 41 }
43. 42
44. 43 static int xxx_remove(struct platform_device *dev)
45. 44 {
46. 45 ......
47. 46 cdev_del(&xxxdev.cdev); /* 删除cdev */
48. 47 /* 函数具体内容 */
49. 48 return 0;
50. 49 }
51. 50
52. 51 /* 匹配列表 */
53. 52 static const struct of_device_id xxx_of_match[] = {
54. 53 { .compatible = "xxx-gpio" },
55. 54 { /* Sentinel */ }
56. 55 };
57. 56
58. 57 /*
59. 58 * platform平台驱动结构体
60. 59 */
61. 60 static struct platform_driver xxx_driver = {
62. 61 .driver = {
63. 62 .name = "xxx",
64. 63 .of_match_table = xxx_of_match,
65. 64 },
66. 65 .probe = xxx_probe,
67. 66 .remove = xxx_remove,
68. 67 };
69. 68
70. 69 /* 驱动模块加载 */
71. 70 static int __init xxxdriver_init(void)
72. 71 {
73. 72 return platform_driver_register(&xxx_driver);
74. 73 }
75. 74
76. 75 /* 驱动模块卸载 */
77. 76 static void __exit xxxdriver_exit(void)
78. 77 {
79. 78 platform_driver_unregister(&xxx_driver);
80. 79 }
81. 80
82. 81 module_init(xxxdriver_init);
83. 82 module_exit(xxxdriver_exit);
84. 83 MODULE_LICENSE("GPL");
85. 84 MODULE_AUTHOR("zuozhongkai");
复制代码

   第1~29行，传统的字符设备驱动，所谓的platform驱动并不是独立于字符设备驱动、块设备驱动和网络设备驱动之外的其他种类的驱动。platform只是为了驱动的分离与分层而提出来的一种框架，其驱动的具体实现还是需要字符设备驱动、块设备驱动或网络设备驱动。
   第35~41行，xxx_probe函数，当驱动和设备匹配成功以后此函数就会执行，以前在驱动入口init函数里面编写的字符设备驱动程序就全部放到此probe函数里面。比如注册字符设备驱动、添加cdev、创建类等等。
   第43~49行，xxx_remove函数，platform_driver结构体中的remove成员变量，当关闭platfor备驱动的时候此函数就会执行，以前在驱动卸载exit函数里面要做的事情就放到此函数中来。比如，使用iounmap释放内存、删除cdev，注销设备号等等。
   第52~55行，xxx_of_match匹配表，如果使用设备树的话将通过此匹配表进行驱动和设备的匹配。第51行设置了一个匹配项，此匹配项的compatible值为“xxx-gpio”，因此当设备树中设备节点的compatible属性值为“xxx-gpio”的时候此设备就会与此驱动匹配。第52行是一个标记，of_device_id表最后一个匹配项必须是空的。
   第60~67行，定义一个platform_driver结构体变量xxx_driver，表示platform驱动，第59~62行设置paltform_driver中的device_driver成员变量的name和of_match_table这两个属性。其中name属性用于传统的驱动与设备匹配，也就是检查驱动和设备的name字段是不是相同。of_match_table属性就是用于设备树下的驱动与设备检查。对于一个完整的驱动程序，必须提供有设备树和无设备树两种匹配方法。最后63和64这两行设置probe和remove这两成员变量。
   第70~73行，驱动入口函数，调用platform_driver_register函数向Linux内核注册一个platform驱动，也就是上面定义的xxx_driver结构体变量。
   第76~79行，驱动出口函数，调用platform_driver_unregister函数卸载前面注册的platform驱动。
   总体来说，platform驱动还是传统的字符设备驱动、块设备驱动或网络设备驱动，只是套上了一张“platform”的皮，目的是为了使用总线、驱动和设备这个驱动模型来实现驱动的分离与分层。
1.2.3platform设备
   platform驱动已经准备好了，我们还需要platform设备，否则的话单单一个驱动也做不了什么。platform_device这个结构体表示platform设备，这里我们要注意，如果内核支持设备树的话就不要再使用platform_device来描述设备了，因为改用设备树去描述了。当然了，你如果一定要用platform_device来描述设备信息的话也是可以的。platform_device结构体定义在文件include/linux/platform_device.h中，结构体内容如下：

1. 示例代码 37.2.9 platform_device结构体代码段
2. 23 struct platform_device {
3. 24 const char *name;
4. 25 int id;
5. 26 bool id_auto;
6. 27 struct device dev;
7. 28 u32 num_resources;
8. 29 struct resource *resource;
9. 30
10. 31 const struct platform_device_id *id_entry;
11. 32 char *driver_override; /* Driver name to force a match */
12. 33
13. 34 /* MFD cell pointer */
14. 35 struct mfd_cell *mfd_cell;
15. 36
16. 37 /* arch specific additions */
17. 38 struct pdev_archdata archdata;
18. 39 };
复制代码

   第24行，name表示设备名字，要和所使用的platform驱动的name字段相同，否则的话设备就无法匹配到对应的驱动。比如对应的platform驱动的name字段为“xxx-gpio”，那么此name字段也要设置为“xxx-gpio”。
   第28行，num_resources表示资源数量，一般为第29行resource资源的大小。
   第29行，resource表示资源，也就是设备信息，比如外设寄存器等。Linux内核使用resource结构体表示资源，resource结构体内容如下：

1. 示例代码 37.2.10 resource结构体代码段
2. 18 struct resource {
3. 19 resource_size_t start;
4. 20 resource_size_t end;
5. 21 const char *name;
6. 22 unsigned long flags;
7. 23 struct resource *parent, *sibling, *child;
8. 24 };
复制代码

start和end分别表示资源的起始和终止信息，对于内存类的资源，就表示内存起始和终止地址，name表示资源名字，flags表示资源类型，可选的资源类型都定义在了文件include/linux/ioport.h里面，如下所示：

1. 示例代码 37.2.11 资源类型
2. 29 #define IORESOURCE_BITS 0x000000ff /* Bus-specific bits */
3. 30
4. 31 #define IORESOURCE_TYPE_BITS 0x00001f00 /* Resource type */
5. 32 #define IORESOURCE_IO 0x00000100 /* PCI/ISA I/O ports */
6. 33 #define IORESOURCE_MEM 0x00000200
7. 34 #define IORESOURCE_REG 0x00000300 /* Register offsets */
8. 35 #define IORESOURCE_IRQ 0x00000400
9. 36 #define IORESOURCE_DMA 0x00000800
10. 37 #define IORESOURCE_BUS 0x00001000
11. ......
12. 104 /* PCI control bits. Shares IORESOURCE_BITS with above PCI ROM. */
13. 105 #define IORESOURCE_PCI_FIXED (1<<4) /* Do not move resource */
复制代码

在以前不支持设备树的Linux版本中，用户需要编写platform_device变量来描述设备信息，然后使用platform_device_register函数将设备信息注册到Linux内核中，此函数原型如下所示：

1. int platform_device_register(struct platform_device *pdev)
复制代码

   函数参数和返回值含义如下：
   pdev：要注册的platform设备。
   返回值：负数，失败；0，成功。
   如果不再使用platform的话可以通过platform_device_unregister函数注销掉相应的platform设备，platform_device_unregister函数原型如下：

1. void platform_device_unregister(struct platform_device *pdev)
复制代码

   函数参数和返回值含义如下：
   pdev：要注销的platform设备。
   返回值：无。
   platform设备信息框架如下所示：

1. 示例代码 37.2.12 platform设备框架使用示例
2. 1 /* 寄存器地址定义*/
3. 2 #define PERIPH1_REGISTER_BASE (0X20000000) /* 外设1寄存器首地址 */
4. 3 #define PERIPH2_REGISTER_BASE (0X020E0068) /* 外设2寄存器首地址 */
5. 4 #define REGISTER_LENGTH 4
6. 5
7. 6 /* 资源 */
8. 7 static struct resource xxx_resources[] = {
9. 8 [0] = {
10. 9 .start = PERIPH1_REGISTER_BASE,
11. 10 .end = (PERIPH1_REGISTER_BASE + REGISTER_LENGTH - 1),
12. 11 .flags = IORESOURCE_MEM,
13. 12 },
14. 13 [1] = {
15. 14 .start = PERIPH2_REGISTER_BASE,
16. 15 .end = (PERIPH2_REGISTER_BASE + REGISTER_LENGTH - 1),
17. 16 .flags = IORESOURCE_MEM,
18. 17 },
19. 18 };
20. 19
21. 20 /* platform设备结构体 */
22. 21 static struct platform_device xxxdevice = {
23. 22 .name = "xxx-gpio",
24. 23 .id = -1,
25. 24 .num_resources = ARRAY_SIZE(xxx_resources),
26. 25 .resource = xxx_resources,
27. 26 };
28. 27
29. 28 /* 设备模块加载 */
30. 29 static int __init xxxdevice_init(void)
31. 30 {
32. 31 return platform_device_register(&xxxdevice);
33. 32 }
34. 33
35. 34 /* 设备模块注销 */
36. 35 static void __exit xxx_resourcesdevice_exit(void)
37. 36 {
38. 37 platform_device_unregister(&xxxdevice);
39. 38 }
40. 39
41. 40 module_init(xxxdevice_init);
42. 41 module_exit(xxxdevice_exit);
43. 42 MODULE_LICENSE("GPL");
44. 43 MODULE_AUTHOR("zuozhongkai");
复制代码

   第7~18行，数组xxx_resources表示设备资源，一共有两个资源，分别为设备外设1和外设2的寄存器信息。因此flags都为IORESOURCE_MEM，表示资源为内存类型的。
   第21~26行，platform设备结构体变量，注意name字段要和所使用的驱动中的name字段一致，否则驱动和设备无法匹配成功。num_resources表示资源大小，其实就是数组xxx_resources的元素数量，这里用ARRAY_SIZE来测量一个数组的元素个数。
   第29~32行，设备模块加载函数，在此函数中调用platform_device_register向Linux内核注册platform设备。
   第35~38行，设备模块卸载函数，在此函数中调用platform_device_unregister从Linux内核中卸载platform设备。
   示例代码 37.2.12主要是在不支持设备树的Linux版本中使用的，当Linux内核支持了设备树以后就不需要用户手动去注册platform设备了。因为设备信息都放到了设备树中去描述，Linux内核启动的时候会从设备树中读取设备信息，然后将其组织成platform_device形式，至于设备树到platform_device的具体过程就不去详细的追究了，感兴趣的可以去看一下，网上也有很多博客详细的讲解了整个过程。
   关于platform下的总线、驱动和设备就讲解到这里，我们接下来就使用platform驱动框架来编写一个LED灯驱动，本章我们不使用设备树来描述设备信息，我们采用自定义platform_device这种“古老”方式来编写LED的设备信息。下一章我们来编写设备树下的platform驱动，这样我们就掌握了无设备树和有设备树这两种platform驱动的开发方式。
   1.3硬件原理图分析
   本章实验我们只使用到开发板上的PS_LED0，因此实验硬件原理图参考22.3小节即可。
   1.4试验程序编写
   本实验对应的例程路径为：领航者ZYNQ开发板光盘资料(A盘)\4_SourceCode\3_Embedded_Linux\Linux驱动例程\17_platform
   本章实验我们需要编写一个驱动模块和一个设备模块，其中驱动模块是platform驱动程序，设备模块是platform的设备信息。当这两个模块都加载成功以后就会匹配成功，然后platform驱动模块中的probe函数就会执行，probe函数中就是传统的字符设备驱动那一套。
1.4.1platform设备与驱动程序编写
   在drivers目录下新建名为“17_platform”的文件夹，在“17_platform”目录下新建名为leddevice.c和leddriver.c这两个源文件，这两个文件分别为LED灯的platform设备源文件和platform驱动源文件。在leddevice.c中输入如下所示内容：

1. 示例代码 37.4.1 leddevice.c文件代码段
2. 1 /***************************************************************
3. 2 Copyright © ALIENTEK Co., Ltd. 1998-2029. All rights reserved.
4. 3 文件名 : leddevice.c
5. 4 作者 : 邓涛
6. 5 版本 : V1.0
7. 6 描述 : platform总线编程示例之platform设备模块
8. 7 其他 : 无
9. 8 论坛 : <a href="www.openedv.com" target="_blank">www.openedv.com</a>
10. 9 日志 : 初版V1.0 2019/1/30 邓涛创建
11. 10 ***************************************************************/
12. 11
13. 12 #include <linux/module.h>
14. 13 #include <linux/platform_device.h>
15. 14
16. 15 /*
17. 16 * GPIO相关寄存器地址定义
18. 17 */
19. 18 #define DATA_REG 0xE000A040
20. 19 #define DIRM_REG 0xE000A204
21. 20 #define OUTEN_REG 0xE000A208
22. 21 #define INTDIS_REG 0xE000A214
23. 22 #define APER_CLK_CTRL_REG 0xF800012C
24. 23
25. 24 /*
26. 25 * @description : platform设备模块卸载时此函数会执行
27. 26 * [url=home.php?mod=space&uid=271674]@param[/url] – dev : 要释放的设备
28. 27 * @return : 无
29. 28 */
30. 29 static void myled_release(struct device *dev)
31. 30 {
32. 31 printk(KERN_INFO "myled: led platform device release!\r\n");
33. 32 }
34. 33
35. 34 /*
36. 35 * platform设备资源信息
37. 36 * 也就是PS_LED0所使用的所有寄存器资源
38. 37 */
39. 38 static struct resource myled_resources[] = {
40. 39 [0] = {
41. 40 .start = DATA_REG,
42. 41 .end = DATA_REG + 3,
43. 42 .flags = IORESOURCE_MEM,
44. 43 },
45. 44 [1] = {
46. 45 .start = DIRM_REG,
47. 46 .end = DIRM_REG + 3,
48. 47 .flags = IORESOURCE_MEM,
49. 48 },
50. 49 [2] = {
51. 50 .start = OUTEN_REG,
52. 51 .end = OUTEN_REG + 3,
53. 52 .flags = IORESOURCE_MEM,
54. 53 },
55. 54 [3] = {
56. 55 .start = INTDIS_REG,
57. 56 .end = INTDIS_REG + 3,
58. 57 .flags = IORESOURCE_MEM,
59. 58 },
60. 59 [4] = {
61. 60 .start = APER_CLK_CTRL_REG,
62. 61 .end = APER_CLK_CTRL_REG + 3,
63. 62 .flags = IORESOURCE_MEM,
64. 63 },
65. 64 };
66. 65
67. 66 /*
68. 67 * platform设备结构体
69. 68 */
70. 69 static struct platform_device myled_device = {
71. 70 .name = "zynq-led",
72. 71 .id = -1,
73. 72 .dev = {
74. 73 .release = &myled_release,
75. 74 },
76. 75 .num_resources = ARRAY_SIZE(myled_resources),
77. 76 .resource = myled_resources,
78. 77 };
79. 78
80. 79 /*
81. 80 * @description : 模块入口函数
82. 81 * @param : 无
83. 82 * @return : 无
84. 83 */
85. 84 static int __init myled_device_init(void)
86. 85 {
87. 86 return platform_device_register(&myled_device);
88. 87 }
89. 88
90. 89 /*
91. 90 * @description : 模块出口函数
92. 91 * @param : 无
93. 92 * @return : 无
94. 93 */
95. 94 static void __exit myled_device_exit(void)
96. 95 {
97. 96 platform_device_unregister(&myled_device);
98. 97 }
99. 98
100. 99 module_init(myled_device_init);
101. 100 module_exit(myled_device_exit);
102. 101
103. 102 MODULE_AUTHOR("DengTao <<a href="mailto:773904075@qq.com">773904075@qq.com</a>>");
104. 103 MODULE_DESCRIPTION("Led Platform Device");
105. 104 MODULE_LICENSE("GPL");
复制代码

   leddevice.c文件内容就是按照示例代码 37.2.12的platform设备模板编写的。
   第18~22行，PS_LED0对应的gpio所使用到的寄存器地址定义。
   第29~32行，myled_release函数，当platform设备模块卸载时会执行这个函数，我们在这个函数中添加了一条打印语句。
   第38~64行，struct resource结构体类型的数组myled_resources，也就是设备资源，描述了LED所要使用到的寄存器信息，也就是IORESOURCE_MEM资源。
   第69~77，platform设备结构体变量myled_device，这里要注意name字段为“zynq-led”，所以稍后编写platform驱动文件中的name字段也要为“zynq-led”，否则设备和驱动匹配失败。
   第84~87行，模块入口函数myled_device_init，在此函数里面通过platform_device_register向Linux内核注册myled_device这个platform设备。
   第94~97行，模块出口函数myled_device_exit，在此函数里面通过platform_device_unregister从Linux内核中删除掉myled_device这个platform设备。
   platform设备文件leddevice.c编写完成以后就编写platform驱动文件leddriver.c，在leddriver.c里面输入如下内容：

1. 示例代码 37.4.2 leddriver.c文件代码
2. 1 /***************************************************************
3. 2 Copyright © ALIENTEK Co., Ltd. 1998-2029. All rights reserved.
4. 3 文件名 : leddriver.c
5. 4 作者 : 邓涛
6. 5 版本 : V1.0
7. 6 描述 : platform总线编程示例之platform驱动模块
8. 7 其他 : 无
9. 8 论坛 : <a href="www.openedv.com" target="_blank">www.openedv.com</a>
10. 9 日志 : 初版V1.0 2019/1/30 邓涛创建
11. 10 ***************************************************************/
12. 11
13. 12 #include <linux/module.h>
14. 13 #include <linux/cdev.h>
15. 14 #include <linux/uaccess.h>
16. 15 #include <asm/io.h>
17. 16 #include <linux/platform_device.h>
18. 17
19. 18 #define MYLED_CNT 1 /* 设备号个数 */
20. 19 #define MYLED_NAME "myled" /* 名字 */
21. 20
22. 21 /* 映射后的寄存器虚拟地址指针 */
23. 22 static void __iomem *data_addr;
24. 23 static void __iomem *dirm_addr;
25. 24 static void __iomem *outen_addr;
26. 25 static void __iomem *intdis_addr;
27. 26 static void __iomem *aper_clk_ctrl_addr;
28. 27
29. 28 /* LED设备结构体 */
30. 29 struct myled_dev {
31. 30 dev_t devid; /* 设备号 */
32. 31 struct cdev cdev; /* cdev结构体 */
33. 32 struct class *class; /* 类 */
34. 33 struct device *device; /* 设备 */
35. 34 };
36. 35
37. 36 static struct myled_dev myled; /* led设备 */
38. 37
39. 38 /*
40. 39 * @description : 打开设备
41. 40 * @param – inode : 传递给驱动的inode
42. 41 * @param – filp : 设备文件，file结构体有个叫做private_data的成员变量
43. 42 * 一般在open的时候将private_data指向设备结构体。
44. 43 * @return : 0 成功;其他失败
45. 44 */
46. 45 static int myled_open(struct inode *inode, struct file *filp)
47. 46 {
48. 47 return 0;
49. 48 }
50. 49
51. 50 /*
52. 51 * @description : 向设备写数据
53. 52 * @param – filp : 设备文件，表示打开的文件描述符
54. 53 * @param – buf : 要写给设备写入的数据
55. 54 * @param – cnt : 要写入的数据长度
56. 55 * @param – offt : 相对于文件首地址的偏移
57. 56 * @return : 写入的字节数，如果为负值，表示写入失败
58. 57 */
59. 58 static ssize_t myled_write(struct file *filp, const char __user *buf,
60. 59 size_t cnt, loff_t *offt)
61. 60 {
62. 61 int ret;
63. 62 int val;
64. 63 char kern_buf[1];
65. 64
66. 65 ret = copy_from_user(kern_buf, buf, cnt); // 得到应用层传递过来的数据
67. 66 if(0 > ret) {
68. 67 printk(KERN_ERR "myled: kernel write failed!\r\n");
69. 68 return -EFAULT;
70. 69 }
71. 70
72. 71 val = readl(data_addr);
73. 72 if (0 == kern_buf[0])
74. 73 val &= ~(0x1U << 7); // 如果传递过来的数据是0则关闭led
75. 74 else if (1 == kern_buf[0])
76. 75 val |= (0x1U << 7); // 如果传递过来的数据是1则点亮led
77. 76
78. 77 writel(val, data_addr);
79. 78 return 0;
80. 79 }
81. 80
82. 81 static int myled_get_platform_resource(struct platform_device *dev)
83. 82 {
84. 83 int i;
85. 84 struct resource *res[5];
86. 85
87. 86 /* 获取资源 */
88. 87 for (i = 0; i < 5; i++) {
89. 88
90. 89 res = platform_get_resource(dev, IORESOURCE_MEM, i);
91. 90 if (!res) {
92. 91 printk(KERN_ERR "no MEM resource found %d\n", i);
93. 92 return -ENXIO;
94. 93 }
95. 94 }
96. 95
97. 96 /* 将物理地址映射为虚拟地址 */
98. 97 data_addr = ioremap(res[0]->start, resource_size(res[0]));
99. 98 dirm_addr = ioremap(res[1]->start, resource_size(res[1]));
100. 99 outen_addr = ioremap(res[2]->start, resource_size(res[2]));
101. 100 intdis_addr = ioremap(res[3]->start, resource_size(res[3]));
102. 101 aper_clk_ctrl_addr = ioremap(res[4]->start, resource_size(res[4]));
103. 102
104. 103 return 0;
105. 104 }
106. 105
107. 106 static void myled_init(void)
108. 107 {
109. 108 u32 val;
110. 109
111. 110 /* 使能GPIO时钟 */
112. 111 val = readl(aper_clk_ctrl_addr);
113. 112 val |= (0x1U << 22);
114. 113 writel(val, aper_clk_ctrl_addr);
115. 114
116. 115 /* 关闭中断功能 */
117. 116 val |= (0x1U << 7);
118. 117 writel(val, intdis_addr);
119. 118
120. 119 /* 设置GPIO为输出功能 */
121. 120 val = readl(dirm_addr);
122. 121 val |= (0x1U << 7);
123. 122 writel(val, dirm_addr);
124. 123
125. 124 /* 使能GPIO输出功能 */
126. 125 val = readl(outen_addr);
127. 126 val |= (0x1U << 7);
128. 127 writel(val, outen_addr);
129. 128
130. 129 /* 默认关闭LED */
131. 130 val = readl(data_addr);
132. 131 val &= ~(0x1U << 7);
133. 132 writel(val, data_addr);
134. 133 }
135. 134
136. 135 static void myled_iounmap(void)
137. 136 {
138. 137 iounmap(data_addr);
139. 138 iounmap(dirm_addr);
140. 139 iounmap(outen_addr);
141. 140 iounmap(intdis_addr);
142. 141 iounmap(aper_clk_ctrl_addr);
143. 142 }
144. 143
145. 144 /* LED设备操作函数 */
146. 145 static struct file_operations myled_fops = {
147. 146 .owner = THIS_MODULE,
148. 147 .open = myled_open,
149. 148 .write = myled_write,
150. 149 };
151. 150
152. 151 /*
153. 152 * @description : platform驱动的probe函数，当platform驱动与platform设备
154. 153 * 匹配以后此函数就会执行
155. 154 * @param – dev : platform设备指针
156. 155 * @return : 0，成功;其他负值,失败
157. 156 */
158. 157 static int myled_probe(struct platform_device *dev)
159. 158 {
160. 159 int ret;
161. 160
162. 161 printk(KERN_INFO "myled: led driver and device has matched!\r\n");
163. 162
164. 163 /* 获取platform设备资源 */
165. 164 ret = myled_get_platform_resource(dev);
166. 165 if (ret)
167. 166 return ret;
168. 167
169. 168 /* led初始化 */
170. 169 myled_init();
171. 170
172. 171 /* 初始化cdev */
173. 172 ret = alloc_chrdev_region(&myled.devid, 0, MYLED_CNT, MYLED_NAME);
174. 173 if (ret)
175. 174 goto out1;
176. 175
177. 176 myled.cdev.owner = THIS_MODULE;
178. 177 cdev_init(&myled.cdev, &myled_fops);
179. 178
180. 179 /* 添加cdev */
181. 180 ret = cdev_add(&myled.cdev, myled.devid, MYLED_CNT);
182. 181 if (ret)
183. 182 goto out2;
184. 183
185. 184 /* 创建类class */
186. 185 myled.class = class_create(THIS_MODULE, MYLED_NAME);
187. 186 if (IS_ERR(myled.class)) {
188. 187 ret = PTR_ERR(myled.class);
189. 188 goto out3;
190. 189 }
191. 190
192. 191 /* 创建设备 */
193. 192 myled.device = device_create(myled.class, &dev->dev,
194. 193 myled.devid, NULL, MYLED_NAME);
195. 194 if (IS_ERR(myled.device)) {
196. 195 ret = PTR_ERR(myled.device);
197. 196 goto out4;
198. 197 }
199. 198
200. 199 return 0;
201. 200
202. 201 out4:
203. 202 class_destroy(myled.class);
204. 203
205. 204 out3:
206. 205 cdev_del(&myled.cdev);
207. 206
208. 207 out2:
209. 208 unregister_chrdev_region(myled.devid, MYLED_CNT);
210. 209
211. 210 out1:
212. 211 myled_iounmap();
213. 212
214. 213 return ret;
215. 214 }
216. 215
217. 216 /*
218. 217 * @description : platform驱动模块卸载时此函数会执行
219. 218 * @param – dev : platform设备指针
220. 219 * @return : 0，成功;其他负值,失败
221. 220 */
222. 221 static int myled_remove(struct platform_device *dev)
223. 222 {
224. 223 printk(KERN_INFO "myled: led platform driver remove!\r\n");
225. 224
226. 225 /* 注销设备 */
227. 226 device_destroy(myled.class, myled.devid);
228. 227
229. 228 /* 注销类 */
230. 229 class_destroy(myled.class);
231. 230
232. 231 /* 删除cdev */
233. 232 cdev_del(&myled.cdev);
234. 233
235. 234 /* 注销设备号 */
236. 235 unregister_chrdev_region(myled.devid, MYLED_CNT);
237. 236
238. 237 /* 删除地址映射 */
239. 238 myled_iounmap();
240. 239
241. 240 return 0;
242. 241 }
243. 242
244. 243 /* platform驱动结构体 */
245. 244 static struct platform_driver myled_driver = {
246. 245 .driver = {
247. 246 .name = "zynq-led", // 驱动名字，用于和设备匹配
248. 247 },
249. 248 .probe = myled_probe, // probe函数
250. 249 .remove = myled_remove, // remove函数
251. 250 };
252. 251
253. 252 /*
254. 253 * @description : 模块入口函数
255. 254 * @param : 无
256. 255 * @return : 无
257. 256 */
258. 257 static int __init myled_driver_init(void)
259. 258 {
260. 259 return platform_driver_register(&myled_driver);
261. 260 }
262. 261
263. 262 /*
264. 263 * @description : 模块出口函数
265. 264 * @param : 无
266. 265 * @return : 无
267. 266 */
268. 267 static void __exit myled_driver_exit(void)
269. 268 {
270. 269 platform_driver_unregister(&myled_driver);
271. 270 }
272. 271
273. 272 module_init(myled_driver_init);
274. 273 module_exit(myled_driver_exit);
275. 274
276. 275 MODULE_AUTHOR("DengTao <<a href="mailto:773904075@qq.com">773904075@qq.com</a>>");
277. 276 MODULE_DESCRIPTION("Led Platform Driver");
278. 277 MODULE_LICENSE("GPL");
复制代码

   leddriver.c文件内容就是按照示例代码 37.2.8的platform驱动模板编写的。
   第18~79行，传统的字符设备驱动，跟前面讲过的内容是一样的。
   第81~104行，自定义了一个函数myled_get_platform_resource，该函数中主要做了两件事情：调用platform_get_resource函数获取platform设备提供的资源，也就是寄存器地址信息；调用ioremap函数将获取到的寄存器物理地址映射到虚拟地址空间。
   第106~133行，自定义函数myled_init，该函数完成了对LED所使用的GPIO进行相关的初始化，包括：GPIO时钟使能、禁止中断、配置输出模式等，这些知识前面章节都已经讲过了，不再啰嗦！
   第135~142行，自定义函数myled_iounmap，调用iounmap函数删除地址映射，这里是为了方便将这些操作放在这个函数里边，在myled_remove函数中会调用myled_iounmap函数。
   第157~214行，platform驱动的probe函数myled_probe，当platform设备和platform驱动匹配以后此函数就会执行，第161行加入了一条打印语句，所以当匹配成功以后会在终端上输出“myled: led driver and device has matched!”这样语句。myled_probe函数中调用myled_get_platform_resource获取platform设备资源、初始化LED、注册字符设备驱动。也就是将原来在驱动加载函数里面做的工作全部放到probe函数里面完成。
   第221~241行，platform驱动的remove函数myled_remove，当platform驱动模块卸载时此函数就会执行。在此函数里面释放内存、注销字符设备等。也就是将原来驱动卸载函数里面的工作全部都放到remove函数中完成。
   第244~250行，platform_driver平台驱动结构体，注意name字段为"zynq-led"，和我们在leddevice.c文件里面设置的设备name字段一致。
   第257~260行，模块入口函数myled_driver_init，在此函数里面通过platform_driver_register向Linux内核注册myled_driver这个platform驱动。
   第267~270行，模块出口函数myled_driver_exit，在此函数里面通过platform_driver_unregister从Linux内核卸载myled_driver这个platform驱动。
1.4.2测试APP编写
   测试APP的内容很简单，就是打开和关闭LED灯，在17_platform实验目录下新建LED测试源文件ledApp.c，然后在里面输入如下内容：

1. 示例代码 37.4.3 ledApp.c文件代码段
2. 1 /***************************************************************
3. 2 Copyright © ALIENTEK Co., Ltd. 1998-2029. All rights reserved.
4. 3 文件名 : ledApp.c
5. 4 作者 : 邓涛
6. 5 版本 : V1.0
7. 6 描述 : LED驱动测试源文件
8. 7 其他 : 无
9. 8 使用方法 : ./ledApp /dev/myled 0 关闭LED
10. 9 ./ledApp /dev/myled 1 打开LED
11. 10 论坛 : <a href="www.openedv.com" target="_blank">www.openedv.com</a>
12. 11 日志 : 初版V1.0 2019/1/30 邓涛创建
13. 12 ***************************************************************/
14. 13
15. 14 #include <stdio.h>
16. 15 #include <unistd.h>
17. 16 #include <sys/types.h>
18. 17 #include <sys/stat.h>
19. 18 #include <fcntl.h>
20. 19 #include <stdlib.h>
21. 20 #include <string.h>
22. 21
23. 22 /*
24. 23 * @description : main主程序
25. 24 * @param – argc : argv数组元素个数
26. 25 * @param – argv : 具体参数
27. 26 * @return : 0 成功;其他失败
28. 27 */
29. 28 int main(int argc, char *argv[])
30. 29 {
31. 30 int fd, ret;
32. 31 unsigned char buf[1];
33. 32
34. 33 if(3 != argc) {
35. 34 printf("Usage:\n"
36. 35 "\t./ledApp /dev/myled 1 [url=home.php?mod=space&uid=95564]@[/url] close LED\n"
37. 36 "\t./ledApp /dev/myled 0 @ open LED\n"
38. 37 );
39. 38 return -1;
40. 39 }
41. 40
42. 41 /* 打开设备 */
43. 42 fd = open(argv[1], O_RDWR);
44. 43 if(0 > fd) {
45. 44 printf("file %s open failed!\r\n", argv[1]);
46. 45 return -1;
47. 46 }
48. 47
49. 48 /* 将字符串转换为int型数据 */
50. 49 buf[0] = atoi(argv[2]);
51. 50
52. 51 /* 向驱动写入数据 */
53. 52 ret = write(fd, buf, sizeof(buf));
54. 53 if(0 > ret){
55. 54 printf("LED Control Failed!\r\n");
56. 55 close(fd);
57. 56 return -1;
58. 57 }
59. 58
60. 59 /* 关闭设备 */
61. 60 close(fd);
62. 61 return 0;
63. 62 }
复制代码

   ledApp.c文件内容很简单，就是控制LED灯的亮灭，和第二十三章的测试APP基本一致，这里就不重复讲解了。
   1.5运行测试
1.5.1编译驱动程序和测试APP
   1、编译驱动程序
   编写Makefile文件，将实验目录16_asyncnoti下的Makefile文件拷贝到本实验目录17_platform中，打开Makefile文件，将obj-m变量的值改为“leddevice.o leddriver.o”，Makefile内容如下所示：

1. 示例代码 37.5.1 Makefile文件
2. 1 KERN_DIR := /home/zynq/linux/kernel/linux-xlnx-xilinx-v2018.3
3. 2
4. 3 obj-m := leddevice.o leddriver.o
5. 4
6. 5 all:
7. 6 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -C $(KERN_DIR) M=`pwd` modules
8. 7
9. 8 clean:
10. 9 make -C $(KERN_DIR) M=`pwd` clean
复制代码

第3行，设置obj-m变量的值为“leddevice.o leddriver.o”。
文件修改完成之后，保存退出。输入如下命令编译出驱动模块文件：

1. make
复制代码

编译成功以后就会生成两个.ko模块文件leddevice.ko和leddriver.ko，如下所示：

图 37.5.1 编译出两个模块文件

2、编译测试APP
输入如下命令编译测试ledApp.c这个测试程序：

1. arm-linux-gnueabihf-gcc ledApp.c -o ledApp
复制代码

编译成功以后就会生成ledApp这个应用程序。
1.5.2运行测试
将上一小节编译出来leddevice.ko、leddriver.ko和ledApp这三个文件拷贝到开发板根文件系统/lib/modules/4.14.0-xilinx目录中，重启开发板，进入到目录/lib/modules/4.14.0-xilinx中，输入如下命令加载leddevice.ko设备模块和leddriver.ko驱动模块。

1. depmod //第一次加载驱动的时候需要运行此命令
2. modprobe leddevice.ko //加载设备模块
3. modprobe leddriver.ko //加载驱动模块
复制代码

图 37.5.2 加载模块

根文件系统中/sys/bus/platform/目录下保存着当前板子platform总线下的设备和驱动，其中devices子目录为platform设备，drivers子目录为plartofm驱动。查看/sys/bus/platform/devices/目录，看看我们的设备是否存在，我们在leddevice.c中设置myled_device(platform_device类型)的name字段为“zynq-led”，也就是设备名字为zynq-led，因此肯定在/sys/bus/platform/devices/目录下存在一个名字“zynq-led”的文件，否则说明我们的设备模块加载失败，结果如图 37.5.3所示：

图 37.5.3 zynq-led设备

同理，查看/sys/bus/platform/drivers/目录，看一下驱动是否存在，我们在leddriver.c中设置myled_driver(platform_driver类型)的name字段为“zynq-led”，因此会在/sys/bus/platform/drivers/目录下存在名为“zynq-led”这个文件，结果如图 37.5.4所示：

图 37.5.4 zynq-led驱动

驱动模块和设备模块加载成功以后platform总线就会进行匹配，当驱动和设备匹配成功以后就会输出如图 37.5.2所示一行语句。
驱动和设备匹配成功以后就可以测试LED灯驱动了，输入如下命令打开PS_LED0：

1. ./ledApp /dev/myled 1 //打开LED灯
复制代码

在输入如下命令关闭PS_LED0灯：

1. ./ledApp /dev/myled 0 //关闭LED灯
复制代码

观察开发板PS_LED0能否打开和关闭，如果可以的话就说明驱动工作正常，如果要卸载驱动的话输入如下命令即可：

1. rmmod leddriver.ko
2. rmmod leddevice.ko
复制代码

图 37.5.5 卸载设备模块和驱动模块

从图 37.5.5可以知道，当卸载leddriver.ko模块的时候，platform驱动的remove函数会被执行；当卸载leddevice.ko模块的时候，platform设备的release函数会被执行！

帐号		自动登录	找回密码
密码			立即注册

[XILINX] 《领航者ZYNQ之嵌入式Linux开发指南_V2.0》第三十七章 platform驱动

浏览过的版块

原子哥极力推荐 /1