按键中断解决irq_of_parse_and_map返回0的问题--Apple的学习笔记

因为我要复习下linux驱动。实现一个五脏俱全的小麻雀。
复习目标：
1.驱动框架
2.常用通过设备树获取信息的of函数
3.驱动io模型（用一个常用的poll非阻塞，仅实现read）
4.添加锁，添加中断（暂不加timer软中断的按键滤波，无需下半部的work thread）。
只有read+中断。那么需求互斥锁进行write同步了。只要原子锁即可。

一，驱动加载完，app运行正确

image.png

//设备树
    applekey{
        compatible = "Apple-key";
        interrupt-parent = <&gpio0>;
        interrupts = <7 1>;                    /* gpio0.7  raise triger*/
        pinctrl-names = "default";
        pinctrl-0 = <&apple_key_test>;
        key-gpio = <&gpio0 7 GPIO_ACTIVE_HIGH>;
        default-state = "on";
        status = "okay";
    };


&am33xx_pinmux {
    pinctrl-names = "default";
    pinctrl-0 = <&clkout2_pin>;

    apple_key_test:apple_ked_test {
        pinctrl-single,pins = <
            AM33XX_IOPAD(0x964, PIN_OUTPUT_PULLUP | MUX_MODE7)  /* gpio0_7 */
        >;  
    };

}；

二，驱动卸载第二次加载后，显示加载错误，irq未分配中断号

image.png

解决方法：
步骤1：
先查看/proc/interrups加载和卸载是否正确。结果正确。
步骤2：
通过报错提示关键字在内核源码搜索到irq_of_parse_and_map函数报出的问题。
步骤3：
通过打印内核信息来查看原因

image.png

image.png

步骤4：
进行分析：原因是irq在加载一次后变成了both边沿触发。而我设备树中添加的type=1是上升沿触发。
为什么会变成both呢？
步骤5：
修改驱动bug，request_irq的第三个参数，我传入的是IRQF_TRIGGER_FALLING|IRQF_TRIGGER_RISING。所以both是我驱动中添加的，改成仅上升沿后。测试通过，多次反复加载卸载都正常。

三，思考

irq_of_parse_and_map的原理是当前实际的trigger和设备树的对比，然后分配中断号。我还以为直接从设备树获取呢？所以通过此代码我觉得设备树中我因为配置化为IRQ_TYPE_NONE。
另外一个问题，irq_free后怎么还有残留信息没有reset中断状态。导致再次加载读取当前type=3？暂时没有时间去分析源码。

四，小结

好吧，了解了这样的坑后，下次使用需要注意。设备树的中断方式要和irq请求配置信息一致。