From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2] leds: leds-gpio: adopt pinctrl support
Date: Mon, 10 Sep 2012 13:44:35 -0600 [thread overview]
Message-ID: <504E4323.9040108@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdb5Gnt0ZOzsSdp28KKKbcC2tCkt+6jN3R+w0X5cs1H9cg@mail.gmail.com>
On 09/10/2012 01:34 PM, Linus Walleij wrote:
> On Mon, Sep 10, 2012 at 7:41 PM, Stephen Warren <swarren@wwwdotorg•org> wrote:
>> On 09/10/2012 09:23 AM, Linus Walleij wrote:
>
>> That seems like exactly what we were trying to avoid when we added the
>> possibility for GPIO to call into pinctrl.
>>
>> Documentation/gpio.txt already contains:
>>
>>> For GPIOs that use pins known to the pinctrl subsystem, that subsystem should
>>> be informed of their use; a gpiolib driver's .request() operation may call
>>> pinctrl_request_gpio(), and a gpiolib driver's .free() operation may call
>>> pinctrl_free_gpio(). The pinctrl subsystem allows a pinctrl_request_gpio()
>>> to succeed concurrently with a pin or pingroup being "owned" by a device for
>>> pin multiplexing.
>>
>> In order to resolve this, shouldn't we simply change the "should" at the
>> end of the first line I quoted to "must"? That way, there'd never be any
>> need to use pinctrl if you're only relying on gpiolib APIs.
>>
>> (and I'd argue that the text was already meant to say "must", so this
>> isn't actually a change to the intent, just a clarification).
>
> It should deal with all the simple muxing use cases yes. And
> I am uncertain about the scope for this patch, if it only pertains
> to muxing, and in that case it would be solved by adding
> a proper GPIO backend to pinctrl-single.c.
>
> But it doesn't help with some real-world usecases if I'm
> not mistaken.
>
> If you want to set up a certain GPIO pin as pull-down (I guess
> this could be the case for a LED array), this cannot be done
> through any of these functions:
>
> extern int pinctrl_request_gpio(unsigned gpio);
> extern void pinctrl_free_gpio(unsigned gpio);
> extern int pinctrl_gpio_direction_input(unsigned gpio);
> extern int pinctrl_gpio_direction_output(unsigned gpio);
>
> So either we have to use a pin config hog to do this,
I'd certainly expect that to be the common case; I'd imagine it's pretty
common you'd never want to change the pulls at runtime, so hogging would
be appropriate.
> or we have
> to use devm_pinctrl_get_select_default(&pdev->dev); from the
> driver (as this patch does).
Yes, true.
> Either way it is using the pinctrl
> system orthogonally to the GPIO system, it doesn't happen
> from pinctrl_request_gpio() or so.
>
> An alternative solution would be to add functions for
> controlling pinconfig and whatnot to the GPIO glue, which
> in turn would require adding frontends all over <linux/gpio.h>
> which in turn was the thing that Grant nixed to I got
> started with pinctrl instead...
Maybe the first gpio_request that GPIO passes to pinctrl could activate
some default "gpio" state or similar? But then you'd get into issues
with: what if the driver selects a pinctrl state for other reasons -
then you'd end up wanting multiple states active at once; the
gpiolib-requested state and the driver-requested state, and maybe they
conflict, ... probably madness ensues!
> But I'm open to any other suggestions. Would it be possible
> for pinctrl_request_gpio() to activate a pin config in the
> map for example? Currently it can only do muxing.
>
> It's also possible to have the driver do something custom
> behind the back of pinctrl altogether as a response to
> pinctrl_request_gpio() but it wouldn't be
> any elegant...
next prev parent reply other threads:[~2012-09-10 19:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-01 8:16 [PATCH v2] leds: leds-gpio: adopt pinctrl support AnilKumar Ch
2012-09-05 3:06 ` Bryan Wu
2012-09-05 3:13 ` Marek Vasut
2012-09-05 23:34 ` Tony Lindgren
2012-09-06 2:05 ` Marek Vasut
2012-09-06 17:45 ` Tony Lindgren
2012-09-07 0:09 ` Marek Vasut
2012-09-07 7:59 ` AnilKumar, Chimata
2012-09-07 8:22 ` Marek Vasut
2012-09-07 16:00 ` Bryan Wu
2012-09-07 21:39 ` Linus Walleij
2012-09-07 21:46 ` Tony Lindgren
2012-09-07 8:48 ` Domenico Andreoli
2012-09-07 9:10 ` AnilKumar, Chimata
2012-09-07 11:02 ` Domenico Andreoli
2012-09-07 14:30 ` AnilKumar, Chimata
2012-09-07 16:00 ` Domenico Andreoli
2012-09-07 16:35 ` Tony Lindgren
2012-09-07 21:59 ` Linus Walleij
2012-09-07 21:57 ` Linus Walleij
2012-09-08 23:44 ` Domenico Andreoli
2012-09-10 15:23 ` Linus Walleij
2012-09-10 17:41 ` Stephen Warren
2012-09-10 19:34 ` Linus Walleij
2012-09-10 19:44 ` Stephen Warren [this message]
2012-09-07 21:36 ` Linus Walleij
2012-09-10 19:40 ` Linus Walleij
2012-10-01 7:03 ` AnilKumar, Chimata
2012-10-01 8:24 ` Linus Walleij
2012-10-01 15:44 ` Tony Lindgren
2012-10-01 19:59 ` Linus Walleij
2012-10-03 10:52 ` AnilKumar, Chimata
2012-10-03 12:36 ` Linus Walleij
2012-10-30 14:12 ` AnilKumar, Chimata
2012-11-04 17:37 ` Linus Walleij
2012-11-05 6:44 ` AnilKumar, Chimata
2012-11-05 16:27 ` Tony Lindgren
2012-10-03 15:53 ` Tony Lindgren
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=504E4323.9040108@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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