Re: GPIO forwarding question

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Tue, Nov 5, 2024 at 1:43 PM Laurentiu Palcu
<laurentiu.palcu@xxxxxxxxxxx> wrote:

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

Heh sorry if I misunderstood it.

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

We have a GPIO "forwarding thing" called the gpio aggregator:
drivers/gpio/gpio-aggregator.c

I suggest you look closely at this driver and how it works. Since
it is software-only it does not have device tree bindings, so your
driver will be the first instance of something similar that actually
uses device tree to bind resources, but the implementation
will be similar +/- the actual hardware quirks to control your
forwarder/amplifier/aggregator or whatever we shall call it.

The interrupt counterpart is called a "hierarchical irqchip" so
perhaps this should be called a "hierarchical gpiochip"?

Yours,
Linus Walleij