Re: Device tree representation of (hotplug) connectors: discussion at ELCE

Herve Codina
2025-09-11T10:11:28Z

Hi David, Geert,

On Wed, 10 Sep 2025 14:36:46 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

...
> >
> > A PMOD Type 2A (expanded SPI) connector provides SPI and 4 GPIOS.
> > A PMOD Type 6A (expanded I2C) connector provides I2C and 4 GPIOS.
> > Hence a plug-in board that needs SPI, I2C, and a few GPIOs, would need
> > to plug into two PMOD connectors.
> >
> > Or:
> > A PMOD Type 1A (expanded GPIO) connector provides 8 GPIOS.
> > Hence a non-multiplexed dual 7-segment LED display plug-in board needs
> > 14 or 16 GPIOS, and thus would plug into two PMOD connectors.
> >
> > To plug into two connectors, a mapping needs to provided between two
> > connectors on base and add-on board.
> >

Base on this, let me draft some ideas to have some basis to move forward.

Suppose:
- A base board with:
2x PMOD Type 2A (SPI + 4 GPIOS)
1x PMOD Type 6A (I2C + 4 GPIOS)
3x PMOD Type 1A ( 8 GPIOS)

- An addon board which needs:
- 1x PMOD type 2A
- 2x PMOD type 1A

Hardware connection:
base board addon board
PMOD 2A #0 +------+ PMOD 2A
PMOD 2A #1
PMOD 6A
PMOD 1A #0
PMOD 1A #1 +------+ PMOD 1A I
PMOD 1A #2 +------+ PMOD 1A II

The base board 'PMOD 1A #0' is not connected to the addon board.
The addon board uses the base board PMOD 1A #1 and #2.

The base board DT:
pmods {
compatible = "pmods";

pmod_2a_0: pmod-2a-0 {
compatible = "pmod-2a"

/* Describe 4 gpios connected to this connector */
gpio-map = < 0 &gpio 10>,
...
< 3 &gpio 43>;

/* Describe the bus connected to this connector */
spi_bus_2a_0: spi-bus {
compatible = "spi-bus-extension";
spi-parent = <&spi2>;
};

/* Export symbols related to this connector */
export-symbols {
pmod-2a = <&pmod_2a_0>;
spi = <&spi_bus_2a_0>;
...
};
};

pmod_2a_1: pmod-2a-1 {
compatible = "pmod-2a"

/* Describe 4 gpios connected to this connector */
gpio-map = ...

/* Describe the bus connected to this connector */
spi_bus_2a_1: spi-bus { ... };

/* Export symbols related to this connector */
export-symbols {
pmod_2a = <&pmod_2a_1>;
spi = <&spi_bus_2a_1>;
...
};
};

pmod_6a: pmod-6a {
compatible = "pmod-6a";
...
export-symbols {
pmod_6a = <&pmod_6a>;
...
};
};

pmod_1a_0: pmod-1a-0 {
compatible = "pmod-1a"

/* Describe 8 gpios connected to this connector */
gpio-map = < 0 &gpio 16>,
...
< 7 &gpio 33>;

export-symbols {
pmod_1a = <&pmod_1a_0>;
gpio0_muxed_as_gpio = <&pin_mux_xxxx>;
gpio1_muxed_as_gpio = <&pin_mux_yyyy>;
gpio2_muxed_as_gpio = <&pin_mux_zzzz>;
};
};

pmod_1a_1: pmod-1a-1 {
compatible = "pmod-1a"

/* Describe 8 gpios connected to this connector */
...

export-symbols {
pmod_1a = <&pmod_1a_1>;
};
};

pmod_1a_2: pmod-1a-2 {
compatible = "pmod-1a"

/* Describe 8 gpios connected to this connector */
...

export-symbols {
pmod_1a = <&pmod_1a_2>;
};
};
};

-- Question 1: How to describe resources needed by the addon

On the addon side, we need to tell that we need 1 PMOD 2A and 2
PMODs 1A (named i and ii).

Proposal supposing that this description will be applied at
base board pmods node (the one grouping pmod connectors):

\{ or ??? corresponding to the entry point of the addon
import-symbols {
pmod_2a = "pmod_2a";
pmod_1a_i = "pmod_1a";
pmod_1a_ii = "pmod_1a";
};

&pmod_2a {
spi-bus {
regulator@0 {
compatible "gpio-regulator";
pinctrl-0 = <&pmod_1a_i.gpio2_muxed_as_gpio>;
enable-gpios = <&pmod_1a_i 2>; /* Use GPIO #2 available on PMOD 1A I */
};

...
};
};

Import-symbols asked for symbols with local name and type (compatible string ?).
for instance 'pmod_1a_i = "pmod_2a";' means:
Hey I refernce localy 'pmod_1a_i' but I don't define it and so 'pmod_1a_i' should
be remapped to a symbol, probably a node of my expected type "pmod_2a".

Also, we can node the syntax:
&pmod_1a_i.gpio2_muxed_as_gpio

meaning I use the symbols gpio2_muxed_as_gpio provided by pmod_1a_i (namespace).
In other word, to have the addon DT successfully applied,
the node remapped to 'pmod_1a_i' has to export the symbol 'gpio2_muxed_as_gpio'.

--- Question 2: how to perform the mapping between pmods available on the
base board and pmods needed by the addon board.

The addon board describes what it is expected:
import-symbols {
pmod_2a = "pmod_2a";
pmod_1a_i = "pmod_1a";
pmod_1a_ii = "pmod_1a";
};

Based on compatible string:
pmod_2a expected by the addon can be remapped to the node
pmod-2a-0 or pmod-2a-1 described in the base board.

pmod_1a_i and pmod_1a_ii expected by the addon can be remapped
to pmod-1a-0, pmod-1a-1, pmod-1a-2.

We need some more information to set correct mapping
pmod_2a <---> pmod-2a-0
pmod_1a_i <---> pmod-1a-1
pmod_1a_ii <---> pmod-1a-2

Can we imagine that this mapping is set by the compatible "pmods"
driver base on some specific external information.
- Read info from addon to have some more hardware connection
details (not sure it is relavant with PMODs connector)

- Expect this information from user-space ?

- Any other ideas ?

Best regards,
Hervé