From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>,
Linus Walleij <linus.walleij@stericsson.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Stephen Warren <swarren@nvidia.com>,
Anmar Oueja <anmar.oueja@linaro.org>
Subject: Re: [PATCH] pinctrl: document semantics vs GPIO
Date: Fri, 14 Sep 2012 09:55:33 -0600 [thread overview]
Message-ID: <50535375.4090606@wwwdotorg.org> (raw)
In-Reply-To: <20120914143056.GA25696@glitch>
On 09/14/2012 08:30 AM, Domenico Andreoli wrote:
> On Fri, Sep 14, 2012 at 03:48:05PM +0200, Linus Walleij wrote:
>> On Fri, Sep 14, 2012 at 12:11 AM, Domenico Andreoli <cavokz@gmail.com> wrote:
>>> On Thu, Sep 13, 2012 at 10:11:29AM -0600, Stephen Warren wrote:
>>
>>>> I think it makes sense to more strongly recommend that for GPIO muxing,
>>>> the GPIO driver always call into the pinctrl subsystem (if needed by the
>>>> HW) to perform that muxing, so that standalone gpio_direction_*() always
>>>> work without any use of pinctrl; the interaction between the two should
>>>> only be required if pin configuration (not just pin muxing) is also
>>>> required.
>>>
>>> Don't know. Isn't possible to reach the same effect moving this kind
>>> of knowledge into higher level helper functions and remove this bridge
>>> across the subsystems?
>>
>> I'm not following, please elaborate on this.
>>
>> What are these higher level functions, and where will they be
>> located? In which subsystem, and using what symbols/signatures and
>> so on?
>
> If the common case is requesting the pin and then the gpio, an helper
> like this would do the trick. So why those calls into pinctrl should be
> done by the GPIO driver itself? Pinctrl and GPIO would be separated,
> ignoring each other.
>
> static int request_muxed_gpio(int gpio, const char *label)
That would require the driver to know when to call gpio_request() as
opposed to request_muxed_gpio() wouldn't it. Whether that is needed or
not depends on the Soc/board the driver is running on. The whole idea of
the internal GPIO->pinctrl driver communication was to avoid that.
I suppose that if we were to mandate that ever device that uses GPIOs
also have at least some (possibly empty) pinctrl state defined, then
request_muxed_gpio() could always be used. However, that's quite a
strong requirement. An also, if we were to make that rule, then we might
as well just implement this inside the existing gpio_request(), so that
no driver changes were required.
next prev parent reply other threads:[~2012-09-14 15:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-13 7:01 [PATCH] pinctrl: document semantics vs GPIO Linus Walleij
2012-09-13 16:11 ` Stephen Warren
2012-09-13 22:11 ` Domenico Andreoli
2012-09-14 13:48 ` Linus Walleij
2012-09-14 14:30 ` Domenico Andreoli
2012-09-14 15:55 ` Stephen Warren [this message]
2012-09-14 13:41 ` 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=50535375.4090606@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=anmar.oueja@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swarren@nvidia.com \
/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