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

[Stephen Warren]

Richard Zhao wrote at Sunday, January 08, 2012 5:52 AM:
> On Sat, Jan 07, 2012 at 09:54:48PM +0800, Shawn Guo wrote:
> > On Fri, Jan 06, 2012 at 10:03:07AM -0800, Stephen Warren wrote:
...
> > > 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