RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmuxmappings

[Stephen Warren]

Shawn Guo wrote at Wednesday, January 11, 2012 4:57 PM:
> On Wed, Jan 11, 2012 at 10:37:36AM -0800, Stephen Warren wrote:
> > 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@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.
> 
> This is somehow overkilled to me.  Doing this will create a big mount
> of .dtsi files to bloat folder arch/arm/boot/dts.  Putting the
> 'combinations' in <soc>.dtsi seems perfect fine to me.

I see a couple problems with that approach:

1) <soc>.dtsi gets very bloated, and wastes space containing board-
specific data for boards other than the "current" one.

2) We need to invent some more complex DT format so you can reference
these canned combinations from the device drivers, rather than simply
enumerating the mux value for each pin/group.

You could put the combination .dtsi files in arch/arm/boot/dts/<soc> to
maintain some extra order.

-- 
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/