1. 这个框架到底在解决什么问题搞Linux驱动开发的人迟早都会撞上V4L2全称是Video for Linux 2。做摄像头、HDMI采集、USB UVC摄像头、ISP图像信号处理相关的驱动绕不开这套框架。它的本质就是Linux内核里的一套视频采集标准接口用来统一管理视频设备的枚举、格式协商、数据流传输和缓冲区管理。先说一个最直接的感受如果你写过不带V4L2的摄像头驱动你大概率是自己在字符设备里搞read/write、自己管理DMA缓冲区、自己实现mmap然后发现用户空间的应用根本不买账因为你用了自己定义的一套接口GStreamer、FFmpeg、OpenCV这些常用的多媒体库全都对接不上。V4L2就是来终结这种各自为战的乱局的。V4L2这套框架做了一件很核心的事把视频设备抽象成标准的字符设备统一的ioctl命令体系。它定义了一套完整的控制协议让内核驱动只需要实现标准的操作函数用户空间就能用统一的API访问任意视频设备。它的意义类似USB协议规范——不管内部怎么实现对外接口统一设备就能互通。这篇内容我会从V4L2框架的核心结构、ioctl命令体系、videobuf2缓冲区管理、实际编写驱动的流程以及常见调试技巧几个方面展开。适合已经接触过Linux字符设备驱动、想进一步深入多媒体驱动方向的同学阅读。无论你是要调USB摄像头、写MIPI CSI摄像头驱动还是做视频采集卡这套框架的原理都是一样的看懂一个就能迁移到其他场景。2. V4L2框架的核心分层与设计思路2.1 从字符设备到视频设备的抽象V4L2驱动在Linux设备模型里依然是一个字符设备驱动主设备号通常是81次设备号动态分配。用户在应用层看到的是/dev/video0、/dev/video1这样的节点。这条链路的层次关系是这样的应用层调用open(/dev/video0)进入VFS层VFS根据设备号找到对应的字符设备调用驱动注册的file_operationsV4L2框架在file_operations上做了一层封装把ioctl分发到视频设备的v4l2_ioctl_ops上驱动就在v4l2_ioctl_ops中实现具体的硬件操作逻辑这套抽象的精妙之处在于硬件差异全部被压缩在驱动内部。对于用户空间来说USB摄像头和MIPI摄像头长得一模一样都是/dev/video0都支持同样的ioctl命令都能用同样的API采集画面。这就是“框架”这个词的真正含义——它把千差万别的硬件实现统一成一套对外契约。2.2 核心数据结构v4l2_device、video_device与v4l2_subdevV4L2框架里有三个核心结构体理解它们的职责分工就理解了整个框架的一半。struct v4l2_device是顶层容器代表一个“视频设备实体”。它并不直接暴露给用户空间而是作为驱动的根节点存在管理着下面挂载的所有子设备。一个完整的摄像头模组可能有传感器、ISP、旋转器等多个功能单元它们都挂在同一个v4l2_device下形成树状结构。struct video_device是真正注册到内核的设备对象用户空间看到的/dev/videoX就是它。它内部有一个v4l2_ioctl_ops结构体里面挂满了各种回调函数指针对应不同的ioctl命令。驱动需要实现哪些功能就填哪些回调。struct v4l2_subdev是子设备抽象对应一个独立的硬件功能单元。比如摄像头模组里的传感器就是一个subdev它通常挂在I2C总线上负责输出图像数据ISP或视频处理芯片也可以是一个subdev。subdev可以有自己的控制函数集通过v4l2_subdev_ops来定义供内核内部其他模块调用。这三者的隶属关系可以这样理解v4l2_device是公司video_device是对外窗口v4l2_subdev是内部的各个部门。公司可以搞多个对外窗口应对不同类型的数据流也可以根据业务需要增设或裁撤内部部门。2.3 videobuf2缓冲区管理的设计哲学V4L2最强大的设计其实是缓冲机制也就是videobuf2通常简称vb2。视频数据是高速大数据流一帧1080p的YUV422画面大约4MB30fps就是每秒120MB以上。如果走传统的read/write内核态拷贝CPU负载会高到完全无法接受。vb2的核心思想是内核对缓冲区做管理不搬运数据。它在驱动和用户空间之间建立一套共享内存机制通过mmap让用户空间直接映射硬件DMA写好的内存或者通过DMA_BUF把缓冲区导入导出到其他设备。数据在内存里只换手不搬家这是一切高性能视频处理的基础。vb2提供了完整的队列管理能力包括VIDIOC_QUERYBUF、VIDIOC_QBUF、VIDIOC_DQBUF这套用户空间侧的接口以及vb2_ops里诸如queue_setup、buf_prepare、start_streaming、stop_streaming等驱动侧回调。这套设计让开发者不需要关心缓冲区如何分配、如何同步、如何入队出队只需要把硬件的中断处理——也就是采集完一帧后调用vb2_buffer_done()——对接上就行了。我从实际使用体验来说这套框架在80%的场景下都是够用的而且设计非常干净。真正需要关注的不是框架本身而是内存分配的路径和DMA访问的安全性这两个点往往是视频驱动不稳定的根源。3. 核心细节解析从ioctl到数据流3.1 常用ioctl命令体系详解V4L2的ioctl命令非常多新手很容易看懵。我习惯把它分成几大类每一类对应一个功能维度第一类是能力查询类包括VIDIOC_QUERYCAP用来查询设备的能力比如是不是视频采集设备、支持哪些硬件功能还有VIDIOC_ENUM_FMT、VIDIOC_ENUM_FRAMESIZES、VIDIOC_ENUM_FRAMEINTERVALS用来枚举驱动支持的像素格式、分辨率和帧率。第二类是参数设置类包括VIDIOC_S_FMT设置格式、VIDIOC_S_PARM设置帧率参数、VIDIOC_S_CTRL设置控制项亮度、对比度、曝光等。第三类是缓冲区管理类包括VIDIOC_REQBUFS申请缓冲区、VIDIOC_QUERYBUF查询缓冲区信息、VIDIOC_QBUF入队、VIDIOC_DQBUF出队。第四类是流控类包括VIDIOC_STREAMON开始采集、VIDIOC_STREAMOFF停止采集。我自己在调试V4L2驱动时的经验是如果驱动能正确响应VIDIOC_QUERYCAP并返回合理的capabilities标志位应用层就不容易立刻崩格式协商环节不做好后面全白搭。这也是为什么我在写驱动时总是先把枚举和格式设置这块做得极其仔细宁可多写几个格式也别漏了应用会问到的条目。3.2 视频格式协商的关键点格式协商是V4L2驱动里最容易出问题的环节。应用的典型操作流程是先用VIDIOC_ENUM_FMT枚举格式然后调用VIDIOC_S_FMT通知驱动“我要用这个格式”驱动需要实际配置硬件并返回最终生效的格式。这里有几个容易踩坑的细节第一个坑是格式协商用的体例。VIDIOC_S_FMT传入的是一个v4l2_format结构体里面有type字段区分是采集还是输出。对于采集设备type必须设置为V4L2_BUF_TYPE_VIDEO_CAPTURE也就是0。如果驱动里只实现了采集类型而应用传了输出类型应该在vidioc_try_fmt和vidioc_s_fmt里先检查type不符合就直接返回-EINVAL。有些新手驱动不检查这一项结果应用传了个奇怪的类型进来驱动就把它当彩集来配置硬件直接跑飞。第二个坑是像素格式的硬件对齐。摄像头传感器输出的数据往往有对齐要求比如每行字节数需要16字节对齐、宽高需要是2的倍数等。驱动在接收应用设置的format时要做一层“修正”把不能支持的值调整到硬件允许的范围内并且把调整后的结果填回v4l2_format结构体。如果忽略这个修正过程后续DMA很可能出现内存越界或数据错位。第三个坑是驱动要支持TRY_FMT。有些应用不会直接用S_FMT而是先调用VIDIOC_TRY_FMT做试探性协商。驱动应该把try_fmt当作set_fmt一样来处理格式的修正和校验但不真正触达硬件。如果偷懒不实现try_fmt回调有的应用会直接报错退出。我测试过很多主流采集应用它们对格式协商的成功率非常敏感。只要协商失败应用往往给出一个让人摸不着头脑的错误比如“Failed to set format”直接退出。所以驱动开发时一定要先验证格式协商的全链路。3.3 数据流状态机的转换逻辑V4L2驱动在数据采集上有一套严格的状态转换逻辑理解这套状态机可以避免很多竞态问题。初始状态是IDLE即还没有申请缓冲区也不会启动采集。应用调用VIDIOC_REQBUFS后驱动进入缓冲区准备阶段分配好DMA缓冲区并将它们挂入空闲队列。这时缓冲区还不能被人取走数据因为还没有开始采集。当应用调用VIDIOC_QBUF把缓冲区入队后缓冲区进入等待填充状态。驱动一旦收到VIDIOC_STREAMON命令就会调用vb2_ops-start_streaming回调驱动在这个回调里打开硬件采集启动DMA让硬件开始往队列中的buffer填数据。硬件每完成一帧采集会触发中断驱动在中断下半部调用vb2_buffer_done(buffer, VB2_BUF_STATE_DONE)把缓冲区标记为完成并交还队列。应用此时通过VIDIOC_DQBUF可以取走这个缓冲区处理完后再QBUF还回来循环使用。停止采集时应用调用VIDIOC_STREAMOFF驱动调用stop_streaming需要等到硬件完全停止且所有缓冲区都归还后才能返回。这里有个很容易犯的错stop_streaming里还在DMA连发结果缓冲区里数据写到一半被用户空间取走了。所以必须等DMA完全停止才能让缓冲队列中的缓冲区状态变为ERROR或DONE。3.4 为什么V4L2选择这种ioctl内存映射的组合有人会问为什么不直接用read/write系统调用把数据交给应用呢这个问题从接口设计的角度很好回答——read/write的数据拷贝开销、阻塞语义、多线程分发这些都无法满足视频场景的高带宽和低延迟需求。V4L2的ioctlmmap组合实现了几个关键目标数据零拷贝硬件DMA把数据写到内存应用通过mmap直接映射内核完全不参与数据搬运多缓冲并发双缓冲、三缓冲机制让采集和消费并行不至于一帧卡一帧流控分离格式协商和实际采集解耦可以做到查询与应用互不干扰统一控制接口摄像头参数和属性暴露为统一的控制类ioctl跨设备适配更容易这套设计几乎找不到更优雅的替代方案。现代视频框架无论Windows的DirectShow还是macOS的AVFoundation本质上也都是类似的思路统一的设备抽象共享内存数据通路标准控制接口。4. 实操过程手写一个V4L2驱动核心流程4.1 驱动入口与设备注册这里以一个简单的虚拟采集驱动为例演示核心注册流程。真实硬件驱动的差异主要在数据生产的逻辑上框架本身的注册流程是通用的。驱动的入口是module_init在初始化函数中需要做三件事分配v4l2_device、初始化video_device、注册到内核。static struct v4l2_device v4l2_dev; static struct video_device vdev; static int v4l2_demo_probe(struct platform_device *pdev) { int ret; /* 1. 初始化v4l2_device */ v4l2_device_init(v4l2_dev, pdev-dev); /* 2. 初始化videobuf2队列 */ v4l2_demo_queue_init(demo_data.vb2_queue); v4l2_dev.queue demo_data.vb2_queue; /* 3. 设置video_device */ strscpy(vdev.name, v4l2-demo, sizeof(vdev.name)); vdev.release video_device_release_empty; vdev.fops v4l2_demo_fops; vdev.ioctl_ops v4l2_demo_ioctl_ops; vdev.v4l2_dev v4l2_dev; vdev.queue demo_data.vb2_queue; /* 4. 注册video_device */ ret video_register_device(vdev, VFL_TYPE_VIDEO, -1); if (ret 0) { v4l2_device_unregister(v4l2_dev); return ret; } video_set_drvdata(vdev, demo_data); return 0; }这里的关键在video_device初始化时fops和ioctl_ops两个指针决定了驱动对外的行为。fops一般直接使用v4l2_fops框架会完成设备和队列的关联内部再把ioctl分发到ioctl_ops去执行。VFL_TYPE_VIDEO这个参数决定设备节点类型使用这个参数会创建/dev/videoX节点。如果创建radio设备则用VFL_TYPE_RADIOVBI设备用VFL_TYPE_VBI这些都对应不同的次设备号范围和udev规则。4.2 ioctl_ops回调的填充v4l2_ioctl_ops结构体非常大但每个字段都有明确的对应ioctl命令。以视频采集驱动为例最核心的字段有这几个vidioc_querycap对应VIDIOC_QUERYCAP报告设备能力vidioc_enum_fmt_vid_cap对应VIDIOC_ENUM_FMT枚举支持的格式vidioc_try_fmt_vid_cap对应VIDIOC_TRY_FMT试探格式vidioc_s_fmt_vid_cap对应VIDIOC_S_FMT设置格式vidioc_reqbufs对应VIDIOC_REQBUFS申请缓冲区vidioc_querybuf对应VIDIOC_QUERYBUF查询缓冲vidioc_qbuf对应VIDIOC_QBUF入队vidioc_dqbuf对应VIDIOC_DQBUF出队vidioc_streamon对应VIDIOC_STREAMON开始采集vidioc_streamoff对应VIDIOC_STREAMOFF停止采集vidioc_querycap的实现很简单主要是填充能力标志位和驱动信息static int v4l2_demo_querycap(struct file *file, void *priv, struct v4l2_capability *cap) { strscpy(cap-driver, v4l2-demo, sizeof(cap-driver)); strscpy(cap-card, v4l2 demo device, sizeof(cap-card)); strscpy(cap-bus_info, platform:v4l2-demo, sizeof(cap-bus_info)); cap-device_caps V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING; cap-capabilities cap-device_caps | V4L2_CAP_DEVICE_CAPS; return 0; }device_caps是驱动对外公布的能力集合它决定了用户空间认为这个设备能干什么。如果这里漏填了V4L2_CAP_STREAMING很多应用会认定设备不支持streaming然后拒绝继续操作。这也是我在调试V4L2驱动时总会第一个怀疑的点。4.3 videobuf2队列的核心回调实现vb2队列是数据通路的心脏每个驱动都需要实现一组vb2_ops。这里演示最核心的四个回调static int v4l2_demo_queue_setup(struct vb2_queue *q, unsigned int *num_buffers, unsigned int *num_planes, unsigned int sizes[], struct device *alloc_devs[]) { struct v4l2_demo_dev *dev vb2_get_drv_priv(q); /* 单平面格式缓冲区大小按当前格式计算 */ if (*num_planes) { if (sizes[0] dev-format.sizeimage) return -EINVAL; return 0; } *num_planes 1; sizes[0] dev-format.sizeimage; return 0; } static int v4l2_demo_buf_prepare(struct vb2_buffer *vb) { struct v4l2_demo_dev *dev vb2_get_drv_priv(vb-vb2_queue); if (vb2_plane_size(vb, 0) dev-format.sizeimage) return -EINVAL; vb2_set_plane_payload(vb, 0, dev-format.sizeimage); return 0; } static int v4l2_demo_start_streaming(struct vb2_queue *q, unsigned int count) { struct v4l2_demo_dev *dev vb2_get_drv_priv(q); /* 开启采集定时器/中断模拟硬件开始输出图像 */ dev-streaming true; schedule_delayed_work(dev-work, msecs_to_jiffies(33)); return 0; } static void v4l2_demo_stop_streaming(struct vb2_queue *q) { struct v4l2_demo_dev *dev vb2_get_drv_priv(q); dev-streaming false; cancel_delayed_work_sync(dev-work); /* 把所有缓冲区的状态置为ERROR归还给app */ while (dev-buf_list) { struct vb2_buffer *vb get_pending_buf(dev); vb2_buffer_done(vb, VB2_BUF_STATE_ERROR); } }queue_setup决定缓冲区怎么分配。视频格式一变sizeimage就变了所以这里要每次都用当前格式的大小去校验。buf_prepare在每次缓冲区入队前都会调用这里检查缓冲区大小是否足够还不够就返回-EINVAL后面就没有然后了。start_streaming里要开启硬件同时要处理缓冲区不足的情况——如果驱动被要求开始采集但队列里还没有足够的buffer有的驱动选择等待有的选择上报错误。vb2框架提供VB2_BUF_STATE_ERROR来做错误处理把相关buffer都置错避免用户空间拿到不完整的帧。4.4 数据生产的模拟中断vs工作队列真实硬件驱动里图像数据通常由DMA完成后触发中断在中断处理函数中调用vb2_buffer_done告诉框架“这一帧好了”。虚拟驱动没有硬件中断可以用内核定时器或者工作队列来模拟数据生产。这里用delayed_work来模拟周期性出帧每个周期填充一帧模拟画面数据然后通知vb2队列。static void v4l2_demo_work_func(struct work_struct *work) { struct v4l2_demo_dev *dev container_of(work, struct v4l2_demo_dev, work.work); struct vb2_buffer *vb; while (dev-streaming) { vb vb2_find_buffer(dev-vb2_queue, dev-buf_counter); if (!vb) break; /* 填充模拟图像数据比如渐变颜色 */ fill_test_pattern(vb2_plane_vaddr(vb, 0), dev-format.sizeimage, dev-frame_count); /* 帧计数器时间戳保证时间单调递增 */ vb-timestamp ktime_get_ns(); vb2_buffer_done(vb, VB2_BUF_STATE_DONE); dev-buf_counter; dev-frame_count; } if (dev-streaming) schedule_delayed_work(dev-work, msecs_to_jiffies(33)); }vb2_plane_vaddr拿到的是内核虚拟地址可以当作普通内存往里边写数据。真实硬件驱动通常用dma_alloc_coherent分配过内存数据由硬件直接写入驱动不需要也不能往这个地址写数据。如果你要写的是真实驱动vb2_plane_vaddr在需要CPU准备数据的场景比如软件编码、格式转换才用得上硬件DMA直接写的话不要动它。4.5 时间戳与帧率控制一个容易忽略但很重要的问题时间戳。V4L2驱动在每次vb2_buffer_done时都应该设置vb-timestamp而且必须是单调递增的时钟通常用ktime_get_ns()或ktime_get_ts64()。为什么这么重要因为用户空间的GStreamer、FFmpeg之类工具会根据时间戳来同步音视频、计算帧率、做延迟补偿。如果时间戳跳跃或者重复会出现视频卡顿、音画不同步等诡异现象而问题根源你根本无从下手。帧率控制上驱动不能完全按自己节奏出数据。应用会通过VIDIOC_S_PARM来设置期望的帧率如果硬件不支持动态帧率至少要在g_parm中返回真实的帧间隔让应用知道实际的输出时序。虚拟驱动里我建议支持帧率切换因为这是测试应用兼容性最便捷的方式。5. 常见问题与排查技巧实录5.1 应用打不开设备节点如果应用反复报open /dev/video0 failed先排除三件事第一设备节点是否真的存在。运行ls /dev/video*查看如果没有节点检查驱动是否加载成功dmesg | tail看有没有注册信息。如果驱动注册了但节点没出现多半是udev规则或者devtmpfs的问题。第二权限是否足够。/dev/video0通常属于video组当前用户不在这个组里就会打开失败。sudo usermod -a -G video $USER可以解决但需要注意重新登录才生效。第三设备是否被其他进程占用。V4L2设备在打开时会检查排他标志如果另一个进程正在占着流你的应用打开后可能卡在VIDIOC_STREAMON上。5.2 格式协商失败或不匹配应用枚举到的格式和驱动实际支持的格式不一致这种问题排查起来很费劲。建议直接在驱动侧打日志在vidioc_try_fmt、vidioc_s_fmt里打印实际收到的fourcc和width、height再配合v4l2-ctl工具对比一遍v4l2-ctl -d /dev/video0 --list-formats-ext v4l2-ctl -d /dev/video0 --set-fmt-videowidth1920,height1080,pixelformatYUYV如果应用设置的格式驱动处理不了v4l2-ctl会直接返回错误码。对照一下就知道是应用传的格式不对还是驱动对格式做修正时出了问题。常见的例子是应用请求NV12驱动却没有实现NV12相关的fmt填写和转换逻辑try_fmt返回-EINVAL应用就认为设备不支持这个格式。这时驱动要把内核日志打开确认request进来的fourcc是什么。5.3 缓冲区入队后一直没有数据VIDIOC_STREAMON已经调用成功但DQBUF一直阻塞这种问题多半出在驱动侧没有真正“造出”数据来。排查路径是start_streaming有没有被调用如果没被调用检查streamon回调实现它有没有调用vb2_streamon如果调用了再看start_streaming里的硬件启动逻辑有没有真正把DMA开起来。虚拟驱动最常见的问题就是start_streaming里没有把定时器或工作队列调度起来或者delayed_work在stop_streaming被cancel后忘了重新schedule。另一种情况是vb2_buffer_done没有被调用。检查你的出帧逻辑是否遍历了当前队列中的所有缓冲区别漏了任何一个。队列里如果有buffer一直处于PREPARED状态却不被填充DQBUF自然就永远等不到。5.4 图像花屏、有噪声但不崩溃驱动能出图但画面不对这种问题在真实硬件中很常见常见原因有DMA地址不连续scatter/gather表没拼对导致一行数据跨页了行字节对齐不一致硬件输出按16字节对齐但用户空间期望的stride和实际不符像素格式匹配错位驱动报了NV12格式实际上硬件输出的是YUV422两个没有任何人会发现这个问题直到画面变成绿色或者有条纹时序问题DMA还有数据在飞驱动就已经宣告一帧完成了画面会有撕裂条纹我的排查习惯是第一站在驱动里把格式设置和实际的硬件寄存器值都打印出来做对照然后抓一帧原始数据保存下来用Python或者直接看hex数据判断格式是否吻合。如果原始数据是正常的那就是用户空间解析的问题如果原始数据就是乱的那问题一定在硬件或DMA配置上。5.5 v4l2-ctl和media-ctl的调试技巧V4L2驱动调试工具里最有用的一个是v4l2-ctl它几乎支持所有V4L2 ioctl命令。拿到一块新的视频设备我第一件事就是先跑这个v4l2-ctl -d /dev/video0 --all v4l2-ctl -d /dev/video0 --list-formats-ext v4l2-ctl -d /dev/video0 --set-fmt-videowidth640,height480,pixelformatYUYV --stream-mmap --stream-count10--stream-mmap用mmap模式抓几帧是验证驱动数据通路最简单的手段。如果这个命令能正常出帧并把统计信息打印出来说明核心采集流程是通的。用户空间再不正常问题就出在应用那边。如果驱动涉及多个subdev的链路用media-ctl查看和修改管线media-ctl -d /dev/media0 --print media-ctl -d /dev/media0 --set-v4l2 sensor 0-0010:0[fmt:SRGGB10_1X10/1920x1080]media-ctl还可以查看每个entity之间的链接状态排查数据通路中某个节点没接通的问题非常有用。5.6 性能优化与常见坑V4L2驱动的性能问题大部分都集中在拷贝和锁这两个方面。第一个大坑是没走零拷贝路径。如果驱动在buf_prepare里自己分配一块内存数据先到内存在拷贝到vb2 buffer性能会直接折半。正确的做法是直接用vb2分配器的内存做DMA数据处理从硬件到用户空间只经过一次内存。第二个大坑是锁粒度过大。采集驱动在中断里要尽量少干活锁竞争会直接影响帧率。我曾经见过一个驱动在中断处理里拿了设备锁再去调用vb2_buffer_done此时应用层正好阻塞在DQBUF上导致中断一直等症状。正确的解法是中断里只做必要的时间戳和状态更新然后唤醒一个线程或直接调用vb2接口避免长时间占用锁。第三个大坑是没有处理streamoff时的DMA残留。硬件还在写内存的时候调用stop_streaming缓冲区以ERROR状态返还已经算不错了更糟糕的是DMA越界写坏内核内存。所以真实驱动在disable DMA后需要通过寄存器确认DMA已经停住再归还buffer这一步不能省。6. 拓展阅读思路与实际应用建议V4L2框架本身知识量很大如果还想深入接下来建议看这几个方向阅读内核自带的vivid和uvcvideo驱动源码。vivid是一个虚拟V4L2设备驱动专门用来做框架学习和测试uvcvideo是真刀真枪跑的USB摄像头驱动代码里对协议处理的细节非常值得学习研究media controller框架。现代SoC的ISP驱动大多采用media controller架构pipe线管理、link使能、pad格式协商这套设计要单独花时间掌握熟悉用户空间主流的采集API。GStreamer v4l2src、FFmpeg v4l2的代码对理解内核接口语义很有帮助遇到疑难问题可以反向追踪用户空间的预期行为我在实际项目中最深刻的体会是V4L2框架本身并不难难的是把框架和硬件行为正确对接。框架只是合同硬件才是甲方。合同写得再漂亮甲方设备行为一复杂该黄还得黄。所以搞V4L2驱动的朋友请务必养成一个习惯——拿到一块板子先用主线工具把驱动“盘”一遍再上你自己的代码。这个习惯能帮你节省大把的排查时间。最后分享一个小技巧调试视频驱动时给驱动模块加一个dyndbg可以只开特定文件的日志echo file drivers/media/platform/v4l2-demo.c p /sys/kernel/debug/dynamic_debug/control这样不用全量打印流量小、定位准比你在代码里到处埋printk然后重新编译要高效得多。
