From: Shawn Guo <shawn.guo@linaro.org>
To: Stephen Warren <swarren@nvidia.com>
Cc: Richard Zhao <richard.zhao@linaro.org>,
"linus.walleij@stericsson.com" <linus.walleij@stericsson.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"Simon Glass (sjg@chromium.org)" <sjg@chromium.org>,
"cjb@laptop.org" <cjb@laptop.org>,
Dong Aisheng-B29396 <B29396@freescale.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Dong Aisheng <dongas86@gmail.com>
Subject: Re: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings
Date: Thu, 12 Jan 2012 07:56:36 +0800 [thread overview]
Message-ID: <20120111235634.GG20968@S2101-09.ap.freescale.net> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF177EE3A6FB@HQMAIL01.nvidia.com>
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.
Regards,
Shawn
> 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.
next prev parent reply other threads:[~2012-01-11 23:45 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 17:40 [RFC PATCH v3 0/5] pinctrl: imx: add pinnmux support Dong Aisheng
2011-12-20 17:40 ` [RFC PATCH v3 1/5] dt: add of_get_child_count helper function Dong Aisheng
2011-12-20 18:35 ` Rob Herring
2011-12-21 2:56 ` Dong Aisheng-B29396
2012-01-01 13:58 ` Linus Walleij
2011-12-20 19:47 ` Marek Vasut
2011-12-21 3:27 ` Dong Aisheng-B29396
2011-12-21 6:05 ` Lothar Waßmann
2011-12-20 23:58 ` Stephen Warren
2011-12-21 3:18 ` Dong Aisheng-B29396
2011-12-20 17:40 ` [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings Dong Aisheng
2011-12-20 19:48 ` Marek Vasut
2011-12-21 0:39 ` Stephen Warren
2011-12-22 8:18 ` Dong Aisheng-B29396
2011-12-25 3:37 ` Stephen Warren
2011-12-27 14:41 ` Dong Aisheng-B29396
2011-12-29 2:46 ` Shawn Guo
2012-01-05 13:14 ` Dong Aisheng
2012-01-05 23:45 ` Stephen Warren
2012-01-06 6:21 ` Shawn Guo
2012-01-05 23:38 ` Stephen Warren
2012-01-06 10:51 ` Dong Aisheng-B29396
2012-01-06 17:23 ` Stephen Warren
2012-01-10 7:02 ` Dong Aisheng-B29396
2012-01-05 13:47 ` Dong Aisheng
2012-01-06 1:05 ` Stephen Warren
2012-01-06 5:27 ` Shawn Guo
2012-01-06 11:33 ` Dong Aisheng-B29396
2012-01-06 13:14 ` Shawn Guo
2012-01-06 18:03 ` Stephen Warren
2012-01-07 13:54 ` Shawn Guo
2012-01-08 12:51 ` Richard Zhao
2012-01-09 1:56 ` Shawn Guo
2012-01-09 6:18 ` Simon Glass
2012-01-10 11:30 ` Dong Aisheng-B29396
2012-01-11 19:19 ` Stephen Warren
2012-01-11 18:37 ` Stephen Warren
2012-01-11 23:56 ` Shawn Guo [this message]
2012-01-11 23:59 ` Stephen Warren
2012-01-12 4:03 ` Shawn Guo
2012-01-12 7:45 ` Dong Aisheng-B29396
2012-01-11 18:28 ` Stephen Warren
2012-01-11 18:17 ` Stephen Warren
2012-01-12 3:39 ` Shawn Guo
2012-01-12 7:40 ` Dong Aisheng-B29396
2012-01-12 20:46 ` Stephen Warren
2012-01-12 21:10 ` Stephen Warren
2012-01-13 3:46 ` Shawn Guo
2012-01-13 18:16 ` Stephen Warren
2012-01-14 1:22 ` Shawn Guo
2012-01-14 18:21 ` Dong Aisheng
2012-01-16 16:08 ` Linus Walleij
2012-01-17 2:32 ` Shawn Guo
2012-01-17 19:50 ` Stephen Warren
2012-01-18 2:30 ` Shawn Guo
2012-01-19 16:55 ` Linus Walleij
2012-01-19 19:30 ` Stephen Warren
2012-01-20 17:51 ` Linus Walleij
2012-01-10 8:21 ` Dong Aisheng-B29396
2012-01-10 13:05 ` Shawn Guo
2012-01-11 19:41 ` Stephen Warren
2012-01-11 23:01 ` Shawn Guo
2012-01-11 22:58 ` Stephen Warren
2012-01-11 20:17 ` Stephen Warren
2012-01-11 23:21 ` Shawn Guo
2012-01-12 8:36 ` Dong Aisheng-B29396
2012-01-12 20:56 ` Stephen Warren
2012-01-13 3:55 ` Shawn Guo
2012-01-13 8:07 ` Dong Aisheng-B29396
2012-01-13 13:35 ` Shawn Guo
2012-01-13 13:48 ` Linus Walleij
2012-01-13 14:23 ` Shawn Guo
2012-01-13 17:11 ` Dong Aisheng
2012-01-13 18:33 ` Stephen Warren
2012-01-14 1:10 ` Shawn Guo
2012-01-17 19:35 ` Stephen Warren
2012-01-17 19:48 ` Rob Herring
2012-01-14 17:58 ` Dong Aisheng
2012-01-17 19:44 ` Stephen Warren
2012-01-01 14:07 ` Linus Walleij
2012-01-01 15:22 ` Rob Herring
2012-01-05 13:59 ` Dong Aisheng
2011-12-20 17:40 ` [RFC PATCH v3 3/5] pinctrl: imx: add pinctrl imx driver Dong Aisheng
2011-12-20 19:50 ` Marek Vasut
2011-12-21 3:09 ` Dong Aisheng-B29396
2012-01-01 14:02 ` Linus Walleij
2012-01-08 13:05 ` Richard Zhao
2012-01-09 2:08 ` Shawn Guo
2012-01-09 2:17 ` Richard Zhao
2012-01-09 6:32 ` Shawn Guo
2012-01-10 8:38 ` Richard Zhao
2012-01-10 10:43 ` Linus Walleij
2012-01-10 10:55 ` Dong Aisheng-B29396
2012-01-10 13:51 ` Shawn Guo
2012-01-11 9:28 ` Linus Walleij
2011-12-20 17:40 ` [RFC PATCH v3 4/5] ARM: imx6q: using pinmux subsystem Dong Aisheng
2011-12-20 17:40 ` [RFC PATCH v3 5/5] mmc: sdhci-esdhc-imx: " Dong Aisheng
2012-01-01 13:54 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120111235634.GG20968@S2101-09.ap.freescale.net \
--to=shawn.guo@linaro.org \
--cc=B29396@freescale.com \
--cc=cjb@laptop.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dongas86@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.zhao@linaro.org \
--cc=rob.herring@calxeda.com \
--cc=s.hauer@pengutronix.de \
--cc=sjg@chromium.org \
--cc=swarren@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).