Re: Requesting as a GPIO a pin already used through pinctrl

[Maxime Ripard <maxime.ripard@free-electrons.com>]

[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]

On Fri, Sep 23, 2016 at 03:22:53PM +0200, Linus Walleij wrote:
> > However, it does have an unexpected side-effect. On our DT, for the
> > GPIOs, we also set up a pinctrl node (which seem to be along the lines
> > of the doc recommandations, section "Drivers needing both pin control
> > and GPIOs").
> >
> > However, when pinctrl_select_default is called by the core, which in
> > turns ends up calling pinmux_enable_setting, which builds the owner
> > name using the dev_name. However, when we call gpiod_request, it ends
> > up in pinmux_request_gpio, which build the owner string using the
> > pinctrl device name and the pin number.
> >
> > This results in a mismatch of owners, and the gpiod_request fails,
> > while the device really is the same.
> 
> Yeah, needing both GPIO and pinctrl on the same pin kind of
> implies that the subsystems are poking at the same hardware and
> that is !=strict.

My understanding was that GPIO and pinctrl were pretty much
orthogonal, a pinctrl property would set up the muxing, and mark the
pin as in use, while the GPIO property would just say what we use the
pin for. In a way, that was similar to what any other controller would
behave. You would mark the pins as exclusive, mux them, and leave the
controller deal with its pin.

Anyway, I'll remove those properties from our DTs, and add the .strict
flag.

> I have had some half-finished thoughts here, for example to add
> more callbacks from GPIO to pinctrl for things like open drain
> and biasing, so that GPIO would be a "pure" front-end with a pinctrl
> back-end. It ends up duplicating a lot of stuff from pinctrl in GPIO,
> but since people will inevitably want to do things like biasing
> from the GPIO chardev I might have to bite the bullet and do it
> that way.
> 
> Other ideas welcome.

If we don't have access to the calling device structure, I'm not sure
how we could fix that properly.

On your more mid-term view of things and where the chardev interface
should be going, I definitely second at least having things like
biasing, strength, and all the configuration really, exposed. There's
a lot of people that actually want to enable biasing and we don't
really have a good solution for that.

One way would be to use the DT overlays, but that seems more of a hack
than anything else.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]