蜗窝科技

致驱动工程师的一封信

作者：smcdef 发布于：2018-4-14 21:00 分类：统一设备模型

注：部分代码分析举例基于linux-4.15。

device {
    rst-gpio = <&gpioc_ctl 10 OF_GPIO_ACTIVE_LOW>;
    irq-gpio = <&gpioc_ctl 11 0>;
    interrupts-extended = <&vic 11 IRQF_TRIGGER_RISING>;
};

int device_probe(struct platform_device *pdev)
{
    rst_gpio = of_get_named_gpio_flags(np, "rst-gpio", 0, &flags);
    if (flags & OF_GPIO_ACTIVE_LOW) {
        struct gpio_desc *desc;

        desc = gpio_to_desc(rst_gpio);
        set_bit(FLAG_ACTIVE_LOW, &desc->flags);
    }

    irq = of_irq_get(np, 0);
    trigger_type = irq_get_trigger_type(irq);
    request_threaded_irq(irq, NULL, irq_handler, trigger_type, "irq", NULL);
}

驱动按照以上代码实现的话，如果修改中断触发类型或者电平有效状态只需要修改dts即可。例如不同的IC复位电平是不一样的，有的IC是高电平复位，有的IC却是低电平复位。其实这就是一个电平有效状态的例子。

static inline int gpio_export(unsigned gpio, bool direction_may_change);
static inline int gpio_export_link(struct device *dev, const char *name,
           unsigned gpio);

cat /proc/interrupts

输出信息不想多余的介绍。看代码去。根据输出的irq num，假设是irq_num。请进入以下目录。看看下面都有什么文件。摸索这些文件可以为你调试带来哪些方便。

cd /proc/irq/irq_num

dts和sysfs有什么关联 

曾经写过一篇dts解析的文章http://www.wowotech.net/device_model/dt-code-file-struct-parse.html。最后一节其实说了一个很有意思的东西。但是仅仅是寥寥结尾。并没有展开。因为他不关乎我写的文章的的主题。但是，他却和调试息息相关。

cd /sys/firmware/devicetree/base

该目录的信息就是整个dts。将整个dts的节点以及属性全部展现在sysfs中。他对我们的调试有什么用呢？Let me tell you。如果你的项目非常的复杂，例如一套代码兼容多种硬件配置。这些硬件配置的差异信息主要是依靠dts进行区分。当编译kernel的时候，你发现你很难确定就是你用的是哪个dts。可能你就会凭借自己多年的工作经验去猜测。是的，你的经验很厉害。但是，如何确定你的dts信息是否添加到kernel使用的dts呢？我觉得你应该got it。就到这个目录去查找是否包含你添加的ndoe和property。dts中有status属性可以设置某个devicec是否使能。当你发现你的driver的probe没有执行的时候，我觉得你就需要确定一遍status是不是“ok”、“okay”或者没有这个属性。

远不止我所说的这个功能，还可以判断当前的硬件是匹配哪个dts文件。你还不去探索一波源码的设计与实现吗？节点为什么出现在某些目录？为什么有些节点的属性cat却是乱码？就是乱码，你没看错。至于为什么。点到为止。

1. 通过sysfs确定对应的device是否注册成功。
2. 通过sysfs确定对应的driver是否注册成功。
3. 通过sysfs中dts的展开信息得到compatible属性的值，然后和driver的compatible进行对比。

评论：