All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-omap@vger.kernel.org, Stephen Warren <swarren@nvidia.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
Date: Fri, 11 May 2012 15:04:39 -0600	[thread overview]
Message-ID: <4FAD7EE7.2070704@wwwdotorg.org> (raw)
In-Reply-To: <20120511195147.GW21851@atomide.com>

On 05/11/2012 01:51 PM, Tony Lindgren wrote:
> * Stephen Warren <swarren@wwwdotorg.org> [120511 12:21]:
>>
>> The mapping of GPIO to pinctrl pins would presumably be driven solely by
>> the HW design of the pin controller and GPIO, and not by the mux
>> selection in the pin controller (otherwise, I'd argue this isn't a
>> simple case that should be handled by pinctrl-simple).
>>
>> As such, I'd expect some properties/table at the top-level of the pin
>> controller object to describe the GPIO mapping. In turn, that implies
>> that the individual per-pin mux-selection/configuration nodes don't need
>> to describe any GPIO-related information.
> 
> Yes good point. I agree it's a HW design issue, and could be in the properties
> for the pin controller object.
> 
> Just to summarize, the things to consider with the GPIO to mux mapping are:
> 
> 1. Having this table as static data in the driver is is not a nice
>    solution as it seems that we'd currently need six mapping tables for
>    omap2+ alone.
> 
> 2. This table is not needed for most of the (hundreds of) pins, it's
>    only needed for a few selected pins, let's say ten or so on an average
>    device. So there's no need to stuff the kernel with information about
>    the unused GPIO pins.
> 
> It seems that the conclusion here is that we don't need to worry about
> GPIOs in the pinctrl-simple binding for now, and it can be added later
> without having to change the basic binding.

The one thing I wanted to resolve here wasn't so much the binding for
GPIO interaction here, but the following comment:

You wrote:
> I wrote:
>> From a binding perspective, I don't see why you'd want to allow two cases:
>>
>> 1) One node with multiple entries in pinctrl-simple,cells
>> 2) Multiple nodes each with a single entry in pinctrl-simple,cells
>>
>> Why not only allow (1)?
>
> Because we need to specify GPIO for some pins. There may be additional flags
> too, we do have external DMA request lines for few pins available.. I'm not
> saying pinctrl fwk should know about that, but it's a similar mapping of pins
> to GPIO lines.

I'm asserting that since any GPIO mapping information would be at the
top-level of the pinctrl-simple binding, we can in fact only allow
option (1) above for the individual pin configuration nodes.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
Date: Fri, 11 May 2012 15:04:39 -0600	[thread overview]
Message-ID: <4FAD7EE7.2070704@wwwdotorg.org> (raw)
In-Reply-To: <20120511195147.GW21851@atomide.com>

On 05/11/2012 01:51 PM, Tony Lindgren wrote:
> * Stephen Warren <swarren@wwwdotorg.org> [120511 12:21]:
>>
>> The mapping of GPIO to pinctrl pins would presumably be driven solely by
>> the HW design of the pin controller and GPIO, and not by the mux
>> selection in the pin controller (otherwise, I'd argue this isn't a
>> simple case that should be handled by pinctrl-simple).
>>
>> As such, I'd expect some properties/table at the top-level of the pin
>> controller object to describe the GPIO mapping. In turn, that implies
>> that the individual per-pin mux-selection/configuration nodes don't need
>> to describe any GPIO-related information.
> 
> Yes good point. I agree it's a HW design issue, and could be in the properties
> for the pin controller object.
> 
> Just to summarize, the things to consider with the GPIO to mux mapping are:
> 
> 1. Having this table as static data in the driver is is not a nice
>    solution as it seems that we'd currently need six mapping tables for
>    omap2+ alone.
> 
> 2. This table is not needed for most of the (hundreds of) pins, it's
>    only needed for a few selected pins, let's say ten or so on an average
>    device. So there's no need to stuff the kernel with information about
>    the unused GPIO pins.
> 
> It seems that the conclusion here is that we don't need to worry about
> GPIOs in the pinctrl-simple binding for now, and it can be added later
> without having to change the basic binding.

The one thing I wanted to resolve here wasn't so much the binding for
GPIO interaction here, but the following comment:

