企业官网建设流程全解析

MTK平台的Sensor驱动调试，最让人头疼的往往不是驱动代码本身，而是数据从AP到SCP这条链路上到底谁在管、谁在转、谁在算。很多刚接触MTK平台的兄弟一上来就扎进kernel层的驱动文件里改寄存器，改了半天发现数据压根没从SCP侧传上来，或者SCP传上来的数据格式跟AP侧解析的对不上，白白浪费好几天。这篇内容就把MTK Sensor驱动从AP侧到SCP侧的完整调试流程拆开讲清楚，包括Tinysys的基本概念、驱动分层结构、数据通路、实际调试步骤，以及我在项目中踩过的那些坑。不管你是刚接手MTK平台Sensor bringup的新手，还是想搞清楚SCP侧到底在干什么的老手，这篇都能给你一条清晰的排查路径。

1. 先搞清楚MTK Sensor架构里AP和SCP到底各管什么

1.1 AP侧和SCP侧的分工逻辑

MTK平台从Helio系列开始，Sensor的处理架构就逐渐从AP侧独揽转向AP+SCP协同。AP就是Application Processor，跑Android系统那一套，负责上层应用、HAL层、Sensor Service。SCP是Sensor Control Processor的缩写，它是MTK平台里一个独立的低功耗协处理器，跑的是Tinysys操作系统。Tinysys是MTK自研的一个RTOS，专门用来处理Sensor数据采集、融合运算这类需要低功耗常开的任务。

为什么要这么分？核心原因是功耗。如果所有Sensor数据都让AP来处理，AP就得频繁从休眠中唤醒，续航直接崩掉。把计步、抬腕、方向融合这些任务丢给SCP，AP可以安心睡觉，SCP用极低的功耗维持Sensor数据流的运转。只有当上层App真正需要数据时，AP才被唤醒去SCP拿结果。

所以你在调试时会发现，MTK的Sensor驱动代码实际上分布在两个地方：一个是AP侧的kernel驱动，通常在kernel-4.19/drivers/misc/mediatek/sensors/下面；另一个是SCP侧的代码，在vendor/mediatek/proprietary/tinysys/scp/里面。两边通过共享内存和IPC机制通信。

1.2 Tinysys在Sensor链路中的角色

Tinysys不是一个简单的透传层。它上面跑着SCP侧的Sensor框架，包括Sensor Manager、Driver层、以及各种算法模块。SCP侧的驱动直接操作硬件寄存器去读取原始数据，然后经过初步处理后通过共享内存传给AP侧。AP侧的kernel驱动拿到数据后，再通过HAL层上报给Android的SensorService。

这里有个关键点：SCP侧的代码和AP侧的代码是独立编译的。SCP的固件是一个单独的bin文件，通常在scp.img或者scp_ramdisk.img里面。你改了SCP侧的代码，必须重新编译SCP固件并烧录，光编译kernel是没用的。这一点我在第一次调试MTK Sensor时吃了大亏，改了SCP代码只push了kernel的ko文件，结果死活不生效，后来才发现SCP固件根本没更新。

1.3 数据从硬件到App的完整通路

一颗Sensor从硬件到App的数据通路大致是这样的：Sensor硬件产生原始数据，通过I2C或SPI总线传到SCP侧的驱动，SCP驱动读取后交给SCP Sensor框架，框架根据配置决定是直接在SCP侧处理还是透传给AP。如果需要在SCP侧做融合运算，数据会在SCP内部流转；如果需要上报给AP，数据会被写入AP和SCP之间的共享内存区域，然后通过IPC中断通知AP侧。AP侧kernel驱动收到中断后从共享内存读取数据，再通过input子系统或者sensor class上报到HAL层，最终到达Android SensorService。

理解这条通路非常重要，因为调试时你需要判断问题出在哪一段。是I2C通信本身就不通？还是SCP侧驱动读到了数据但没传上来？还是AP侧收到了但解析错了？每一段的排查方法都不一样。

2. 调试环境搭建与SCP固件编译的关键细节

2.1 代码目录结构与关键文件定位

MTK平台的Sensor相关代码分散在多个目录，先把关键路径列清楚。AP侧kernel驱动一般在：

kernel-4.19/drivers/misc/mediatek/sensors/ ├── hwmon/ │ ├── accelerometer/ │ ├── gyroscope/ │ ├── magnetometer/ │ ├── alsps/ │ └── ... ├── sensorHub/ └── ...

SCP侧代码在：

