fimc_capture.c在FIMC系统中的位置，网上偷来的一幅图片

http://blog.csdn.net/kickxxx/article/details/7733482

这个列表列出了FIMC支持的capture格式，app可以通过vidioc_s_fmt设置capture的输出格式，capture的输出格式必须在上面的列表中

这里的flags标志位并不符合V4L2标准，V4L2只支持一种标志：V4L2_FMT_FLAG_COMPRESSED。

samsung扩展了flags标志：

FORMAT_FLAGS_PACKED: 图片的像素点分量放在一同一个buffer中

FORMAT_FLAGS_PLANAR：图片像素的分量放在不同的buffer中

FORMAT_FLAGS_ENCODED：图片数据编码存储，如jpeg格式

定义了FIMC支持的ctrl，后面四个ctrl: V4L2_CID_PADDR_Y, V4L2_CID_PADDR_CB, V4L2_CID_PADDR_CR, V4L2_CID_PADDR_CBCR 是samsung fimc私有的ctrl id, 用来获取分量的物理起始地址。

这个函数主要对camera的sensor进行上电，初始化，这个函数最早的调用位置是streamon。

但是有一个问题，假定外围电路是一个video AD转换芯片托多个cvbs s-video或者YPbPr输入，那么在执行streamon之前，要首先执行s_input操作选择哪个video AD芯片的输入。选择video AD 的input输入是要操作AD芯片I2C寄存器的，因此这个上电位置是有问题的。

这个函数被qbuf调用，把@i指定的buffer加到cap->inq链表中

cap->inq是可用buffer链表，当FIMC更新out DMA address时，就设置为cap->inq中的一个buffer

411 在cap->inq buffer链表中取得第一个可用buffer

413 ～ 418 一直没明白为什么这里把buf设置到两个输出out DMA address寄存器中，华清远见有篇文档http://www.embedu.org/Column/Column457.htm对这个代码的解释是说最多可以把四个out DMA address都配置上，可以增加画面的流畅度。

我原来也是同意华清讲师的说法的，四个output DMA address把帧数分成四个部分，第一个DMA address存储 1, 5, 9, 13… 帧， 第二个DMA address存储2, 6, 10, 14…帧， 第三个存储3, 7, 11, 15…帧， 第四个存储4, 8, 12, 16…帧，如果仅使用一个output DMA address，那么仅能得到1/4的帧率。

但是测试后发现，删除414~415后重新编译的内核没发现有帧率的变化，对帧率没有任何影响。

420 ～ 421 从cap->inq 链表中删除这个buf

我觉得fimc应该把ENUMINPUT ioctl调用传递给sensor驱动实现，毕竟std, status甚至name，是隶属于sensor的特性，fimc不该管理这些信息，管理就破坏了fimc驱动的通用性。

与fimc_enum_input不同，fimc_g_input可以完全由fimc驱动实现，毕竟这个函数仅仅返回current input的编号，这个编号应该算是隶属于video设备@file的一个特性。

这个函数选择@file指定的video设备的input路径，我的理解是s_input必须要有sensor驱动参与，这里的实现并没有调用sensor的接口

分配queue buffer

@align：queue buffer是DMA buffer，所以会有alignment要求

@size：不同的format，每帧需要的子buffers数目不同，这个函数的plane就代表需要的子buffers数目，size[]是一个数组，表示queue buffers的每个子buffer需求的尺寸

902 cap->nr_bufs，是capture总的queue buffers数量。

975 ～978 FIMC_CAPBUFS是fimc支持的最大queue buffers数量，可以根据最大capture buffers数目，以及帧buffer所需空间大小（所有子buffers空间总和），加上alignment所带来的空间损失，大致算出fimc capture设备需要预留的物理空间
992 ～ 1057 根据pixelformat和width/height计算每个帧子buffers的尺寸。

1093 ~ 1095 buffer的length由三个分量buffer总长度决定
1097 这个需要结合fimc_mmap_cap来看，b->m.offset可以用来表示buffer的索引值

fimc_cropcap_capture：fimc的VIDIOC_CROPCAP的实现

cropcap.bounds 是capture window 最大边界，capture.defrect是capture window的默认方框

cropcap.defrect一定不会超出cropcap.bounds的范围，他们的关系如下图

cropcap.pixelaspect ＝垂直像素数 / 水平像素数

fimc_g_crop_capture 是capture设备的VIDIOC_G_CROP实现，返回当前的crop