两个节点之间的设备树依赖性 [英] Device Tree dependency between two nodes

问题描述

我有两个设备树节点，一个设置一个gpio引脚，另一个配置一个i2c总线，例如:

I have two device tree nodes, one sets a gpio pin and the other one configures one i2c bus, ex:

&gpio2 {
  en-gpio {
    gpio-hog;
    gpios = <5 0>;
    output-high;
  };
};

&i2c1 {
  gpiom1: gpio@27 {
    compatible = "microchip,mcp23008";
    gpio-controller;
    #gpio-cells = <2>;
    reg = <0x27>;
  };
};

如何在i2c节点和gpio one之间添加依赖项?我要实现的是，应该在初始化i2c上的设备之前设置gpio引脚.

How can i add a dependency between the i2c node and gpio one? What i want to achieve is that the gpio pin should be set before the devices on i2c are initialized.

推荐答案

简短答案

在这种情况下，您不能提供节点之间的依赖关系.但是最有可能的是，您的情况已经按照正确的顺序进行了处理，并且由于在GPIO控制器驱动程序中使用了更早的initcall，并且因为使用了 gpio-hog ，所以在I2C设备初始化之前会设置GPIO引脚.如果您想确定平台是否正确，请在下面查看详细信息.

Short answer

You can't provide dependency between nodes in this case. But most likely the correct order is already taken care of in your case, and GPIO pin will be set before I2C device initialization, thanks to earlier initcall used for GPIO controller driver, and because gpio-hog is used. If you want to check it for your platform to be sure -- below are details.

如设备树II:较难的部分 LWN文章所述:

自然，在每种情况下，提供中断或GPIO的设备都需要初始化，然后才能找到并使用它们.并不是很多内核版本之前，这是一个真正的问题.但是在3.4内核中，驱动程序获得了初始化(或 probe )例程以返回错误 EPROBE_DEFER 的能力，这将导致稍后再次尝试初始化.因此，如果驱动程序发现设备树中列出了GPIO线路，但尚未有驱动程序为目标节点注册GPIO，则它可能会失败，并显示 EPROBE_DEFER ，并且可以稍后重试.这甚至可以用来消除对回调文件的需要和在电路板文件中的延迟注册，但这对于devicetree确实是必不可少的，而且很高兴它可以很好地工作.

Naturally, in each case the device which provides the interrupt or GPIO will need to be initialized before it can be found and used. It wasn't very many kernel versions ago that this was a real problem. However in the 3.4 kernel, drivers gained the ability for their initialization (or probe) routine to return the error EPROBE_DEFER which would cause the initialization to be tried again later. So if a driver finds that a GPIO line is listed in the devicetree, but no driver has registered GPIOs for the target node yet, it can fail with EPROBE_DEFER and know it can try again later. This can even be used to remove the need for callbacks and delayed registration in board files, but it is really essential for devicetree, and happily it works quite well.

A，在您的情况下，可能无法指定节点之间的依赖关系，因此您的 i2c1 或 gpiom1 依赖于 gpio2 .至少在 Documentation/devicetree/bindings/中看不到I2C控制器或GPIO控制器的任何 gpios 属性，这些属性可用于引用您的 en-gpio .因此，看来您应该依赖驱动程序的加载顺序.

Alas, in your case it's probably not possible to specify dependency between nodes, so that your i2c1 or gpiom1 depends on gpio2. At least I don't see any gpios properties for I2C controllers or GPIO controllers in Documentation/devicetree/bindings/, that can be used for referencing your en-gpio. So it seems like you should rely on drivers loading order.

驱动程序之间可能存在两种依赖关系:

There are two possible dependencies between drivers:

1. 如果驱动程序是内置的(位于内核映像内部):可以在不同的

1. If drivers are built-in (inside of kernel image): drivers can be initialized at different initcalls, thus being loaded in correct order
2. If drivers are loadable (.ko files): drivers can have dependencies, defined in kernel build system

因为您没有提到平台，所以让我们看看使用BeagleBone Black板如何工作.您可以将其用作模板，以了解如何在您的平台上完成.

As you didn't mention your platform, let's see how it works using BeagleBone Black board for example. You can use this as a template to find out how it's done on your platform.

