public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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