中断丢失问题是我们项目在调试韦根信号输入驱动时出现的。韦根输入驱动是这样的，使用两个GPIO脚分别来接收输入的韦根信号D0和D1，把接收的GPIO脚注册为中断，韦根信号输入是就会触发中断，每触发一次中断就计数一个信号。韦根输入有26bit和34bit两种信号，即产生中断时会在规定时间里连续触发26次或者34次才算是一个合格的韦根信号。但是我们在实际测试中发现，产生中断的脉冲间隔小于3ms时，中断会丢失 ，例如从机发送了26bit的韦根信号，实际产生的中断数少于26次，次数大概率在18-25次，如下图。
于是做出以下多种情况分析：
- 可能是从机发送端的信号问题？
在机器上飞了线，接上逻辑分析仪，接上示波器，结果都显示发送端信号是 正常的，排除该问题。
-
是中断子程序执行过久导致？
修改代码，删除点中断子程序里的任何内容，直接返回return IRQ_HANDLED;
验证结果：查看/proc/interrupts中断数，即时中断子程序里啥也不干，问题依然存在。排除该问题 -
但是看/proc/interrupts节点时，发现中断次数都集中在CPU0上，其他中断也一样大部分在CPU0,SDM450是8核，其他都比较空闲，怀疑是不是负载过高导致？
于是百度查了函数irq_set_affinity()可以将中断绑定在其他CPU上。
结果实际测试时，发现韦根输入还是集中在CPU0上，该函数没有起作用，追了一下代码，流程跑到这里就出错了，原因未知，没有继续追下去。 -
继续追查中意外发现，当我不停点击刷新屏幕的时候，中断就没有出错过？！难道是平时CPU降频了导致的？于是查了一下CPU、GPU等频率，这里记录下相关节点命令：
1)查看CPU工作模式列表
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil
performance性能最好，不降频,cpu核心会一直保持在可用的最高频率，ondemand表示使用内核提供的功能，可以动态调节频率，powersvae表示省电模式，通常是在最低频率下运行，
userspace表示用户模式，在此模式下允许其他用户程序调节CPU频率。
2)设置工作模式
echo “performance” >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
3)查看GPU频率
cat /sys/bus/platform/devices/soc:qcom,gpubw/devfreq/soc:qcom,gpubw/cur_freq
同样将GPU设置到performance
CPU和GPU设置到performance后测试，中断依然存在丢失的情况。 -
最后在百度中发现一条指令disabled低功耗模式
adb shell “echo Y > /sys/module/lpm_levels/parameters/sleep_disabled”
测试，未再发现丢中断的情况。
结果：由于CPU工作在低功耗模式，所以在快速连续中断时可能出现中断丢失的情况，接下来得测试其他性能，看看机器的发热情况，能不能在实际中这么应用。