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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF1740805421@HQMAIL01.nvidia.com>
Date:	Thu, 10 Nov 2011 08:33:59 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: pinctrl discussions @ Linaro Connect, and also requesting GPIOs

Linus Walleij wrote at Thursday, November 10, 2011 1:40 AM:
> On Wed, Nov 9, 2011 at 9:34 PM, Stephen Warren <swarren@...dia.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/