All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [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.

WARNING: multiple messages have this Message-ID (diff)
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: 14+ 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  7:01 ` Linus Walleij
2012-09-13 16:11 ` Stephen Warren
2012-09-13 16:11   ` Stephen Warren
2012-09-13 22:11   ` Domenico Andreoli
2012-09-13 22:11     ` Domenico Andreoli
2012-09-14 13:48     ` Linus Walleij
2012-09-14 13:48       ` Linus Walleij
2012-09-14 14:30       ` Domenico Andreoli
2012-09-14 14:30         ` Domenico Andreoli
2012-09-14 15:55         ` Stephen Warren [this message]
2012-09-14 15:55           ` Stephen Warren
2012-09-14 13:41   ` Linus Walleij
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=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.