linux-kernel - Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120504163420.GA5613@atomide.com>
Date:	Fri, 4 May 2012 09:34:20 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-omap@...r.kernel.org, Stephen Warren <swarren@...dia.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that
 supports omap2+ padconf

* Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.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@...ff800 {
> 		compatible = "atmel,at91rm9200-gpio";
> 		reg = <0xfffff800 0x100>;
> 		interrupts = <5 4>;
> 		#gpio-cells = <2>;
> 		gpio-controller;
> 		interrupt-controller;
> 	};
> 
> 	pioE: gpio@...ffa00 {
> 		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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/