dts/bindings: Add gpio-generic binding

[tsvehagen]

This binding is meant to specify gpios in the device-tree that are not leds
or buttons.

Signed-off-by: Tobias Svehagen [email protected]

[zephyrbot]

All checks are passing now.

Review history of this comment for details about previous failed status.
Note that some checks might have not completed yet.

[galak]

Can you give an example of when or how this would be used. Normally I'd expect GPIOs to be related to some other device.

[raveslave]

Can you give an example of when or how this would be used. Normally I'd expect GPIOs to be related to some other device.

some examples:

• getting defines for named gpio's (usually mirroring the netnames of the schematic)
  • used directly in application code where there isn't a particular driver or peripheral IC involved
• could be a state-machine that looks at a few generic signals like POWER_GOOD + BOOT_DONE from some Co-processor or FPGA

[galak]

• getting defines for named gpio's (usually mirroring the netnames of the schematic)

  • used directly in application code where there isn't a particular driver or peripheral IC involved

This is a bit too vague as an example.

• could be a state-machine that looks at a few generic signals like POWER_GOOD + BOOT_DONE from some Co-processor or FPGA

I would argue that the FPGA or co-processor should have a node in the device tree and the gpio's would live there.

[tsvehagen]

Can you give an example of when or how this would be used. Normally I'd expect GPIOs to be related to some other device.

A lot of peripheral devices have very simple interfaces. For example a motion sensor as an input or a relay control pin as output. I think it makes more sense to have these as generic gpios rather than having a separate binding.

[galak]

A lot of peripheral devices have very simple interfaces. For example a motion sensor as an input or a relay control pin as output. I think it makes more sense to have these as generic gpios rather than having a separate binding.

And how is that motion sensor connected to the SoC? Is this some on SoC peripheral or I2C or SPI device. As in the case of the FPGA, the motion sensor should have a device node in the device tree and that device can have a -gpios property as part of it.

[tsvehagen]

A lot of peripheral devices have very simple interfaces. For example a motion sensor as an input or a relay control pin as output. I think it makes more sense to have these as generic gpios rather than having a separate binding.

And how is that motion sensor connected to the SoC? Is this some on SoC peripheral or I2C or SPI device. As in the case of the FPGA, the motion sensor should have a device node in the device tree and that device can have a -gpios property as part of it.

In the case of a PIR sensor it's usually just connected with a pin to signal motion, no bus involved. I agree with you that these devices could have their own node in the device-tree but then there would be a lot of different names for all of the different devices. It would be kind of a hassle to have all of these upstream. I guess it could be okay if it's possible to have out-of-tree dts bindings. Is this possible?

[galak]

In the case of a PIR sensor it's usually just connected with a pin to signal motion, no bus involved. I agree with you that these devices could have their own node in the device-tree but then there would be a lot of different names for all of the different devices. It would be kind of a hassle to have all of these upstream. I guess it could be okay if it's possible to have out-of-tree dts bindings. Is this possible?

Yes, out of tree bindings is possible, see:

https://docs.zephyrproject.org/latest/application/index.html?highlight=dts_root#devicetree-definitions

[raveslave]

I would argue that the FPGA or co-processor should have a node in the device tree and the gpio's would live there.

Sounds reasonable that this is the right way. Can you please reference to an example?

[mnkp]

The requirement to give names to arbitrary GPIO pins keeps popping up on the email list and Slack. I assume, as a convenient and quick way to play with the evaluation board - which typically offers lots of free GPIO pins readily available - without hard coding pin numbers in the source code. In truth, I never asked.

One example of a more legitimate use case would be to give names to pins that control power domains on the board. If we have a pin that controls power supply of a high voltage or analog part of the board having a way to easily name it is quite convenient. Creating an extra DTS node describing such a 'virtual' component feels like a long way to go. Another example would be to name a GPIO wake-up pin that is not associated with any specific hardware module.

That said, some time ago I searched through the Linux DTS files and documentation to see if they provide a similar 'general' mapping mechanism but couldn't find anything. It seems like they don't.

[pabigot]

One example of a more legitimate use case would be to give names to pins that control power domains on the board. If we have a pin that controls power supply of a high voltage or analog part of the board having a way to easily name it is quite convenient. Creating an extra DTS node describing such a 'virtual' component feels like a long way to go.

If the only thing it powers is a single device, such a pin could be a power-gpios property on that device. But in the general case it should be in a regulator-gpio device node where it can participate in power management of dependent devices.

Another example would be to name a GPIO wake-up pin that is not associated with any specific hardware module.

Linux use would also have that within a standard node.

[henrikbrixandersen]

That said, some time ago I searched through the Linux DTS files and documentation to see if they provide a similar 'general' mapping mechanism but couldn't find anything. It seems like they don't.

@pabigot Actually, Linux does support named GPIOs: See gpio-line-names in https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt.

[galak]

See #25945 as to the provider solution path for this.

[pabigot]

Superseded by #27937. Please open a new RFC if that solution doesn't meet the need.