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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF177EE3A6FB@HQMAIL01.nvidia.com>
Date:	Wed, 11 Jan 2012 10:37:36 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Shawn Guo <shawn.guo@...aro.org>,
	Richard Zhao <richard.zhao@...aro.org>
CC:	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"Simon Glass (sjg@...omium.org)" <sjg@...omium.org>,
	"cjb@...top.org" <cjb@...top.org>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Dong Aisheng <dongas86@...il.com>
Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
 mappings

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. 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

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