Question

我无法理解设备树是如何工作的，或者特别是为什么这个驱动程序不能初始化。这是针对android的版本3.10

的rockchip供应商内核

drivers / watchdog / rk29_wdt.c （因可读性而降低）

static const struct of_device_id of_rk29_wdt_match[] = {
    { .compatible = "rockchip,watch dog" }
};
static struct platform_driver rk29_wdt_driver = {
    .probe          = rk29_wdt_probe,
    [..]
            .of_match_table = of_rk29_wdt_match,
            .name   = "rk29-wdt",
    },
};

static int __init watchdog_init(void)
{ 
    printk("watchdog_init\n");
    return platform_driver_register(&rk29_wdt_driver);
}

这是soc dtsi

拱/臂/引导/ DTS / rk3288.dtsi

    watchdog: wdt@2004c000 {
            compatible = "rockchip,watch dog";
            reg = <0xff800000 0x100>;
            clocks = <&pclk_pd_alive>;
            clock-names = "pclk_wdt";
            interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
            rockchip,irq = <0>;
            rockchip,timeout = <2>;
            rockchip,atboot = <1>;
            rockchip,debug = <0>;
            status = "okay";
    };

但是，从不调用驱动程序的.probe函数。编译它并调用__init函数。我怀疑它有什么可以使设备树条目不匹配？也许空间是一个问题？

或者还有其他什么在.probe之前运行，以确定驱动程序是否应该继续？

此外，我不确定扁平树是如何工作的，所以这可能是相关的：

拱/臂/马赫 - 瑞芯/ RK3288

DT_MACHINE_START(RK3288_DT, "Rockchip RK3288 (Flattened Device Tree)")
    .smp            = smp_ops(rockchip_smp_ops),
    .map_io         = rk3288_dt_map_io,
    .init_time      = rk3288_dt_init_timer,
    .dt_compat      = rk3288_dt_compat,
    .init_late      = rk3288_init_late,
    .reserve        = rk3288_reserve,
    .restart        = rk3288_restart,
MACHINE_END

Answer 1

这可能会发生多种可能的方式，而且大多数方法都远离驱动程序代码本身。首先，单独的.dtsi片段并不能说明整个故事 - 设备树语法是分层的，因此属性（特别是status）可能仍然被板级.dts覆盖，其中包括一个基本的SoC .dtsi文件。其次，编译后的DTB也不是最后一个字，因为引导加载程序可以在将其传递给内核之前对其进行动态修改 - 这通常是针对内存节点和SMP启用方法完成的，但可能会影响任何内容。

这种调试通常最好通过检查启动系统的状态来反过来解决，然后向后工作以弄清楚事情是如何形成的 - 这个特定问题的具体细节已经确定了一些，但对于为了完整起见：

如果内核知道驱动程序，并且已加载并正确初始化，它应该显示在/ sys / bus / * / drivers /中的某个地方 - 否则，它可能位于需要加载的模块中，或者它可能有由于某些其他驱动程序或资源的某些未满足的依赖性而无法初始化。
如果内核知道设备，它应该显示在/ sys / bus / * / devices /中的某个位置，如果它正确绑定到驱动程序并进行探测，那么它们应该彼此都有一个符号链接。
如果无法找到设备，那么在基于DT的系统上，下一个要检查的位置是/ proc / device-tree /（取决于旧内核上的CONFIG_PROC_DEVICETREE，并且在/ sys / firmware /中规范地找到） devicetree / base / on newer） - 这将显示内核找到的DT的视图，并且应该在那里进行一些调整，希望能够清除任何丢失的节点或不合适的属性，例如禁用的节点导致内核完全跳过创建设备。请注意，属性文件本身只是原始数据 - 因此您可能希望使用hexdump而不是cat来窥探 - 并且所有数字单元格都采用big-endian字节顺序。

Answer 2

我注意到，在您的定义中，您在数组中错过了所谓的SENTINEL，空的空结构为空。看一个例子：

static const struct of_device_id clk_ids[]  = {
{ .compatible = "sirf,atlas7-clkc" },
{},

};

设备树不匹配：.probe从未调用

2 个答案: