【 声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：feixiaoxing @163.com】
前面我们聊过，树莓派的soc是怎么进行camera sensor驱动配置的。基本上它的camera驱动还是按照linux v4l2那一套处理的，比如说sensor代码放在什么地方，platform平台代码放在什么地方，这部分都是公开的，大家也都是可以看到源码的。但是ipcam soc的驱动，尤其是sensor驱动，可能和大家想的不一样。
1、camera sensor驱动是用户层
传统的v4l2驱动，sensor这一部分都是放在drivers/media/i2c里面完成的。如果是单独编译，也是编译成ko文件的。但是对于ipcam soc而言，这部分的驱动都是用so来完成的，也就是说，编译成的文件是动态库文件。这就意味着，整体的调试和基于kernel的驱动相比，要简单、方便很多。
2、sensor驱动放在用户层的原因
ipcam soc的用户很多，它面对的客户差异很大，大部分客户开发能力远没有那么强，这个时候如果把驱动放在用户层，就可以降低客户开发的难度。对于soc厂家来说，实现上面只需要配置一个virtual sensor device，然后通过某些char device接口和外部的so通信，这样就可以实现用户层开发驱动的目的。这一点和android的hal层非常相似，也就是说驱动部分，一部分放在了内核层，一部分放在了用户层。
3、mipi只需要靠配置文件解决
如果soc定下来了，那么怎么启动csi2、怎么初始化mipi，原则上这些都应该是厂家设置好的。作为用户来说，自己只要学会怎么使用就好了。对于里面的细节，实在是没有必要去了解。对于用户而言，他只要知道mipi lane数、bit位、分辨率、帧率这些简单的配置，应该就可以很快将mipi设置好，并且使用起来。对于csi2、dphy、mipi、platform这些底层的内容，即使不太了解，也完全不影响自己的嵌入式开发进度。
4、一个sensor驱动调试的通用方法
实际camera sensor驱动的过程当中，难免有很多的错误，这个时候调试手段就显得非常重要。目前而言，一般都是借助于/proc/mpp下面的子目录来进行调试的，比如vi就是cat /proc/mpp/vi。如果是输出，那么就是cat /proc/mpp/vo，这些都是ipcam soc下非常通用的一个调试方法。
5、isp标定需要server程序和上位机程序
server程序是跑在开发板上面的，通常是h264压缩后通过网络送上来的。如果没有压缩，很难做到实时性。而上位机程序，就是isp的标定软件。本身soc带有的这些isp功能，比如常见的blc、lsc、awb、ae、ccm、gamma、sharp这些，都是通过上位机标定程序、送上来的图片和道具一起来完成的。
6、isp驱动、encode驱动、decode驱动、sdk都是闭源的
**不管哪一家soc，实际运行的时候，我们发现他们提供的ko驱动是闭源的，提供的sdk（也就是上层动态库、静态库）也是闭源的。**这些sdk大部分不复杂，很大一部分就是对驱动里面的属性和寄存器进行配置，但是怎么配置，我们是不知道的。因此，对于每一个客户而言，大家能做的就是看懂手册、看懂demo代码，把这些demo代码转换成客户的功能需求。
实际开发的时候，对于输入、输出、编码、解码，我们很多时候也不是直接使用linux内核的v4l2接口，而是调用厂家自定义的mpp（多媒体处理平台）接口。好在当前各家soc厂家，基本都是以海思mpp sdk作为模板参考的，所以哪怕是其他soc平台的sdk，基本看下api名称，也知道怎么使用了。