dts: bindings: Add Pmod connector GPIO nexus

[abxy]

Add a GPIO nexus binding for Pmod interface connectors. This commit also includes a header file with macros that map signal names in the Pmod specification to the corresponding indices in the GPIO nexus, meant for use in devicetree files.

There are multiple boards in the tree sporting Pmod connectors where this binding could be useful. With the right GPIO mapping nodes and pinctrl nodes added to the board definitions it becomes easy to set up the devicetree for Pmod peripherals. At Elektronikutvecklingsbyrån we already use this with some in-house boards for prototyping.

Example:

&spi3 {
    status = "okay";

    cs-gpios = <&pmod2 PMOD_SPI_CS GPIO_ACTIVE_LOW>;
    pinctrl-0 = <&spi3_pmod2_default>;
    pinctrl-1 = <&spi3_pmod2_sleep>;
    pinctrl-names = "default", "sleep";

    sensor@0 { /* ... */ };
};

[tautologyclub]

To provide additional arguments for why this will be useful, the following boards all have PMOD connectors:

imxrt685_evk
lpcxpresso55s28
dragino_nbsn95
lpcxpresso55s16
lpcxpresso55s16
lpcxpresso51u68
lpcxpresso55s69
cy8ckit_062_wifi_bt
lpcxpresso55s36
lpcxpresso55s36
lpcxpresso54114
cy8ckit_062_ble
dragino_lsn50
stm32l496g_disco
stm32l562e_dk
stm32h735g_disco
lpcxpresso55s06
lpcxpresso55s06
mimxrt595_evk
b_l4s5i_iot01a

[henrikbrixandersen]

Thanks, looks good. One suggestion:

[henrikbrixandersen]

I would suggest naming it digilent,pmod. Although the nexus purely deals with GPIOs, the connector itself is a Digilent Pmod connector, not a Digilent Pmod GPIO connector.

[abxy]

Thanks for the suggestion. What do you think of also renaming the header file to match? In that case the full include path would be zephyr/dt-bindings/gpio/digilent-pmod.h

[henrikbrixandersen]

Please add a Pmod connector to at least one of the in-tree boards to document usage and ensure it is tested in-tree.

[abxy]

I made the requested change of name and added SCL/SDA/MOSI/MISO/SCK signal defines that I had initially omitted since they would normally not be used with GPIO nexus, but I figure they can be used in a pinch with a bit-banged bus driver.

I also added Pmod connectors to two boards but unfortunately I don't have either of them on hand to verify the pinout, so if that's a requirement I will have to order some or ask assistance of someone.

[henrikbrixandersen]

I made the requested change of name and added SCL/SDA/MOSI/MISO/SCK signal defines that I had initially omitted since they would normally not be used with GPIO nexus, but I figure they can be used in a pinch with a bit-banged bus driver.

I also added Pmod connectors to two boards but unfortunately I don't have either of them on hand to verify the pinout, so if that's a requirement I will have to order some or ask assistance of someone.

I don't get it. If you do not have any in-tree board with a Pmod connector, how come you are adding a binding for it upstream?

[abxy]

[abxy]

@henrikbrixandersen Thanks for approving. This dropped off my radar, sorry for not replying sooner.

I don't get it. If you do not have any in-tree board with a Pmod connector, how come you are adding a binding for it upstream?

We have out-of-tree boards using it and we think it's pretty great for rapidly prototyping new hardware designs, and we enjoy sharing the tools we build and use. It's a topic we've been thinking about writing a blog post about, so we're in the works of releasing an open-hardware board that really goes all in on Pmod.

[henrikbrixandersen]

We have out-of-tree boards using it and we think it's pretty great for rapidly prototyping new hardware designs, and we enjoy sharing the tools we build and use. It's a topic we've been thinking about writing a blog post about, so we're in the works of releasing an open-hardware board that really goes all in on Pmod.

Interesting. I will look forward to hearing more about that.

The reason we need in-tree users is to ensure we cover this addition in CI and not just let it sit there to bitrot (even if it is just a DTS binding).