(1)前面已经已经详细介绍了LED驱动如何进行编写的代码。如果韦东山Linux驱动入门实验班(4)LED驱动已经看懂了,驱动入门实验班后面的那些模块实验,其实和单片机操作差不太多了。我就不再浪费时间进行讲解了。
(2)本文主要进行讲解驱动的分层和分离,平台总线模型。
(3)对于韦东山老师的代码,我进行了微调,因为他代码写的比较着急,所以我感觉有些地方感觉有点冗余了就自作主张的进行了调整。但是原来他的部分没有删除,如果你认为韦东山老师的比我的好就可以注释掉我微调的部分。(微调部分我会进行说明)
(4)代码仓库:gitee仓库;github仓库
(5)注意:大家下载我仓库里面的代码再阅读本文会跟好理解一点。我仓库里面的代码依旧加上了详细的注释,觉得本文过于冗余。可以看我仓库代码和正点原子的文档学习
(1)通过前面的学习,我们会发现,Linux开发将一个程序分成了两个层,应用层和驱动层。但是我们在编写驱动层程序的时候,会发现,驱动还是和指定的引脚以及开发板有关。
(2)这时候肯定会有人说了,我只需要你改一下哪个数组就可以了啊,这有什么难的吗?
(3)不难,但是对于 Linux 这样一个成熟、庞大、复杂的操作系统,代码的重用性非常重要,否则的话就会在 Linux 内核中存在大量无意义的重复代码。尤其是驱动程序,因为驱动程序占用了 Linux内核代码量的大头,如果不对驱动程序加以管理,任由重复的代码肆意增加,那么用不了多久Linux 内核的文件数量就庞大到无法接受的地步。
(4)可能有些人会说了,我之前编写的程序,也没有重复啊。不过就只是要改一下驱动程序的gpios[]结构体的定义。但是,你要知道,在开发大型项目的时候,你将设备信息存入驱动程序中。每次调整都需要打开对应的驱动程序,如果我们不小心动了驱动程序的某个地方,产生了bug,排查是非常麻烦的。所以说,为了让Linux系统不变的臃肿,同时,为了安全性,于是Linux决定将驱动程序拆分成驱动程序和硬件描述程序,驱动程序一旦编写了,基本就不再需要再打开了。
(5)现在我们知道了,驱动程序与硬件描述程序的剥离之后。Linux于是提出了平台总线模型。我们将驱动程序和硬件描述信息都挂载在这个总线上面。
(6)有了这个总线,我们就可以先把我们设备上的一些信息挂载在总线上。然后给这些设备命一个名字。
(7)当我们需要使用指定设备的时候,驱动就可以通过给设备命的名字来找到设备信息。一旦驱动和设备匹配上,就可以执行指定的程序了。
(8)这样做有什么好处?这样我们的驱动程序可以直接进行移植,不需要受限于任何设备。而我们拿到一块开发板之后,可以直接把驱动移植过来,然后再编写设备描述信息即可,驱动代码几乎不再需要进行什么调整。
上面我们说了,Linux发明了平台总线,我们只需要将设备和驱动挂载在总线上,如果匹配上了,就会自动执行程序。那么设备是如何挂载在平台总线上。
(1)platform_device_register()这个函数可以将设备信息挂载在平台总线上。我们只需要传入struct platform_device结构体类型指针。
(2)如下是platform_device()结构体的定义,虽然参数很多,但是真正需要关注的只有name,id,resource,num_resources,dev。
<1>name:设备的名字, 用来和驱动相匹配。 名字相同才能匹配成功
<2>id:ID 是用来区分如果设备名字相同的时候(通过在后面添加一个数字来代表不同的设备, 因为有时候有这种需求)
<3>resource:资源结构体数组。我们需要写的设备信息写在这个数组里面。
<4>num_resources:资源结构体数量。表明这个设备结构体有多少个,其实就是一个宏定义#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
<5>dev:与平台设备相关联的设备对象。这个只需要知道要给.release参数传入一个函数指针即可。当设备被卸载的时候,会调用这个函数。
// platform 设备结构体
struct platform_device led_device = {
.name = "led_device", //platform 设备的名字, 用来和 platform 驱动相匹配。 名字相同才能匹配成功
.id = -1, // ID 是用来区分如果设备名字相同的时候(通过在后面添加一个数字来代表不同的设备, 因为有时候有这种需求)
.resource = led_resource, //指向一个资源结构体数组。 一般包含设备信息
.num_resources = ARRAY_SIZE(led_resource), //资源结构体数量
.dev = {
.release = LED_release,
}
};
(1)这个用于将设备从平台总线上卸载。当这个设备不需要的时候,我们就可以对他进行卸载。
(2)与platform_device_register()相同,也是只需要传入struct platform_device结构体类型指针。
(1)设备程序和驱动程序一样,都是使用insmod和rmmod进行装载和卸载。程序入口都是使用module_init()宏来进行定义,程序出口也都是使用module_exit()来定义。
(2)他也必须使用调用MODULE_LICENSE(“GPL”);指定模块为GPL协议
(1)这个函数只需要传入一个static struct platform_driver类型结构体指针。
(2)这个驱动的结构体,比设备的那个结构体还是好理解很多的。
<1>我们只需要知道platform_driver结构体".driver"中的".name"和platform_device结构体中的".name"一模一样就可以了。
<2>当设备和驱动匹配上了之后,我们就会执行probe函数。如果设备和驱动一旦断开联系了,就执行remove函数。你可以这么理解,一对男女,男生和女生结婚了,那么就会颁发结婚证(执行probe函数)。有一天,他们俩因为一些事情,感情破裂了,就会给他们一个离婚证(执行remove函数)。
static struct platform_driver led_driver = {
.driver = {
.name = "led_device", //根据这个名字,找到设备
.owner = THIS_MODULE,
},
.probe = led_drver_probe, //注册平台之后,内核如果发现支持某一个平台设备,这个函数就会被调用。入口函数
.remove = led_drver_remove, //出口函数
};
这个是用于在平台上卸载驱动的。和platform_driver_register()一样,都是传入一个static struct platform_driver结构体指针。
(1)这里主要就是把原来放在gpios[] 数组中的硬件描述信息,放在另外一个文件中。让驱动程序与硬件平台剥离。
(2)原来的硬件描述是存放在一个数组中,而现在的硬件描述是放在一个结构体指针里面,然后通过Linux中的平台总线获得设备信息。
/********** 原来的硬件描述 **********/
static struct gpio_desc gpios[] = {
{131, "led0" }, //引脚编号,名字
};
/********** 现在的硬件描述 **********/
static struct gpio_desc *gpios; //描述gpio
(1)在上一篇博客中,我们的驱动初始化函数都是放在module_init()这个宏里面。
(2)但是现在不一样了,module_init()这个宏里面的那个函数,只做一件事情,就是将static struct platform_driver结构体注册到平台总线上。
/********** 原来的module_init()中的函数任务 **********/
static int __init gpio_drv_init(void)
{
//申请GPIO
//将GPIO设置为输出
//注册字符驱动程序
//创建类
//创建设备名/dev目录下的设备名
}
/********** 现在的module_init()中的函数任务 **********/
//注册时候的入口函数
static int __init led_drver_init(void)
{
int ret = 0;
// platform驱动注册到 Linux 内核
ret = platform_driver_register(&led_driver); //注意,这里是driver表示是驱动
if(ret<0)
{
printk("platform_driver_register error \n");
return ret;
}
printk("platform_driver_register ok \n");
return ret;
}
(1)原来,我们初始化程序,只需要装载驱动程序即可。
(2)现在不一样了,我们需要注册相互匹配的设备程序和驱动程序,初始化程序probe函数才会执行。
(3)注意,设备程序和驱动程序的注册没有顺序。随便你先注册谁。
(1)下面这里有些人可能对pdev有疑问,这个是啥玩意?这个东西很简单,pdev就是被匹配上的设备struct platform_device结构体指针。
(2)当驱动和设备匹配上之后,执行probe函数。而这个函数的传入值struct platform_device *pdev就是被匹配上的设备struct platform_device结构体指针。
(3)因为struct platform_device结构体的num_resources记录了资源结构体的数量。所以可以通过pdev -> num_resources获取GPIO数量。
(4)我们看韦东山老师的代码,会发现好长,好麻烦。一开始我也是这么想的,命名一条指令就可以解决,搞这么长干嘛?后面简单的思考了一下。代码些这么长,还是一定作用的。
(5)我们来看platform_get_resource()这个函数,就是用于返回struct platform_device结构体中资源resource中flags被标记为IORESOURCE_IRQ的GPIO的GPIO信息。当我们这个GPIO的flags被标记为IORESOURCE_IRQ,就会返回一个指针指向这里。
(6)如果我们的设备,有些GPIO的flags没有被标记为了IORESOURCE_IRQ,那么就不会被count统计在内。
/********** 原来获取GPIO数量 **********/
int count = sizeof(gpios)/sizeof(gpios[0]); //统计有多少个GPIO
/********** 现在获取GPIO数量(作者的方法) **********/
count = pdev -> num_resources;
/********** 现在获取GPIO数量(韦东山老师的方法) **********/
while (1)
{
/* 下面这9行,是用于统计有多少个GPIO的
* dev:一个指向 platform_device 结构的指针,表示要获取资源信息的设备。
* type:一个无符号整数,表示要获取的资源类型。在 Linux 内核中,资源类型使用常量来表示,
例如 IORESOURCE_MEM 表示内存资源,IORESOURCE_IRQ 表示中断资源等。你可以根据需要选择适当的资源类型。
* num:一个无符号整数,表示要获取的资源的索引号。在一个设备中可能存在多个相同类型的资源,通过索引号可以区分它们。
* 返回值:返回一个指向 resource 结构的指针,表示获取到的资源信息。
resource 结构包含了资源的起始地址、大小等信息。如果没有找到指定的资源,函数将返回 NULL。
*/
led_resource = platform_get_resource(pdev, IORESOURCE_IRQ, count);
if (led_resource)
{
count++;
}
else
{
break;
}
}
(1)在原来的代码里面,我们的gpios被定义成了一个数组gpios[]。所以当我们在这个数组里面写入设备信息的时候,这个数组会自动改变空间大小。
(2)但是这里的设备信息不在驱动文件里面了,因此我们需要使用内存的动态分配了。我们知道GPIO有多少个之后,调用内存动态分配函数获取一个空间,然后把这个空间的首地址指针返回给gpios。
(3)需要注意的一点是,驱动的动态内存分配不能使用malloc,而是需要使用kmalloc。这个和驱动不能使用printf函数,只能使用printk函数是一个道理。
/********** 原来gpios空间分配 **********/
static struct gpio_desc gpios[] = {
{131, "led0" }, //引脚编号,名字
};
/********** 现在gpios空间分配 **********/
static struct gpio_desc *gpios; //描述gpio
/* 作用 : kmalloc是Linux内核中的一个内存分配函数,用于在内核空间中动态分配内存。
* 它类似于C语言中的malloc函数,但是在内核中使用kmalloc而不是 malloc,因为内核空间和用户空间有不同的内存管理机制。
* size : 要分配的内存大小,以字节为单位。
* flags : 分配内存时的标志,表示内存的类型和分配策略,是一个 gfp_t 类型的值。常常采用GFP_KERNEL
* GFP_KERNEL是内存分配的标志之一,它表示在内核中以普通的内核上下文进行内存分配。
* 返回值 : 如果内存分配成功,返回指向分配内存区域的指针。如果内存分配失败(例如内存不足),返回NULL。
*/
gpios = kmalloc(count * sizeof(struct gpio_desc), GFP_KERNEL);
(1)原来,我们直接向gpios[]数组里面写入硬件信息就可以了。
(2)因为现在我们将硬件信息写入了设备程序里面了,所以需要其他办法获得。从设备程序中获得硬件信息有两种方法。
<1>通过pedv指针直接获得硬件信息。
<2>通过platform_get_resource()函数获得。
(3)
<1>我们对比下面的代码会发现,led_resource和pdev->resource[i]是一个东西啊。
<2>可以这么说,但是还是有一定的区别。如果pdev->resource[i]的flags不是IORESOURCE_IRQ,那么就不会被提取出来成led_resource。
/********** 原来gpios获得硬件信息 **********/
static struct gpio_desc gpios[] = {
{131, "led0" }, //引脚编号,名字
};
/********** 现在gpios获得硬件信息 **********/
//通过pedv指针直接获得硬件信息。
gpios[i].gpio = pdev->resource[i].start;
sprintf(gpios[i].name, "%s", pdev->resource[i].name); //将platform_device.resource.name传递给gpios[i].name
//通过platform_get_resource()函数获得。
struct resource *led_resource;
led_resource = platform_get_resource(pdev, IORESOURCE_IRQ, i); //从节点里面取出第i项
gpios[i].gpio = led_resource->start; //将需要操作的IO号传递给gpios[i].gpio
sprintf(gpios[i].name, "%s", led_resource->name); //将platform_device.resource.name传递给gpios[i].name