All of lore.kernel.org
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: Pinmux bindings proposal
Date: Thu, 19 Jan 2012 02:57:28 -0800	[thread overview]
Message-ID: <20120119105728.GE22818@atomide.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF1780DAAEBB@HQMAIL01.nvidia.com>

* Stephen Warren <swarren@nvidia.com> [120118 11:29]:
> Tony Lindgren wrote at Wednesday, January 18, 2012 7:13 AM:
> 
> I'd prefer not to do that for my platforms, for the reason Shawn points
> out in his reply to yours.
> 
> However, I believe the bindings I proposed are flexible enough to allow
> you to do exactly this for your platforms without requiring that everyone
> do it.

Well I can easily use one phandle per pinmux controller instance
instead of one phandle per pin, so let's plan on doing that.
 
> Recall my proposal was:

Yes I think that's pretty close to what I'm using, just few
minor comments below.
 
> pmx_sdhci_standby: pinctrl at 0 {
>     /* Format is <&pmx_controller_phandle muxable_entity_id
>      * selected_function>.
>      */
>     mux =
>         <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
>         <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>;

Assuming this is describing the pins a driver is using, how
about calling it pins?

That's because you might want to do all the muxing in a
bootloader, but still need to tell how many pins you're using
for MMC on a device. So it actually has a wider meaning than just
mux.

Also, we need to standardize on some name to use for parsing pins
using of_parse_phandle_with_args, and I suggested #pin-args.

>     config =
>         <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_TRISTATE 1>
>         <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_TRISTATE 1>
>         <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
>         <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
>         <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
>         <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
> };

Here I don't quite understand how config is different from pins/mux
above? It seems to set the driver/pull stuff, but why don't you
just make #pin-args larger and have a wider pin array?

Something like:

	pins =
	<&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1 TEGRA_PMX_CONF_TRISTATE 1
	 &tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1 TEGRA_PMX_CONF_TRISTATE 1>;

and in the parent set #pin-args to 3.
 
> (Note that I think we've agreed to remove the first cell above, &tegra_pmx,
> now by requiring such nodes exist as children of the pin controller.)

Sorry I don't quite follow, can you please maybe repost a complete
.dts entry for your pin controller and one driver entry?
 
> My assertion is that the common pinmux bindings define that the
> Interpretation of muxable_entity_id is left up to the binding of the
> specific pin controller. Hence, I can says "it's an integer, and here
> is the list of valid values and what they mean", and you can say "it's
> a phandle, which must refer to one of the per-pin nodes defined by the
> pin controller".
> 
> Does that work for you?

Yes it does, other than the comments above.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Dong Aisheng-B29396 <B29396@freescale.com>,
	"linus.walleij@stericsson.com" <linus.walleij@stericsson.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"cjb@laptop.org" <cjb@laptop.org>,
	"Simon Glass (sjg@chromium.org)" <sjg@chromium.org>,
	Dong Aisheng <dongas86@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>
Subject: Re: Pinmux bindings proposal
Date: Thu, 19 Jan 2012 02:57:28 -0800	[thread overview]
Message-ID: <20120119105728.GE22818@atomide.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF1780DAAEBB@HQMAIL01.nvidia.com>

* Stephen Warren <swarren@nvidia.com> [120118 11:29]:
> Tony Lindgren wrote at Wednesday, January 18, 2012 7:13 AM:
> 
> I'd prefer not to do that for my platforms, for the reason Shawn points
> out in his reply to yours.
> 
> However, I believe the bindings I proposed are flexible enough to allow
> you to do exactly this for your platforms without requiring that everyone
> do it.

Well I can easily use one phandle per pinmux controller instance
instead of one phandle per pin, so let's plan on doing that.
 
> Recall my proposal was:

Yes I think that's pretty close to what I'm using, just few
minor comments below.
 
> pmx_sdhci_standby: pinctrl@0 {
>     /* Format is <&pmx_controller_phandle muxable_entity_id
>      * selected_function>.
>      */
>     mux =
>         <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
>         <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>;

Assuming this is describing the pins a driver is using, how
about calling it pins?

That's because you might want to do all the muxing in a
bootloader, but still need to tell how many pins you're using
for MMC on a device. So it actually has a wider meaning than just
mux.

Also, we need to standardize on some name to use for parsing pins
using of_parse_phandle_with_args, and I suggested #pin-args.

>     config =
>         <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_TRISTATE 1>
>         <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_TRISTATE 1>
>         <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
>         <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
>         <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
>         <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
> };

