From: Arnd Bergmann <arnd@arndb.de>
To: Alex Courbot <acourbot@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Linus Walleij <linus.walleij@linaro.org>,
Guenter Roeck <linux@roeck-us.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [PATCH 0/4] gpio: introduce descriptor-based interface
Date: Thu, 10 Jan 2013 10:08:44 +0000 [thread overview]
Message-ID: <201301101008.45091.arnd@arndb.de> (raw)
In-Reply-To: <2270940.DTxEYMZtED@percival>
On Thursday 10 January 2013, Alex Courbot wrote:
> On Wednesday 09 January 2013 18:46:12 Arnd Bergmann wrote:
> >
> > Only legacy users did this. Initially there was only the header file,
> > with the API declared but several different implementations of it.
> > gpiolib was introduced later to reduce code duplication and allow having
> > multiple implementations in the same kernel.
>
> Does the following sound reasonable?
> 1) Make sure every target that uses GENERIC_GPIO also implements its drivers
> using gpiolib, convert the (hopefully) few ones that don't to use gpiolib
> 2) Make GENERIC_GPIO require GPIOLIB or just merge both options into a single
> one
> 3) Turn gpio into a full subsystem (like pinctrl)
>
> This should make things less blurry and easier to maintain (less header files,
> only one interface, etc.) GPIO controllers would also be better integrated
> into the driver model.
Yes, I think that would be good.
I've tried to find platforms that don't yet use GPIOLIB and fortunately
there are very few left:
I found two that provide the generic gpio interfaces when gpiolib
is disabled, but use gpiolib otherwise for the same hardware,
arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h.
I would assume that we can simply remove the non-gpiolib shortcut
here at cost of a small overhead.
Then there are a bunch that use gpiolib but have a nontrivial
implementation of gpio_get_value and other functions. I'm not sure
if these are a problematic with your code.
> > Regarding the integration of pinctrl with gpio,
> > I was thinking in the past that we could make pinctrl provide everything
> > that gpiolib does, and have a generic gpiolib driver on top of pinctrl
> > so that platforms don't need to implement both interfaces but only need
> > to provide a pure pinctrl driver. Not sure if this makes any sense.
>
> That would work if all GPIOs were connected to a ball, but how about GPIO
> expanders that are external to the chip? They have no use for pinctrl AFAICT.
> On the other hand, maybe we can have one pinctrl-gpio driver for those chips
> where pinctrl alone can emulate all the functionality of a GPIO controller.
> Maybe such a driver exists already?
I don't think we have that yet, but it would be another option: rather
than putting a generic gpiolib driver on top of pinctrl, we could have
pinctrl support for all gpios that go through gpiolib, and move device
drivers over to use pinctrl as the way to manage gpios rather than the
classic gpio drivers. That would be a larger change though, and require
that we pull in the pinctrl subsystem on a lot of machines that don't
need it today.
Arnd
next prev parent reply other threads:[~2013-01-10 10:09 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 7:18 [PATCH 0/4] gpio: introduce descriptor-based interface Alexandre Courbot
2013-01-08 7:18 ` [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 12:59 ` Arnd Bergmann
2013-01-09 1:06 ` Alexandre Courbot
2013-01-09 10:25 ` Russell King - ARM Linux
2013-01-09 10:35 ` Arnd Bergmann
2013-01-09 10:44 ` Russell King - ARM Linux
2013-01-09 11:10 ` Russell King - ARM Linux
[not found] ` <20130109111055.GG3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-09 11:52 ` Arnd Bergmann
2013-01-09 11:52 ` Arnd Bergmann
2013-01-09 14:44 ` Nicolas Pitre
2013-01-09 15:04 ` [PATCH] Proposed removal of IS_ERR_OR_NULL() (was: Re: [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface) Russell King - ARM Linux
[not found] ` <20130109150427.GL3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-09 15:21 ` Grant Likely
2013-01-09 15:21 ` Grant Likely
2013-01-09 15:26 ` Arnd Bergmann
2013-01-09 15:27 ` Nicolas Pitre
2013-01-09 15:27 ` Nicolas Pitre
2013-01-09 15:51 ` Russell King - ARM Linux
2013-01-09 16:09 ` Nicolas Pitre
2013-01-09 16:21 ` Russell King - ARM Linux
2013-01-09 17:12 ` Russell King - ARM Linux
2013-01-09 17:52 ` Tony Lindgren
2013-01-17 10:28 ` Linus Walleij
2013-01-10 8:36 ` [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface Thierry Reding
2013-01-10 8:36 ` Thierry Reding
2013-01-08 7:18 ` [PATCH 2/4] gpiolib: add gpiod_get and gpiod_put functions Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 13:07 ` Arnd Bergmann
2013-01-09 1:49 ` Alexandre Courbot
2013-01-08 7:18 ` [PATCH 3/4] gpiolib: of: convert OF helpers to descriptor API Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 7:18 ` [PATCH 4/4] gpiolib: add documentation for new gpiod_ API Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 13:06 ` [PATCH 0/4] gpio: introduce descriptor-based interface Arnd Bergmann
2013-01-08 13:06 ` Arnd Bergmann
2013-01-09 1:48 ` Alexandre Courbot
2013-01-09 10:46 ` Arnd Bergmann
2013-01-10 4:07 ` Alex Courbot
2013-01-10 10:08 ` Arnd Bergmann [this message]
2013-01-14 10:21 ` Alex Courbot
2013-01-14 10:46 ` Arnd Bergmann
2013-01-14 10:46 ` Arnd Bergmann
2013-01-17 11:15 ` Linus Walleij
2013-01-17 11:15 ` Linus Walleij
2013-01-17 12:02 ` Greg Ungerer
2013-01-17 16:50 ` Steven King
2013-01-17 16:50 ` Steven King
2013-01-17 19:22 ` Arnd Bergmann
2013-01-20 6:07 ` Alex Courbot
2013-01-22 8:55 ` Linus Walleij
2013-01-22 8:55 ` Linus Walleij
2013-01-17 11:25 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201301101008.45091.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=acourbot@nvidia.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).