展锐公司有自己的isp 图像处理引擎，从2012 年底就开始在智能手机上部署应用。最初的时候就几个人做一款isp的从hal 到kernel 驱动的完整软件系统，分工不是很明确，基本是谁擅长哪些就搞哪些，除了架构和编码实现之外，另外还要解决各种客户问题，验证芯片等等，工作量非常之大。
后续随着分工的精细，部门的扩展，各种模块分层迭代和维护越来越明确和专业。本人最后在展锐的时候，基本上分成内核驱动，hal驱动，sensor 和mipi 驱动，tuning效果，3A 算法，效果算法，功耗带宽，isp工具，总体架构这样的团组划分。每一款手机芯片都是按照这样的分类来集体参与完成了。
每一款芯片从评估定案到最终的平台开发完成，都是一个比较耗时的过程。下面详细介绍下一款芯片项目camera系统的周期和阶段内容。
评估定案
评估定案基本上需要半年的时间，这期间asic 和总体架构部门会综合市场各家的手机特点需求，行业对isp的预期需求，camera团组内部基于前几款芯片使用实现上的痛点和优改需求，逐步迭代出一款比较准确的芯片规格出来。
芯片规格在定案后期，需要各个团队来参与讨论，设计是否满足需求，验证case需要哪些，工期如何安排，进行一系列的交流和宣导。这期间开发人员都能拿到最初的规格书，同步开始学习，预先安排后期的验证和集成了。
芯片验证
项目首先开展的是芯片的验证，asic 会在整体的芯片基础上，保留最基本的AP的CPU 子系统，加上最新的isp 子系统，扣出生成早期是在FPGA 44b0，后来是在稳定的HAPS 系统上来验证camera 的除了功耗，带宽性能的各项基本功能的bitfile出来。
验证的软件 是在没有os的小系统上展开，使用纯粹的小code，接入帧率降的足够低的sensor配置，验证各通路和各个通路模块依次打开，不同组合，在典型配置的情形下的图像输出状况。一般来说，首先是offline的验证，也就是从DDR 输入到DDR 输出，这个最容易比较和确认。然后是senor没打通情形下 使用test pattern 这类内部预定的格式图样进行验证，最后是真实的sensor 接入的online 验证。
小code 也有专门的分支管理，基本上沿用之前芯片项目上的小code，芯片变化部分做额外的修改处理，框架保持不变，而且寄存器操作的code 可以复制到安卓等的内核驱动中去，减少了后续额外的工作量，这样对后续的项目和人员的稳定非常友好，验证过一款芯片以后，基本上后续的芯片项目都能迅速上手。
完整的验证过程需要和sensor 厂商和asic 部门经常做交互沟通，在摄像头出帧和isp 输出不达预期的各种情形下反复的交互。这个小code 验证在早期的芯片项目上需要花费2人2个多月的时间，最新的项目上应该有3~4人，至少3月的投入，这部分工作由内核驱动驱动组来承担完成。
集成到安卓
芯片验证完成，这时候asic 这边在送样到台积电，中芯国际这些厂商之前，还有其他的工作量，基本上有2~3月这样的时间，这期间平台部门在综合可运行安卓大系统bit的FPGA或者HAPS 上跑安卓系统，在安卓系统起来之后各个部门可以运行自己的模块，比如camera 系统，也是在这时候完整的搭建起来。
在安卓系统在FPGA或者HAPS 上平台部门运行起来之后，camera 这边需要在以前最接近的芯片安卓项目的基础上做个移植，将完整的从HAL到kernel的code porting到安卓分支上，去除电源管理和clk等，这样才能在安卓系统上适配，但是安卓系统过于庞大，在FPGA或者HAPS 运行效率过于低下，一次开机运行到安卓界面至少需要2个小时，中间如果修改没有致命的宕机问题，可以使用adb 来反复装载调试，但是一旦宕机，这重启运行的时间成本比较高昂。
展锐在2013年后开始了minicamera 这种简易化开发，就是仅需要linux 在FPGA或者HAPS起来，在输出log的串口和关联sensor的i2c 驱动可用的情形下，就可以通过剪裁后的安卓camera系统，也就是minicamer 这种，来进行高效的大系统camera 集成，等到这种调试完毕，在安卓上只要切换下被开关屏蔽的部分，就能转入完整安卓系统的运行。这样minicamera 完成的同时，安卓系统也宣告基本搭建完成。
minicamera的构建原理起初是在HAL 层之上，增加一个main.c 文件，模仿cameraserver 调用HAL的打开关闭sensor后预览拍照录像流程，生成单独的elf 文件，来实现这些基本流程的运行，从而在简单的linux上来实现调式。后续是做在了sprd_oem之上，撇开了HAL的模块。具体可以参考 展锐平台手机camera 软硬件架构 这个框架图。
这里需要串口来输出kernel 和 hal 驱动运行中的log，有时还需要另外一个串口来建立gdb 链接来调试HAL 层这部分的流程code，还需要调试器等技能配合来查看isp 硬件系统的寄存器和iommu 页表等。
minicamera的搭建和集成一般花费kernel 驱动组 1个人1个多月的时间，基本上在安卓大系统上验证了整体的预览拍照录像，还有tuning需要的raw 拍照流程，这样搭建好了关于此款芯片安卓上实现架构。和小code验证一样，唯一没有用到的就是供电，clk 这类。这样验证完毕后，安卓大系统上asic 关于芯片的设计是完全基本可用，没有大的方向上的问题了。
芯片bringup
第一批芯片回来之后，在大系统上配置好clk，供电部分code，或者搞成clk 或者eb全开方式，使用上节**" 集成到安卓"**同样的流程，一般花费不到1周，就能在安卓上去点亮sensor，预览到实时图像。证明完整的系统是能初步工作了，这个还是kernel 驱动组单个人能完成的事情。
芯片回片的同时，也会另外安排小code 验证的人员，加上最高的频率，正常的sensor帧率，可配置的供电，重新对在FPGA或则和HAPS 的验证case 进行验证。有时还需要对各种额外发现的case 进行验证，这部分在芯片上非常快，不会像在**"芯片验证"**这么拖沓冗长了。
基本功能走通
第一步告成之后，kernel 驱动组会增加投入人力，依次把基本的预览，拍照，录像，raw 拍照等基本功能快速都走通。这样后续的HAL，tuning效果，isp工具等也能参与进来，进行后续的全面展开。
一般这些HAL，tuning效果，isp工具的基本框架在** 集成到安卓**阶段都已经完成，在当前阶段都能快速的完成。
这个过程在内部被称为TR0 的过程。
芯片全部camera功能展开
内核驱动组只对基本功能的流程比较专业，对于各种新增或者修改的效果算法，支持流程等的模块需要其他的团队来一起配合展开实现了。把所有的功能和特征都完成需要涉及到的全部团队抽人来完成，这个阶段是整个camera 软件部门开始繁忙的时候，一般要花费整个camera 部门至少3个多月的时间。
这个过程在内部被称为TR1 的过程。
稳定
最后一步就是整个系统的功能稳定，达到量产交付的标准了，要过相应的各项认证等等。这些问题又要花费整个camera 部门至少有半年多的时间。
这个过程在内部被称为TR2 的过程。
一款芯片，总的这样算下来，至少需要1年8个多月的时间，如果加上中间的流片等待，比如芯片验证和集成到安卓之间的安卓bringup，集成到安卓到回片这段时间的等待， 一般是2年这样的周期，才能走完从预研评估到稳定量产这样的过程。这是一项非常耗人耗时的高技术高成本投入，非常考验研发公司整体的智慧决策和执行能力。