You wrote:
> I wrote:
>> From a binding perspective, I don't see why you'd want to allow two cases:
>>
>> 1) One node with multiple entries in pinctrl-simple,cells
>> 2) Multiple nodes each with a single entry in pinctrl-simple,cells
>>
>> Why not only allow (1)?
>
> Because we need to specify GPIO for some pins. There may be additional flags
> too, we do have external DMA request lines for few pins available.. I'm not
> saying pinctrl fwk should know about that, but it's a similar mapping of pins
> to GPIO lines.

I'm asserting that since any GPIO mapping information would be at the
top-level of the pinctrl-simple binding, we can in fact only allow
option (1) above for the individual pin configuration nodes.

  reply	other threads:[~2012-05-11 21:04 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-02 17:24 [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf Tony Lindgren
2012-05-02 17:24 ` Tony Lindgren
2012-05-03  6:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-03  6:51   ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-03 15:27   ` Tony Lindgren
2012-05-03 15:27     ` Tony Lindgren
2012-05-03 22:34     ` Stephen Warren
2012-05-03 22:34       ` Stephen Warren
2012-05-04  4:43       ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04  4:43         ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 15:03         ` Tony Lindgren
2012-05-04 15:03           ` Tony Lindgren
2012-05-04 15:32           ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 15:32             ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 15:32             ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 16:34             ` Tony Lindgren
2012-05-04 16:34               ` Tony Lindgren
2012-05-04 16:38               ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 16:38                 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 18:55               ` Stephen Warren
2012-05-04 18:55                 ` Stephen Warren
2012-05-04 22:08                 ` Tony Lindgren
2012-05-04 22:08                   ` Tony Lindgren
2012-05-09 20:19                   ` Stephen Warren
2012-05-09 20:19                     ` Stephen Warren
2012-05-09 20:49                     ` Tony Lindgren
2012-05-09 20:49                       ` Tony Lindgren
2012-05-10 17:05                       ` Stephen Warren
2012-05-10 17:05                         ` Stephen Warren
2012-05-10 17:27                         ` Tony Lindgren
2012-05-10 17:27                           ` Tony Lindgren
2012-05-11 19:17                           ` Stephen Warren
2012-05-11 19:17                             ` Stephen Warren
2012-05-11 19:51                             ` Tony Lindgren
2012-05-11 19:51                               ` Tony Lindgren
2012-05-11 21:04                               ` Stephen Warren [this message]
2012-05-11 21:04                                 ` Stephen Warren
2012-05-11 21:18                                 ` Tony Lindgren
2012-05-11 21:18                                   ` Tony Lindgren
2012-05-12 23:49                         ` Linus Walleij
2012-05-12 23:49                           ` Linus Walleij
2012-05-12 23:49                           ` Linus Walleij
2012-05-14 18:38                           ` Stephen Warren
2012-05-14 18:38                             ` Stephen Warren
2012-05-15 20:07                             ` Tony Lindgren
2012-05-15 20:07                               ` Tony Lindgren
2012-05-16  7:14                             ` Linus Walleij
2012-05-16  7:14                               ` Linus Walleij
2012-05-16 15:53                               ` Stephen Warren
2012-05-16 15:53                                 ` Stephen Warren
2012-05-05  2:04                 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-05  2:04                   ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-09 20:24                   ` Stephen Warren
2012-05-09 20:24                     ` Stephen Warren
2012-05-09  9:09           ` Linus Walleij
2012-05-09  9:09             ` Linus Walleij
2012-05-09 20:50             ` Tony Lindgren
2012-05-09 20:50               ` Tony Lindgren
2012-05-04 19:23 ` Stephen Warren
2012-05-04 19:23   ` Stephen Warren
2012-05-04 21:57   ` Tony Lindgren
2012-05-04 21:57     ` Tony Lindgren
2012-05-09 20:16     ` Stephen Warren
2012-05-09 20:16       ` Stephen Warren
2012-05-09 21:08       ` Tony Lindgren
2012-05-09 21:08         ` 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=4FAD7EE7.2070704@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=plagnioj@jcrosoft.com \
    --cc=swarren@nvidia.com \
    --cc=tony@atomide.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 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.