From: Shawn Guo <shawn.guo@linaro.org>
To: Stephen Warren <swarren@nvidia.com>
Cc: Dong Aisheng-B29396 <B29396@freescale.com>,
Dong Aisheng <dongas86@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linus.walleij@stericsson.com" <linus.walleij@stericsson.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"cjb@laptop.org" <cjb@laptop.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"Simon Glass (sjg@chromium.org)" <sjg@chromium.org>,
Richard Zhao <richard.zhao@linaro.org>
Subject: Re: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings
Date: Sat, 14 Jan 2012 09:22:15 +0800 [thread overview]
Message-ID: <20120114012213.GD1810@S2101-09.ap.freescale.net> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF17801D1F9D@HQMAIL01.nvidia.com>
On Fri, Jan 13, 2012 at 10:16:36AM -0800, Stephen Warren wrote:
...
> For reference, that message is:
>
> Linusw wrote:
> > On Mon, Dec 5, 2011 at 3:43 AM, Dong Aisheng <dongas86 <at> gmail.com> wrote:
> > > My current plan is to define all (might be frequently) used functoin
> > > and groups for the exist upstreamed board like 53 Loco and etc, is
> > > that ok?
> >
> > Yes, but do it in respective board file, so if we say, one day
> > stops to support a certain board we can just delete that board
> > file and be done with it.
> >
> > Plus this gives us a nice separation as we move toward
> > device trees. (I think.)
>
> My interpretation of what Dong wrote there is "I'm only going to define
> the functions and groups that are actually in use by upstream boards,
> not everything the SoC supports". However, your (Shawn's) references to
> the email, it sounds like you're interpreting what Dong wrong as "I'm
> going to define some virtual groups that don't exist in HW but represent
> common use-cases of the HW".
>
Then what does the word 'groups' in Dong's sentence means with your
understanding, considering there is no HW level pingroup on imx?
> Admittedly, the wording of Linusw's actually seems to agree more with how
> you're interpreting what Dong said, but in that case, I don't think his
> reply makes sense - the whole purpose of the mux mapping table is to
> represent the board-specific configuration. If we're going to circumvent
> it, we should completely remove it from the pinctrl subsystem, rather than
> having some boards avoid using it by creating virtual pin groups instead.
>
IMO, it's a compromise. It still makes sense to have concept of
pingroup in pinctrl subsystem, because platforms like Tegra have
the HW pingroup.
> > > > For imx6q example, we have 193 pins as the muxable entities, and for
> > > > each of those pin, there are 8 alternative functions. Let's see what
> > > > we will have if we enumerate all the available functions for each pin.
> ...
> > > > We simply do not want to over bloat imx6q pinctrl driver with such
> > > > enumeration.
> > >
> > > Yes, I see you'd end up with a huge number of function definitions here.
> > >
> > > You may be able to avoid this by changing the way you name/number the
> > > functions though.
> > >
> > > The example above has a unique function name for every individual signal.
> > > instead, can you name functions based on the controller they connect to?
> > >
> > > So, instead of having:
> > >
> > > IMX6Q_PAD_SD2_DAT1__USDHC2_DAT1
> > > IMX6Q_PAD_SD2_DAT2__USDHC2_DAT2
> > > IMX6Q_PAD_SD2_DAT3__USDHC2_DAT3
> > > IMX6Q_PAD_SD2_DAT4__USDHC2_DAT4
> > >
> > > Can you replace this with a single:
> > >
> > > IMX_FUNC_USDHC2
> >
> > So all 'enum imx6q_pad_*' goes away, and instead, we define macros
> > IMX_FUNC_* at controller basis, correct?
>
> Yes, something like that. The best set to choose probably differs based
> on the SoC and its mux capabilities. But thinking more, if you're going
> along this kind of route, I'd prefer to just define the "func0", "func1",
> ... "func7" functions that represent the raw HW selection instead.
>
In this case, I do not see any point to define them, since it does not
make too much difference than integer 0, 1, ..., 7.
--
Regards,
Shawn
next prev parent reply other threads:[~2012-01-14 1:11 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
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 [this message]
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=20120114012213.GD1810@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).