From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
Date: Thu, 10 May 2012 10:27:22 -0700 [thread overview]
Message-ID: <20120510172722.GE21851@atomide.com> (raw)
In-Reply-To: <4FABF553.20601@wwwdotorg.org>
* Stephen Warren <swarren@wwwdotorg.org> [120510 10:09]:
> On 05/09/2012 02:49 PM, Tony Lindgren wrote:
> > * Stephen Warren <swarren@wwwdotorg.org> [120509 13:22]:
> >> On 05/04/2012 04:08 PM, Tony Lindgren wrote:
> >>> * Stephen Warren <swarren@wwwdotorg.org> [120504 11:59]:
> >>>> On 05/04/2012 10:34 AM, Tony Lindgren wrote:
> >>>>> * Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [120504 08:58]:
> >>>>>> On 08:03 Fri 04 May , Tony Lindgren wrote:
> >>>>>>>>
> >>>>>>>> so I was thinking to do like on gpio
> >>>>>>>>
> >>>>>>>> uart {
> >>>>>>>> pin = < &pioA 12 {pararms} >
> >>>>>>>>
> >>>>>>>> }
> >>>>>>>
> >>>>>>> Hmm I assume the "12" above the gpio number?
> >>>>>> no pin number in the bank because it could not be gpio
> >>>>>
> >>>>> Yes OK, but pin number 12 in the gpio bank, not in the mux register.
> >>>>> Got it.
> >>>>
> >>>> I'd prefer to avoid any references to GPIOs here; not all muxable pins
> >>>> are GPIOs and not all GPIOs are muxable pins. Lets keep the two concepts
> >>>> independent.
> >>>
> >>> And it seems that &pioA 12 is not always enough information for the pinctrl
> >>> driver to request a GPIO. So it's best to specify it separately.
> >>
> >> Why would a pinctrl driver "request a GPIO"?
> >
> > Hmm what would pinctrl_request_gpio do if the GPIO driver is separate driver?
>
> Well, that's a GPIO driver requesting a GPIO from the pinctrl system,
> rather than the pinctrl driver requesting a GPIO (sorry to be picky).
Oh sorry maybe I misunderstood what pinctrl_request_gpio is doing.
Seems like that should work the same way from binding point of view.
> It wasn't at all obvious to me from your binding proposal that you
> intended the pinctrl-simple driver to support the GPIO operations at
> all. If you do want this, I think you'd need some properties (perhaps
> some kind of explicit table) in order to set up the GPIO ID -> pinctrl
> pin ID mapping. I don't recall seeing those; did I just miss them? I
> think we'd want this to be explicit because:
>
> a) It may well be the case that not all users of pinctrl-simple actually
> mux/control GPIOs at all. It's certainly possible to only mux "special
> functions", and have dedicated pins for a GPIO controller.
>
> b) Even when GPIOs do come into the picture, it may be that only some of
> the pins are available as GPIOs.
Right, we need some pinctrl to gpio mapping eventually. That comes
automatically from DT for the pins and gpios we care about.
And that's why the binding needs to be flexible enough so we can add
optional pin specific options as needed in addition to parsing a larger
set of pins with no options.
> Also, were you intending pinctrl-simple to actually be the GPIO
> controller itself? That'd be another case that one might consider fairly
> simple, but then extends to being gpio-simple as well as pinctrl-simple...
No, I was thinking that we can have other drivers using pinctrl simple
and add the extra features for the pins that have those.
Regards,
Tony
next prev parent reply other threads:[~2012-05-10 17:27 UTC|newest]
Thread overview: 32+ 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-03 6:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-03 15:27 ` Tony Lindgren
2012-05-03 22:34 ` Stephen Warren
2012-05-04 4:43 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 15:03 ` Tony Lindgren
2012-05-04 15:32 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 16:34 ` Tony Lindgren
2012-05-04 16:38 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 18:55 ` Stephen Warren
2012-05-04 22:08 ` Tony Lindgren
2012-05-09 20:19 ` Stephen Warren
2012-05-09 20:49 ` Tony Lindgren
2012-05-10 17:05 ` Stephen Warren
2012-05-10 17:27 ` Tony Lindgren [this message]
2012-05-11 19:17 ` Stephen Warren
2012-05-11 19:51 ` Tony Lindgren
2012-05-11 21:04 ` Stephen Warren
2012-05-11 21:18 ` Tony Lindgren
2012-05-12 23:49 ` Linus Walleij
2012-05-14 18:38 ` Stephen Warren
2012-05-15 20:07 ` Tony Lindgren
2012-05-16 7:14 ` Linus Walleij
2012-05-16 15:53 ` Stephen Warren
2012-05-05 2:04 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-09 20:24 ` Stephen Warren
2012-05-09 9:09 ` Linus Walleij
2012-05-09 20:50 ` Tony Lindgren
2012-05-04 19:23 ` Stephen Warren
2012-05-04 21:57 ` Tony Lindgren
2012-05-09 20:16 ` Stephen Warren
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=20120510172722.GE21851@atomide.com \
--to=tony@atomide.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).