linux驱动模型

linux驱动开发（⼀）1：驱动开发环境要进⾏linux驱动开发我们⾸先要有linux内核的源码树，并且这个linux内核的源码树要和开发板中的内核源码树要⼀直；⽐如说我们开发板中⽤的是linux kernel内核版本为2.6.35.7，在我们ubuntu虚拟机上必须要有同样版本的源码树，我们再编译好驱动的的时候，使⽤modinfo XXX命令会打印出⼀个版本号，这个版本号是与使⽤的源码树版本有关，如果开发板中源码树中版本与modinfo的版本信息不⼀致使⽆法安装驱动的；我们开发板必须设置好nfs挂载；这些在根⽂件系统⼀章有详细的介绍；2：开发驱动常⽤的⼏个命令lsmod ：list moduel 把我们机器上所有的驱动打印出来，insmod：安装驱动rmmod：删除驱动modinfo：打印驱动信息3：写linux驱动⽂件和裸机程序有很⼤的不同，虽然都是操作硬件设备，但是由于写裸机程序的时候是我们直接写代码操作硬件设备，这只有⼀个层次；⽽我们写驱动程序⾸先要让linux内核通过⼀定的接⼝对接，并且要在linux内核注册，应⽤程序还要通过内核跟应⽤程序的接⼝相关api来对接；4：驱动的编译模式是固定的，以后编译驱动的就是就按照这个模式来套即可，下⾯我们来分下⼀下驱动的编译规则：#ubuntu的内核源码树，如果要编译在ubuntu中安装的模块就打开这2个#KERN_VER = $(shell uname -r)#KERN_DIR = /lib/modules/$(KERN_VER)/build# 开发板的linux内核的源码树⽬录KERN_DIR = /root/driver/kernelobj-m += module_test.oall:make -C $(KERN_DIR) M=`pwd` modulescp:cp *.ko /root/porting_x210/rootfs/rootfs/driver_test.PHONY: cleanclean:make -C $(KERN_DIR) M=`pwd` modules cleanmake -C $(KERN_DIR) M=`PWD` modules这句话代码的作⽤就是到 KERN_DIR这个⽂件夹中 make modules把当前⽬录赋值给M，M作为参数传到主⽬录的Makefile中，实际上是主⽬录的makefile中有⽬标modules，下⾯有⼀定的规则来编译驱动；#KERN_VER = $(shell uname -r)#KERN_DIR = /lib/modules/$(KERN_VER)/build我们在ubuntu中编译内核的时候⽤这两句代码，因为在ubuntu中为我们保留了⼀份linux内核的源码树，我们编译的时候直接调⽤那个源码树的主Makefile以及⼀些头⽂件、内核函数等；了解规则以后，我们设置好KERN_DIR、obj-m这两个变量以后直接make就可以了；经过编译会得到下⾯⼀些⽂件：下⾯我们可以使⽤lsmod命令来看⼀下我们ubuntu机器现有的⼀些驱动可以看到有很多的驱动，下⾯我们使⽤insmod XXX命令来安装驱动，在使⽤lsmod命令看⼀下实验现象可以看到我们刚才安装的驱动放在了第⼀个位置；使⽤modinfo来打印⼀下驱动信息modinfo xxx.ko这⾥注意vermagic 这个的1.8.0-41是你⽤的linux内核源码树的版本号，只有这个编译的版本号与运⾏的linux内核版本⼀致的时候，驱动程序才会被安装注意license：GPL linux内核开元项⽬的许可证⼀般都是GPL这⾥尽量设置为GPL，否则有些情况下会出现错误；下⾯使⽤rmmod xxx删除驱动；-------------------------------------------------------------------------------------5：下⾯我们分析⼀下驱动。

Linux的电源管理架构Linux的源代码里，大部分都属于设备驱动程序的代码，因此，大多数电源管理（PM）的代码也是存在于驱动程序当中。

很多驱动程序可能只做了少量的工作，另外一些，例如使用电池供电的硬件平台（移动电话等）则会在电源管理上做了大量的工作。

