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

[Stephen Warren]

Shawn Guo wrote at Sunday, January 08, 2012 6:56 PM:
> On Sun, Jan 08, 2012 at 08:51:59PM +0800, Richard Zhao wrote:
> ...
> > > > So, this does appear to be conflating the two things: The definition of
> > > > what pins are in a pingroup, and the mux function for a particular
> > > > setting of that pingroup. I think you need separate nodes for this.
> > > >
> > > At least for imx, we do not have mux function setting for pingroup.
> > > Instead, it only applies to individual pin.
> > I think it depends on function definition of pinmux driver. For the
> > imx example patch, it's one-to-one.
> 
> It should depend on particular imx soc pinmux design rather than
> pinmux driver.  If it's always one-to-one case, we do not need
> pinmux at all.  Aisheng's patch just did not enumerate all the groups
> for given function.  Instead, it puts a couple simple examples there
> for demonstration.
> 
> ...
> 
> > > > 		uart4func: func at 1 {
> > > > 			func-name = "uart4";
> > > > 			locations = <&bargrp &bazgrp>;
> > > > 			mux-value = <6 3>;
> > > > 		};
> > >
> > > I prefer to have function node defined in <board>.dtsi, since it's
> > > all about defining phandle to the correct pingroup, which should be
> > > decided by board design.
> > group and function are one-to-one mapped for imx.
> 
> Again, it's not the case.
> 
> > So if you put function
> > in board dts, why not put pin group there too?
> 
> If we put pingroup data in <board>.dts, the data will be likely get
> duplicated a lot in different board dts files.  For example, if
> imx6q-sabrelite chooses the same pingroup for usdhc3 and usdhc4 as
> imx6q-arm2, the pingroup data will be duplicated between imx6q-arm2.dts
> and imx6q-sabrelite.dts.
> 
> On the contrary, putting pingroup data in <soc>.dtsi and having function
> node in <board>.dts with phandle pointing to the correct pingroup will
> help avoid such data duplication.

Oh, when I wrote in my first mail today that I'd expand on one of my
points when responding to Richard Zhao's email, I actually meant when
responding to this email. Sorry for the confusion!

So, I don't agree with putting the "combinations" in the SoC .dtsi file,
since that could grow it into a huge file that contains a lot of nodes
that are used on some board somewhere, but typically not the "current"
board that's including it.

However, I do see that there are probably lots of common combinations
that get re-used across multiple boards, and you might want a common
place to put those definitions so they don't need to be cut/paste
everywhere.

So, why not create specific include files (.dtsi files) for each of those
combinations? Each include could define one particular common combination
of pin mux usage, or perhaps even a set of them if they're commonly used
together. Each board file would include the SoC .dtsi file, the relevant
set of "pinmux config" .dtsi files, and then include anything custom to
that board. Remember, that include files simply get merged into the device
tree, so you can easily add based definitions (like) regs for e.g. an
SDHCI controller in a SoC .dtsi file, the pinmux properties in a .dtsi
file specific to SHDCI controller 3, and then e.g. CD/WP/power GPIOs in
the final board .dts file.

Following this model, we can initially just put the pinmux config into
each board file, then factor it out into new .dtsi files as/when we see
duplication. We get to start off simple, then clean up by refactoring as
we go.

-- 
nvpublic