小概率按键失灵分析结论

**结论：**按键失灵是因为在按键松开时有抖动产生了杂波而出现异常中断。

**分析：**从 GF3_L125_PP1_KeyLife_test_issue_1.zip 压缩包中的 kernel.log.8 中，可以看到：问题出现的时间点为：[21707.129545 / 09-20 16:57:27.430]，之后的log ，就再无aw9523_key_work的log打印。表明出现异常，按键不再正常工作了。结合驱动代码，从流程上看是进入了第二个if语句，直接return掉了。
static void aw9523_key_work(struct work_struct *work)
{ …
if(!(memcmp(&keyst_new[0], &keyst_def[KEYST_NEW][0], P1_NUM_MAX))) {
// all key release
…
enable_irq(client->irq); //enable bb irq
return;
}
时序图分析如下：

1． 在检测到所有的按键释放后， 会先清除aw9523b的中断（图中绿色线），让INIT回到高电平，之后先使能aw9523b的中断（图中红色标线），再使能cpu的中断（蓝色标线）
2． 因为指令执行很快，一般情况下，在红色粗线的这段时间内是没有电平变化的。cpu中断使能之后，又为下一次按键做好了准备，INIT引脚为高。
3． 但由于按键抖动，在低概率下可能会在红色粗线的时间段内有杂波出现，而此时aw9523的中断已经使能，且触发方式是双边沿触发，有可能触发aw9523b的中断，导致INIT引脚被拉低，之后再使能cpu中断。此时程序认为所有按键已经释放，而INIT引脚却异常为低，所以之后不能再产生中断。

方案：
1． 修改触发方式为低电平触发
2． 优化释放所有按键时的中断使能时序，
a) 清aw9523b的中断，让INIT回到高电平
b) 先使能cpu的中断，让cpu端先做好准备
c) 最后使能aw9523b的中断，以接收下一次的按键触发
3． 在i2c读写的接口中做错误重读机制，防止因为i2c读写出错导致的问题。修改后的时序图如下：