这份文档对驱动程序如何与系统的电源管理部分交互做了一个大概的描述，尤其是关联到驱动程序核心中的模型和接口的共享，建议从事驱动程序相关领域的人通过本文档可以了解相关的背景知识。

设备电源管理的两种模型===================================驱动程序可以使用其中一种模型来使设备进入低功耗状态：1. 系统睡眠模型：驱动程序作为一部分，跟随系统级别的低功耗状态，就像”suspend”（也叫做”suspend-to-RAM”），或者对于有硬盘的系统，可以进入”hibernation”（也叫做”suspend-to-disk”）。

这种情况下，驱动程序，总线，设备类驱动一起，通过各种特定于设备的suspend和resume 方法，清晰地关闭硬件设备和各个软件子系统，然后在数据不被丢失的情况下重新激活硬件设备。

有些驱动程序可以管理硬件的唤醒事件，这些事件可以让系统离开低功耗状态。

这一特性可以通过相应的/sys/devices/…/power /wakeup文件来开启和关闭（对于Ethernet驱动程序，ethtool通过ioctl接口达到同样的目的）；使能该功能可能会导致额外的功耗，但他让整个系统有更多的机会进入低功耗状态。

2. Runtime 电源管理模型：这种模型允许设备在系统运行阶段进入低功耗状态，原则上，他可以独立于其他的电源管理活动。

不过，通常设备之间不能单独进行控制（例如，父设备不能进入suspend，除非他的所有子设备已经进入suspend状态）。

此外，依据不同的总线类型，可能必须做出一些特别的操作来达到目的。

如果设备在系统运行阶段进入了低功耗状态，在系统级别的电源状态迁移时（suspend或hibernation）就必须做出特别的处理。

linux的bus、device、driver介绍 linux 通过device和driver分别管理系统中的设备和驱动，⽤bus将设备和驱动关联起来，bus可以看成是设备和驱动的媒介，可以匹配设备和驱动。

这样设备和驱动可以独⽴加载，互不影响。

sysfs是⼀个基于内存的⽂件系统，它的作⽤是将内核信息以⽂件的⽅式提供给⽤户程序使⽤。

我们都知道设备和对应的驱动都是由内核管理的，这些对于⽤户空间是不可见的。

现在通过sysfs，可以在⽤户空间直观的了解设备驱动的层次结构。

⼀、bus注册过程bus_type结构体代表⼀条总线，如下所⽰：struct bus_type {const char *name; //名称const char *dev_name;struct device *dev_root;struct device_attribute *dev_attrs; /* use dev_groups instead */const struct attribute_group **bus_groups;const struct attribute_group **dev_groups;const struct attribute_group **drv_groups;int (*match)(struct device *dev, struct device_driver *drv); //device和driver的匹配函数int (*uevent)(struct device *dev, struct kobj_uevent_env *env);int (*probe)(struct device *dev);int (*remove)(struct device *dev);void (*shutdown)(struct device *dev);int (*online)(struct device *dev);int (*offline)(struct device *dev);int (*suspend)(struct device *dev, pm_message_t state);int (*resume)(struct device *dev);const struct dev_pm_ops *pm;const struct iommu_ops *iommu_ops;struct subsys_private *p; struct lock_class_key lock_key;};struct subsys_private {struct kset subsys; //对应/sys/bus⽬录struct kset *devices_kset; //对应/sys/bus/devices⽬录struct list_head interfaces;struct mutex mutex;struct kset *drivers_kset; //对应/sys/bus/drivers⽬录struct klist klist_devices; //该bus下的所有devicestruct klist klist_drivers; //该bus下的所有driverstruct blocking_notifier_head bus_notifier;unsigned int drivers_autoprobe:1;struct bus_type *bus;struct kset glue_dirs;struct class *class;};向系统添加⼀条bus_type总线时，改总线会⾃动添加到/sys/bus⽬录下，bus⽬录是系统⾃动创建的，这个bus⽬录为static struct kset *bus_kset，定义在kernel/drivers/base/bus.c中。

Linux设备驱动程序原理及框架-内核模块入门篇内核模块介绍应用层加载模块操作过程内核如何支持可安装模块内核提供的接口及作用模块实例内核模块内核模块介绍Linux采用的是整体式的内核结构，这种结构采用的是整体式的内核结构，采用的是整体式的内核结构的内核一般不能动态的增加新的功能。

为此，的内核一般不能动态的增加新的功能。

为此，Linux提供了一种全新的机制，叫(可安装) 提供了一种全新的机制，可安装) 提供了一种全新的机制模块” )。

