Thread (98 messages) 98 messages, 13 authors, 2012-01-20

[RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings

From: Stephen Warren <hidden>
Date: 2012-01-11 18:29:04
Also in: linux-devicetree, lkml

Richard Zhao wrote at Sunday, January 08, 2012 5:52 AM:
On Sat, Jan 07, 2012 at 09:54:48PM +0800, Shawn Guo wrote:
quoted
On Fri, Jan 06, 2012 at 10:03:07AM -0800, Stephen Warren wrote:
...
quoted
quoted
Without separate nodes, there will eventually be a lot of duplication.
A made-up example of the same uart4grp allowing either of two functions
uart3, uart4 to be muxed out onto it:

aips-bus at 02000000 { /* AIPS1 */
	iomuxc at 020e0000 {
		pinctrl_uart4_3: uart4 at option_3 {
			func-name = "uart3";
			grp-name = "uart4grp";
			grp-pins = <107 108>;
			num-pins = <2>;
			grp-mux = <3 3>;
			num-mux = <2>;
		};
		pinctrl_uart4_4: uart4 at option_4 {
			func-name = "uart4";
			grp-name = "uart4grp";
			grp-pins = <107 108>;
			num-pins = <2>;
			grp-mux = <3 3>;
			num-mux = <2>;
		};
	}
};

Now I understand that initially you aren't going to type out the complete
list of every available option into imx6q.dtsi because it's probably huge,
but the binding does need to allow you to do so without duplicating a lot
of data, because eventually you'll get boards that use a larger and larger
subset of all the options, so the number you need to represent at once in
imx6q.dtsi will grow.
If we don't want to lose flexibity, the pin group number will be huge
than you think. For example, 16bit display interface, has two alternatives
for every pin. The group number will be 2^16.
I originally misunderstood IMX HW; I though the HW muxed at a group-of-
pins level (as Tegra does), but actually it's muxing at a per-pin level,
hence some of what I wrote may have been confusing to people familiar
with how IMX HW really works.

So yes, I definitely agree that representing all possible mux combinations
(combinations of pins in use and the mux function selected for them) could
be extremely large and we don't want to enumerate /that/ list anywhere; in
.dts files or in the pinctrl driver.

So, as a result of that, and as I mentioned in my immediately previous
email, I don't think those two nodes "uart4 at option_3", "uart4 at option_4"
should be in the SoC .dtsi file.

Later you wrote:
group and function are one-to-one mapped for imx. So if you put function
in board dts, why not put pin group there too?
I agree, I think: Everything that defines the board-specific usage of
the pinmux should be part of the board's .dtsi file, not the SoC's .dtsi
file.

-- 
nvpublic
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help