让我们检查驱动程序的初始化顺序:

Let's check drivers init order:

1. 从 am33xx-l4.dtsi 文件中，我们可以看到:
   • GPIO控制器: compatible ="ti，omap4-gpio"
   • I2C控制器: compatible ="ti，omap4-i2c"
   • I2C设备: compatible ="microchip，mcp23008"

1. From am33xx-l4.dtsi file we can see that:
   • GPIO controller: compatible = "ti,omap4-gpio"
   • I2C controller: compatible = "ti,omap4-i2c"
   • I2C device: compatible = "microchip,mcp23008"

• GPIO控制器: drivers/gpio/gpio-omap.c
• I2C控制器: drivers/i2c/busses/i2c-omap.c
• I2C设备: drivers/pinctrl/pinctrl-mcp23s08.c

• GPIO控制器: postcore_initcall (= 2)
• I2C控制器: subsys_initcall (= 4)
• I2C设备: subsys_initcall (= 4)

• GPIO controller: postcore_initcall (=2)
• I2C controller: subsys_initcall (=4)
• I2C device: subsys_initcall (=4)

因此GPIO控制器驱动程序将在I2C驱动程序之前初始化.

So GPIO controller driver will be initialized before I2C drivers.

动态依赖关系如何?从相应的 Makefile 和 Kconfig 文件中，我们可以看到配置选项和依赖项:

What about dynamic dependencies? From corresponding Makefile and Kconfig files we can see config options and dependencies:

• GPIO控制器: CONFIG_GPIO_OMAP ，三态，不依赖于I2C内容
• I2C控制器: CONFIG_I2C_OMA ，三态，不依赖GPIO东西
• I2C设备: CONFIG_PINCTRL_MCP23S08 ，三态，取决于I2C

• GPIO controller: CONFIG_GPIO_OMAP, tristate, doesn't depend on I2C stuff
• I2C controller: CONFIG_I2C_OMA, tristate, doesn't depend on GPIO stuff
• I2C device: CONFIG_PINCTRL_MCP23S08, tristate, depends on I2C

因此，如果驱动程序以 .ko 文件的形式加载到用户空间中，则这完全取决于它们的加载顺序，用户必须在rootfs中进行处理.通常GPIO和I2C控制器驱动程序是内置的，因此无需进一步讨论，只需FYI，

So if drivers are loaded in user-space as .ko files, it all depends on the order of their loading, user must take care of it in rootfs. Usually GPIO and I2C controller drivers are built-in, so no need to discuss this further, but just FYI, here is how the order is defined for modprobe tool.

要检查驱动程序的构建方式(内置或可加载)，可以检查 .config 文件.例如.如果使用 multi_v7_defconfig :

To check how drivers are built (built-in or loadable), one can check .config file. E.g. if multi_v7_defconfig is used:

• CONFIG_GPIO_OMAP = y
• CONFIG_I2C_OMAP = y

在那种情况下，两个驱动程序都是内置的，并且我们知道GPIO驱动程序的initcall早于I2C一个.

In that case both drivers are built-in, and we know that GPIO driver has earlier initcall than I2C one.

通过将您的密码声明为 gpio-hog ，您做了正确的事情.您可能已经知道这意味着什么，但是我将在这里为其他感兴趣的人提供解释.来自 Documentation/devicetree/bindings/gpio/gpio.txt :

You did the right thing by declaring your pin as gpio-hog. You probably already know what it means, but I'll reference the explanation here for everyone else who is interested. From Documentation/devicetree/bindings/gpio/gpio.txt:

GPIO芯片可能包含GPIO猪定义.GPIO占用是一种机制提供自动GPIO请求和配置，作为gpio-controller的驱动程序探测功能.

所以这是尽早得到的.而且，如果您的GPIO控制器驱动程序是内置的，并且I2C驱动程序的initcall号小于1，则可以说您的 en-gpio 引脚将在I2C设备驱动程序初始化之前设置.

So this is as early as you can get. And if your GPIO controller driver is built-in and has initcall number smaller than one for I2C drivers, you can argue that your en-gpio pin will be set before I2C device driver init.

这篇关于两个节点之间的设备树依赖性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！