因为我要复习下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请求配置信息一致。
