From: Tony Lindgren <tony@atomide.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: "Shawn Guo (shawn.guo@linaro.org)" <shawn.guo@linaro.org>,
Dong Aisheng <dongas86@gmail.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"Linus Walleij (linus.walleij@linaro.org)"
<linus.walleij@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"Grant Likely (grant.likely@secretlab.ca)"
<grant.likely@secretlab.ca>,
Thomas Abraham <thomas.abraham@linaro.org>,
"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>,
"Sascha Hauer (s.hauer@pengutronix.de)" <s.hauer@pengutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Pinmux bindings proposal V2
Date: Fri, 27 Jan 2012 09:42:32 -0800 [thread overview]
Message-ID: <20120127174232.GK13504@atomide.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF178E123E57@HQMAIL01.nvidia.com>
* Stephen Warren <swarren@nvidia.com> [120127 09:05]:
> Tony Lindgren wrote at Thursday, January 26, 2012 7:09 PM:
> ...
> > I don't think we should try to pass the different possible states from
> > device tree. The pinmux/pinconf driver should know how to deal with that,
>
> Somehow, the pinctrl driver needs to know how to implement each state. In
> general, I believe this will be board-specific.
>
> Do you disagree with this assertion?
>
> If the data is board-specific, I don't see how it can be represented
> anywhere but the device tree.
Agreed, for board specific things device tree is the place to put it.
> > and the driver using the mux should be able to communicate what it wants
> > to the pinmux/pinconf driver. If people really want to be able to pass
> > alternative mux states from device tree, they should be standard bindings
> > for things like active/idle/suspend/off.
>
> As I've mentioned before, people have asked for driver-specific states to
> handle the case where e.g. drive strength must be adjusted based on clock
> rates of the interface. Again, I believe that's board-specific data since
> the actual values to use may be derived during board calibration, not
> SoC design.
>
> Do you disagree that this data may be board specific?
Right, but for the dynamic mux cases I've seen the alternative states
are usually specific to the driver using the mux. That's why I'm
suspicious of the board specific custom alternative states :)
Anyways, do you think the pinctrl-static + pinctrl-dynamic binding
I just posted as a reply to Simon's email would work for you?
Regards,
Tony
next prev parent reply other threads:[~2012-01-27 17:42 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 22:22 Pinmux bindings proposal V2 Stephen Warren
2012-01-23 21:00 ` Tony Lindgren
2012-01-23 23:08 ` Stephen Warren
2012-01-24 1:20 ` Tony Lindgren
2012-01-24 22:29 ` Stephen Warren
2012-01-25 0:04 ` Tony Lindgren
2012-01-26 19:33 ` Stephen Warren
2012-01-27 2:08 ` Tony Lindgren
2012-01-27 6:57 ` Shawn Guo
2012-01-27 17:05 ` Tony Lindgren
2012-01-30 1:56 ` Shawn Guo
2012-01-30 17:20 ` Tony Lindgren
2012-01-31 1:32 ` Shawn Guo
2012-01-31 2:29 ` Tony Lindgren
2012-02-01 5:36 ` Shawn Guo
2012-01-27 17:36 ` Stephen Warren
2012-01-27 17:42 ` Tony Lindgren [this message]
2012-01-26 9:36 ` Shawn Guo
2012-01-26 17:51 ` Tony Lindgren
2012-01-27 7:19 ` Shawn Guo
2012-01-27 17:16 ` Tony Lindgren
2012-01-30 2:10 ` Shawn Guo
2012-01-30 17:43 ` Tony Lindgren
2012-01-31 1:07 ` Shawn Guo
2012-01-26 9:24 ` Shawn Guo
2012-01-26 17:42 ` Simon Glass
2012-01-27 2:21 ` Tony Lindgren
2012-01-27 15:43 ` Simon Glass
2012-01-27 17:37 ` Tony Lindgren
2012-01-27 17:51 ` Stephen Warren
2012-01-27 18:10 ` Tony Lindgren
2012-01-30 3:27 ` Shawn Guo
2012-01-30 3:13 ` Shawn Guo
2012-01-30 17:49 ` Tony Lindgren
2012-01-27 17:38 ` Stephen Warren
2012-01-27 17:29 ` Stephen Warren
2012-01-30 2:31 ` Shawn Guo
2012-02-01 14:35 ` Shawn Guo
2012-02-02 18:36 ` Stephen Warren
2012-02-02 20:07 ` Dong Aisheng
2012-02-03 14:02 ` Shawn Guo
2012-02-03 17:21 ` Dong Aisheng
2012-02-03 17:32 ` Tony Lindgren
2012-02-03 18:13 ` Dong Aisheng
2012-02-03 21:05 ` Tony Lindgren
2012-02-04 16:55 ` Dong Aisheng
2012-02-04 17:15 ` Tony Lindgren
2012-02-03 8:46 ` Shawn Guo
2012-02-13 19:58 ` Stephen Warren
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=20120127174232.GK13504@atomide.com \
--to=tony@atomide.com \
--cc=B29396@freescale.com \
--cc=cjb@laptop.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dongas86@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=kernel@pengutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=s.hauer@pengutronix.de \
--cc=shawn.guo@linaro.org \
--cc=sjg@chromium.org \
--cc=swarren@nvidia.com \
--cc=thomas.abraham@linaro.org \
/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).