Re: GPIO forwarding question

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Nov 4, 2024 at 4:17 PM Laurentiu Palcu
<laurentiu.palcu@xxxxxxxxxxx> wrote:

> We're working with some Analog Devices SerDes chips which provide "reliable
> transport of high-resolution digital video for camera and display-based
> applications" over a GMSL link [1]. But, besides video data, they can also
> transport audio data, control (I2C) and GPIO.
>
> We have some drivers downstream that I intend to upstream but there's one
> particular issue I don't know how to do it right: GPIO forwarding. Below are 2
> examples of how we use this feature. For the sake of not complicating the
> diagrams I only show the SoC on the left leaving out the I2C and other data
> connections.
>
> A)
>      |       +-----+            +-----+
>      |  (1) _|Rx   |            |   Tx|_ (1)
>      |       |     |            |     |
> SoC  |       | Ser |=== GMSL ===| Des |
>      |  (2) _|Tx   |            |   Rx|_ (2)
>      |       |     |            |     |
>      |       +-----+            +-----+
>
> So, in the first, simplified, scenario, any transitions on the Rx pin (1) of
> Ser chip will be replicated on the Tx pin (1) of Des chip. And vice versa,
> anything happening on Rx pin (2) of Des chip will be replicated on the Tx pin
> (2) of Ser chip. To make things more complicated, transitions on one GPIO pin
> can even be sent to more pins on the other side...

This is just a big confusion for me because you are giving a UART
example and then saying this is a GPIO example.

I think it's a terminology problem:

What Linux mean with "GPIO" is
- A number of lines which are software-controlled
- May go into high or low state on request of a consumer (such as
  a driver)
- May be read by software to be high or low.
- Optionally supports interrupts triggered for input lines.
- Optionally supports biasing and other things.

I think you have confused terminology used by hardware designers.
What hardware designers mean with GPIO is "some wire we use for
different things". This is not the same as what Linux GPIO means.
Compare for example the pin control subsystem which is about
pin multiplexing, which is something that some hardware designers
unhelpfully call "GPIO".

For this specific usecase, however, I suggest you look into
drivers/mux which is the multiplexer subsystem, it looks closest
to what you want to do, though I don't know much about muxes
myself.

Yours,
Linus Walleij