Shawn Guo wrote at Sunday, January 08, 2012 6:56 PM:

On Sun, Jan 08, 2012 at 08:51:59PM +0800, Richard Zhao wrote:
...

quoted

quoted

quoted

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.

...

quoted

quoted

quoted

		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.

quoted

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