利用这个机制“模块”(module)。

利用这个机制，可以)。

利用这个机制，根据需要，根据需要，在不必对内核重新编译链接的条件将可安装模块动态的插入运行中的内核，下，将可安装模块动态的插入运行中的内核，成为内核的一个有机组成部分；成为内核的一个有机组成部分；或者从内核移走已经安装的模块。

正是这种机制，走已经安装的模块。

正是这种机制，使得内核的内存映像保持最小，的内存映像保持最小，但却具有很大的灵活性和可扩充性。

和可扩充性。

内核模块内核模块介绍可安装模块是可以在系统运行时动态地安装和卸载的内核软件。

严格来说，卸载的内核软件。

严格来说，这种软件的作用并不限于设备驱动，并不限于设备驱动，例如有些文件系统就是以可安装模块的形式实现的。

但是，另一方面，可安装模块的形式实现的。

但是，另一方面，它主要用来实现设备驱动程序或者与设备驱动密切相关的部分(如文件系统等)。

密切相关的部分(如文件系统等)。

课程内容内核模块介绍应用层加载模块操作过程内核如何支持可安装模块内核提供的接口及作用模块实例内核模块应用层加载模块操作过程内核引导的过程中，会识别出所有已经安装的硬件设备，内核引导的过程中，会识别出所有已经安装的硬件设备，并且创建好该系统中的硬件设备的列表树：文件系统。

且创建好该系统中的硬件设备的列表树：/sys 文件系统。

(udev 服务就是通过读取该文件系统内容来创建必要的设备文件的。

)。

Linuxkernel驱动相关抽象概念及其实现之“bus，device，driver”bus，device，driver三个很重要的概念贯穿Linux内核驱动架构，特转载⼀篇博⽂：内核的开发者将总线，设备，驱动这三者⽤软件思想抽象了出来，巧妙的建⽴了其间的关系，使之更形象化。

结合前⾯所学的知识，总的来说其三者间的关系为bus有两条链表，分别⽤于挂接设备和驱动，指定了其⾃⾝bus的device或者driver最后都会分别连接到对应bus的这两条链表上，⽽总线⼜有其始端，为bus_kset，⼀个driver可以对应于⼏个设备，因此driver同样有其设备链表，⽤于挂接可以操作的设备，其⾃⾝也有bus挂接点，⽤于将⾃⾝挂接到对应bus（每个driver只属于⼀条总线），⽽对于device，⼀个设备只属于⼀条总线，只能有⼀个driver与其对应，因此对于device，都是单⼀的，⼀个driver挂接点，⼀个bus挂接点，device与bus相同的是都有始端，device为devices_kset，因此device的注册同时会出现在对应的bus⽬录和device总⽬录下。

好了，下⾯就以源码为例分别分析⼀下bus，device，driver的注册过程。

