1. 高通PDAF调试的核心逻辑与迁移背景做过高通Camera驱动的人都知道PDAFPhase Detection Auto Focus相位检测自动对焦的调试是整个Camera Bring-up里最磨人的环节之一。它不像普通的对比度对焦那样“跑起来就行”PDAF涉及Sensor端的相位像素排布、平台端的Type配置、以及后期效果调试中的参数标定任何一个环节对不上轻则对焦慢半拍重则直接对焦拉风箱甚至完全失焦。我最近在做一个从老平台往新平台迁移的项目正好踩了一遍PDAF从Type2往Type3迁移的坑。这里说的Type2和Type3是高通Camera框架里对PDAF数据处理方式的两种不同架构定义。简单来说Type2是早期平台比如SDM660、SDM845那一代常用的方案Sensor输出的PD数据经过一定的预处理后送到AF算法端而Type3是高通在新一代平台比如SM8350、SM8450以及最新的SM8550 kalama平台上主推的方案PD数据的处理链路、数据格式、以及和AF算法的对接方式都发生了变化。为什么会有这个迁移核心原因有两个。一是新平台的ISP架构升级了PD数据的吞吐路径和缓存机制跟老平台不一样继续沿用Type2的配置会出现数据对不齐、帧同步异常等问题。二是高通的AF算法本身也在迭代Type3方案下算法对PD数据的置信度评估、稀疏PD点的处理、以及和反差对焦的融合策略都做了优化如果Sensor端支持Type3但你还在用Type2配等于白白浪费了硬件能力。这个内容适合谁看如果你正在做高通平台的Camera Bring-up尤其是从老平台迁移到新平台时遇到PDAF相关的问题或者你刚接手一个PDAF调试任务但不确定该用Type2还是Type3那这篇内容应该能帮你少走不少弯路。我会从配置差异、代码修改、参数标定、问题排查几个维度把整个迁移过程拆开来讲。1.1 Type2与Type3的本质区别先把这个事情说清楚不然后面的配置你都不知道为什么要那么改。Type2方案下PD数据通常是以“PD Buffer”的形式由Sensor输出经过CSIDCamera Serial Interface Decoder后由CamSSCamera Subsystem直接写入DDR的特定区域然后AF算法从这块内存里读取PD数据做相位差计算。这个链路比较直接但问题在于PD数据的格式和排列方式高度依赖Sensor厂商的实现不同Sensor之间的差异很大平台端需要做很多适配工作。Type3方案则不同。高通在Type3里引入了一个更规范的PD数据抽象层PD数据不再直接以原始Buffer形式暴露给算法而是经过一层“PD数据重组”的处理把不同Sensor的PD排布统一成算法能识别的格式。这样做的好处是算法端不需要关心具体Sensor的PD排布细节坏处是平台端的配置项变多了而且这些配置项之间的依赖关系比较绕配错一个就可能导致PD数据解析失败。用个生活化的类比Type2就像你直接拿原材料给厨师厨师得自己根据食材种类决定怎么切怎么炒Type3则是先把原材料预处理成半成品厨师拿到手就能直接下锅。前者灵活但适配成本高后者规范但前期配置复杂。1.2 迁移前必须确认的硬件与平台信息在动手改配置之前有几件事必须先确认清楚否则后面全是无用功。第一确认Sensor是否支持Type3。不是所有Sensor都支持Type3输出格式有些老Sensor只支持Type2的PD Buffer模式。你需要查Sensor的Datasheet或者找FAE确认看它是否支持“Type3 PD data output”或者类似的描述。如果Sensor本身不支持那你再怎么改平台配置也没用。第二确认平台端的CamSS版本和ISP固件是否支持Type3。高通不同平台的CamSS IP版本不同Type3的支持程度也不一样。比如SM8550kalama平台上Type3是默认推荐的方案但如果你用的是更早的SM7250可能Type3的支持还不完善。这个信息可以从高通发布的Camera相关Release Note或者Platform Spec里查到。第三确认AF算法端的版本。Type3对AF算法的版本有最低要求如果算法版本太老可能根本不认识Type3的PD数据格式。这个通常需要跟高通的技术支持确认或者查算法Release Note里的兼容性说明。注意这三项确认工作看起来简单但我见过太多人跳过这一步直接改代码结果调了两周发现Sensor根本不支持Type3白白浪费时间。先确认再动手这是铁律。2. 配置迁移的核心步骤与代码修改要点确认完硬件和平台支持后就可以开始动手迁移了。整个迁移过程可以分成三个层面设备树Device Tree配置、CamSS驱动配置、以及AF算法端的参数调整。下面我逐个拆开讲。2.1 设备树中PD相关节点的修改设备树是起点。在高通平台里Camera Sensor的PD配置通常写在Sensor的Device Tree节点里具体位置在cam_sensor或者cam_pdaf相关的子节点下。Type2方案下你可能会看到类似这样的配置qcom,pdaf-type 2; qcom,pdaf-support 1; qcom,pdaf-buffer-size 0x1000;迁移到Type3后这些字段需要改成qcom,pdaf-type 3; qcom,pdaf-support 1; qcom,pdaf-data-format 0x01; // 具体值取决于Sensor输出格式 qcom,pdaf-block-size 0x800; qcom,pdaf-block-count 2;这里有几个关键变化。首先pdaf-type从2改成3这个最直观。其次Type3不再使用pdaf-buffer-size这个字段而是用pdaf-block-size和pdaf-block-count来描述PD数据的块大小和块数量。这是因为Type3下PD数据是按块组织的每块对应一定数量的PD点算法端按块读取。pdaf-data-format这个字段是Type3新增的用来告诉平台端PD数据的排列格式。不同的Sensor这个值可能不同常见的有0x01左右PD点交替排列、0x02上下PD点交替排列、0x03稀疏PD点矩阵排列等。这个值必须跟Sensor的实际输出格式一致否则算法端解析出来的相位差是错的。实操心得pdaf-data-format这个值我建议直接找Sensor厂商的FAE要不要自己猜。我试过根据Datasheet里的描述自己推算结果推错了导致PD数据解析出来全是噪声。后来找FAE确认发现Datasheet里描述的排列方式跟实际输出差了一个字节序的问题。2.2 CamSS驱动中的PD数据路径配置设备树改完后CamSS驱动里也需要做相应调整。Type2和Type3在CamSS里的PD数据路径配置差异主要体现在两个方面CSID的PD数据输出配置和PD数据写入DDR的方式。在Type2下CSID通常配置为将PD数据作为单独的VCVirtual Channel输出然后由CamSS的PD模块直接写入DDR。而在Type3下PD数据可能跟图像数据混合在同一个VC里输出需要CamSS做分离处理。这个配置通常在cam_csid_hw或者cam_camss相关的驱动文件里。具体来说你需要检查cam_csid_hw.c里的cam_csid_config_pdaf函数不同平台函数名可能略有差异看它是否支持Type3的配置。如果平台代码里没有Type3的分支可能需要手动添加。这个工作量取决于平台代码的完善程度新平台一般都已经支持了老平台可能需要自己补。另外Type3下PD数据写入DDR的地址对齐要求跟Type2不同。Type2通常要求4字节对齐Type3可能要求8字节或16字节对齐。这个对齐要求会影响你在DDR里分配PD Buffer时的地址选择如果不对齐可能导致数据写入异常或者性能下降。// Type3下PD Buffer地址对齐示例 #define PDAF_TYPE3_ALIGNMENT 16 pdaf_buffer_addr ALIGN(pdaf_buffer_addr, PDAF_TYPE3_ALIGNMENT);2.3 AF算法端的参数适配平台端配置改完后AF算法端也需要做适配。Type3下AF算法对PD数据的处理方式有变化主要体现在PD置信度评估和PD点权重计算上。在Type2下算法通常直接使用所有PD点的相位差做平均或者加权平均。而在Type3下算法会先对PD点做置信度评估低置信度的PD点会被剔除或者降权。这个置信度评估的参数需要在AF算法的配置文件里设置通常是一个阈值或者一组阈值。这个配置一般在af_pdaf_params或者类似的配置文件里具体字段名可能因算法版本而异。你需要查算法Release Note或者找高通技术支持确认。我这边用的算法版本里相关字段是pdaf_confidence_threshold和pdaf_weight_table前者是置信度阈值后者是不同置信度区间的权重表。注意置信度阈值设得太高会导致可用PD点太少对焦变慢设得太低会导致噪声PD点被引入对焦不准。这个值需要根据实际场景调没有万能值。我一般会先在室内正常光照下调到一个基本可用的值然后再根据暗光和强光场景微调。3. 实操过程与关键环节实现前面讲了配置层面的东西这一章我拿一个实际项目案例把整个迁移过程从头到尾走一遍。项目背景是高通SM8450平台Sensor是某款支持Type3的50MP主摄从Type2迁移到Type3。3.1 迁移前的基线测试与数据采集动手改之前我先在Type2配置下做了一轮基线测试目的是记录当前的对焦性能数据方便迁移后对比。测试项目包括正常光照下的对焦时间、暗光下的对焦时间、对焦成功率、以及PD数据的基本统计信息比如有效PD点数量、PD相位差的分布范围。这些数据通过高通提供的Camera调试工具采集具体工具名这里不展开做过的都知道。采集PD数据统计信息的时候我特别关注了PD相位差的分布。Type2下如果Sensor的PD排布跟平台配置匹配得好相位差应该集中在一个合理的范围内比如-100到100之间。如果分布很散或者有明显偏移说明PD配置有问题这种情况下迁移到Type3也不会变好得先把Type2下的问题解决掉。基线测试完成后我把所有数据整理成表格作为迁移后的对比基准。测试项Type2基线值目标值正常光照对焦时间320ms250ms暗光对焦时间850ms600ms对焦成功率92%95%有效PD点数量12001500PD相位差范围-150~180-100~1003.2 设备树与驱动修改的实际操作基线测试完成后开始改配置。第一步是改设备树把pdaf-type从2改成3同时添加Type3需要的pdaf-data-format、pdaf-block-size、pdaf-block-count字段。这里有个细节需要注意pdaf-block-size和pdaf-block-count的乘积应该等于总的PD数据大小。这个总大小可以从Sensor Datasheet里查到或者通过Type2下的pdaf-buffer-size推算。我这边Type2下的pdaf-buffer-size是0x10004096字节迁移到Type3后我设置pdaf-block-size为0x8002048字节pdaf-block-count为2乘积正好是4096字节。改完设备树后编译内核并烧录。第一次启动后通过dmesg查看CamSS的初始化日志确认PD配置是否被正确解析。如果看到类似pdaf type 3 configured的日志说明设备树配置生效了。如果看到pdaf type mismatch或者pdaf config failed说明配置有问题需要检查字段名和值是否正确。设备树生效后接着改CamSS驱动。我这边平台代码里已经有Type3的支持只需要在cam_csid_config_pdaf函数里把Type3的分支打开即可。如果你的平台代码里没有Type3分支需要参考高通提供的参考代码手动添加主要工作是配置CSID的PD数据输出格式和DDR写入地址。3.3 AF算法参数调整与效果验证驱动改完后开始调AF算法参数。第一步是设置PD置信度阈值。我初始设置的是0.6然后通过调试工具观察PD点的置信度分布。发现大部分PD点的置信度在0.7以上少数在0.5以下。把阈值设到0.6后有效PD点数量从1200增加到了1600左右符合预期。接着调PD权重表。Type3下算法会根据PD点的置信度分配权重高置信度点权重大低置信度点权重小。我初始用的是算法默认的权重表观察对焦效果后发现暗光下对焦还是偏慢。后来把低置信度区间的权重稍微调高了一点暗光对焦时间从850ms降到了650ms左右。参数调完后做了一轮完整的效果验证对比迁移前后的数据测试项Type2基线值Type3迁移后变化正常光照对焦时间320ms230ms-28%暗光对焦时间850ms620ms-27%对焦成功率92%96%4%有效PD点数量1200160033%PD相位差范围-150~180-95~105明显收窄从数据上看迁移到Type3后对焦性能有比较明显的提升尤其是有效PD点数量增加了33%说明Type3的PD数据重组确实让更多PD点被算法有效利用了。实操心得迁移后第一次测试如果发现对焦反而变差了不要慌大概率是PD数据格式配置不对。我遇到过pdaf-data-format设错导致PD相位差完全乱掉的情况表现是对焦直接拉风箱。这时候用调试工具抓一帧PD数据看相位差的分布如果分布完全无规律基本可以确定是格式配错了。4. 常见问题与排查技巧实录迁移过程中我踩了不少坑这里整理成常见问题速查表方便你遇到类似问题时快速定位。4.1 PD数据解析失败与对焦异常排查PD数据解析失败是最常见的问题表现是对焦完全不能用或者对焦极其缓慢。排查思路如下首先确认设备树配置是否正确。检查pdaf-type是否设为3pdaf-data-format是否跟Sensor实际输出一致pdaf-block-size和pdaf-block-count的乘积是否等于总PD数据大小。这几个字段任何一个不对都会导致PD数据解析失败。其次确认CamSS驱动是否支持Type3。如果平台代码里没有Type3分支或者分支代码有bug也会导致PD数据无法正确写入DDR。可以通过查看CamSS的中断统计和DDR写入日志来确认。最后确认AF算法版本是否支持Type3。如果算法版本太老可能根本不认识Type3的PD数据格式这种情况下需要升级算法版本。问题现象可能原因排查方法对焦完全不能用pdaf-type未设为3检查设备树对焦拉风箱pdaf-data-format错误抓PD数据看相位差分布对焦缓慢PD置信度阈值过高降低阈值观察有效PD点数量暗光对焦差PD权重表不合理调整低置信度区间权重PD数据全零CamSS驱动不支持Type3检查驱动代码和日志4.2 帧同步与PD数据对齐问题Type3下PD数据是按块组织的如果块与块之间的对齐有问题会导致PD数据错位表现是对焦时好时坏或者对焦方向偶尔反掉。这个问题的根源通常是DDR地址对齐不对。Type3要求PD Buffer的起始地址按16字节对齐如果不对齐可能导致PD数据写入时跨块错位。解决方法是在分配PD Buffer时强制对齐pdaf_buffer_addr (pdaf_buffer_addr 15) ~15;另外如果Sensor输出的PD数据速率跟CamSS的读取速率不匹配也可能导致帧同步问题。这个通常需要调整CSID的时钟配置或者PD数据的FIFO深度具体值需要根据Sensor的时序参数计算。4.3 迁移后效果反差的调试思路如果迁移到Type3后对焦效果反而变差了不要急着回退先按以下思路排查第一步确认PD数据本身是否正确。用调试工具抓一帧PD数据看相位差的分布是否合理。如果分布完全无规律说明PD数据解析有问题回到4.1排查。第二步确认AF算法参数是否适配。Type3下算法对PD数据的处理方式跟Type2不同直接沿用Type2的参数可能不合适。建议先用算法默认参数跑一遍看效果如何然后再逐步调整。第三步确认是否跟其他模块有冲突。比如AEC自动曝光的收敛速度如果太慢会影响PDAF的输入图像质量导致PD数据置信度下降。这种情况下需要先调好AEC再调PDAF。注意PDAF调试不是孤立的它跟AEC、AWB、以及ISP的其他模块都有耦合。我见过有人调PDAF调了两周没进展最后发现是AEC的收敛策略有问题导致PDAF拿到的图像一直处于过曝或欠曝状态。所以调PDAF之前先确认其他基础模块是稳定的。4.4 平台差异与兼容性处理不同高通平台的Type3实现可能有细微差异比如SM8450和SM8550在PD数据路径的配置上就不完全一样。SM8550上PD数据的DDR写入是由专门的PD DMA通道完成的而SM8450上可能还是通过CamSS的通用DMA。这个差异会影响驱动配置和性能表现。处理平台差异的通用思路是先查平台Release Note里关于PDAF的说明看有没有特殊配置要求然后参考同平台其他项目的PDAF配置看是否有可复用的部分最后如果还不确定找高通技术支持确认。另外如果你是从更老的平台比如SDM660迁移到新平台可能还需要考虑PD数据格式的兼容性问题。老平台的PD数据格式可能跟新平台的Type3不兼容这种情况下可能需要在Sensor端做格式转换或者在新平台上做兼容处理。这个工作量比较大建议提前评估。5. 迁移后的性能优化与长期维护建议迁移完成并验证通过后还有一些优化工作可以做让PDAF的性能更稳定。5.1 PD数据置信度调优与场景适配Type3下PD置信度的评估是动态的不同场景下置信度分布不同。我建议针对几个典型场景分别调优室内正常光照、室外强光、暗光、以及逆光场景。每个场景下观察PD置信度分布然后调整置信度阈值和权重表让算法在不同场景下都能拿到足够多的高质量PD点。这个调优过程比较耗时但效果提升明显。我这边针对四个场景分别调完后暗光对焦时间从620ms进一步降到了550ms左右逆光场景的对焦成功率从88%提升到了94%。5.2 长期维护中的版本管理与回归测试PDAF配置涉及设备树、驱动、算法三个层面任何一个层面升级都可能导致PDAF行为变化。建议在项目维护中做好版本管理每次升级后都跑一遍PDAF回归测试确保对焦性能没有退化。回归测试的项目不用太多但关键指标要覆盖正常光照对焦时间、暗光对焦时间、对焦成功率、以及PD数据的基本统计信息。这些数据记录下来形成趋势图一旦发现异常可以快速定位是哪个版本引入的。另外如果项目后续要支持新的Sensor建议先确认新Sensor的PD输出格式是否跟当前Type3配置兼容。如果不兼容可能需要调整pdaf-data-format或者其他配置字段。这个确认工作最好在项目早期做避免后期返工。我个人在实际操作中的体会是PDAF迁移这件事难点不在改配置本身而在于理解Type2和Type3的本质区别以及迁移过程中各个配置项之间的依赖关系。把这两点搞清楚了剩下的就是按部就班地改、测、调。踩过的坑主要集中在PD数据格式配置和AF算法参数适配上这两个地方多花点时间确认能省掉后面大量的调试时间。