vendor/mediatek/proprietary/tinysys/scp/ ├── middleware/ │ └── sensor/ │ ├── driver/ │ └── ... ├── project/ │ └── mtXXXX/ └── ...

配置文件通常在vendor/mediatek/proprietary/tinysys/scp/project/下面，每个项目有自己的文件夹，里面定义了哪些Sensor被使能、I2C地址、中断引脚等。

2.2 SCP固件编译与烧录的注意事项

编译SCP固件不像编译kernel那么简单。你需要先确认编译环境里SCP的toolchain是否配置正确。通常MTK的编译脚本会通过make scp或者在整个工程编译时自动带上SCP。但如果你只改了SCP代码，单独编译SCP的命令大概是：

./mk -t scp project_name

编译完成后生成的scp.img需要跟其他镜像一起烧录。这里有个坑：有些项目SCP固件是打包在scp_ramdisk.img里的，有些是独立的scp.img，具体看项目的partition表。烧录时如果只烧了boot.img而没烧SCP相关的img，你的修改就不会生效。

另外，SCP固件烧录后需要重启设备才能加载。有些平台支持通过sysfs节点触发SCP reload，但大多数情况下还是老老实实重启。

2.3 调试工具与日志抓取方式

调试MTK Sensor，最常用的日志来源有几个。AP侧kernel log用dmesg或者adb shell cat /proc/kmsg。SCP侧的日志需要通过特定通道抓取，MTK提供了scp_log相关的节点，通常在/sys/kernel/debug/scp/下面。你可以用：

adb shell cat /sys/kernel/debug/scp/log

或者有些平台是/proc/scp_log。如果SCP日志没开，需要在SCP的配置里使能log输出等级。我一般会把SCP log level调到最高，虽然日志量大，但排查问题时信息最全。

还有一个工具是metalog，MTK的日志系统，可以同时抓AP和SCP的日志并打上时间戳，方便对照分析。用metalog -s启动，日志会存在/data/metalog/下面。

3. AP侧驱动调试的核心操作与常见问题

3.1 设备树与GPIO配置的核对

AP侧驱动调试的第一步不是看驱动代码，而是核对设备树（DTS）配置。MTK平台的Sensor在DTS里的配置包括I2C总线号、设备地址、中断GPIO、供电GPIO等。这些配置如果错了，驱动加载了也读不到数据。

以加速度计为例，DTS里通常有这样的节点：

accelerometer@68 { compatible = "mediatek,accelerometer"; reg = <0x68>; interrupt-parent = <&pio>; interrupts = <12 IRQ_TYPE_EDGE_RISING>; vdd-supply = <&mt_pmic_vio28_ldo_reg>; ... };

你需要确认几个点：I2C地址跟硬件原理图是否一致，中断引脚编号是否正确，供电LDO是否使能。我遇到过好几次中断引脚配错导致数据不更新的情况，因为Sensor的INT引脚没接对，驱动一直在等中断但永远等不到。

3.2 I2C通信是否正常的快速验证

在深入驱动逻辑之前，先确认I2C通信本身是通的。最直接的方法是用i2c-tools：

adb shell i2cdetect -y <bus_number>

如果能看到Sensor的地址出现在列表里，说明I2C物理连接和基本通信没问题。如果看不到，那就要查硬件焊接、上拉电阻、供电是否正常。

进一步可以用i2cget读取Sensor的WHO_AM_I寄存器，确认读到的值跟datasheet一致：

adb shell i2cget -y <bus_number> <device_addr> <register_addr>

这一步能排除很多低级问题。我见过有人调了两天驱动，最后发现是I2C总线上拉电阻没焊。

3.3 数据上报通路的排查方法

如果I2C通信正常但App收不到数据，就要排查数据上报通路。AP侧kernel驱动通常通过input子系统或者sensor_class上报数据。你可以先看/sys/class/sensor/下面的节点是否有数据变化，或者用getevent看input事件：

adb shell getevent -l

如果kernel层有数据但HAL层没有，那问题可能出在HAL的配置或者SCP到AP的数据传递上。这时候需要同时抓AP和SCP的日志对照看。

4. SCP侧调试：数据不通时怎么逐层排查

4.1 SCP侧驱动加载状态的确认

SCP侧的驱动加载日志是排查的第一手资料。在SCP log里搜索驱动名称，看是否有probe成功的打印。如果SCP侧驱动根本没加载，AP侧再怎么调也没用。