Here I don't quite understand how config is different from pins/mux
above? It seems to set the driver/pull stuff, but why don't you
just make #pin-args larger and have a wider pin array?

Something like:

	pins =
	<&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1 TEGRA_PMX_CONF_TRISTATE 1
	 &tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1 TEGRA_PMX_CONF_TRISTATE 1>;

and in the parent set #pin-args to 3.
 
> (Note that I think we've agreed to remove the first cell above, &tegra_pmx,
> now by requiring such nodes exist as children of the pin controller.)

Sorry I don't quite follow, can you please maybe repost a complete
.dts entry for your pin controller and one driver entry?
 
> My assertion is that the common pinmux bindings define that the
> Interpretation of muxable_entity_id is left up to the binding of the
> specific pin controller. Hence, I can says "it's an integer, and here
> is the list of valid values and what they mean", and you can say "it's
> a phandle, which must refer to one of the per-pin nodes defined by the
> pin controller".
> 
> Does that work for you?

Yes it does, other than the comments above.

Regards,

Tony

  reply	other threads:[~2012-01-19 10:57 UTC|newest]

Thread overview: 132+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-13 20:39 Pinmux bindings proposal Stephen Warren
2012-01-13 20:39 ` Stephen Warren
2012-01-14  7:09 ` Shawn Guo
2012-01-14  7:09   ` Shawn Guo
2012-01-17 18:47   ` Stephen Warren
2012-01-17 18:47     ` Stephen Warren
2012-01-18  3:32     ` Shawn Guo
2012-01-18  3:32       ` Shawn Guo
2012-01-18 19:00       ` Stephen Warren
2012-01-18 19:00         ` Stephen Warren
2012-01-16 12:50 ` Dong Aisheng-B29396
2012-01-16 12:50   ` Dong Aisheng-B29396
2012-01-17  8:23   ` Shawn Guo
2012-01-17  8:23     ` Shawn Guo
2012-01-17  8:23     ` Shawn Guo
2012-01-17  9:46     ` Dong Aisheng-B29396
2012-01-17  9:46       ` Dong Aisheng-B29396
2012-01-17  9:46       ` Dong Aisheng-B29396
2012-01-17 14:13       ` Shawn Guo
2012-01-17 14:13         ` Shawn Guo
2012-01-17 19:32         ` Stephen Warren
2012-01-17 19:32           ` Stephen Warren
2012-01-18  3:44         ` Dong Aisheng-B29396
2012-01-18  3:44           ` Dong Aisheng-B29396
2012-01-18  3:44           ` Dong Aisheng-B29396
2012-01-18  4:47           ` Shawn Guo
2012-01-18  4:47             ` Shawn Guo
2012-01-18  4:47             ` Shawn Guo
2012-01-18 19:24           ` Stephen Warren
2012-01-18 19:24             ` Stephen Warren
2012-01-17 19:28       ` Stephen Warren
2012-01-17 19:28         ` Stephen Warren
2012-01-18 11:06         ` Dong Aisheng-B29396
2012-01-18 11:06           ` Dong Aisheng-B29396
2012-01-20 20:28           ` Stephen Warren
2012-01-20 20:28             ` Stephen Warren
2012-01-20 20:28             ` Stephen Warren
2012-01-27 12:00             ` Linus Walleij
2012-01-27 12:00               ` Linus Walleij
2012-01-27 12:00               ` Linus Walleij
2012-01-27 16:58               ` Stephen Warren
2012-01-27 16:58                 ` Stephen Warren
2012-01-17 19:21     ` Stephen Warren
2012-01-17 19:21       ` Stephen Warren
2012-01-18  4:01       ` Shawn Guo
2012-01-18  4:01         ` Shawn Guo
2012-01-18  4:01         ` Shawn Guo
2012-01-18  9:32       ` Dong Aisheng-B29396
2012-01-18  9:32         ` Dong Aisheng-B29396
2012-01-18  9:32         ` Dong Aisheng-B29396
2012-01-17 19:09   ` Stephen Warren
2012-01-17 19:09     ` Stephen Warren
2012-01-18  7:24     ` Dong Aisheng-B29396
2012-01-18  7:24       ` Dong Aisheng-B29396
2012-01-18  7:24       ` Dong Aisheng-B29396
2012-01-18 19:42       ` Stephen Warren
2012-01-18 19:42         ` Stephen Warren
2012-01-18 19:42         ` Stephen Warren
2012-01-16 18:28 ` Grant Likely
2012-01-16 18:28   ` Grant Likely
2012-01-18 14:13   ` Tony Lindgren
2012-01-18 14:13     ` Tony Lindgren
2012-01-18 14:13     ` Tony Lindgren
2012-01-18 14:30     ` Shawn Guo
2012-01-18 14:30       ` Shawn Guo
2012-01-18 15:32       ` Tony Lindgren
2012-01-18 15:32         ` Tony Lindgren
2012-01-18 16:29         ` Tony Lindgren
2012-01-18 16:29           ` Tony Lindgren
2012-01-18 16:29           ` Tony Lindgren
2012-01-18 20:22           ` Grant Likely
2012-01-18 20:22             ` Grant Likely
2012-01-18 20:22             ` Grant Likely
2012-01-18 20:20         ` Grant Likely
2012-01-18 20:20           ` Grant Likely
2012-01-18 20:20           ` Grant Likely
2012-01-19 10:31           ` Tony Lindgren
2012-01-19 10:31             ` Tony Lindgren
2012-01-19 10:31             ` Tony Lindgren
2012-01-18 20:02     ` Stephen Warren
2012-01-18 20:02       ` Stephen Warren
2012-01-19 10:57       ` Tony Lindgren [this message]
2012-01-19 10:57         ` Tony Lindgren
2012-01-20 20:50         ` Stephen Warren
2012-01-20 20:50           ` Stephen Warren
2012-01-23 20:13           ` Tony Lindgren
2012-01-23 20:13             ` Tony Lindgren
2012-01-23 22:54             ` Stephen Warren
2012-01-23 22:54               ` Stephen Warren
2012-01-23 22:54               ` Stephen Warren
2012-01-27 13:11           ` Linus Walleij
2012-01-27 13:11             ` Linus Walleij
2012-01-18 12:16 ` Thomas Abraham
2012-01-18 12:16   ` Thomas Abraham
2012-01-18 19:52   ` Stephen Warren
2012-01-18 19:52     ` Stephen Warren
2012-01-19 17:01     ` Tony Lindgren
2012-01-19 17:01       ` Tony Lindgren
2012-01-19 17:01       ` Tony Lindgren
2012-01-19 13:10 ` Thomas Abraham
2012-01-19 13:10   ` Thomas Abraham
2012-01-19 13:10   ` Thomas Abraham
2012-01-19 16:56   ` Tony Lindgren
2012-01-19 16:56     ` Tony Lindgren
2012-01-19 17:38     ` Thomas Abraham
2012-01-19 17:38       ` Thomas Abraham
2012-01-19 17:38       ` Thomas Abraham
2012-01-19 18:20       ` Tony Lindgren
2012-01-19 18:20         ` Tony Lindgren
2012-01-19 18:20         ` Tony Lindgren
2012-01-19 18:38         ` Thomas Abraham
2012-01-19 18:38           ` Thomas Abraham
2012-01-20 10:05           ` Tony Lindgren
2012-01-20 10:05             ` Tony Lindgren
2012-01-20 16:17             ` Thomas Abraham
2012-01-20 16:17               ` Thomas Abraham
2012-01-20 16:17               ` Thomas Abraham
2012-01-20 17:53               ` Tony Lindgren
2012-01-20 17:53                 ` Tony Lindgren
2012-01-21  1:38                 ` Thomas Abraham
2012-01-21  1:38                   ` Thomas Abraham
2012-01-21  1:38                   ` Thomas Abraham
2012-01-20 21:15     ` Stephen Warren
2012-01-20 21:15       ` Stephen Warren
2012-01-20 21:15       ` Stephen Warren
2012-01-20 21:11   ` Stephen Warren
2012-01-20 21:11     ` Stephen Warren
2012-01-20 21:11     ` Stephen Warren
2012-01-21  1:27     ` Thomas Abraham
2012-01-21  1:27       ` Thomas Abraham
2012-01-23 22:43       ` Stephen Warren
2012-01-23 22:43         ` 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=20120119105728.GE22818@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.