RE: pinctrl discussions @ Linaro Connect, and also requesting GPIOs

[Stephen Warren]

Linus Walleij wrote at Thursday, November 10, 2011 1:40 AM:
> On Wed, Nov 9, 2011 at 9:34 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> 
> > I'm curious about any pinctrl-related discussions that happened at Linaro
> > Connect. Are you able to summarize any discussions/decisions, or point me
> > at some existing summary? Especially anything to do with the new pin config
> > options, possibly extending the mapping table to control them, etc.
> 
> There was not much of discussion really, and I didn't have any specific
> pinmux session. It seems like most people with an interest in this were
> in Prague, none in Orlando...
> 
> I'll make a patch with some kind of solution that I intutively came up
> with, then we will probably refactor that a few good times before the
> next merge window.
> 
> > Many drivers currently call gpio_request(). This is defined /not/ to
> > perform any pinmux manipulation.
> 
> Is it?
> 
> I always though that the GPIO driver could call out to the pinctrl
> counterpart.

I'd originally thought that too, but when I tried to "fix" gpio_request()
on Tegra to perform any necessary pinmux actions, it was pointed out that
Documentation/gpio.txt says:

" Note that requesting a GPIO does NOT cause it to be configured in any
" way; it just marks that GPIO as in use.  Separate code must handle any
" pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
                              ^^^^^^^^^^^^^^^^^^^^^^^

Given that, it appears that the pinctrl/pinmux API is the way to perform
that setup, including muxing the GPIO controller onto the pin if required.
Given the similarity of that mux setup with more general non-GPIO mux
setup is why I suggested including GPIO muxing in the regular mapping
table.

(as I think I mentioned) and alternative to a custom GPIO mapping table
entry would be to remove the GPIO-specific APIs from pinctrl, and have
all pinctrl drivers only expose GPIO as an additional function available
on a pin (group). Systems that support N different GPIOs on a pin would
need to expose GPIO this way anyway.

-- 
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/