Re: Enable buttons GPIO passthrough

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Jan 14, 2019 at 3:59 AM Andrew Jeffery <andrew@xxxxxxxx> wrote:
> On Fri, 11 Jan 2019, at 19:31, Linus Walleij wrote:

> > I am sorry but I'm confused about this. It's a very terse explanation
> > of the problem and a bunch of code.
> >
> > Can you folks please define what exactly you mean with a
> > "GPIO passthrough" and what you are trying to achieve with
> > this on these buttons?
>
> On the Aspeed BMC SoCs, several GPIO banks (D and E) can be
> configured so the pins in the low half of a bank of 8 pins are
> input, and the pins in the high half of the bank are output. The
> line state of pins 0 <= i < 4 is reflected on pin i + 4. This way it
> appears as though the BMC is not present in the circuit.
>
> This is useful when the BMC may not have firmware of its own,
> or if it does, if the BMC firmware is not required on the critical
> path of the host's boot process. If or when the BMC firmware
> boots up, it may choose to break the pass-through behaviour
> in order to provide its own out-of-band management capabilities.
>
> This can be used for things like a box's power button as
> mentioned: If the BMC is not up, poke the host directly,
> otherwise, poke the BMC firmware and have it poke the host.
>
> The pass-through settings are tied to the SoC's pinmux. Intuitively
> it should be integrated into the pinmux driver, but IIRC there was
> some ugly coupling of the function that didn't have a neat solution
> with the currently-separate GPIO and pinmux drivers.
>
> Hope that helps.

Yes I get it now! Thanks a lot!

That's a very neat hardware trick, I like how they think.

Pin config in the pin control driver is indeed the recommended
way to go, if possible.

If not possible, so that this particular trick needs to be handled
on the GPIO side of the world, I would recommend to work
with adding it as generic GPIO line config on the GPIO side.

That means, document passthrough in
include/linux/pinctrl/pinconf-generic.h
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
so it is a generic config in the pin control world, then
also make it a GPIO-only binding:

Documentation/devicetree/bindings/gpio/gpio.txt
include/dt-bindings/gpio/gpio.h
And parse it as an argument for the second cell in the
GPIO phandle, then manage it in the GPIO driver
.set_config() callback without calling into the pin config
backend.

Thomas Petazzoni is currently looking into using some
of the standard pin config set ups on the pure GPIO
path so keep him in CC. I think it will be necessary to go
down this path for some line configurations rather than
forcibly keep GPIO and pin control electronic settings
separate.

My idea as maintainer is that I want to keep
the available configs together so that it can be seamlessly
switched between the GPIO front-end and a pin control
back-end.

Yours,
Linus Walleij