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: <CACRpkdY8YXooD5ChHqQnERPPGhk7TgUvL=TodAPY8Jit9eS=fw@mail.gmail.com>
Date:	Thu, 10 Nov 2011 09:40:18 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: pinctrl discussions @ Linaro Connect, and also requesting GPIOs

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.

For COH901* GPIO driver I plan to move the entire GPIO driver
to drivers/pinctrl/ and add pin config in the same file, then also
expose a pinctrl interface. This way the functionality can cross-call
each other using local statics. IIRC Grant also said ACKed this
approach to silicon that do combines pin control and GPIO in
one block especially.

> a) Should drivers explicitly call pinmux_request_gpio() before calling
> gpio_request() instead, so that the board files don't have to set this up
> first?

I hope not. I think the GPIO driver shall do this as part of
gpio_request().

> b) Shouldn't this be hidden inside the pinctrl's mapping table; if a driver
> needs to set up non-GPIO pinmux options, it's all done in pinmux_get() and
> pinmux_enable(), whereas for GPIOs they need to use the other API. Can we
> unify this?

Is there some problem with having it as part of gpio_request()?

> I think extending the mapping table to be able to represent either the
> existing mux configuration, or GPIO allocation, might make sense. In fact,
> if we do that, perhaps pinmux_{request,free}_gpio() wouldn't even be needed?

Hmmm I definately want different mappings for muxes and
pinctrl since they can be used as orthogonal concepts.

As for GPIO allocation thru mappings somekindof, I don't have a clear
picture. I always though of the cross-relationship between GPIO
and pin control as an intrinsic of each GPIO driver, not a system-wide
configuration problem.

Yours,
Linus Walleij
--
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/