RE: Enable buttons GPIO passthrough

["Wang, Kuiying" <kuiying.wang@xxxxxxxxx>]

Hi Linus,
Thanks a lot for your sharing and suggestion.
My proposal to enable buttons GPIO pass-through based on pinmux driver as following:
1. remove codes about SCU7C clearance (from line 194 to line 236) in aspeed_sig_expr_set function in pinctrl-aspeed.c file.
2. create 2 new functions in pinctrl-aspeed.c file: “aspeed_gpio_passthrough_enable” and “aspeed_gpio_passthrough_disable”
3. bind button gpio to pinctrl

Please feel free to correct me and share your preferred solution.

Thanks,
Kwin.


-----Original Message-----
From: Linus Walleij [mailto:linus.walleij@xxxxxxxxxx] 
Sent: Monday, January 14, 2019 4:19 PM
To: Andrew Jeffery <andrew@xxxxxxxx>; Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxx>
Cc: Joel Stanley <joel@xxxxxxxxx>; Wang, Kuiying <kuiying.wang@xxxxxxxxx>; open list:GPIO SUBSYSTEM <linux-gpio@xxxxxxxxxxxxxxx>; Andrew Geissler <geissonator@xxxxxxxxx>; OpenBMC Maillist <openbmc@xxxxxxxxxxxxxxxx>; Mauery, Vernon <vernon.mauery@xxxxxxxxx>; Feist, James <james.feist@xxxxxxxxx>; Yoo, Jae Hyun <jae.hyun.yoo@xxxxxxxxx>
Subject: Re: Enable buttons GPIO passthrough

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