linuxvfe框架,linuxcameraV4L2框架(一)

1.V4L2 驱动中的核心结构体

v4l2_device;一个v4l2的总设备。

v4l2_sbudev&＃xff1a;来描述camera等sensor设备&＃xff0c;一般是指挂接在总线(i2c)上的摄像头

video_device:实际和处理器采集口相关的配置&＃xff0c;一般该设备会完成注册以/dev/video0&＃xff0c;video1的字符设备注册的形式暴露给应用层。

video_device的重要性在于它具备承上启下的作用&＃xff0c;驱动实现的ioctl内容&＃xff0c;刚好则是为用户的控制提供了内核的实现。当然内核ioctl向下又是能控制相关的vfe和sensor&＃xff0c;如下

static struct video_device vfe_template &＃61; {

.name &＃61; "vfe",

.fops &＃61; &vfe_fops, //用户open的相关内容

.ioctl_ops &＃61; &vfe_ioctl_ops,//用户ioctl对应的相关内容 .release &＃61; video_device_release,

};

static const struct v4l2_file_operations vfe_fops &＃61; {

.owner &＃61; THIS_MODULE,

.open &＃61; vfe_open,

.release &＃61; vfe_close,

.read &＃61; vfe_read,

.poll &＃61; vfe_poll,

.ioctl &＃61; video_ioctl2, //最终会调用v4l2_ioctl_ops这个实际处理器的相关处理逻辑 // //.unlocked_ioctl &＃61;

.mmap &＃61; vfe_mmap,

};

static const struct v4l2_ioctl_ops vfe_ioctl_ops &＃61; {

.vidioc_querycap &＃61; vidioc_querycap,

.vidioc_enum_fmt_vid_cap &＃61; vidioc_enum_fmt_vid_cap,

.vidioc_enum_framesizes &＃61; vidioc_enum_framesizes,

.vidioc_g_fmt_vid_cap &＃61; vidioc_g_fmt_vid_cap,

.vidioc_try_fmt_vid_cap &＃61; vidioc_try_fmt_vid_cap,

.vidioc_s_fmt_vid_cap &＃61; vidioc_s_fmt_vid_cap,

.vidioc_reqbufs &＃61; vidioc_reqbufs,//video buffer缓存申请

.vidioc_querybuf &＃61; vidioc_querybuf,//查询buffer属性&＃xff0c;完成对用户v4l2的设置&＃xff0c;为mmap做准备

.vidioc_qbuf &＃61; vidioc_qbuf,//入列

.vidioc_dqbuf &＃61; vidioc_dqbuf,//出列

.vidioc_enum_input &＃61; vidioc_enum_input,

.vidioc_g_input &＃61; vidioc_g_input,

.vidioc_s_input &＃61; vidioc_s_input,

.vidioc_streamon &＃61; vidioc_streamon,//启动视频采集

.vidioc_streamoff &＃61; vidioc_streamoff,

.vidioc_queryctrl &＃61; vidioc_queryctrl,

.vidioc_g_ctrl &＃61; vidioc_g_ctrl,

.vidioc_s_ctrl &＃61; vidioc_s_ctrl,

.vidioc_g_parm &＃61; vidioc_g_parm,

.vidioc_s_parm &＃61; vidioc_s_parm,

#ifdef CONFIG_VIDEO_V4L1_COMPAT

.vidiocgmbuf &＃61; vidiocgmbuf,

#endif

};

video_device除了实现对基本的视频端口的硬件初始化&＃xff0c;还完成对相关的视频采集缓存区的维护&＃xff0c;通过queue来维护采集逻辑&＃xff0c;通过中断来触发处理。

2.视频采集的最底层部分当然是外设camera

不同的camera有不同的驱动&＃xff0c;但是他都凌驾在i2c的控制器上。故实现camera的驱动&＃xff0c;通常都是实现i2c_driver和i2c_client的相关内容。这里相关的i2c_adapter(和处理器自己的i2c总线特性相关&＃xff0c;比如A31有4路i2c&＃xff0c;故有4个 adapter)。

比如camera ov5640的驱动架构很简单&＃xff0c;但是为了和专门的视频采集挂接在一起&＃xff0c;他作为i2c_client的同时也是v4l2_sbudev子设备。

static const struct v4l2_subdev_ops sensor_ops &＃61; {

.core &＃61; &sensor_core_ops,

.video &＃61; &sensor_video_ops,

};

这个结构体是作为v4l2子设备的op,会通过video device的ioctl来调用实现。

在video的驱动中&＃xff0c;可以看到如下API&＃xff1a;

v4l2_i2c_new_subdev_b oard()&＃xff1a;生成一个新的i2c的v4l2子设备&＃xff0c;内部核心&＃xff1a;是建立一个i2c_board_info(表明板级上的一个i2c client),并将其完成设备的注册&＃xff0c;这会调用对应的camera驱动的probe函数。这里会调用函数&＃xff1a;

v4l2_i2c_subdev_init(sd, client, &sensor_ops);//subdevice建立&＃xff0c;与i2c client建立联系。

从上面的这个API的实现&＃xff0c;建立了subdev和client的关系后&＃xff0c;video这边就可以通过用户传入的ioctl命令来对subdev进行控制如&＃xff1a;

v4l2_subdev_call内部会调用i2c_client的驱动处理即上文中的sensor_ops中的core和video过程。

到此为止&＃xff0c;video device&＃xff0c;subdev, sensor之间的关系基本理通&＃xff0c;调用的顺序合理而且紧密&＃xff0c;如下图所示。

图1&＃xff1a;  linux内核视频采集驱动架构