SCP侧驱动的probe流程跟AP侧类似，会去读chip id、配置寄存器、注册中断等。如果probe失败，日志里通常会有错误码。常见的失败原因包括I2C地址配错、GPIO配置冲突、供电未使能等。

4.2 共享内存与IPC通信的检查

AP和SCP之间的数据传递依赖共享内存和IPC。如果SCP侧读到了数据但AP侧收不到，就要检查共享内存区域是否正常初始化、IPC中断是否触发。

在AP侧kernel log里搜索scp相关的IPC日志，看是否有中断收到但数据解析失败的打印。SCP侧则看是否有写入共享内存的日志。两边对照，就能定位是发送端没发还是接收端没收。

有个常见问题是共享内存的地址或大小配置不对，导致SCP写入了但AP读的是另一块区域。这种问题通常需要核对scp_reserve_mem相关的DTS配置。

4.3 SCP侧算法模块的配置与影响

很多Sensor数据在SCP侧会经过算法处理，比如计步、方向融合、抬腕检测等。如果算法模块配置不对，可能导致数据被错误处理或者根本不上报。

SCP侧的算法配置通常在vendor/mediatek/proprietary/tinysys/scp/middleware/sensor/下面的配置文件里。你需要确认哪些算法被使能、输入输出格式是什么。我遇到过因为算法模块的输入数据率配置跟驱动不匹配，导致算法一直输出无效值的情况。

5. 几个真实踩坑案例与排查思路复盘

5.1 案例一：SCP固件未更新导致调试无效

这个坑我在前面提过，但值得展开说。当时改了SCP侧的驱动代码，编译了kernel并push了ko文件，重启后发现问题依旧。抓SCP log发现打印的还是旧代码的日志。后来才意识到SCP固件是独立编译和烧录的，只更新kernel没用。重新编译SCP并烧录scp.img后问题解决。

教训：每次改SCP代码，必须确认SCP固件被重新编译并烧录。可以通过SCP log里的版本号或者编译时间戳来确认。

5.2 案例二：I2C地址冲突导致probe失败

有一次调试一颗新的ALSPS Sensor，I2C地址配的是0x48，但probe一直失败。用i2cdetect扫描发现0x48地址上有两个设备响应。查原理图发现另一颗Sensor也用了0x48地址，硬件上冲突了。解决办法是改其中一颗的地址引脚配置，或者换到不同的I2C总线。

这个问题的排查思路是：probe失败先看I2C通信，i2cdetect能快速暴露地址冲突。

5.3 案例三：中断触发方式配错导致数据不更新

还有一次是加速度计数据一直不更新，但手动读寄存器有数据。查DTS发现中断配置的是IRQ_TYPE_EDGE_RISING，但Sensor的INT引脚实际是低电平有效。改成IRQ_TYPE_LEVEL_LOW后数据正常更新。

中断触发方式一定要跟Sensor datasheet里的INT配置一致，上升沿、下降沿、高电平、低电平，四种组合不能配错。

6. 提升调试效率的几个实用技巧

6.1 善用SCP log level动态调整

SCP的log level可以在运行时通过sysfs节点调整，不用重新编译固件。具体节点路径看平台，通常在/sys/kernel/debug/scp/log_level或者类似位置。把level调高可以看到更详细的驱动和框架日志，排查完再调回去减少日志量。

6.2 用metalog做AP和SCP日志的时间对齐

AP和SCP的日志时间戳基准可能不同，直接对照容易看错。metalog会把两边日志统一到一个时间轴上，排查跨AP-SCP的问题时特别有用。启动metalog后复现问题，然后拉出日志文件分析，比分别抓两边日志再手动对齐效率高得多。

6.3 建立自己的调试检查清单

调多了之后我总结了一个检查清单，每次遇到Sensor问题按顺序过一遍：I2C通信是否正常、DTS配置是否跟硬件一致、SCP固件是否最新、SCP驱动probe是否成功、共享内存和IPC是否正常、算法配置是否匹配。按这个顺序排查，大部分问题都能在半小时内定位。

这个清单不是死的，不同项目可能有不同的侧重点，但核心思路是先确认底层通信，再往上查数据通路，最后看算法和应用层。从下往上排查，比一上来就改上层代码有效得多。

调试MTK Sensor驱动，说到底就是对整条数据链路的理解程度。你知道数据从哪来、经过谁、到哪去，排查时就能有的放矢。AP和SCP的分工是MTK平台的设计特点，理解了这个架构，调试就不再是碰运气。希望这些经验能帮你在下一个项目中少走弯路。