Re: GPIO forwarding question

[Laurentiu Palcu <laurentiu.palcu@xxxxxxxxxxx>]

On Tue, Nov 05, 2024 at 11:00:21AM +0100, Linus Walleij wrote:
> 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".whe

I guess I chose the example badly as it does, indeed, resemble UART...

However, even though those pins are MFPs (multi-function pins), it's the
GPIO functionality I'm referring to. An input GPIO value can be (or not)
tunneled on the other side of the GMSL link. So, a GPIO pin on either of
the chips can be controlled by the host in the way Linux means it or it
can be forwarded. If we choose to use gpiochip API in the drivers, we'll
be able to control those pins in the Linux GPIO way. Which is fine. But,
I'm totally lost when it comes to the forwarding functionality.

I think this brief section of the specs does a better job explaining the
functionality than I did... See page 95 of the following doc:

https://www.analog.com/media/en/technical-documentation/user-guides/max96724fr-user-guide.pdf

Thanks,
Laurentiu

> 
> 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