linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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: Fri, 4 May 2012 09:34:20 -0700	[thread overview]
Message-ID: <20120504163420.GA5613@atomide.com> (raw)
In-Reply-To: <20120504153251.GE7788@game.jcrosoft.org>

* 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.
 
> 	pioD: gpio at fffff800 {
> 		compatible = "atmel,at91rm9200-gpio";
> 		reg = <0xfffff800 0x100>;
> 		interrupts = <5 4>;
> 		#gpio-cells = <2>;
> 		gpio-controller;
> 		interrupt-controller;
> 	};
> 
> 	pioE: gpio at fffffa00 {
> 		compatible = "atmel,at91rm9200-gpio";
> 		reg = <0xfffffa00 0x100>;
> 		interrupts = <5 4>;
> 		#gpio-cells = <2>;
> 		gpio-controller;
> 		interrupt-controller;
> 	};
> 
> 	dbgu {
> 		pins = < &pioB 12 0 0
> 			 &pioB 13 0 2 >;
> 	/* with macro */
> 		pins = < &pioB 12 MUX_A NO_PULL_UP
> 			 &pioB 13 MUX_A PULL_UP >;
> 	};

I could change to use this too no problem. The only concern I have is
that is "&pioB 12" immutable for all gpio controllers?

Grepping the *.dts* files, at least exynos is using the following
for gpios:

gpios = <&gpx2 0 0 0 2>;

If we can conclude that phandle to the gpio controller instance and
the register offset is always enough here, then I'm OK changing to
that format. It would actually save some parsing in most cases.
 
> 	/* and also the notion of linked group
> 	 * as on uart of network you have often the same subset of pin use.
> 	 *
> 	 * As example on uart rxd/txd is use for the group without rts/cts
> 	 * and the one with it
> 	 * on ethernet the RMII pin are use also on MII
> 	 */
> 
> 	uart0_rxd_txd {
> 		pins = < &pioB 19 MUX_A PULL_UP		/* rxd */
> 			 &pioB 18 MUX_A NO_PULL_UP >;	/* txd */
> 	};
> 
> 	uart0_rts_cts {
> 		groups = < &uart0_rxd_txd >;
> 		pins = < &pioB 17 MUX_B NO_PULL_UP	/* rts */
> 			 &pioB 15 MUX_B NO_PULL_UP >;	/* cts */
> 	};
> 
> 	uart0_rts_cts_external_pull_up {
> 		groups = < &uart0_rts_cts >;
> 		gpios = <&pioC 1 0>;
> 	};
> };
> 
> The idea is to avoid duplication the xlate for pins will be driver specific
> with maybe a common implementation
> 
> the 3 or 4 first fix as done on gpio

Yeah sounds doable to me, but can probably be added later?

Regarding grouping, basically for most cases it makes sense to have
three states: default, active, idle instead of just active and idle.
The reason is that for most cases the default pins only need to be
set once for each devices. Only few pins need to toggle between
active and idle states.

For example, omap2 uart needs to toggle rx pin to gpio input everytime
it hits idle to provide wake-up events. Other pins do not need to change.
As this is done all the time, the active and idle toggling should be kept
to minimum.

Regards,

Tony

  reply	other threads:[~2012-05-04 16:34 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 [this message]
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
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=20120504163420.GA5613@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).