⼀、bus的注册bus的注册⽐较简单，⾸先来看⼀下bus的结构：1struct bus_type {2const char *name; //名字3struct bus_attribute *bus_attrs; //bus属性集4struct device_attribute *dev_attrs; //device属性集5struct driver_attribute *drv_attrs; //driver属性集6int (*match)(struct device *dev, struct device_driver *drv);7int (*uevent)(struct device *dev, struct kobj_uevent_env *env);8int (*probe)(struct device *dev);9int (*remove)(struct device *dev);10void (*shutdown)(struct device *dev);11int (*suspend)(struct device *dev, pm_message_t state);12int (*resume)(struct device *dev);13const struct dev_pm_ops *pm;14struct bus_type_private *p; //bus的私有成员15 };16//其中重点看⼀下私有成员结构体：17struct bus_type_private {18struct kset subsys; //bus内嵌的kset，代表其⾃⾝19struct kset *drivers_kset;20struct kset *devices_kset;21struct klist klist_devices; //包含devices链表及其操作函数22struct klist klist_drivers; //driver链表及其操作函数23struct blocking_notifier_head bus_notifier;24 unsigned int drivers_autoprobe:1; //匹配成功⾃动初始化标志25struct bus_type *bus;26 };⽆论是bus，driver，还是device其本⾝特征都放在私有成员⾥，其注册时，都会申请并填充这个结构体，下⾯具体分析⼀下bus的注册流程，从bus_register开始：1int bus_register(struct bus_type *bus)2 {3int retval;4struct bus_type_private *priv;5 priv = kzalloc(sizeof(struct bus_type_private), GFP_KERNEL); //进⼊时bus_type->bus_type_private为NULL6if (!priv) //该函数主要是对其的设置7return -ENOMEM;8 priv->bus = bus; //私有成员的bus回指该bus9 bus->p = priv; //初始化bus->p,即其私有属性10 BLOCKING_INIT_NOTIFIER_HEAD(&priv->bus_notifier);11 retval = kobject_set_name(&priv->subsys.kobj, "%s", bus->name); //设置该bus的名字，bus是kset的封装12if (retval)13goto out;14//bus_kset即为所有bus的总起始端点15//围绕bus内嵌的kset初始化，和kset的初始化时围绕16 priv->subsys.kobj.kset = bus_kset; //kobj相似，没有parent时，就会⽤kset的kobj，此处即是17 priv->subsys.kobj.ktype = &bus_ktype; //属性操作级别统⼀为bus_ktype18 priv->drivers_autoprobe = 1; //设置该标志，当有driver注册时，会⾃动匹配devices19//上的设备并⽤probe初始化，20//当有device注册时也同样找到 driver并会初始化21 retval = kset_register(&priv->subsys); //注册kset，创建⽬录结构，以及层次关系22if (retval)23goto out;24 retval = bus_create_file(bus, &bus_attr_uevent); //当前bus⽬录下⽣成bus_attr_uevent属性⽂件25if (retval)26goto bus_uevent_fail;27 priv->devices_kset = kset_create_and_add("devices", NULL, //初始化bus⽬录下的devices⽬录，⾥⾯级联了该bus下设备，28 &priv->subsys.kobj); //仍然以kset为原型29if (!priv->devices_kset) {30 retval = -ENOMEM;31goto bus_devices_fail;32 }33 priv->drivers_kset = kset_create_and_add("drivers", NULL, //初始化bus⽬录下的drivers⽬录，⾥⾯级联了该bus下设备的driver34 &priv->subsys.kobj);35if (!priv->drivers_kset) {36 retval = -ENOMEM;37goto bus_drivers_fail;38 }39 klist_init(&priv->klist_devices, klist_devices_get, klist_devices_put); //初始化klist_devices⾥的操作函数成员40 klist_init(&priv->klist_drivers, NULL, NULL); //klist_drivers⾥的操作函数置空41 retval = add_probe_files(bus); //增加bus_attr_drivers_probe和bus_attr_drivers_autoprobe42if (retval) //属性⽂件43goto bus_probe_files_fail;44 retval = bus_add_attrs(bus); //增加默认的属性⽂件45if (retval)46goto bus_attrs_fail;47 pr_debug("bus: '%s': registered/n", bus->name);48return0;49 bus_attrs_fail: //以下为错误处理50 remove_probe_files(bus);51 bus_probe_files_fail:52 kset_unregister(bus->p->drivers_kset);53 bus_drivers_fail:54 kset_unregister(bus->p->devices_kset);55 bus_devices_fail:56 bus_remove_file(bus, &bus_attr_uevent);57 bus_uevent_fail:58 kset_unregister(&bus->p->subsys);59out:60 kfree(bus->p);61 bus->p = NULL;62return retval;63 }由此可见，bus⼜是kset的封装，bus_register主要完成了其私有成员bus_type_private的初始化，并初始化了其下的两个⽬录devices和drivers，及其属性⽂件，bus有个⾃⼰的根⽬录也就是bus有个起始端点，是bus_kset，经过此番的注册，bus⽬录下将会出现我们注册的bus，并且其下会有device和driver两个⼦⽬录，代表它下⾯的driver和device链表。

Linux设备模型的关键之一：Uevent1. Uevent的功能Uevent是Kobject的一部分，用于在Kobject状态发生改变时，例如增加、移除等，通知用户空间程序。

用户空间程序收到这样的事件后，会做相应的处理。

该机制通常是用来支持热拔插设备的，例如U盘插入后，USB相关的驱动软件会动态创建用于表示该U盘的device结构（相应的也包括其中的kobject），并告知用户空间程序，为该U盘动态的创建/dev/目录下的设备节点，更进一步，可以通知其它的应用程序，将该U盘设备mount到系统中，从而动态的支持该设备。

2. Uevent在kernel中的位置下面图片描述了Uevent模块在内核中的位置：由此可知，Uevent的机制是比较简单的，设备模型中任何设备有事件需要上报时，会触发Uevent提供的接口。

Uevent模块准备好上报事件的格式后，可以通过两个途径把事件上报到用户空间：一种是通过kmod模块，直接调用用户空间的可执行文件；另一种是通过netlink通信机制，将事件从内核空间传递给用户空间。

注1：有关kmod和netlink，会在其它文章中描述，因此本文就不再详细说明了。

3. Uevent的内部逻辑解析3.1 Source Code位置Uevent的代码比较简单，主要涉及kobject.h和kobject_uevent.c两个文件，如下：include/linux/kobject.hlib/kobject_uevent.c3.2 数据结构描述kobject.h定义了uevent相关的常量和数据结构，如下：kobject_action1: /* include/linux/kobject.h, line 50 */2: enum kobject_acTIon {。

Linux摄像头驱动学习之：（四）UVC-摄像头驱动框架分析UVC: USB Video ClassUVC驱动：drivers\media\video\uvc\uvc_driver.c分析:1. usb_register(&uvc_driver.driver);2. uvc_probeuvc_register_videovdev = video_device_alloc();vdev->fops = &uvc_fops;video_register_device在下载 uvc specification,UVC 1.5 Class specification.pdf : 有详细描述USB_Video_Example 1.5.pdf : 有⽰例通过VideoControl Interface来控制，通过VideoStreaming Interface来读视频数据，VC⾥含有多个Unit/Terminal等功能模块，可以通过访问这些模块进⾏控制，⽐如调亮度分析UVC驱动调⽤过程：const struct v4l2_file_operations uvc_fops = {.owner = THIS_MODULE,.open = uvc_v4l2_open,.release = uvc_v4l2_release,.ioctl = uvc_v4l2_ioctl,.read = uvc_v4l2_read,.mmap = uvc_v4l2_mmap,.poll = uvc_v4l2_poll,};1. open:uvc_v4l2_open2. VIDIOC_QUERYCAP // video->streaming->type 应该是在设备被枚举时分析描述符时设置的if (video->streaming->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)cap->capabilities = V4L2_CAP_VIDEO_CAPTURE| V4L2_CAP_STREAMING;elsecap->capabilities = V4L2_CAP_VIDEO_OUTPUT| V4L2_CAP_STREAMING;3. VIDIOC_ENUM_FMT // format数组应是在设备被枚举时设置的format = &video->streaming->format[fmt->index];4. VIDIOC_G_FMTuvc_v4l2_get_format // USB摄像头⽀持多种格式fromat, 每种格式下有多种frame(⽐如分辨率)struct uvc_format *format = video->streaming->cur_format;struct uvc_frame *frame = video->streaming->cur_frame;5. VIDIOC_TRY_FMTuvc_v4l2_try_format/* Check if the hardware supports the requested format. *//* Find the closest image size. The distance between image sizes is* the size in pixels of the non-overlapping regions between the* requested size and the frame-specified size.*/6. VIDIOC_S_FMT // 只是把参数保存起来，还没有发给USB摄像头uvc_v4l2_set_formatuvc_v4l2_try_formatvideo->streaming->cur_format = format;video->streaming->cur_frame = frame;7. VIDIOC_REQBUFSuvc_alloc_buffersfor (; nbuffers > 0; --nbuffers) {mem = vmalloc_32(nbuffers * bufsize);if (mem != NULL)break;}8. VIDIOC_QUERYBUFuvc_query_buffer__uvc_query_buffermemcpy(v4l2_buf, &buf->buf, sizeof *v4l2_buf); // 复制参数9. mmapuvc_v4l2_mmap10. VIDIOC_QBUFuvc_queue_bufferlist_add_tail(&buf->stream, &queue->mainqueue);list_add_tail(&buf->queue, &queue->irqqueue);11. VIDIOC_STREAMONuvc_video_enable(video, 1) // 把所设置的参数发给硬件,然后启动摄像头/* Commit the streaming parameters. */uvc_commit_videouvc_set_video_ctrl /* 设置格式fromat, frame */ret = __uvc_query_ctrl(video->dev /* 哪⼀个USB设备 */, SET_CUR, 0,video->streaming->intfnum /* 哪⼀个接⼝: VS */,probe ? VS_PROBE_CONTROL : VS_COMMIT_CONTROL, data, size,uvc_timeout_param);/* 启动：Initialize isochronous/bulk URBs and allocate transfer buffers. */uvc_init_video(video, GFP_KERNEL);uvc_init_video_isoc / uvc_init_video_bulkurb->complete = uvc_video_complete; (收到数据后此函数被调⽤,它⼜调⽤video->decode(urb, video, buf); ==>uvc_video_decode_isoc/uvc_video_encode_bulk => uvc_queue_next_buffer => wake_up(&buf->wait);)usb_submit_urb12. polluvc_v4l2_polluvc_queue_pollpoll_wait(file, &buf->wait, wait); // 休眠等待有数据13. VIDIOC_DQBUFuvc_dequeue_bufferlist_del(&buf->stream);14. VIDIOC_STREAMOFFuvc_video_enable(video, 0);usb_kill_urb(urb);usb_free_urb(urb);分析设置亮度过程：ioctl: VIDIOC_S_CTRLuvc_ctrl_setuvc_ctrl_commit__uvc_ctrl_commit(video, 0);uvc_ctrl_commit_entity(video->dev, entity, rollback);ret = uvc_query_ctrl(dev /* 哪⼀个USB设备 */, SET_CUR, ctrl->entity->id /* 哪⼀个unit/terminal */,dev->intfnum /* 哪⼀个接⼝: VC interface */, ctrl->info->selector,uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT),ctrl->info->size);总结：1. UVC设备有2个interface: VideoControl Interface, VideoStreaming Interface2. VideoControl Interface⽤于控制，⽐如设置亮度。

Linux驱动中，probe函数何时被调⽤最近看到linux的设备驱动模型，关于Kobject、Kset等还不是很清淅。

看到了struct device_driver这个结构时，想到⼀个问题：它的初始化函数到底在哪⾥调⽤呢？以前搞PCI驱动时⽤pci驱动注册函数就可以调⽤它，搞s3c2410驱动时只要在mach-smdk2410.c中的struct platform_device *smdk2410_devices {}中加⼊设备也会调⽤。

但从来就没有想过具体的驱动注册并调⽤probe的过程。

于是打开SourceInsight追踪了⼀下：从driver_register看起：int driver_register(struct device_driver * drv){klist_init(&drv->klist_devices, klist_devices_get, klist_devices_put);init_completion(&drv->unloaded);return bus_add_driver(drv);}klist_init与init_completion没去管它，可能是2.6的这个设备模型要做的⼀些⼯作。

直觉告诉我要去bus_add_driver。

bus_add_driver中：都是些Kobject 与 klist 、attr等。

还是与设备模型有关的。

但是其中有⼀句：driver_attach(drv);单听名字就很像：void driver_attach(struct device_driver * drv){bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);}这个熟悉，遍历总线上的设备并设⽤__driver_attach。

在__driver_attach中⼜主要是这样：driver_probe_device(drv, dev);跑到driver_probe_device中去看看：有⼀段很重要：if (drv->bus->match && !drv->bus->match(dev, drv))goto Done;明显，是调⽤的驱动的总线上的match函数。