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

[Herve Codina <herve.codina@bootlin.com>]

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é