[RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Stephen Warren]

v2:
* Enhanced pinmux code to handle "drive pingroups" as well as "mux
  pingroups". This altered the pinmux binding a little; shifting each
  type of pingroup into a sub-node in the pinmux node.
* Enumerate pingroups by enumerating DT child nodes, and mapping them to
  pingroups, rather than the other way around. Hence also removed
  modifications to <linux/of.h> and drivers/of/base.c.
* Included documentation of the bindings.
* Represent pingroup names and function names, as lower case in DT.
* Used a better name for GPIO binding GPIO list.
* Switched to boolean properties for pinmux pull-up/down.
* s/dev_err/dev_dbg/ in DT parsing debug code.
* Various minor cleanups (e.g. typos, white-space).

This patch modifies Tegra's device tree support to remove the dependency
on harmony_pinmux_init(), thus making it completely board-independent.

Some notes:

* This series is built on top of linux-next with a bunch of patches
  applied, in particular the removal of irq_to_gpio and custom gpio_to_irq
  that I'm in the process of sending to Russell. I haven't yet thought
  through how/where to merge this without causing all kinds of conflicts.

* I took care to preserve bisectability of Tegra DT support. However,
  linux-next doesn't yet have entirely useful Tegra DT support; some stuff
  from Grant's devicetree/next hasn't been pushed into linux-next yet. If
  we don't care about bisectability, I can remove a couple commits and
  possibly squash some others.

* The approach taken here is to have a custom semantic SoC-specific
  binding for each the gpio and pinmux drivers. Other alternatives
  suggested included:

  1) A generic "list of register writes" to be performed at boot. This has
     the advantage of reusability across different SoCs. However, this
     approach isn't semantic, and requires detailed knowledge of pinmux
     registers and potentially fiddly calculations when constructing the
     device tree.

  2) The ability to define disabled child nodes of the pinmux controller
     that are not processed by tegra_pinmux_probe_dt(). Other devices may
     refer to those using phandles, and later enable/disable them, thus
     representing dynamic pinmuxing in the device tree. I wasn't convinced
     whether we should represent dynamic pinmuxing using phandles.

  I discussed in more detail why I prefer the current proposal in various
  email threads.

Thanks for reading!

Stephen Warren (13):
  arm/tegra: Prep boards for gpio/pinmux conversion to pdevs
  arm/tegra: Avoid duplicate gpio/pinmux devices with dt
  arm/tegra: board-dt: Add AUXDATA for tegra-gpio and tegra-pinmux
  docs/dt: Document nvidia,tegra20-gpio's nvidia,enabled-gpios property
  arm/dt: Tegra: Add nvidia,gpios property to GPIO controller
  docs/dt: Document nvidia,tegra20-pinmux binding
  arm/dt: Tegra: Add pinmux node
  gpio/tegra: Convert to a platform device
  gpio/tegra: Add device tree support
  arm/tegra: Convert pinmux driver to a platform device
  arm/tegra: Add device tree support to pinmux driver
  arm/tegra: board-dt: Remove dependency on non-dt pinmux functions
  arm/tegra: Remove temporary gpio/pinmux registration workaround

 .../devicetree/bindings/gpio/gpio_nvidia.txt       |   20 +
 .../devicetree/bindings/pinmux/pinmux_nvidia.txt   |  294 ++++++++++++
 arch/arm/boot/dts/tegra-harmony.dts                |  483 ++++++++++++++++++++
 arch/arm/boot/dts/tegra-seaboard.dts               |  421 +++++++++++++++++
 arch/arm/boot/dts/tegra20.dtsi                     |    5 +
 arch/arm/mach-tegra/Makefile                       |    1 -
 arch/arm/mach-tegra/board-dt.c                     |   12 +-
 arch/arm/mach-tegra/board-harmony-pinmux.c         |    8 +
 arch/arm/mach-tegra/board-paz00-pinmux.c           |    8 +
 arch/arm/mach-tegra/board-seaboard-pinmux.c        |    9 +-
 arch/arm/mach-tegra/board-trimslice-pinmux.c       |    7 +
 arch/arm/mach-tegra/devices.c                      |   10 +
 arch/arm/mach-tegra/devices.h                      |    2 +
 arch/arm/mach-tegra/pinmux.c                       |  269 +++++++++++
 drivers/gpio/gpio-tegra.c                          |   57 ++-
 15 files changed, 1582 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt

[RFC PATCH v2 02/13] arm/tegra: Avoid duplicate gpio/pinmux devices with dt

[Stephen Warren]

A future change will set up gpio and pinmux platform device registration
in device-tree files, via board-dt.c. When board-dt.c calls into
harmony/seaboard_pinmux_init(), this will cause a duplicate registration
of those platform devices, which will cause kernel boot failure.

To solve this, modify harmony/seaboard_pinmux_init() so that they only
register the platform devices when actually running on Harmony/Seaboard;
when board-dt.c is in use, a different machine type is used.

This change is a temporary measure to ensure git bisectability. It will
be reverted when board-dt.c no longer calls harmony/seaboard_pinmux_init().

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/mach-tegra/board-harmony-pinmux.c  |    5 ++++-
 arch/arm/mach-tegra/board-seaboard-pinmux.c |    5 ++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-tegra/board-harmony-pinmux.c b/arch/arm/mach-tegra/board-harmony-pinmux.c
index e99b456..130018d 100644
--- a/arch/arm/mach-tegra/board-harmony-pinmux.c
+++ b/arch/arm/mach-tegra/board-harmony-pinmux.c
@@ -14,6 +14,8 @@
  *
  */
 
+#include <asm/mach-types.h>
+
 #include <linux/kernel.h>
 #include <linux/gpio.h>
 #include <mach/pinmux.h>
@@ -161,7 +163,8 @@ static struct tegra_gpio_table gpio_table[] = {
 
 void harmony_pinmux_init(void)
 {
-	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
+	if (machine_is_harmony())
+		platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
 
 	tegra_pinmux_config_table(harmony_pinmux, ARRAY_SIZE(harmony_pinmux));
 
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index f092298..bc4dc17 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -12,6 +12,8 @@
  *
  */
 
+#include <asm/mach-types.h>
+
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/gpio.h>
@@ -176,7 +178,8 @@ static struct tegra_gpio_table gpio_table[] = {
 
 void __init seaboard_pinmux_init(void)
 {
-	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
+	if (machine_is_seaboard())
+		platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
 
 	tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
 
-- 
1.7.0.4

RE: [RFC PATCH v2 02/13] arm/tegra: Avoid duplicate gpio/pinmux devices with dt

[Stephen Warren]

Stephen Warren wrote at Monday, August 15, 2011 2:28 PM:
> A future change will set up gpio and pinmux platform device registration
> in device-tree files, via board-dt.c. When board-dt.c calls into
> harmony/seaboard_pinmux_init(), this will cause a duplicate registration
> of those platform devices, which will cause kernel boot failure.

It looks like this patch, and the subsequent revert, aren't actually needed.

The boot failure I saw earlier was actually due to the pinmux driver crashing
if pdev->dev.of_node==NULL during probe.

With that fixed, with this patch series as is, there are then warnings due
to tegra-gpio and tegra-pinmux each being registered twice, due to the
following patch setting up AUXDATA and causing the device-tree-registered
and platform-device-registered devices to have the same name.

However, I'm dropping the AUXDATA patch, so that issue doesn't occur.

And hence, I will drop this patch, and its subsequent revert. This will
cause the GPIO and pinmux drivers to be temporarily instantiated twice.
However, that doesn't actually cause any problems, and will be solved af
ew patches later anyway.

(Let me know if anyone thinks this patch should stay in).

> To solve this, modify harmony/seaboard_pinmux_init() so that they only
> register the platform devices when actually running on Harmony/Seaboard;
> when board-dt.c is in use, a different machine type is used.
> 
> This change is a temporary measure to ensure git bisectability. It will
> be reverted when board-dt.c no longer calls harmony/seaboard_pinmux_init().
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  arch/arm/mach-tegra/board-harmony-pinmux.c  |    5 ++++-
>  arch/arm/mach-tegra/board-seaboard-pinmux.c |    5 ++++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-tegra/board-harmony-pinmux.c b/arch/arm/mach-tegra/board-harmony-pinmux.c
> index e99b456..130018d 100644
> --- a/arch/arm/mach-tegra/board-harmony-pinmux.c
> +++ b/arch/arm/mach-tegra/board-harmony-pinmux.c
> @@ -14,6 +14,8 @@
>   *
>   */
> 
> +#include <asm/mach-types.h>
> +
>  #include <linux/kernel.h>
>  #include <linux/gpio.h>
>  #include <mach/pinmux.h>
> @@ -161,7 +163,8 @@ static struct tegra_gpio_table gpio_table[] = {
> 
>  void harmony_pinmux_init(void)
>  {
> -	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
> +	if (machine_is_harmony())
> +		platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
> 
>  	tegra_pinmux_config_table(harmony_pinmux, ARRAY_SIZE(harmony_pinmux));
> 
> diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
> index f092298..bc4dc17 100644
> --- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
> +++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
> @@ -12,6 +12,8 @@
>   *
>   */
> 
> +#include <asm/mach-types.h>
> +
>  #include <linux/kernel.h>
>  #include <linux/init.h>
>  #include <linux/gpio.h>
> @@ -176,7 +178,8 @@ static struct tegra_gpio_table gpio_table[] = {
> 
>  void __init seaboard_pinmux_init(void)
>  {
> -	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
> +	if (machine_is_seaboard())
> +		platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
> 
>  	tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
> 
> --
> 1.7.0.4

-- 
nvpublic

[RFC PATCH v2 09/13] gpio/tegra: Add device tree support

[Stephen Warren]

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 drivers/gpio/gpio-tegra.c |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 4da4839..1d0a764 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -326,6 +326,30 @@ static struct irq_chip tegra_gpio_irq_chip = {
 #endif
 };
 
+#ifdef CONFIG_OF
+static void __init tegra_gpio_probe_dt(struct platform_device *pdev)
+{
+	const __be32 *gpios;
+	u32 gpioslen;
+	int i;
+
+	gpios = of_get_property(pdev->dev.of_node, "nvidia,enabled-gpios",
+				&gpioslen);
+	if (gpios == NULL)
+		return;
+
+	gpioslen /= sizeof(*gpios);
+	for (i = 0; i < gpioslen; i++, gpios++) {
+		u32 gpio = be32_to_cpup(gpios);
+		dev_dbg(&pdev->dev, "Enabling GPIO %d\n", gpio);
+		tegra_gpio_enable(gpio);
+	}
+}
+#else
+static inline void __init tegra_gpio_probe_dt(struct platform_device *pdev)
+{
+}
+#endif
 
 /* This lock class tells lockdep that GPIO irqs are in a different
  * category than their parents, so it won't report false recursion.
@@ -371,13 +395,21 @@ static int __init tegra_gpio_probe(struct platform_device *pdev)
 			spin_lock_init(&bank->lvl_lock[j]);
 	}
 
+	tegra_gpio_probe_dt(pdev);
+
 	return 0;
 }
 
+static struct of_device_id tegra_gpio_of_match[] __devinitdata = {
+	{ .compatible = "nvidia,tegra20-gpio", },
+	{ },
+};
+
 static struct platform_driver tegra_gpio_driver = {
 	.driver		= {
 		.name	= "tegra-gpio",
 		.owner	= THIS_MODULE,
+		.of_match_table = tegra_gpio_of_match,
 	},
 	.probe		= tegra_gpio_probe,
 };
-- 
1.7.0.4

Re: [RFC PATCH v2 09/13] gpio/tegra: Add device tree support

[Shawn Guo]

On Mon, Aug 15, 2011 at 02:28:16PM -0600, Stephen Warren wrote:
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  drivers/gpio/gpio-tegra.c |   32 ++++++++++++++++++++++++++++++++
>  1 files changed, 32 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
> index 4da4839..1d0a764 100644
> --- a/drivers/gpio/gpio-tegra.c
> +++ b/drivers/gpio/gpio-tegra.c
> @@ -326,6 +326,30 @@ static struct irq_chip tegra_gpio_irq_chip = {
>  #endif
>  };
>  
> +#ifdef CONFIG_OF
> +static void __init tegra_gpio_probe_dt(struct platform_device *pdev)
> +{
> +	const __be32 *gpios;
> +	u32 gpioslen;
> +	int i;
> +
> +	gpios = of_get_property(pdev->dev.of_node, "nvidia,enabled-gpios",
> +				&gpioslen);
> +	if (gpios == NULL)
> +		return;
> +
> +	gpioslen /= sizeof(*gpios);
> +	for (i = 0; i < gpioslen; i++, gpios++) {
> +		u32 gpio = be32_to_cpup(gpios);
> +		dev_dbg(&pdev->dev, "Enabling GPIO %d\n", gpio);
> +		tegra_gpio_enable(gpio);
> +	}
> +}
> +#else
> +static inline void __init tegra_gpio_probe_dt(struct platform_device *pdev)
> +{
> +}
> +#endif
>  
With your patch below being merged, and the suggestion that
of_property_read_u32[_array] should be used to read integer from
device tree, the #ifdef thing can be removed?

  [PATCH] dt: add empty of_get_property for non-dt

Regards,
Shawn

>  /* This lock class tells lockdep that GPIO irqs are in a different
>   * category than their parents, so it won't report false recursion.
> @@ -371,13 +395,21 @@ static int __init tegra_gpio_probe(struct platform_device *pdev)
>  			spin_lock_init(&bank->lvl_lock[j]);
>  	}
>  
> +	tegra_gpio_probe_dt(pdev);
> +
>  	return 0;
>  }
>  
> +static struct of_device_id tegra_gpio_of_match[] __devinitdata = {
> +	{ .compatible = "nvidia,tegra20-gpio", },
> +	{ },
> +};
> +
>  static struct platform_driver tegra_gpio_driver = {
>  	.driver		= {
>  		.name	= "tegra-gpio",
>  		.owner	= THIS_MODULE,
> +		.of_match_table = tegra_gpio_of_match,
>  	},
>  	.probe		= tegra_gpio_probe,
>  };
> -- 
> 1.7.0.4
> 
> 

[RFC PATCH v2 11/13] arm/tegra: Add device tree support to pinmux driver

[Stephen Warren]

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/mach-tegra/pinmux.c |  249 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 249 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
index ed316f9..5dfe6c1 100644
--- a/arch/arm/mach-tegra/pinmux.c
+++ b/arch/arm/mach-tegra/pinmux.c
@@ -20,6 +20,7 @@
 #include <linux/errno.h>
 #include <linux/spinlock.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 
 #include <mach/iomap.h>
@@ -124,6 +125,21 @@ static const char *pingroup_name(enum tegra_pingroup pg)
 	return pingroups[pg].name;
 }
 
+#ifdef CONFIG_OF
+static int pingroup_enum(const char *name, enum tegra_pingroup *pg_out)
+{
+	int pg;
+
+	for (pg = 0; pg < TEGRA_MAX_PINGROUP; pg++)
+		if (!strcasecmp(name, tegra_soc_pingroups[pg].name)) {
+			*pg_out = pg;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+#endif
+
 static const char *func_name(enum tegra_mux_func func)
 {
 	if (func == TEGRA_MUX_RSVD1)
@@ -147,6 +163,41 @@ static const char *func_name(enum tegra_mux_func func)
 	return tegra_mux_names[func];
 }
 
+#ifdef CONFIG_OF
+static int func_enum(const char *name, enum tegra_mux_func *func_out)
+{
+	int func;
+
+	if (!strcasecmp(name, "RSVD1")) {
+		*func_out = TEGRA_MUX_RSVD1;
+		return 0;
+	}
+	if (!strcasecmp(name, "RSVD2")) {
+		*func_out = TEGRA_MUX_RSVD2;
+		return 0;
+	}
+	if (!strcasecmp(name, "RSVD3")) {
+		*func_out = TEGRA_MUX_RSVD3;
+		return 0;
+	}
+	if (!strcasecmp(name, "RSVD4")) {
+		*func_out = TEGRA_MUX_RSVD4;
+		return 0;
+	}
+	if (!strcasecmp(name, "NONE")) {
+		*func_out = TEGRA_MUX_NONE;
+		return 0;
+	}
+
+	for (func = 0; func < TEGRA_MAX_MUX; func++)
+		if (!strcasecmp(name, tegra_mux_names[func])) {
+			*func_out = func;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+#endif
 
 static const char *tri_name(unsigned long val)
 {
@@ -329,6 +380,22 @@ static const char *drive_pinmux_name(enum tegra_drive_pingroup pg)
 	return drive_pingroups[pg].name;
 }
 
+#ifdef CONFIG_OF
+static int drive_pinmux_enum(const char *name,
+			     enum tegra_drive_pingroup *pg_out)
+{
+	int pg;
+
+	for (pg = 0; pg < TEGRA_MAX_DRIVE_PINGROUP; pg++)
+		if (!strcasecmp(name, drive_pingroups[pg].name)) {
+			*pg_out = pg;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+#endif
+
 static const char *enable_name(unsigned long val)
 {
 	return val ? "ENABLE" : "DISABLE";
@@ -666,15 +733,197 @@ void tegra_pinmux_config_pullupdown_table(const struct tegra_pingroup_config *co
 	}
 }
 
+#ifdef CONFIG_OF
+static void __init tegra_pinmux_parse_mux_groups(
+			struct platform_device *pdev,
+			struct device_node *mux_node)
+{
+	struct device_node *node;
+
+	for_each_child_of_node(mux_node, node) {
+		struct tegra_pingroup_config config;
+		int ret;
+		const char *func;
+
+		ret = pingroup_enum(node->name, &config.pingroup);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(mux) %s: Invalid pingroup name\n",
+				node->name);
+			continue;
+		}
+
+		ret = of_property_read_string(node, "nvidia,function",
+					      &func);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(mux) %s: Missing property nvidia,function\n",
+				node->name);
+			continue;
+		}
+		ret = func_enum(func, &config.func);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(mux) %s: Invalid nvidia,function value %s\n",
+				node->name, func);
+			continue;
+		}
+
+		if (of_find_property(node, "nvidia,pull-up", NULL))
+			config.pupd = TEGRA_PUPD_PULL_UP;
+		else if (of_find_property(node, "nvidia,pull-down", NULL))
+			config.pupd = TEGRA_PUPD_PULL_DOWN;
+		else
+			config.pupd = TEGRA_PUPD_NORMAL;
+
+		if (of_find_property(node, "nvidia,tristate", NULL))
+			config.tristate = TEGRA_TRI_TRISTATE;
+		else
+			config.tristate = TEGRA_TRI_NORMAL;
+
+		dev_dbg(&pdev->dev, "(mux) %s: func %d (%s) pull %d tri %d\n",
+			node->name, config.func, func, config.pupd,
+			config.tristate);
+
+		tegra_pinmux_config_pingroup(&config);
+	}
+}
+
+static void __init tegra_pinmux_parse_drive_groups(
+			struct platform_device *pdev,
+			struct device_node *drive_node)
+{
+	struct device_node *node;
+
+	for_each_child_of_node(drive_node, node) {
+		enum tegra_drive_pingroup pg;
+		enum tegra_hsm hsm;
+		enum tegra_schmitt schmitt;
+		enum tegra_drive drive;
+		enum tegra_pull_strength pull_down;
+		enum tegra_pull_strength pull_up;
+		enum tegra_slew slew_rising;
+		enum tegra_slew slew_falling;
+		int ret;
+
+		ret = drive_pinmux_enum(node->name, &pg);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(drive) %s: Invalid pingroup name\n",
+				node->name);
+			continue;
+		}
+
+		if (of_find_property(node, "nvidia,high-speed-mode", NULL))
+			hsm = TEGRA_HSM_ENABLE;
+		else
+			hsm = TEGRA_HSM_DISABLE;
+
+		if (of_find_property(node, "nvidia,schmitt", NULL))
+			schmitt = TEGRA_SCHMITT_ENABLE;
+		else
+			schmitt = TEGRA_SCHMITT_DISABLE;
+
+		ret = of_property_read_u32(node, "nvidia,drive-power", &drive);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(drive) %s: Missing property "
+				"nvidia,drive-power\n",
+				node->name);
+			continue;
+		}
+
+		ret = of_property_read_u32(node, "nvidia,pull-down-strength",
+					   &pull_down);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(drive) %s: Missing property "
+				"nvidia,pull-down-strength\n",
+				node->name);
+			continue;
+		}
+
+		ret = of_property_read_u32(node, "nvidia,pull-up-strength",
+					   &pull_up);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(drive) %s: Missing property "
+				"nvidia,pull-up-strength\n",
+				node->name);
+			continue;
+		}
+
+		ret = of_property_read_u32(node, "nvidia,slew-rate-rising",
+					   &slew_rising);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(drive) %s: Missing property "
+				"nvidia,slew_rate-rising\n",
+				node->name);
+			continue;
+		}
+
+		ret = of_property_read_u32(node, "nvidia,slew-rate-falling",
+					   &slew_rising);
+		if (ret < 0) {
+			dev_err(&pdev->dev,
+				"(drive) %s: Missing property "
+				"nvidia,slew_rate-falling\n",
+				node->name);
+			continue;
+		}
+
+		dev_dbg(&pdev->dev,
+			"(drive) %s: hsm %d schmitt %d drive %d "
+			"pull_down %d pull_up %d slew_r %d slew_f %d\n",
+			node->name,
+			hsm, schmitt, drive,
+			pull_down, pull_up,
+			slew_rising, slew_falling);
+
+		tegra_drive_pinmux_config_pingroup(pg, hsm, schmitt, drive,
+						   pull_down, pull_up,
+						   slew_rising, slew_falling);
+	}
+}
+
+static void __init tegra_pinmux_probe_dt(struct platform_device *pdev)
+{
+	struct device_node *node;
+
+	for_each_child_of_node(pdev->dev.of_node, node) {
+		if (!strcmp(node->name, "nvidia,mux-groups"))
+			tegra_pinmux_parse_mux_groups(pdev, node);
+		else if (!strcmp(node->name, "nvidia,drive-groups"))
+			tegra_pinmux_parse_drive_groups(pdev, node);
+		else
+			dev_err(&pdev->dev, "%s: Unknown child node\n",
+				node->name);
+	}
+}
+#else
+static inline void __init tegra_pinmux_probe_dt(struct platform_device *pdev)
+{
+}
+#endif
+
 static int __init tegra_pinmux_probe(struct platform_device *pdev)
 {
+	tegra_pinmux_probe_dt(pdev);
+
 	return 0;
 }
 
+static struct of_device_id tegra_pinmux_of_match[] __devinitdata = {
+	{ .compatible = "nvidia,tegra20-pinmux", },
+	{ },
+};
+
 static struct platform_driver tegra_pinmux_driver = {
 	.driver		= {
 		.name	= "tegra-pinmux",
 		.owner	= THIS_MODULE,
+		.of_match_table = tegra_pinmux_of_match,
 	},
 	.probe		= tegra_pinmux_probe,
 };
-- 
1.7.0.4

Re: [RFC PATCH v2 11/13] arm/tegra: Add device tree support to pinmux driver

[Shawn Guo]

On Mon, Aug 15, 2011 at 02:28:18PM -0600, Stephen Warren wrote:
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  arch/arm/mach-tegra/pinmux.c |  249 ++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 249 insertions(+), 0 deletions(-)
> 
Same question here, since we are moving over to device tree anyway,
is it necessarily to keep these "#ifdef CONFIG_OF" all over the files?
Can we manage to get rid of them, since we have a suite of empty OF API
created for this?

Regards,
Shawn

> diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
> index ed316f9..5dfe6c1 100644
> --- a/arch/arm/mach-tegra/pinmux.c
> +++ b/arch/arm/mach-tegra/pinmux.c
> @@ -20,6 +20,7 @@
>  #include <linux/errno.h>
>  #include <linux/spinlock.h>
>  #include <linux/io.h>
> +#include <linux/of.h>
>  #include <linux/platform_device.h>
>  
>  #include <mach/iomap.h>
> @@ -124,6 +125,21 @@ static const char *pingroup_name(enum tegra_pingroup pg)
>  	return pingroups[pg].name;
>  }
>  
> +#ifdef CONFIG_OF
> +static int pingroup_enum(const char *name, enum tegra_pingroup *pg_out)
> +{
> +	int pg;
> +
> +	for (pg = 0; pg < TEGRA_MAX_PINGROUP; pg++)
> +		if (!strcasecmp(name, tegra_soc_pingroups[pg].name)) {
> +			*pg_out = pg;
> +			return 0;
> +		}
> +
> +	return -EINVAL;
> +}
> +#endif
> +
>  static const char *func_name(enum tegra_mux_func func)
>  {
>  	if (func == TEGRA_MUX_RSVD1)
> @@ -147,6 +163,41 @@ static const char *func_name(enum tegra_mux_func func)
>  	return tegra_mux_names[func];
>  }
>  
> +#ifdef CONFIG_OF
> +static int func_enum(const char *name, enum tegra_mux_func *func_out)
> +{
> +	int func;
> +
> +	if (!strcasecmp(name, "RSVD1")) {
> +		*func_out = TEGRA_MUX_RSVD1;
> +		return 0;
> +	}
> +	if (!strcasecmp(name, "RSVD2")) {
> +		*func_out = TEGRA_MUX_RSVD2;
> +		return 0;
> +	}
> +	if (!strcasecmp(name, "RSVD3")) {
> +		*func_out = TEGRA_MUX_RSVD3;
> +		return 0;
> +	}
> +	if (!strcasecmp(name, "RSVD4")) {
> +		*func_out = TEGRA_MUX_RSVD4;
> +		return 0;
> +	}
> +	if (!strcasecmp(name, "NONE")) {
> +		*func_out = TEGRA_MUX_NONE;
> +		return 0;
> +	}
> +
> +	for (func = 0; func < TEGRA_MAX_MUX; func++)
> +		if (!strcasecmp(name, tegra_mux_names[func])) {
> +			*func_out = func;
> +			return 0;
> +		}
> +
> +	return -EINVAL;
> +}
> +#endif
>  
>  static const char *tri_name(unsigned long val)
>  {
> @@ -329,6 +380,22 @@ static const char *drive_pinmux_name(enum tegra_drive_pingroup pg)
>  	return drive_pingroups[pg].name;
>  }
>  
> +#ifdef CONFIG_OF
> +static int drive_pinmux_enum(const char *name,
> +			     enum tegra_drive_pingroup *pg_out)
> +{
> +	int pg;
> +
> +	for (pg = 0; pg < TEGRA_MAX_DRIVE_PINGROUP; pg++)
> +		if (!strcasecmp(name, drive_pingroups[pg].name)) {
> +			*pg_out = pg;
> +			return 0;
> +		}
> +
> +	return -EINVAL;
> +}
> +#endif
> +
>  static const char *enable_name(unsigned long val)
>  {
>  	return val ? "ENABLE" : "DISABLE";
> @@ -666,15 +733,197 @@ void tegra_pinmux_config_pullupdown_table(const struct tegra_pingroup_config *co
>  	}
>  }
>  
> +#ifdef CONFIG_OF
> +static void __init tegra_pinmux_parse_mux_groups(
> +			struct platform_device *pdev,
> +			struct device_node *mux_node)
> +{
> +	struct device_node *node;
> +
> +	for_each_child_of_node(mux_node, node) {
> +		struct tegra_pingroup_config config;
> +		int ret;
> +		const char *func;
> +
> +		ret = pingroup_enum(node->name, &config.pingroup);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(mux) %s: Invalid pingroup name\n",
> +				node->name);
> +			continue;
> +		}
> +
> +		ret = of_property_read_string(node, "nvidia,function",
> +					      &func);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(mux) %s: Missing property nvidia,function\n",
> +				node->name);
> +			continue;
> +		}
> +		ret = func_enum(func, &config.func);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(mux) %s: Invalid nvidia,function value %s\n",
> +				node->name, func);
> +			continue;
> +		}
> +
> +		if (of_find_property(node, "nvidia,pull-up", NULL))
> +			config.pupd = TEGRA_PUPD_PULL_UP;
> +		else if (of_find_property(node, "nvidia,pull-down", NULL))
> +			config.pupd = TEGRA_PUPD_PULL_DOWN;
> +		else
> +			config.pupd = TEGRA_PUPD_NORMAL;
> +
> +		if (of_find_property(node, "nvidia,tristate", NULL))
> +			config.tristate = TEGRA_TRI_TRISTATE;
> +		else
> +			config.tristate = TEGRA_TRI_NORMAL;
> +
> +		dev_dbg(&pdev->dev, "(mux) %s: func %d (%s) pull %d tri %d\n",
> +			node->name, config.func, func, config.pupd,
> +			config.tristate);
> +
> +		tegra_pinmux_config_pingroup(&config);
> +	}
> +}
> +
> +static void __init tegra_pinmux_parse_drive_groups(
> +			struct platform_device *pdev,
> +			struct device_node *drive_node)
> +{
> +	struct device_node *node;
> +
> +	for_each_child_of_node(drive_node, node) {
> +		enum tegra_drive_pingroup pg;
> +		enum tegra_hsm hsm;
> +		enum tegra_schmitt schmitt;
> +		enum tegra_drive drive;
> +		enum tegra_pull_strength pull_down;
> +		enum tegra_pull_strength pull_up;
> +		enum tegra_slew slew_rising;
> +		enum tegra_slew slew_falling;
> +		int ret;
> +
> +		ret = drive_pinmux_enum(node->name, &pg);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(drive) %s: Invalid pingroup name\n",
> +				node->name);
> +			continue;
> +		}
> +
> +		if (of_find_property(node, "nvidia,high-speed-mode", NULL))
> +			hsm = TEGRA_HSM_ENABLE;
> +		else
> +			hsm = TEGRA_HSM_DISABLE;
> +
> +		if (of_find_property(node, "nvidia,schmitt", NULL))
> +			schmitt = TEGRA_SCHMITT_ENABLE;
> +		else
> +			schmitt = TEGRA_SCHMITT_DISABLE;
> +
> +		ret = of_property_read_u32(node, "nvidia,drive-power", &drive);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(drive) %s: Missing property "
> +				"nvidia,drive-power\n",
> +				node->name);
> +			continue;
> +		}
> +
> +		ret = of_property_read_u32(node, "nvidia,pull-down-strength",
> +					   &pull_down);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(drive) %s: Missing property "
> +				"nvidia,pull-down-strength\n",
> +				node->name);
> +			continue;
> +		}
> +
> +		ret = of_property_read_u32(node, "nvidia,pull-up-strength",
> +					   &pull_up);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(drive) %s: Missing property "
> +				"nvidia,pull-up-strength\n",
> +				node->name);
> +			continue;
> +		}
> +
> +		ret = of_property_read_u32(node, "nvidia,slew-rate-rising",
> +					   &slew_rising);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(drive) %s: Missing property "
> +				"nvidia,slew_rate-rising\n",
> +				node->name);
> +			continue;
> +		}
> +
> +		ret = of_property_read_u32(node, "nvidia,slew-rate-falling",
> +					   &slew_rising);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"(drive) %s: Missing property "
> +				"nvidia,slew_rate-falling\n",
> +				node->name);
> +			continue;
> +		}
> +
> +		dev_dbg(&pdev->dev,
> +			"(drive) %s: hsm %d schmitt %d drive %d "
> +			"pull_down %d pull_up %d slew_r %d slew_f %d\n",
> +			node->name,
> +			hsm, schmitt, drive,
> +			pull_down, pull_up,
> +			slew_rising, slew_falling);
> +
> +		tegra_drive_pinmux_config_pingroup(pg, hsm, schmitt, drive,
> +						   pull_down, pull_up,
> +						   slew_rising, slew_falling);
> +	}
> +}
> +
> +static void __init tegra_pinmux_probe_dt(struct platform_device *pdev)
> +{
> +	struct device_node *node;
> +
> +	for_each_child_of_node(pdev->dev.of_node, node) {
> +		if (!strcmp(node->name, "nvidia,mux-groups"))
> +			tegra_pinmux_parse_mux_groups(pdev, node);
> +		else if (!strcmp(node->name, "nvidia,drive-groups"))
> +			tegra_pinmux_parse_drive_groups(pdev, node);
> +		else
> +			dev_err(&pdev->dev, "%s: Unknown child node\n",
> +				node->name);
> +	}
> +}
> +#else
> +static inline void __init tegra_pinmux_probe_dt(struct platform_device *pdev)
> +{
> +}
> +#endif
> +
>  static int __init tegra_pinmux_probe(struct platform_device *pdev)
>  {
> +	tegra_pinmux_probe_dt(pdev);
> +
>  	return 0;
>  }
>  
> +static struct of_device_id tegra_pinmux_of_match[] __devinitdata = {
> +	{ .compatible = "nvidia,tegra20-pinmux", },
> +	{ },
> +};
> +
>  static struct platform_driver tegra_pinmux_driver = {
>  	.driver		= {
>  		.name	= "tegra-pinmux",
>  		.owner	= THIS_MODULE,
> +		.of_match_table = tegra_pinmux_of_match,
>  	},
>  	.probe		= tegra_pinmux_probe,
>  };
> -- 
> 1.7.0.4
> 
> 

RE: [RFC PATCH v2 11/13] arm/tegra: Add device tree support to pinmux driver

[Stephen Warren]

Shawn Guo wrote at Monday, August 15, 2011 9:45 PM:
> On Mon, Aug 15, 2011 at 02:28:18PM -0600, Stephen Warren wrote:
> > Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> >  arch/arm/mach-tegra/pinmux.c |  249 ++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 249 insertions(+), 0 deletions(-)
> >
> Same question here, since we are moving over to device tree anyway,
> is it necessarily to keep these "#ifdef CONFIG_OF" all over the files?
> Can we manage to get rid of them, since we have a suite of empty OF API
> created for this?

Yes, the ifdefs can all be eliminated. I'll need to add a couple other
empty functions to <linux/of.h>. I also folded the foo_probe_dt()
functions into foo_probe(), since the need for the ifdefs is gone.

-- 
nvpublic

[RFC PATCH v2 12/13] arm/tegra: board-dt: Remove dependency on non-dt pinmux functions

[Stephen Warren]

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/mach-tegra/Makefile   |    1 -
 arch/arm/mach-tegra/board-dt.c |   10 ----------
 2 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index f11b910..bab6544 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -30,7 +30,6 @@ obj-${CONFIG_MACH_SEABOARD}             += board-seaboard.o
 obj-${CONFIG_MACH_SEABOARD}             += board-seaboard-pinmux.o
 
 obj-${CONFIG_MACH_TEGRA_DT}             += board-dt.o
-obj-${CONFIG_MACH_TEGRA_DT}             += board-harmony-pinmux.o
 
 obj-${CONFIG_MACH_TRIMSLICE}            += board-trimslice.o
 obj-${CONFIG_MACH_TRIMSLICE}            += board-trimslice-pinmux.o
diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 1995b79..06e82c4 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -41,14 +41,9 @@
 #include <mach/irqs.h>
 
 #include "board.h"
-#include "board-harmony.h"
 #include "clock.h"
 #include "devices.h"
 
-void harmony_pinmux_init(void);
-void seaboard_pinmux_init(void);
-
-
 struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("nvidia,tegra20-gpio", TEGRA_GPIO_BASE, "tegra-gpio", NULL),
 	OF_DEV_AUXDATA("nvidia,tegra20-pinmux", TEGRA_APB_MISC_BASE, "tegra-pinmux", NULL),
@@ -93,11 +88,6 @@ static void __init tegra_dt_init(void)
 
 	tegra_clk_init_from_table(tegra_dt_clk_init_table);
 
-	if (of_machine_is_compatible("nvidia,harmony"))
-		harmony_pinmux_init();
-	else if (of_machine_is_compatible("nvidia,seaboard"))
-		seaboard_pinmux_init();
-
 	/*
 	 * Finished with the static registrations now; fill in the missing
 	 * devices
-- 
1.7.0.4

[RFC PATCH v2 13/13] arm/tegra: Remove temporary gpio/pinmux registration workaround

[Stephen Warren]

This reverts commit "arm/tegra: Avoid duplicate gpio/pinmux devices with
dt"; board-dt.c no long calls harmony/seaboard_pinmux_init(), so the
workaround is no longer needed.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/mach-tegra/board-harmony-pinmux.c  |    5 +----
 arch/arm/mach-tegra/board-seaboard-pinmux.c |    5 +----
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-tegra/board-harmony-pinmux.c b/arch/arm/mach-tegra/board-harmony-pinmux.c
index 130018d..e99b456 100644
--- a/arch/arm/mach-tegra/board-harmony-pinmux.c
+++ b/arch/arm/mach-tegra/board-harmony-pinmux.c
@@ -14,8 +14,6 @@
  *
  */
 
-#include <asm/mach-types.h>
-
 #include <linux/kernel.h>
 #include <linux/gpio.h>
 #include <mach/pinmux.h>
@@ -163,8 +161,7 @@ static struct tegra_gpio_table gpio_table[] = {
 
 void harmony_pinmux_init(void)
 {
-	if (machine_is_harmony())
-		platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
+	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
 
 	tegra_pinmux_config_table(harmony_pinmux, ARRAY_SIZE(harmony_pinmux));
 
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index bc4dc17..f092298 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -12,8 +12,6 @@
  *
  */
 
-#include <asm/mach-types.h>
-
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/gpio.h>
@@ -178,8 +176,7 @@ static struct tegra_gpio_table gpio_table[] = {
 
 void __init seaboard_pinmux_init(void)
 {
-	if (machine_is_seaboard())
-		platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
+	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
 
 	tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
 
-- 
1.7.0.4

[RFC PATCH v2 01/13] arm/tegra: Prep boards for gpio/pinmux conversion to pdevs

[Stephen Warren]

The Tegra GPIO driver will be converted from static registration via
postcore_initcall() to be a platform device later in this patch series.
A new Tegra pinmux platform device will also be added.

Prepare for this by modifying all boards to register the appropriate
platform devices before-hand, so that when the drivers are converted,
those devices will be probed, and git bisectability will be maintained.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/mach-tegra/board-harmony-pinmux.c   |    8 ++++++++
 arch/arm/mach-tegra/board-paz00-pinmux.c     |    8 ++++++++
 arch/arm/mach-tegra/board-seaboard-pinmux.c  |    9 +++++++--
 arch/arm/mach-tegra/board-trimslice-pinmux.c |    7 +++++++
 arch/arm/mach-tegra/devices.c                |   10 ++++++++++
 arch/arm/mach-tegra/devices.h                |    2 ++
 6 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-tegra/board-harmony-pinmux.c b/arch/arm/mach-tegra/board-harmony-pinmux.c
index 4d63e2e..e99b456 100644
--- a/arch/arm/mach-tegra/board-harmony-pinmux.c
+++ b/arch/arm/mach-tegra/board-harmony-pinmux.c
@@ -20,6 +20,7 @@
 
 #include "gpio-names.h"
 #include "board-harmony.h"
+#include "devices.h"
 
 static struct tegra_pingroup_config harmony_pinmux[] = {
 	{TEGRA_PINGROUP_ATA,   TEGRA_MUX_IDE,           TEGRA_PUPD_NORMAL,    TEGRA_TRI_NORMAL},
@@ -140,6 +141,11 @@ static struct tegra_pingroup_config harmony_pinmux[] = {
 	{TEGRA_PINGROUP_XM2D,  TEGRA_MUX_NONE,          TEGRA_PUPD_NORMAL,    TEGRA_TRI_NORMAL},
 };
 
+static struct platform_device *pinmux_devices[] = {
+	&tegra_gpio_device,
+	&tegra_pinmux_device,
+};
+
 static struct tegra_gpio_table gpio_table[] = {
 	{ .gpio = TEGRA_GPIO_SD2_CD,		.enable = true	},
 	{ .gpio = TEGRA_GPIO_SD2_WP,		.enable = true	},
@@ -155,6 +161,8 @@ static struct tegra_gpio_table gpio_table[] = {
 
 void harmony_pinmux_init(void)
 {
+	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
+
 	tegra_pinmux_config_table(harmony_pinmux, ARRAY_SIZE(harmony_pinmux));
 
 	tegra_gpio_config(gpio_table, ARRAY_SIZE(gpio_table));
diff --git a/arch/arm/mach-tegra/board-paz00-pinmux.c b/arch/arm/mach-tegra/board-paz00-pinmux.c
index bdd2627..43633f4 100644
--- a/arch/arm/mach-tegra/board-paz00-pinmux.c
+++ b/arch/arm/mach-tegra/board-paz00-pinmux.c
@@ -20,6 +20,7 @@
 
 #include "gpio-names.h"
 #include "board-paz00.h"
+#include "devices.h"
 
 static struct tegra_pingroup_config paz00_pinmux[] = {
 	{TEGRA_PINGROUP_ATA,   TEGRA_MUX_GMI,           TEGRA_PUPD_NORMAL,    TEGRA_TRI_NORMAL},
@@ -140,6 +141,11 @@ static struct tegra_pingroup_config paz00_pinmux[] = {
 	{TEGRA_PINGROUP_XM2D,  TEGRA_MUX_NONE,          TEGRA_PUPD_NORMAL,    TEGRA_TRI_NORMAL},
 };
 
+static struct platform_device *pinmux_devices[] = {
+	&tegra_gpio_device,
+	&tegra_pinmux_device,
+};
+
 static struct tegra_gpio_table gpio_table[] = {
 	{ .gpio = TEGRA_GPIO_SD1_CD,	.enable = true },
 	{ .gpio = TEGRA_GPIO_SD1_WP,	.enable = true },
@@ -149,6 +155,8 @@ static struct tegra_gpio_table gpio_table[] = {
 
 void paz00_pinmux_init(void)
 {
+	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
+
 	tegra_pinmux_config_table(paz00_pinmux, ARRAY_SIZE(paz00_pinmux));
 
 	tegra_gpio_config(gpio_table, ARRAY_SIZE(gpio_table));
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index 74f78b7..f092298 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -21,6 +21,7 @@
 
 #include "gpio-names.h"
 #include "board-seaboard.h"
+#include "devices.h"
 
 #define DEFAULT_DRIVE(_name)					\
 	{							\
@@ -157,8 +158,10 @@ static __initdata struct tegra_pingroup_config seaboard_pinmux[] = {
 	{TEGRA_PINGROUP_XM2D,  TEGRA_MUX_NONE,          TEGRA_PUPD_NORMAL,    TEGRA_TRI_NORMAL},
 };
 
-
-
+static struct platform_device *pinmux_devices[] = {
+	&tegra_gpio_device,
+	&tegra_pinmux_device,
+};
 
 static struct tegra_gpio_table gpio_table[] = {
 	{ .gpio = TEGRA_GPIO_SD2_CD,		.enable = true },
@@ -173,6 +176,8 @@ static struct tegra_gpio_table gpio_table[] = {
 
 void __init seaboard_pinmux_init(void)
 {
+	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
+
 	tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
 
 	tegra_drive_pinmux_config_table(seaboard_drive_pinmux,
diff --git a/arch/arm/mach-tegra/board-trimslice-pinmux.c b/arch/arm/mach-tegra/board-trimslice-pinmux.c
index bcb1916..4969dd2 100644
--- a/arch/arm/mach-tegra/board-trimslice-pinmux.c
+++ b/arch/arm/mach-tegra/board-trimslice-pinmux.c
@@ -21,6 +21,7 @@
 
 #include "gpio-names.h"
 #include "board-trimslice.h"
+#include "devices.h"
 
 static __initdata struct tegra_pingroup_config trimslice_pinmux[] = {
 	{TEGRA_PINGROUP_ATA,   TEGRA_MUX_IDE,           TEGRA_PUPD_NORMAL,	TEGRA_TRI_TRISTATE},
@@ -141,6 +142,11 @@ static __initdata struct tegra_pingroup_config trimslice_pinmux[] = {
 	{TEGRA_PINGROUP_XM2D,  TEGRA_MUX_NONE,          TEGRA_PUPD_NORMAL,      TEGRA_TRI_NORMAL},
 };
 
+static struct platform_device *pinmux_devices[] = {
+	&tegra_gpio_device,
+	&tegra_pinmux_device,
+};
+
 static struct tegra_gpio_table gpio_table[] = {
 	{ .gpio = TRIMSLICE_GPIO_SD4_CD, .enable = true	}, /* mmc4 cd */
 	{ .gpio = TRIMSLICE_GPIO_SD4_WP, .enable = true	}, /* mmc4 wp */
@@ -151,6 +157,7 @@ static struct tegra_gpio_table gpio_table[] = {
 
 void __init trimslice_pinmux_init(void)
 {
+	platform_add_devices(pinmux_devices, ARRAY_SIZE(pinmux_devices));
 	tegra_pinmux_config_table(trimslice_pinmux, ARRAY_SIZE(trimslice_pinmux));
 	tegra_gpio_config(gpio_table, ARRAY_SIZE(gpio_table));
 }
diff --git a/arch/arm/mach-tegra/devices.c b/arch/arm/mach-tegra/devices.c
index 57e35d2..48262bf 100644
--- a/arch/arm/mach-tegra/devices.c
+++ b/arch/arm/mach-tegra/devices.c
@@ -31,6 +31,16 @@
 #include <mach/usb_phy.h>
 #include "gpio-names.h"
 
+struct platform_device tegra_gpio_device = {
+	.name		= "tegra-gpio",
+	.id		= -1,
+};
+
+struct platform_device tegra_pinmux_device = {
+	.name		= "tegra-pinmux",
+	.id		= -1,
+};
+
 static struct resource i2c_resource1[] = {
 	[0] = {
 		.start	= INT_I2C,
diff --git a/arch/arm/mach-tegra/devices.h b/arch/arm/mach-tegra/devices.h
index 4a7dc0a..873ecb2 100644
--- a/arch/arm/mach-tegra/devices.h
+++ b/arch/arm/mach-tegra/devices.h
@@ -21,6 +21,8 @@
 
 #include <linux/platform_device.h>
 
+extern struct platform_device tegra_gpio_device;
+extern struct platform_device tegra_pinmux_device;
 extern struct platform_device tegra_sdhci_device1;
 extern struct platform_device tegra_sdhci_device2;
 extern struct platform_device tegra_sdhci_device3;
-- 
1.7.0.4

[RFC PATCH v2 03/13] arm/tegra: board-dt: Add AUXDATA for tegra-gpio and tegra-pinmux

[Stephen Warren]

Add AUXDATA so that Tegra GPIO and pinmux devices that are instantiated
from device-tree are named consistently with the static platform devices
in mach-tegra/devices.c. Note that the device-tree file tegra20.dtsi
already includes a node for the Tegra GPIO controller, whereas the node
for the Tegra pinmux controller will be added in a subsequent commit.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/mach-tegra/board-dt.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 9f47e04..1995b79 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -50,6 +50,8 @@ void seaboard_pinmux_init(void);
 
 
 struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("nvidia,tegra20-gpio", TEGRA_GPIO_BASE, "tegra-gpio", NULL),
+	OF_DEV_AUXDATA("nvidia,tegra20-pinmux", TEGRA_APB_MISC_BASE, "tegra-pinmux", NULL),
 	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC1_BASE, "sdhci-tegra.0", NULL),
 	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC2_BASE, "sdhci-tegra.1", NULL),
 	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC3_BASE, "sdhci-tegra.2", NULL),
-- 
1.7.0.4

Re: [RFC PATCH v2 03/13] arm/tegra: board-dt: Add AUXDATA for tegra-gpio and tegra-pinmux

[Shawn Guo]

On Mon, Aug 15, 2011 at 02:28:10PM -0600, Stephen Warren wrote:
> Add AUXDATA so that Tegra GPIO and pinmux devices that are instantiated
> from device-tree are named consistently with the static platform devices
> in mach-tegra/devices.c. Note that the device-tree file tegra20.dtsi
> already includes a node for the Tegra GPIO controller, whereas the node
> for the Tegra pinmux controller will be added in a subsequent commit.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  arch/arm/mach-tegra/board-dt.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
> index 9f47e04..1995b79 100644
> --- a/arch/arm/mach-tegra/board-dt.c
> +++ b/arch/arm/mach-tegra/board-dt.c
> @@ -50,6 +50,8 @@ void seaboard_pinmux_init(void);
>  
>  
>  struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
> +	OF_DEV_AUXDATA("nvidia,tegra20-gpio", TEGRA_GPIO_BASE, "tegra-gpio", NULL),
> +	OF_DEV_AUXDATA("nvidia,tegra20-pinmux", TEGRA_APB_MISC_BASE, "tegra-pinmux", NULL),
>  	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC1_BASE, "sdhci-tegra.0", NULL),
>  	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC2_BASE, "sdhci-tegra.1", NULL),
>  	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC3_BASE, "sdhci-tegra.2", NULL),
> 
The whole auxdata table was primarily added to keep clk API working
with the device name looking up.  Your gpio and pinmux can still work
without this patch, right?  If that's case, I do not think we need to
have this patch just for consistent device name between dt and non-dt.
They are not and they do not have to be.

-- 
Regards,
Shawn

RE: [RFC PATCH v2 03/13] arm/tegra: board-dt: Add AUXDATA for tegra-gpio and tegra-pinmux

[Stephen Warren]

Shawn Guo wrote at Monday, August 15, 2011 9:31 PM:
> On Mon, Aug 15, 2011 at 02:28:10PM -0600, Stephen Warren wrote:
> > Add AUXDATA so that Tegra GPIO and pinmux devices that are instantiated
> > from device-tree are named consistently with the static platform devices
> > in mach-tegra/devices.c. Note that the device-tree file tegra20.dtsi
> > already includes a node for the Tegra GPIO controller, whereas the node
> > for the Tegra pinmux controller will be added in a subsequent commit.
> >
> > Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> >  arch/arm/mach-tegra/board-dt.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
> > index 9f47e04..1995b79 100644
> > --- a/arch/arm/mach-tegra/board-dt.c
> > +++ b/arch/arm/mach-tegra/board-dt.c
> > @@ -50,6 +50,8 @@ void seaboard_pinmux_init(void);
> >
> >
> >  struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
> > +	OF_DEV_AUXDATA("nvidia,tegra20-gpio", TEGRA_GPIO_BASE, "tegra-gpio", NULL),
> > +	OF_DEV_AUXDATA("nvidia,tegra20-pinmux", TEGRA_APB_MISC_BASE, "tegra-pinmux", NULL),
> >  	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC1_BASE, "sdhci-tegra.0", NULL),
> >  	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC2_BASE, "sdhci-tegra.1", NULL),
> >  	OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC3_BASE, "sdhci-tegra.2", NULL),
> >
> The whole auxdata table was primarily added to keep clk API working
> with the device name looking up.  Your gpio and pinmux can still work
> without this patch, right?  If that's case, I do not think we need to
> have this patch just for consistent device name between dt and non-dt.
> They are not and they do not have to be.

Indeed, everything does work fine without the AUXDATA; there's no
dependence on any clock lookups or similar in the new drivers.

Initially, I thought consistency in device naming would be important,
since Tegra works with and without device-tree, but I guess we'll be able
to turn off the hard-coded board files soon, so device name consistency
probably isn't too relevant.

I'll drop this patch.

-- 
nvpublic

[RFC PATCH v2 04/13] docs/dt: Document nvidia, tegra20-gpio's nvidia, enabled-gpios property

[Stephen Warren]

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 .../devicetree/bindings/gpio/gpio_nvidia.txt       |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt b/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt
index eb4b530..b22fff3 100644
--- a/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt
@@ -6,3 +6,23 @@ Required properties:
   second cell is used to specify optional parameters:
   - bit 0 specifies polarity (0 for normal, 1 for inverted)
 - gpio-controller : Marks the device node as a GPIO controller.
+
+Optional properties:
+- nvidia,enabled-gpios : The list of GPIOs that should be controlled by the
+  GPIO controller rather than the pinmux controller.
+
+Example of a gpio-controller node:
+
+	gpio: gpio@6000d000 {
+		compatible = "nvidia,tegra20-gpio";
+		reg = < 0x6000d000 0x1000 >;
+		interrupts = < 64 65 66 67 87 119 121 >;
+		#gpio-cells = <2>;
+		gpio-controller;
+		nvidia,enabled-gpios = <
+			69	// TEGRA_GPIO_PI5 SD2_CD
+			57	// TEGRA_GPIO_PH1 SD2_WP
+			155	// TEGRA_GPIO_PT3 SD2_POWER
+		>;
+	};
+
-- 
1.7.0.4

[RFC PATCH v2 05/13] arm/dt: Tegra: Add nvidia, gpios property to GPIO controller

[Stephen Warren]

Add board-specific gpio node for Harmony and Seaboard. This lists the
GPIOs used by the board. Note that not all GPIOs that exist on the board
are listed; only those used by devices currently supported by device
tree.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra-harmony.dts  |   15 +++++++++++++++
 arch/arm/boot/dts/tegra-seaboard.dts |    8 ++++++++
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra-harmony.dts b/arch/arm/boot/dts/tegra-harmony.dts
index 4c05334..d680707 100644
--- a/arch/arm/boot/dts/tegra-harmony.dts
+++ b/arch/arm/boot/dts/tegra-harmony.dts
@@ -15,6 +15,21 @@
 		reg = < 0x00000000 0x40000000 >;
 	};
 
+	gpio: gpio@6000d000 {
+		nvidia,enabled-gpios = <
+			69	// TEGRA_GPIO_PI5 SD2_CD
+			57	// TEGRA_GPIO_PH1 SD2_WP
+			155	// TEGRA_GPIO_PT3 SD2_POWER
+			58	// TEGRA_GPIO_PH2 SD4_CD
+			59	// TEGRA_GPIO_PH3 SD4_WP
+			70	// TEGRA_GPIO_PI6 SD4_POWER
+			187	// TEGRA_GPIO_PX3 CDC_IRQ
+			178	// TEGRA_GPIO_PW2 HP_DET
+			184	// TEGRA_GPIO_PX0 INT_MIC_EN
+			185	// TEGRA_GPIO_PX1 EXT_MIC_EN
+		>;
+	};
+
 	i2c@7000c000 {
 		clock-frequency = <400000>;
 
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts b/arch/arm/boot/dts/tegra-seaboard.dts
index 1940cae..43c8b2c 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -16,6 +16,14 @@
 		reg = < 0x00000000 0x40000000 >;
 	};
 
+	gpio: gpio@6000d000 {
+		nvidia,enabled-gpios = <
+			69 // TEGRA_GPIO_PI5 SD2_CD
+			57 // TEGRA_GPIO_PH1 SD2_WP
+			70 // TEGRA_GPIO_PI6 SD2_POWER
+		>;
+	};
+
 	serial@70006300 {
 		clock-frequency = < 216000000 >;
 	};
-- 
1.7.0.4

[RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Stephen Warren]

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 .../devicetree/bindings/pinmux/pinmux_nvidia.txt   |  294 ++++++++++++++++++++
 1 files changed, 294 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt

diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
new file mode 100644
index 0000000..744e1b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
@@ -0,0 +1,294 @@
+NVIDIA Tegra 2 pinmux controller
+
+Required properties:
+- compatible : "nvidia,tegra20-pinmux"
+
+Optional sub-nodes:
+- nvidia,mux-groups : Mux group settings; see below.
+- nvidia,drive-groups : Drive group settings; see below.
+
+nvidia,mux-groups sub-node:
+
+Each mux pin group is represented as a sub-node of the nvidia,mux-groups node.
+The name of the sub-node should be the name of the mux pingroup. The following
+names are valid:
+
+	ata
+	atb
+	atc
+	atd
+	ate
+	cdev1
+	cdev2
+	crtp
+	csus
+	dap1
+	dap2
+	dap3
+	dap4
+	ddc
+	dta
+	dtb
+	dtc
+	dtd
+	dte
+	dtf
+	gma
+	gmb
+	gmc
+	gmd
+	gme
+	gpu
+	gpu7
+	gpv
+	hdint
+	i2cp
+	irrx
+	irtx
+	kbca
+	kbcb
+	kbcc
+	kbcd
+	kbce
+	kbcf
+	lcsn
+	ld0
+	ld1
+	ld10
+	ld11
+	ld12
+	ld13
+	ld14
+	ld15
+	ld16
+	ld17
+	ld2
+	ld3
+	ld4
+	ld5
+	ld6
+	ld7
+	ld8
+	ld9
+	ldc
+	ldi
+	lhp0
+	lhp1
+	lhp2
+	lhs
+	lm0
+	lm1
+	lpp
+	lpw0
+	lpw1
+	lpw2
+	lsc0
+	lsc1
+	lsck
+	lsda
+	lsdi
+	lspi
+	lvp0
+	lvp1
+	lvs
+	owc
+	pmc
+	pta
+	rm
+	sdb
+	sdc
+	sdd
+	sdio1
+	slxa
+	slxc
+	slxd
+	slxk
+	spdi
+	spdo
+	spia
+	spib
+	spic
+	spid
+	spie
+	spif
+	spig
+	spih
+	uaa
+	uab
+	uac
+	uad
+	uca
+	ucb
+	uda
+	ck32
+	ddrc
+	pmca
+	pmcb
+	pmcc
+	pmcd
+	pmce
+	xm2c
+	xm2d
+
+Required subnode-properties:
+- nvidia,function : A string containing the name of the pinmux function to
+  mux to the pingroup. The following names are valid; see the Tegra TRM to
+  determine which are valid for each pingroup:
+
+	none (used for pingroups without muxing functionality)
+	ahb_clk
+	apb_clk
+	audio_sync
+	crt
+	dap1
+	dap2
+	dap3
+	dap4
+	dap5
+	displaya
+	displayb
+	emc_test0_dll
+	emc_test1_dll
+	gmi
+	gmi_int
+	hdmi
+	i2c
+	i2c2
+	i2c3
+	ide
+	irda
+	kbc
+	mio
+	mipi_hs
+	nand
+	osc
+	owr
+	pcie
+	plla_out
+	pllc_out1
+	pllm_out1
+	pllp_out2
+	pllp_out3
+	pllp_out4
+	pwm
+	pwr_intr
+	pwr_on
+	rtck
+	sdio1
+	sdio2
+	sdio3
+	sdio4
+	sflash
+	spdif
+	spi1
+	spi2
+	spi2_alt
+	spi3
+	spi4
+	trace
+	twc
+	uarta
+	uartb
+	uartc
+	uartd
+	uarte
+	ulpi
+	vi
+	vi_sensor_clk
+	xio
+
+optional subnode-properties:
+- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin.
+- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin.
+- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it.
+
+If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up
+takes precedence.
+
+nvidia,drive-groups sub-node:
+
+Each drive pin group is represented as a sub-node of the nvidia,drive-groups
+node. The name of the sub-node should be the name of the drive pingroup. The
+following names are valid:
+
+	ao1
+	ao2
+	at1
+	at2
+	cdev1
+	cdev2
+	csus
+	dap1
+	dap2
+	dap3
+	dap4
+	dbg
+	lcd1
+	lcd2
+	sdmmc2
+	sdmmc3
+	spi
+	uaa
+	uab
+	uart2
+	uart3
+	vi1
+	vi2
+	xm2a
+	xm2c
+	xm2d
+	xm2clk
+	memcomp
+	sdio1
+	crt
+	ddc
+	gma
+	gmb
+	gmc
+	gmd
+	gme
+	owr
+	uad
+
+Required subnode-properties:
+- nvidia,high-speed-mode : Boolean, enable high speed mode the pins.
+- nvidia,schmitt : Boolean, enables Schmitt Trigger on the input.
+- nvidia,drive-power : Integer, valid values 0-3. 0 is least power, 3 is
+  most power. Controls the drive power or current. See "Low Power Mode"
+  or "LPMD1" and "LPMD0" in the Tegra TRM.
+- nvidia,pull-down-strength : Integer, valid values 0-31. Controls drive
+  strength. See "CAL_DRVDN" in the Tegra TRM.
+- nvidia,pull-up-strength : Integer, valid values 0-31. Controls drive
+  strength. See "CAL_DRVUP" in the Tegra TRM.
+- nvidia,slew_rate-rising : Integer, valid values 0-3. 0 is fastest, 3 is
+  slowest. See "DRVUP_SLWR" in the Tegra TRM.
+- nvidia,slew_rate-falling : Integer, valid values 0-3. 0 is fastest, 3 is
+  slowest. See "DRVDN_SLWR" in the Tegra TRM.
+
+Example of a gpio-controller node:
+
+	pinmux: pinmux@70000000 {
+		compatible = "nvidia,tegra20-pinmux";
+		reg = < 0x70000000 0xc00 >;
+		nvidia,mux-groups {
+			cdev1 {
+				nvidia,function = "plla_out";
+			};
+			cdev2 {
+				nvidia,function = "pllp_out4";
+				nvidia,pull-down;
+				nvidia,tristate;
+			};
+		};
+		nvidia,drive-groups {
+			sdio1 {
+				nvidia,schmitt;
+				nvidia,drive-power = <1>;
+				nvidia,pull-down-strength = <31>;
+				nvidia,pull-up-strength = <31>;
+				nvidia,slew-rate-rising = <3>;
+				nvidia,slew-rate-falling = <3>;
+			};
+		};
+	};
+
-- 
1.7.0.4

Re: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Shawn Guo]

On Mon, Aug 15, 2011 at 02:28:13PM -0600, Stephen Warren wrote:
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../devicetree/bindings/pinmux/pinmux_nvidia.txt   |  294 ++++++++++++++++++++
>  1 files changed, 294 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> 
[...]
> +
> +Example of a gpio-controller node:
> +

You meant pinmux node instead of gpio.

Regards,
Shawn

> +	pinmux: pinmux@70000000 {
> +		compatible = "nvidia,tegra20-pinmux";
> +		reg = < 0x70000000 0xc00 >;
> +		nvidia,mux-groups {
> +			cdev1 {
> +				nvidia,function = "plla_out";
> +			};
> +			cdev2 {
> +				nvidia,function = "pllp_out4";
> +				nvidia,pull-down;
> +				nvidia,tristate;
> +			};
> +		};
> +		nvidia,drive-groups {
> +			sdio1 {
> +				nvidia,schmitt;
> +				nvidia,drive-power = <1>;
> +				nvidia,pull-down-strength = <31>;
> +				nvidia,pull-up-strength = <31>;
> +				nvidia,slew-rate-rising = <3>;
> +				nvidia,slew-rate-falling = <3>;
> +			};
> +		};
> +	};
> +
> -- 
> 1.7.0.4
> 
> 

Re: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Arnd Bergmann]

On Monday 15 August 2011, Stephen Warren wrote:
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../devicetree/bindings/pinmux/pinmux_nvidia.txt   |  294 ++++++++++++++++++++
>  1 files changed, 294 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> 
> diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> new file mode 100644
> index 0000000..744e1b7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> @@ -0,0 +1,294 @@
> +NVIDIA Tegra 2 pinmux controller
> +
> +Required properties:
> +- compatible : "nvidia,tegra20-pinmux"

Hmm, I think it would be much better in general if we could define
pinmux bindings in a way that is less specific to just one soc.
The contents of this file seem to be specific to even just one
version of the tegra chip, and might be completely different for
tegra30 and later, right?

Maybe Linus W can comment on this and say whether he thinks it can
be generalized enough to apply to other pinmux drivers.

> +Optional sub-nodes:
> +- nvidia,mux-groups : Mux group settings; see below.
> +- nvidia,drive-groups : Drive group settings; see below.
> +
> +nvidia,mux-groups sub-node:

These concepts seem general enough to me that they can apply to
other chips, and I would consequently drop the nvidia, prefix.

> +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node.
> +The name of the sub-node should be the name of the mux pingroup. The following
> +names are valid:
> +
> +	ata
> +	atb
> +	atc
> +	atd
> +	ate
> +	cdev1
> +	cdev2
> ...

I noticed that each board you define has a complete list of these. Would
it be possible to move a generic list into a tegra20-pinmux.dtsi file and
just override the pins in the per-board .dts file that require some special
setup?


> +
> +optional subnode-properties:
> +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin.
> +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin.
> +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it.
> +
> +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up
> +takes precedence.

These again seem generic enough to go into a general pinmux binding, without
the nvidia, prefix.

	Arnd

RE: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Stephen Warren]

Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM:
> On Monday 15 August 2011, Stephen Warren wrote:
> > Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> >  .../devicetree/bindings/pinmux/pinmux_nvidia.txt   |  294 ++++++++++++++++++++
> >  1 files changed, 294 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> > new file mode 100644
> > index 0000000..744e1b7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> > @@ -0,0 +1,294 @@
> > +NVIDIA Tegra 2 pinmux controller
> > +
> > +Required properties:
> > +- compatible : "nvidia,tegra20-pinmux"
> 
> Hmm, I think it would be much better in general if we could define
> pinmux bindings in a way that is less specific to just one soc.

> The contents of this file seem to be specific to even just one
> version of the tegra chip, and might be completely different for
> tegra30 and later, right?

The general concepts are the same between tegra20 and tegra30.

Tegra30 has a different set of mux and drive pingroups.

Tegra30 has more functions that can be assigned to pins.

Tegra30 has three more options per mux pingroup, although I haven't
Investigated whether any of those would need to be represented in DT;
I suspect at least one will, possibly all.

> Maybe Linus W can comment on this and say whether he thinks it can
> be generalized enough to apply to other pinmux drivers.
> 
> > +Optional sub-nodes:
> > +- nvidia,mux-groups : Mux group settings; see below.
> > +- nvidia,drive-groups : Drive group settings; see below.
> > +
> > +nvidia,mux-groups sub-node:
> 
> These concepts seem general enough to me that they can apply to
> other chips, and I would consequently drop the nvidia, prefix.

Two things to note about Tegra that might not apply to all SoCs:

* There are separate groups of pins for Muxing (plus some config) vs.
drive-strength (and related config). Some SoCs might use the same set
of groups for both. Perhaps some SoC might even have three or more types
of groups! I expect this to have some impact on the binding; I created
explicit mux-groups and drive-groups sub-nodes to represent this.

* Tegra's pinmux apply settings to groups of pins instead of individual
pins. Some SoCs might allow each setting to be configurable per-pin.
I don't expect this to have any impact as far as the bindings go though;
it'll simply impact the names of the available pin "groups"; some SoCs
will name groups, others pins.

> > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node.
> > +The name of the sub-node should be the name of the mux pingroup. The following
> > +names are valid:
> > +
> > +	ata
> > +	atb
> > +	atc
> > +	atd
> > +	ate
> > +	cdev1
> > +	cdev2
> > ...
> 
> I noticed that each board you define has a complete list of these. Would
> it be possible to move a generic list into a tegra20-pinmux.dtsi file and
> just override the pins in the per-board .dts file that require some special
> setup?

I'm not sure how much commonality there will really be.

Certainly, many boards are based off our reference designs and so will
have many similarities that could be shared.

That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows
a lot of differences. It seems a lot less error-prone to just completely
describe the entire pinmux state in each board's .dts file, rather than
trying to represent half the information as default in the SoC .dtsi file,
and just the diff in the board .dts file. I suppose perhaps if we put the
hardware's own default settings in tegra20.dtsi, that'd make sense, since
people are presumably reasonably aware of the delta relative to that.

We'd need to add new properties to override defaults, like:

nvidia,tristate --> nvidia,drive
nvidia,pull-*   --> nvidia,no-pull

> > +
> > +optional subnode-properties:
> > +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin.
> > +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin.
> > +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it.
> > +
> > +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up
> > +takes precedence.
> 
> These again seem generic enough to go into a general pinmux binding, without
> the nvidia, prefix.

Yes, I believe Jamie Iles was going to try cooking up a generic core binding
that could be shared across different SoCs, and extended with custom stuff.

-- 
nvpublic

Re: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Shawn Guo]

On Tue, Aug 16, 2011 at 10:32:05AM -0700, Stephen Warren wrote:
> Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM:
> > On Monday 15 August 2011, Stephen Warren wrote:
> > > Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > ---
> > >  .../devicetree/bindings/pinmux/pinmux_nvidia.txt   |  294 ++++++++++++++++++++
> > >  1 files changed, 294 insertions(+), 0 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> > > new file mode 100644
> > > index 0000000..744e1b7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> > > @@ -0,0 +1,294 @@
> > > +NVIDIA Tegra 2 pinmux controller
> > > +
> > > +Required properties:
> > > +- compatible : "nvidia,tegra20-pinmux"
> > 
> > Hmm, I think it would be much better in general if we could define
> > pinmux bindings in a way that is less specific to just one soc.
> 
> > The contents of this file seem to be specific to even just one
> > version of the tegra chip, and might be completely different for
> > tegra30 and later, right?
> 
> The general concepts are the same between tegra20 and tegra30.
> 
> Tegra30 has a different set of mux and drive pingroups.
> 
> Tegra30 has more functions that can be assigned to pins.
> 
> Tegra30 has three more options per mux pingroup, although I haven't
> Investigated whether any of those would need to be represented in DT;
> I suspect at least one will, possibly all.
> 
> > Maybe Linus W can comment on this and say whether he thinks it can
> > be generalized enough to apply to other pinmux drivers.
> > 
> > > +Optional sub-nodes:
> > > +- nvidia,mux-groups : Mux group settings; see below.
> > > +- nvidia,drive-groups : Drive group settings; see below.
> > > +
> > > +nvidia,mux-groups sub-node:
> > 
> > These concepts seem general enough to me that they can apply to
> > other chips, and I would consequently drop the nvidia, prefix.
> 
> Two things to note about Tegra that might not apply to all SoCs:
> 
> * There are separate groups of pins for Muxing (plus some config) vs.
> drive-strength (and related config). Some SoCs might use the same set
> of groups for both. Perhaps some SoC might even have three or more types
> of groups! I expect this to have some impact on the binding; I created
> explicit mux-groups and drive-groups sub-nodes to represent this.
> 
> * Tegra's pinmux apply settings to groups of pins instead of individual
> pins. Some SoCs might allow each setting to be configurable per-pin.
> I don't expect this to have any impact as far as the bindings go though;
> it'll simply impact the names of the available pin "groups"; some SoCs
> will name groups, others pins.
> 
+1

imx's pinmux applies settings to individual pins.

> > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node.
> > > +The name of the sub-node should be the name of the mux pingroup. The following
> > > +names are valid:
> > > +
> > > +	ata
> > > +	atb
> > > +	atc
> > > +	atd
> > > +	ate
> > > +	cdev1
> > > +	cdev2
> > > ...
> > 
> > I noticed that each board you define has a complete list of these. Would
> > it be possible to move a generic list into a tegra20-pinmux.dtsi file and
> > just override the pins in the per-board .dts file that require some special
> > setup?
> 

It sounds sane for imx though.  I'm going to take this suggestion to
have imx53-pinmux.dtsi holding register offset for each pin, which is
common across all i.mx53 boards.

> I'm not sure how much commonality there will really be.
> 
> Certainly, many boards are based off our reference designs and so will
> have many similarities that could be shared.
> 
> That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows
> a lot of differences. It seems a lot less error-prone to just completely
> describe the entire pinmux state in each board's .dts file, rather than
> trying to represent half the information as default in the SoC .dtsi file,
> and just the diff in the board .dts file. I suppose perhaps if we put the
> hardware's own default settings in tegra20.dtsi, that'd make sense, since
> people are presumably reasonably aware of the delta relative to that.
> 
> We'd need to add new properties to override defaults, like:
> 
> nvidia,tristate --> nvidia,drive
> nvidia,pull-*   --> nvidia,no-pull
> 
> > > +
> > > +optional subnode-properties:
> > > +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin.
> > > +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin.
> > > +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it.
> > > +
> > > +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up
> > > +takes precedence.
> > 
> > These again seem generic enough to go into a general pinmux binding, without
> > the nvidia, prefix.
> 
> Yes, I believe Jamie Iles was going to try cooking up a generic core binding
> that could be shared across different SoCs, and extended with custom stuff.
> 
I would image that whatever common binding for pin/pad configuration
comes can hardly work for imx out of box.  For each pin/pad, imx have
4 configurations for pull:

  00: 100KOhm Pull Down
  01: 47KOhm Pull Up
  10: 100KOhm Pull Up
  11: 22KOhm Pull Up

4 configurations for drive:

  00: 100KOhm Pull Down
  01: 47KOhm Pull Up
  10: 100KOhm Pull Up
  11: 22KOhm Pull Up

some other 1 bit configuration fields:

  low/high output voltage Field
  Hyst. Enable Field
  Pull / Keep Enable Field
  Pull / Keep Select Field
  Slew Rate Field

All these are all in one register <pad_name>_PAD_CTL (mux configuration
is in another register <pad_name>_PAD_MUX).  The best binding for
PAD_CTL I can think of so far is to encode the register value in DT
directly.

-- 
Regards,
Shawn

Re: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Shawn Guo]

On Wed, Aug 17, 2011 at 02:02:43PM +0800, Shawn Guo wrote:
> On Tue, Aug 16, 2011 at 10:32:05AM -0700, Stephen Warren wrote:
> > Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM:
> > > On Monday 15 August 2011, Stephen Warren wrote:
> > > > Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > > ---
> > > >  .../devicetree/bindings/pinmux/pinmux_nvidia.txt   |  294 ++++++++++++++++++++
> > > >  1 files changed, 294 insertions(+), 0 deletions(-)
> > > >  create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> > > > new file mode 100644
> > > > index 0000000..744e1b7
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
> > > > @@ -0,0 +1,294 @@
> > > > +NVIDIA Tegra 2 pinmux controller
> > > > +
> > > > +Required properties:
> > > > +- compatible : "nvidia,tegra20-pinmux"
> > > 
> > > Hmm, I think it would be much better in general if we could define
> > > pinmux bindings in a way that is less specific to just one soc.
> > 
> > > The contents of this file seem to be specific to even just one
> > > version of the tegra chip, and might be completely different for
> > > tegra30 and later, right?
> > 
> > The general concepts are the same between tegra20 and tegra30.
> > 
> > Tegra30 has a different set of mux and drive pingroups.
> > 
> > Tegra30 has more functions that can be assigned to pins.
> > 
> > Tegra30 has three more options per mux pingroup, although I haven't
> > Investigated whether any of those would need to be represented in DT;
> > I suspect at least one will, possibly all.
> > 
> > > Maybe Linus W can comment on this and say whether he thinks it can
> > > be generalized enough to apply to other pinmux drivers.
> > > 
> > > > +Optional sub-nodes:
> > > > +- nvidia,mux-groups : Mux group settings; see below.
> > > > +- nvidia,drive-groups : Drive group settings; see below.
> > > > +
> > > > +nvidia,mux-groups sub-node:
> > > 
> > > These concepts seem general enough to me that they can apply to
> > > other chips, and I would consequently drop the nvidia, prefix.
> > 
> > Two things to note about Tegra that might not apply to all SoCs:
> > 
> > * There are separate groups of pins for Muxing (plus some config) vs.
> > drive-strength (and related config). Some SoCs might use the same set
> > of groups for both. Perhaps some SoC might even have three or more types
> > of groups! I expect this to have some impact on the binding; I created
> > explicit mux-groups and drive-groups sub-nodes to represent this.
> > 
> > * Tegra's pinmux apply settings to groups of pins instead of individual
> > pins. Some SoCs might allow each setting to be configurable per-pin.
> > I don't expect this to have any impact as far as the bindings go though;
> > it'll simply impact the names of the available pin "groups"; some SoCs
> > will name groups, others pins.
> > 
> +1
> 
> imx's pinmux applies settings to individual pins.
> 
> > > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node.
> > > > +The name of the sub-node should be the name of the mux pingroup. The following
> > > > +names are valid:
> > > > +
> > > > +	ata
> > > > +	atb
> > > > +	atc
> > > > +	atd
> > > > +	ate
> > > > +	cdev1
> > > > +	cdev2
> > > > ...
> > > 
> > > I noticed that each board you define has a complete list of these. Would
> > > it be possible to move a generic list into a tegra20-pinmux.dtsi file and
> > > just override the pins in the per-board .dts file that require some special
> > > setup?
> > 
> 
> It sounds sane for imx though.  I'm going to take this suggestion to
> have imx53-pinmux.dtsi holding register offset for each pin, which is
> common across all i.mx53 boards.
> 
> > I'm not sure how much commonality there will really be.
> > 
> > Certainly, many boards are based off our reference designs and so will
> > have many similarities that could be shared.
> > 
> > That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows
> > a lot of differences. It seems a lot less error-prone to just completely
> > describe the entire pinmux state in each board's .dts file, rather than
> > trying to represent half the information as default in the SoC .dtsi file,
> > and just the diff in the board .dts file. I suppose perhaps if we put the
> > hardware's own default settings in tegra20.dtsi, that'd make sense, since
> > people are presumably reasonably aware of the delta relative to that.
> > 
> > We'd need to add new properties to override defaults, like:
> > 
> > nvidia,tristate --> nvidia,drive
> > nvidia,pull-*   --> nvidia,no-pull
> > 
> > > > +
> > > > +optional subnode-properties:
> > > > +- nvidia,pull-up : Boolean, apply Tegra's internal pull-up to the pin.
> > > > +- nvidia,pull-down : Boolean, apply Tegra's internal pull-down to the pin.
> > > > +- nvidia,tristate : Boolean, tristate the pin. Otherwise, drive it.
> > > > +
> > > > +If both nvidia,pull-up and nvidia,pull-down are specified, nvidia,pull-up
> > > > +takes precedence.
> > > 
> > > These again seem generic enough to go into a general pinmux binding, without
> > > the nvidia, prefix.
> > 
> > Yes, I believe Jamie Iles was going to try cooking up a generic core binding
> > that could be shared across different SoCs, and extended with custom stuff.
> > 
> I would image that whatever common binding for pin/pad configuration
> comes can hardly work for imx out of box.  For each pin/pad, imx have
> 4 configurations for pull:
> 
>   00: 100KOhm Pull Down
>   01: 47KOhm Pull Up
>   10: 100KOhm Pull Up
>   11: 22KOhm Pull Up
> 
> 4 configurations for drive:
> 
>   00: 100KOhm Pull Down
>   01: 47KOhm Pull Up
>   10: 100KOhm Pull Up
>   11: 22KOhm Pull Up
> 
Correction:

  00 Low Drive Strength
  01 Medium Drive Strength
  10 High Drive Strength
  11 Max Drive Strength

> some other 1 bit configuration fields:
> 
>   low/high output voltage Field
>   Hyst. Enable Field
>   Pull / Keep Enable Field
>   Pull / Keep Select Field
>   Slew Rate Field
> 
> All these are all in one register <pad_name>_PAD_CTL (mux configuration
> is in another register <pad_name>_PAD_MUX).  The best binding for
> PAD_CTL I can think of so far is to encode the register value in DT
> directly.
> 

-- 
Regards,
Shawn

Re: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Arnd Bergmann]

On Tuesday 16 August 2011, Stephen Warren wrote:
> Arnd Bergmann wrote at Tuesday, August 16, 2011 7:52 AM:
> > On Monday 15 August 2011, Stephen Warren wrote:
> 
> > The contents of this file seem to be specific to even just one
> > version of the tegra chip, and might be completely different for
> > tegra30 and later, right?
> 
> The general concepts are the same between tegra20 and tegra30.
> 
> Tegra30 has a different set of mux and drive pingroups.
> 
> Tegra30 has more functions that can be assigned to pins.
> 
> Tegra30 has three more options per mux pingroup, although I haven't
> Investigated whether any of those would need to be represented in DT;
> I suspect at least one will, possibly all.

Thanks for the info!
 
> Two things to note about Tegra that might not apply to all SoCs:
> 
> * There are separate groups of pins for Muxing (plus some config) vs.
> drive-strength (and related config). Some SoCs might use the same set
> of groups for both. Perhaps some SoC might even have three or more types
> of groups! I expect this to have some impact on the binding; I created
> explicit mux-groups and drive-groups sub-nodes to represent this.
>
> * Tegra's pinmux apply settings to groups of pins instead of individual
> pins. Some SoCs might allow each setting to be configurable per-pin.
> I don't expect this to have any impact as far as the bindings go though;
> it'll simply impact the names of the available pin "groups"; some SoCs
> will name groups, others pins.

ok, makes sense. So if we want to have a general binding that applies
to all, we really need to cover a lot of different ways to set these up.

> > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node.
> > > +The name of the sub-node should be the name of the mux pingroup. The following
> > > +names are valid:
> > > +
> > > +	ata
> > > +	atb
> > > +	atc
> > > +	atd
> > > +	ate
> > > +	cdev1
> > > +	cdev2
> > > ...
> > 
> > I noticed that each board you define has a complete list of these. Would
> > it be possible to move a generic list into a tegra20-pinmux.dtsi file and
> > just override the pins in the per-board .dts file that require some special
> > setup?
> 
> I'm not sure how much commonality there will really be.
> 
> Certainly, many boards are based off our reference designs and so will
> have many similarities that could be shared.
> 
> That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows
> a lot of differences. It seems a lot less error-prone to just completely
> describe the entire pinmux state in each board's .dts file, rather than
> trying to represent half the information as default in the SoC .dtsi file,
> and just the diff in the board .dts file. I suppose perhaps if we put the
> hardware's own default settings in tegra20.dtsi, that'd make sense, since
> people are presumably reasonably aware of the delta relative to that.
> 
> We'd need to add new properties to override defaults, like:
> 
> nvidia,tristate --> nvidia,drive
> nvidia,pull-*   --> nvidia,no-pull

The split I had in mind is more to the effect that the .dtsi file
describes the set of pins that is there with their names and addresses,
while the board specific file describes how they are set up. Does that
make sense? I think I'm still missing some essential aspect of what the
pinmux code actually does ;-)

I now saw that you have the full description in the
arch/arm/mach-tegra/pinmux-t2-tables.c and arch/arm/mach-tegra/pinmux.c
files, with all the names again, and apparently your patch set leaves
these around. Do you think it's possible to actually move the static
tables from there into the device tree and do the entire setup based
on that?

	Arnd

Re: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Jamie Iles]

Hi Arnd,

On Wed, Aug 17, 2011 at 01:37:25PM +0200, Arnd Bergmann wrote:
> The split I had in mind is more to the effect that the .dtsi file
> describes the set of pins that is there with their names and addresses,
> while the board specific file describes how they are set up. Does that
> make sense? I think I'm still missing some essential aspect of what the
> pinmux code actually does ;-)
> 
> I now saw that you have the full description in the
> arch/arm/mach-tegra/pinmux-t2-tables.c and arch/arm/mach-tegra/pinmux.c
> files, with all the names again, and apparently your patch set leaves
> these around. Do you think it's possible to actually move the static
> tables from there into the device tree and do the entire setup based
> on that?

The platform I'm working on has a different method of muxing for almost 
every pin (some aren't even memory mapped registers) so defining the SoC 
pin definitions in the DTS could result in some pretty horrible 
bindings.

Stephens bindings for configuring the muxing of the pins works quite 
nicely for our platform though, and I'm just about to post patches that 
abstract the tegra specific bits out.

Jamie

RE: [RFC PATCH v2 06/13] docs/dt: Document nvidia,tegra20-pinmux binding

[Stephen Warren]

Arnd Bergmann wrote at Wednesday, August 17, 2011 5:37 AM:
...
> > > > +Each mux pin group is represented as a sub-node of the nvidia,mux-groups node.
> > > > +The name of the sub-node should be the name of the mux pingroup. The following
> > > > +names are valid:
> > > > +
> > > > +	ata
> > > > +	atb
> > > > +	atc
> > > > +	atd
> > > > +	ate
> > > > +	cdev1
> > > > +	cdev2
> > > > ...
> > >
> > > I noticed that each board you define has a complete list of these. Would
> > > it be possible to move a generic list into a tegra20-pinmux.dtsi file and
> > > just override the pins in the per-board .dts file that require some special
> > > setup?
> >
> > I'm not sure how much commonality there will really be.
> >
> > Certainly, many boards are based off our reference designs and so will
> > have many similarities that could be shared.
> >
> > That said, comparing even tegra-harmony.dts and tegra-seaboard.dts shows
> > a lot of differences. It seems a lot less error-prone to just completely
> > describe the entire pinmux state in each board's .dts file, rather than
> > trying to represent half the information as default in the SoC .dtsi file,
> > and just the diff in the board .dts file. I suppose perhaps if we put the
> > hardware's own default settings in tegra20.dtsi, that'd make sense, since
> > people are presumably reasonably aware of the delta relative to that.
> >
> > We'd need to add new properties to override defaults, like:
> >
> > nvidia,tristate --> nvidia,drive
> > nvidia,pull-*   --> nvidia,no-pull
> 
> The split I had in mind is more to the effect that the .dtsi file
> describes the set of pins that is there with their names and addresses,
> while the board specific file describes how they are set up. Does that
> make sense? I think I'm still missing some essential aspect of what the
> pinmux code actually does ;-)
> 
> I now saw that you have the full description in the
> arch/arm/mach-tegra/pinmux-t2-tables.c and arch/arm/mach-tegra/pinmux.c
> files, with all the names again, and apparently your patch set leaves
> these around. Do you think it's possible to actually move the static
> tables from there into the device tree and do the entire setup based
> on that?

Ah, so you're looking for tegra20.dtsi to define the set pin groups that
can be configured, and tegra-harmony.dts to provide the configuration for
each of those pingroups.

As you see from my patches, I had assumed that the Tegra pinmux driver
would be what ended up defining the available pin groups, the register
addresses and fields for those groups, just like it does today. The DT
would only provide the configuration for each group. That's the reason
I didn't understand your questions the first time around.

So yes, I think we could represent the set of available pin groups in
tegra20.dtsi; it's just some data tables. I don't think this provides as
much benefit as moving the per-board configuration data into DT though,
because it changes only per SoC generation, not per board.

Still, putting the list of pingroups in tegra20.dtsi does move that data
out of the kernel, although it bloats each DTB with almost static data
that'll take a bunch of time to parse. It's worth considering though.

I'm unclear how to resolve where the best location for the data is though;
should we just go ahead and move it from the pinmux driver to DT right now,
or discuss more or ...?

-- 
nvpublic

[RFC PATCH v2 07/13] arm/dt: Tegra: Add pinmux node

[Stephen Warren]

Add a pinmux node to tegra20.dtsi in order to instantiate the future
pinmux device. Add pinmux nodes to Harmony and Seaboard, which detail
the entire initial pinmux configuration. This configuration is identical
to that in board-harmony/seaboard-pinmux.c.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra-harmony.dts  |  468 ++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/tegra-seaboard.dts |  413 ++++++++++++++++++++++++++++++
 arch/arm/boot/dts/tegra20.dtsi       |    5 +
 3 files changed, 886 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra-harmony.dts b/arch/arm/boot/dts/tegra-harmony.dts
index d680707..e84a7fa 100644
--- a/arch/arm/boot/dts/tegra-harmony.dts
+++ b/arch/arm/boot/dts/tegra-harmony.dts
@@ -30,6 +30,474 @@
 		>;
 	};
 
+	pinmux: pinmux@70000000 {
+		nvidia,mux-groups {
+			ata {
+				nvidia,function = "ide";
+			};
+			atb {
+				nvidia,function = "sdio4";
+			};
+			atc {
+				nvidia,function = "nand";
+			};
+			atd {
+				nvidia,function = "gmi";
+			};
+			ate {
+				nvidia,function = "gmi";
+			};
+			cdev1 {
+				nvidia,function = "plla_out";
+			};
+			cdev2 {
+				nvidia,function = "pllp_out4";
+				nvidia,pull-down;
+				nvidia,tristate;
+			};
+			crtp {
+				nvidia,function = "crt";
+				nvidia,tristate;
+			};
+			csus {
+				nvidia,function = "vi_sensor_clk";
+				nvidia,pull-down;
+				nvidia,tristate;
+			};
+			dap1 {
+				nvidia,function = "dap1";
+			};
+			dap2 {
+				nvidia,function = "dap2";
+				nvidia,tristate;
+			};
+			dap3 {
+				nvidia,function = "dap3";
+				nvidia,tristate;
+			};
+			dap4 {
+				nvidia,function = "dap4";
+				nvidia,tristate;
+			};
+			ddc {
+				nvidia,function = "i2c2";
+				nvidia,pull-up;
+			};
+			dta {
+				nvidia,function = "sdio2";
+				nvidia,pull-up;
+			};
+			dtb {
+				nvidia,function = "rsvd1";
+			};
+			dtc {
+				nvidia,function = "rsvd1";
+				nvidia,tristate;
+			};
+			dtd {
+				nvidia,function = "sdio2";
+				nvidia,pull-up;
+			};
+			dte {
+				nvidia,function = "rsvd1";
+				nvidia,tristate;
+			};
+			dtf {
+				nvidia,function = "i2c3";
+				nvidia,tristate;
+			};
+			gma {
+				nvidia,function = "sdio4";
+			};
+			gmb {
+				nvidia,function = "gmi";
+			};
+			gmc {
+				nvidia,function = "uartd";
+			};
+			gmd {
+				nvidia,function = "gmi";
+			};
+			gme {
+				nvidia,function = "sdio4";
+			};
+			gpu {
+				nvidia,function = "gmi";
+				nvidia,tristate;
+			};
+			gpu7 {
+				nvidia,function = "rtck";
+			};
+			gpv {
+				nvidia,function = "pcie";
+				nvidia,tristate;
+			};
+			hdint {
+				nvidia,function = "hdmi";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			i2cp {
+				nvidia,function = "i2c";
+			};
+			irrx {
+				nvidia,function = "uarta";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			irtx {
+				nvidia,function = "uarta";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			kbca {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbcb {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbcc {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbcd {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbce {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbcf {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			lcsn {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			ld0 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld1 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld10 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld11 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld12 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld13 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld14 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld15 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld16 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld17 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld2 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld3 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld4 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld5 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld6 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld7 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld8 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ld9 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			ldc {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			ldi {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			lhp0 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			lhp1 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			lhp2 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			lhs {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+			};
+			lm0 {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+			};
+			lm1 {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			lpp {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			lpw0 {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+			};
+			lpw1 {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			lpw2 {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+			};
+			lsc0 {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+			};
+			lsc1 {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			lsck {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			lsda {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			lsdi {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			lspi {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+			};
+			lvp0 {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			lvp1 {
+				nvidia,function = "displaya";
+				nvidia,pull-down;
+			};
+			lvs {
+				nvidia,function = "displaya";
+				nvidia,pull-up;
+			};
+			owc {
+				nvidia,function = "rsvd2";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			pmc {
+				nvidia,function = "pwr_on";
+			};
+			pta {
+				nvidia,function = "hdmi";
+			};
+			rm {
+				nvidia,function = "i2c";
+			};
+			sdb {
+				nvidia,function = "pwm";
+				nvidia,tristate;
+			};
+			sdc {
+				nvidia,function = "pwm";
+				nvidia,pull-up;
+			};
+			sdd {
+				nvidia,function = "pwm";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			sdio1 {
+				nvidia,function = "sdio1";
+				nvidia,tristate;
+			};
+			slxa {
+				nvidia,function = "pcie";
+				nvidia,tristate;
+			};
+			slxc {
+				nvidia,function = "spdif";
+				nvidia,tristate;
+			};
+			slxd {
+				nvidia,function = "spdif";
+				nvidia,tristate;
+			};
+			slxk {
+				nvidia,function = "pcie";
+				nvidia,tristate;
+			};
+			spdi {
+				nvidia,function = "rsvd2";
+				nvidia,tristate;
+			};
+			spdo {
+				nvidia,function = "rsvd2";
+				nvidia,tristate;
+			};
+			spia {
+				nvidia,function = "gmi";
+			};
+			spib {
+				nvidia,function = "gmi";
+			};
+			spic {
+				nvidia,function = "gmi";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			spid {
+				nvidia,function = "spi1";
+				nvidia,pull-down;
+				nvidia,tristate;
+			};
+			spie {
+				nvidia,function = "spi1";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			spif {
+				nvidia,function = "spi1";
+				nvidia,pull-down;
+				nvidia,tristate;
+			};
+			spig {
+				nvidia,function = "spi2_alt";
+				nvidia,tristate;
+			};
+			spih {
+				nvidia,function = "spi2_alt";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			uaa {
+				nvidia,function = "ulpi";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			uab {
+				nvidia,function = "ulpi";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			uac {
+				nvidia,function = "rsvd2";
+				nvidia,tristate;
+			};
+			uad {
+				nvidia,function = "irda";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			uca {
+				nvidia,function = "uartc";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			ucb {
+				nvidia,function = "uartc";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			uda {
+				nvidia,function = "ulpi";
+				nvidia,tristate;
+			};
+			ck32 {
+				nvidia,function = "none";
+			};
+			ddrc {
+				nvidia,function = "none";
+			};
+			pmca {
+				nvidia,function = "none";
+			};
+			pmcb {
+				nvidia,function = "none";
+			};
+			pmcc {
+				nvidia,function = "none";
+			};
+			pmcd {
+				nvidia,function = "none";
+			};
+			pmce {
+				nvidia,function = "none";
+			};
+			xm2c {
+				nvidia,function = "none";
+			};
+			xm2d {
+				nvidia,function = "none";
+			};
+		};
+		nvidia,drive-groups {
+		};
+	};
+
 	i2c@7000c000 {
 		clock-frequency = <400000>;
 
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts b/arch/arm/boot/dts/tegra-seaboard.dts
index 43c8b2c..29114b7 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -24,6 +24,419 @@
 		>;
 	};
 
+	pinmux: pinmux@70000000 {
+		nvidia,mux-groups {
+			ata {
+				nvidia,function = "ide";
+			};
+			atb {
+				nvidia,function = "sdio4";
+			};
+			atc {
+				nvidia,function = "nand";
+			};
+			atd {
+				nvidia,function = "gmi";
+			};
+			ate {
+				nvidia,function = "gmi";
+				nvidia,tristate;
+			};
+			cdev1 {
+				nvidia,function = "plla_out";
+			};
+			cdev2 {
+				nvidia,function = "pllp_out4";
+			};
+			crtp {
+				nvidia,function = "crt";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			csus {
+				nvidia,function = "vi_sensor_clk";
+				nvidia,tristate;
+			};
+			dap1 {
+				nvidia,function = "dap1";
+			};
+			dap2 {
+				nvidia,function = "dap2";
+			};
+			dap3 {
+				nvidia,function = "dap3";
+				nvidia,tristate;
+			};
+			dap4 {
+				nvidia,function = "dap4";
+			};
+			ddc {
+				nvidia,function = "rsvd2";
+				nvidia,tristate;
+			};
+			dta {
+				nvidia,function = "vi";
+				nvidia,pull-down;
+			};
+			dtb {
+				nvidia,function = "vi";
+				nvidia,pull-down;
+			};
+			dtc {
+				nvidia,function = "vi";
+				nvidia,pull-down;
+			};
+			dtd {
+				nvidia,function = "vi";
+				nvidia,pull-down;
+			};
+			dte {
+				nvidia,function = "vi";
+				nvidia,pull-down;
+				nvidia,tristate;
+			};
+			dtf {
+				nvidia,function = "i2c3";
+			};
+			gma {
+				nvidia,function = "sdio4";
+			};
+			gmb {
+				nvidia,function = "gmi";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			gmc {
+				nvidia,function = "uartd";
+			};
+			gmd {
+				nvidia,function = "sflash";
+			};
+			gme {
+				nvidia,function = "sdio4";
+			};
+			gpu {
+				nvidia,function = "pwm";
+			};
+			gpu7 {
+				nvidia,function = "rtck";
+			};
+			gpv {
+				nvidia,function = "pcie";
+				nvidia,tristate;
+			};
+			hdint {
+				nvidia,function = "hdmi";
+				nvidia,tristate;
+			};
+			i2cp {
+				nvidia,function = "i2c";
+			};
+			irrx {
+				nvidia,function = "uartb";
+			};
+			irtx {
+				nvidia,function = "uartb";
+			};
+			kbca {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbcb {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbcc {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbcd {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbce {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			kbcf {
+				nvidia,function = "kbc";
+				nvidia,pull-up;
+			};
+			lcsn {
+				nvidia,function = "rsvd4";
+				nvidia,tristate;
+			};
+			ld0 {
+				nvidia,function = "displaya";
+			};
+			ld1 {
+				nvidia,function = "displaya";
+			};
+			ld10 {
+				nvidia,function = "displaya";
+			};
+			ld11 {
+				nvidia,function = "displaya";
+			};
+			ld12 {
+				nvidia,function = "displaya";
+			};
+			ld13 {
+				nvidia,function = "displaya";
+			};
+			ld14 {
+				nvidia,function = "displaya";
+			};
+			ld15 {
+				nvidia,function = "displaya";
+			};
+			ld16 {
+				nvidia,function = "displaya";
+			};
+			ld17 {
+				nvidia,function = "displaya";
+			};
+			ld2 {
+				nvidia,function = "displaya";
+			};
+			ld3 {
+				nvidia,function = "displaya";
+			};
+			ld4 {
+				nvidia,function = "displaya";
+			};
+			ld5 {
+				nvidia,function = "displaya";
+			};
+			ld6 {
+				nvidia,function = "displaya";
+			};
+			ld7 {
+				nvidia,function = "displaya";
+			};
+			ld8 {
+				nvidia,function = "displaya";
+			};
+			ld9 {
+				nvidia,function = "displaya";
+			};
+			ldc {
+				nvidia,function = "rsvd4";
+				nvidia,tristate;
+			};
+			ldi {
+				nvidia,function = "displaya";
+			};
+			lhp0 {
+				nvidia,function = "displaya";
+			};
+			lhp1 {
+				nvidia,function = "displaya";
+			};
+			lhp2 {
+				nvidia,function = "displaya";
+			};
+			lhs {
+				nvidia,function = "displaya";
+			};
+			lm0 {
+				nvidia,function = "rsvd4";
+			};
+			lm1 {
+				nvidia,function = "crt";
+				nvidia,tristate;
+			};
+			lpp {
+				nvidia,function = "displaya";
+			};
+			lpw0 {
+				nvidia,function = "hdmi";
+			};
+			lpw1 {
+				nvidia,function = "rsvd4";
+				nvidia,tristate;
+			};
+			lpw2 {
+				nvidia,function = "hdmi";
+			};
+			lsc0 {
+				nvidia,function = "displaya";
+			};
+			lsc1 {
+				nvidia,function = "hdmi";
+				nvidia,tristate;
+			};
+			lsck {
+				nvidia,function = "hdmi";
+				nvidia,tristate;
+			};
+			lsda {
+				nvidia,function = "hdmi";
+				nvidia,tristate;
+			};
+			lsdi {
+				nvidia,function = "rsvd4";
+				nvidia,tristate;
+			};
+			lspi {
+				nvidia,function = "displaya";
+			};
+			lvp0 {
+				nvidia,function = "rsvd4";
+				nvidia,tristate;
+			};
+			lvp1 {
+				nvidia,function = "displaya";
+			};
+			lvs {
+				nvidia,function = "displaya";
+			};
+			owc {
+				nvidia,function = "rsvd2";
+				nvidia,tristate;
+			};
+			pmc {
+				nvidia,function = "pwr_on";
+			};
+			pta {
+				nvidia,function = "hdmi";
+			};
+			rm {
+				nvidia,function = "i2c";
+			};
+			sdb {
+				nvidia,function = "sdio3";
+			};
+			sdc {
+				nvidia,function = "sdio3";
+			};
+			sdd {
+				nvidia,function = "sdio3";
+			};
+			sdio1 {
+				nvidia,function = "sdio1";
+				nvidia,pull-up;
+			};
+			slxa {
+				nvidia,function = "pcie";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			slxc {
+				nvidia,function = "spdif";
+				nvidia,tristate;
+			};
+			slxd {
+				nvidia,function = "spdif";
+			};
+			slxk {
+				nvidia,function = "pcie";
+			};
+			spdi {
+				nvidia,function = "rsvd2";
+			};
+			spdo {
+				nvidia,function = "rsvd2";
+			};
+			spia {
+				nvidia,function = "gmi";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			spib {
+				nvidia,function = "gmi";
+				nvidia,tristate;
+			};
+			spic {
+				nvidia,function = "gmi";
+				nvidia,pull-up;
+			};
+			spid {
+				nvidia,function = "spi1";
+				nvidia,tristate;
+			};
+			spie {
+				nvidia,function = "spi1";
+				nvidia,tristate;
+			};
+			spif {
+				nvidia,function = "spi1";
+				nvidia,pull-down;
+				nvidia,tristate;
+			};
+			spig {
+				nvidia,function = "spi2_alt";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			spih {
+				nvidia,function = "spi2_alt";
+				nvidia,pull-up;
+				nvidia,tristate;
+			};
+			uaa {
+				nvidia,function = "ulpi";
+				nvidia,pull-up;
+			};
+			uab {
+				nvidia,function = "ulpi";
+				nvidia,pull-up;
+			};
+			uac {
+				nvidia,function = "rsvd2";
+			};
+			uad {
+				nvidia,function = "irda";
+			};
+			uca {
+				nvidia,function = "uartc";
+			};
+			ucb {
+				nvidia,function = "uartc";
+			};
+			uda {
+				nvidia,function = "ulpi";
+			};
+			ck32 {
+				nvidia,function = "none";
+			};
+			ddrc {
+				nvidia,function = "none";
+			};
+			pmca {
+				nvidia,function = "none";
+			};
+			pmcb {
+				nvidia,function = "none";
+			};
+			pmcc {
+				nvidia,function = "none";
+			};
+			pmcd {
+				nvidia,function = "none";
+			};
+			pmce {
+				nvidia,function = "none";
+			};
+			xm2c {
+				nvidia,function = "none";
+			};
+			xm2d {
+				nvidia,function = "none";
+			};
+		};
+		nvidia,drive-groups {
+			sdio1 {
+				nvidia,schmitt;
+				nvidia,drive-power = <3>;
+				nvidia,pull-down-strength = <31>;
+				nvidia,pull-up-strength = <31>;
+				nvidia,slew-rate-rising = <3>;
+				nvidia,slew-rate-falling = <3>;
+			};
+		};
+	};
+
 	serial@70006300 {
 		clock-frequency = < 216000000 >;
 	};
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 5727595..5921c1d 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -77,6 +77,11 @@
 		gpio-controller;
 	};
 
+	pinmux: pinmux@70000000 {
+		compatible = "nvidia,tegra20-pinmux";
+		reg = < 0x70000000 0xc00 >;
+	};
+
 	serial@70006000 {
 		compatible = "nvidia,tegra20-uart";
 		reg = <0x70006000 0x40>;
-- 
1.7.0.4

[RFC PATCH v2 08/13] gpio/tegra: Convert to a platform device

[Stephen Warren]

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 drivers/gpio/gpio-tegra.c |   25 ++++++++++++++-----------
 1 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index df64536..4da4839 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -20,10 +20,10 @@
 #include <linux/init.h>
 #include <linux/irq.h>
 #include <linux/interrupt.h>
-
 #include <linux/io.h>
 #include <linux/gpio.h>
 #include <linux/of.h>
+#include <linux/platform_device.h>
 
 #include <asm/mach/irq.h>
 
@@ -332,7 +332,7 @@ static struct irq_chip tegra_gpio_irq_chip = {
  */
 static struct lock_class_key gpio_lock_class;
 
-static int __init tegra_gpio_init(void)
+static int __init tegra_gpio_probe(struct platform_device *pdev)
 {
 	struct tegra_gpio_bank *bank;
 	int gpio;
@@ -346,15 +346,6 @@ static int __init tegra_gpio_init(void)
 		}
 	}
 
-#ifdef CONFIG_OF_GPIO
-	/*
-	 * This isn't ideal, but it gets things hooked up until this
-	 * driver is converted into a platform_device
-	 */
-	tegra_gpio_chip.of_node = of_find_compatible_node(NULL, NULL,
-						"nvidia,tegra20-gpio");
-#endif /* CONFIG_OF_GPIO */
-
 	gpiochip_add(&tegra_gpio_chip);
 
 	for (gpio = 0; gpio < TEGRA_NR_GPIOS; gpio++) {
@@ -383,6 +374,18 @@ static int __init tegra_gpio_init(void)
 	return 0;
 }
 
+static struct platform_driver tegra_gpio_driver = {
+	.driver		= {
+		.name	= "tegra-gpio",
+		.owner	= THIS_MODULE,
+	},
+	.probe		= tegra_gpio_probe,
+};
+
+static int __init tegra_gpio_init(void)
+{
+	return platform_driver_register(&tegra_gpio_driver);
+}
 postcore_initcall(tegra_gpio_init);
 
 void __init tegra_gpio_config(struct tegra_gpio_table *table, int num)
-- 
1.7.0.4

[RFC PATCH v2 10/13] arm/tegra: Convert pinmux driver to a platform device

[Stephen Warren]

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/mach-tegra/pinmux.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
index f80d507..ed316f9 100644
--- a/arch/arm/mach-tegra/pinmux.c
+++ b/arch/arm/mach-tegra/pinmux.c
@@ -20,6 +20,7 @@
 #include <linux/errno.h>
 #include <linux/spinlock.h>
 #include <linux/io.h>
+#include <linux/platform_device.h>
 
 #include <mach/iomap.h>
 #include <mach/pinmux.h>
@@ -665,6 +666,25 @@ void tegra_pinmux_config_pullupdown_table(const struct tegra_pingroup_config *co
 	}
 }
 
+static int __init tegra_pinmux_probe(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static struct platform_driver tegra_pinmux_driver = {
+	.driver		= {
+		.name	= "tegra-pinmux",
+		.owner	= THIS_MODULE,
+	},
+	.probe		= tegra_pinmux_probe,
+};
+
+static int __init tegra_pinmux_init(void)
+{
+	return platform_driver_register(&tegra_pinmux_driver);
+}
+postcore_initcall(tegra_pinmux_init);
+
 #ifdef	CONFIG_DEBUG_FS
 
 #include <linux/debugfs.h>
-- 
1.7.0.4

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Arnd Bergmann]

On Monday 15 August 2011, Stephen Warren wrote:
> v2:
> * Enhanced pinmux code to handle "drive pingroups" as well as "mux
>   pingroups". This altered the pinmux binding a little; shifting each
>   type of pingroup into a sub-node in the pinmux node.
> * Enumerate pingroups by enumerating DT child nodes, and mapping them to
>   pingroups, rather than the other way around. Hence also removed
>   modifications to <linux/of.h> and drivers/of/base.c.
> * Included documentation of the bindings.
> * Represent pingroup names and function names, as lower case in DT.
> * Used a better name for GPIO binding GPIO list.
> * Switched to boolean properties for pinmux pull-up/down.
> * s/dev_err/dev_dbg/ in DT parsing debug code.
> * Various minor cleanups (e.g. typos, white-space).
> 
> This patch modifies Tegra's device tree support to remove the dependency
> on harmony_pinmux_init(), thus making it completely board-independent.

I don't understand enough of the technical background to comment on
the contents, on the surface it all makes sense.

I do think that you should keep Linus Walleij on Cc in these emails, since
he first started pushing for a common pinmux layer, and we need to make
sure that the binding works for all SoCs, not just for tegra.

	Arnd

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Linus Walleij]

On Tue, Aug 16, 2011 at 3:09 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:

> I do think that you should keep Linus Walleij on Cc in these emails, since
> he first started pushing for a common pinmux layer, and we need to make
> sure that the binding works for all SoCs, not just for tegra.

Sorry for slipping off the pinmux stuff, I will make it my goal to recap
discussion and try to post a new patchset this week.

Concepts have grown, I see Stephen have created the new concept
of e.g. bias groups which is a real good idea

One problem is that I wanted to start out small with the pinctrl
subsystem, and now it looks like it has to do a *lot* of stuff from
day 1 to be of any use ...

One specific thing worries me: Grant asked me to make sure
to NOT create a global pin number space for the pinmuxes (and thus
pinctrl). This means that in order to proceed, mappings of pinmux
groups or pincontrol (such as bias) groups, each device using such
an entity need to reference the intended pincontroller/mux instance.

Say mmc instance 0 need pingroup foo on pincontroller bar
means that there must be a specific reference from mmc.0:s
struct device * to pinctrl bar:s struct device *. Maybe this is
peanuts in DT, sorry not enough insight.

I wonder if this has bearing on how the device tree need to be
structured to be future proof? (Hopefully not.)

Yours,
Linus Walleij

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Arnd Bergmann]

On Tuesday 16 August 2011, Linus Walleij wrote:
> One specific thing worries me: Grant asked me to make sure
> to NOT create a global pin number space for the pinmuxes (and thus
> pinctrl). This means that in order to proceed, mappings of pinmux
> groups or pincontrol (such as bias) groups, each device using such
> an entity need to reference the intended pincontroller/mux instance.
> 
> Say mmc instance 0 need pingroup foo on pincontroller bar
> means that there must be a specific reference from mmc.0:s
> struct device * to pinctrl bar:s struct device *. Maybe this is
> peanuts in DT, sorry not enough insight.

I think what you are looking for is the equivalent of the
interrupt-parent property for pinmux. The idea is that each
node in the device tree can point to a device managing the
pinmux, so reference would point to a local number in that
space. We have discussed this for the GPIO case already, and
I suspect that the two should be identical (gpio-controller
and pinmux-controller using the same device node and same
property to refer to them). Since the pinmux-parent
(gpio-parent, ...) property gets inherited by all child
devices, you only need to set it once at the root of the
device tree for the simple case where there is only one
controller.

	Arnd

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Linus Walleij]

On Tue, Aug 16, 2011 at 4:37 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Tuesday 16 August 2011, Linus Walleij wrote:
>> Say mmc instance 0 need pingroup foo on pincontroller bar
>> means that there must be a specific reference from mmc.0:s
>> struct device * to pinctrl bar:s struct device *. Maybe this is
>> peanuts in DT, sorry not enough insight.
>
> I think what you are looking for is the equivalent of the
> interrupt-parent property for pinmux. The idea is that each
> node in the device tree can point to a device managing the
> pinmux, so reference would point to a local number in that
> space. We have discussed this for the GPIO case already, and
> I suspect that the two should be identical (gpio-controller
> and pinmux-controller using the same device node and same
> property to refer to them).

Yes. I discussed with Grant and his idea is for e.g.
advanced combined pincontrol + GPIO blocks that handle
a lot of stuff like muxing, biasing and GPIO, to expose
a single pinctrl device that in turn provide also a gpio_chip
in addition to the pinctrl interfaces so tehy should be
all on the same struct device *

> Since the pinmux-parent
> (gpio-parent, ...) property gets inherited by all child
> devices, you only need to set it once at the root of the
> device tree for the simple case where there is only one
> controller.

This will likely be the case for most of the advanced muxes
I know of, OMAP, Tegra and Nomadik.

Thanks,
Linus Walleij

RE: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Stephen Warren]

Arnd Bergmann wrote at Tuesday, August 16, 2011 8:37 AM:
> On Tuesday 16 August 2011, Linus Walleij wrote:
> > One specific thing worries me: Grant asked me to make sure
> > to NOT create a global pin number space for the pinmuxes (and thus
> > pinctrl). This means that in order to proceed, mappings of pinmux
> > groups or pincontrol (such as bias) groups, each device using such
> > an entity need to reference the intended pincontroller/mux instance.
> >
> > Say mmc instance 0 need pingroup foo on pincontroller bar
> > means that there must be a specific reference from mmc.0:s
> > struct device * to pinctrl bar:s struct device *. Maybe this is
> > peanuts in DT, sorry not enough insight.
> 
> I think what you are looking for is the equivalent of the
> interrupt-parent property for pinmux. The idea is that each
> node in the device tree can point to a device managing the
> pinmux, so reference would point to a local number in that
> space. We have discussed this for the GPIO case already, and
> I suspect that the two should be identical (gpio-controller
> and pinmux-controller using the same device node and same
> property to refer to them). Since the pinmux-parent
> (gpio-parent, ...) property gets inherited by all child
> devices, you only need to set it once at the root of the
> device tree for the simple case where there is only one
> controller.

One issue here: There isn't always a single gpio/pinmux parent; as a
concrete example, the ALSA/ASoC driver for Tegra+WM8903 uses GPIOs both
from Tegra itself, and from the WM8903 audio codec.

I could imagine the same being true in basically any case where one
device uses N GPIOs (e.g. SD controller with power, change-detect,
and read-only GPIOs; some could easily come from the SoC and some
from a GPIO expander).

I'm not quite so sure that multiple parents would be useful for pinmux,
but I wouldn't say that it was impossible...

-- 
nvpublic

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Arnd Bergmann]

On Tuesday 16 August 2011, Stephen Warren wrote:
> One issue here: There isn't always a single gpio/pinmux parent; as a
> concrete example, the ALSA/ASoC driver for Tegra+WM8903 uses GPIOs both
> from Tegra itself, and from the WM8903 audio codec.
> 
> I could imagine the same being true in basically any case where one
> device uses N GPIOs (e.g. SD controller with power, change-detect,
> and read-only GPIOs; some could easily come from the SoC and some
> from a GPIO expander).
> 
> I'm not quite so sure that multiple parents would be useful for pinmux,
> but I wouldn't say that it was impossible...

Hmm, how common do you think the example is?

It it's just a very rare case, we can still special-case it by
introducing fake subdevices for the Tegra+WM8903 driver, each of
which has only one gpio-parent. This is ugly but keeps the special
case to the rare devices.

If we can expect more than a handful of these, we probably need
a better design for the binding, which will cause a burden for
all drivers.

	Arnd

RE: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Stephen Warren]

Arnd Bergmann wrote at Wednesday, August 17, 2011 5:24 AM:
> On Tuesday 16 August 2011, Stephen Warren wrote:
> > One issue here: There isn't always a single gpio/pinmux parent; as a
> > concrete example, the ALSA/ASoC driver for Tegra+WM8903 uses GPIOs both
> > from Tegra itself, and from the WM8903 audio codec.
> >
> > I could imagine the same being true in basically any case where one
> > device uses N GPIOs (e.g. SD controller with power, change-detect,
> > and read-only GPIOs; some could easily come from the SoC and some
> > from a GPIO expander).
> >
> > I'm not quite so sure that multiple parents would be useful for pinmux,
> > but I wouldn't say that it was impossible...
> 
> Hmm, how common do you think the example is?
> 
> It it's just a very rare case, we can still special-case it by
> introducing fake subdevices for the Tegra+WM8903 driver, each of
> which has only one gpio-parent. This is ugly but keeps the special
> case to the rare devices.
> 
> If we can expect more than a handful of these, we probably need
> a better design for the binding, which will cause a burden for
> all drivers.

It looks like DT already supports the generic case for GPIO; each GPIO
reference is of the form:

<&gpio 69 0>

and so each GPIO has a "parent" specified, and hence can come from a
different controller.

For drivers, this is all completely hidden by of_get_gpio().

I imagine we'd just use the same pattern for pinmux. This would both
support the general case, and end up being consistent with how GPIOs
already work, so this seems like a win both ways.

-- 
nvpublic

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Arnd Bergmann]

On Thursday 18 August 2011, Stephen Warren wrote:
> It looks like DT already supports the generic case for GPIO; each GPIO
> reference is of the form:
> 
> <&gpio 69 0>
> 
> and so each GPIO has a "parent" specified, and hence can come from a
> different controller.
> 
> For drivers, this is all completely hidden by of_get_gpio().
> 
> I imagine we'd just use the same pattern for pinmux. This would both
> support the general case, and end up being consistent with how GPIOs
> already work, so this seems like a win both ways.
> 

Ah right. I had not seen the gpio binding yet, so that definitely works.

	Arnd

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Linus Walleij]

On Tue, Aug 16, 2011 at 7:12 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:

> One issue here: There isn't always a single gpio/pinmux parent; as a
> concrete example, the ALSA/ASoC driver for Tegra+WM8903 uses GPIOs both
> from Tegra itself, and from the WM8903 audio codec.

The Ux500 have pinmuxing on the DB8500 and AB8500 - the latter
is a PMIC (&misc) connected to the DB8500 via I2C.

In the pincontrol subsystem I'm brewing, each of these will have
their own pin controller instance and their own struct gpio_chip as
well, so:

DB8500: pinctrl.0, gpio.0
AB8500: pinctrl.1, gpio.1

Each GPIO chip may have it's respective pin controller as parent
I guess, or they may simply be the same struct device * whatdoIknow.

I know this is vaporware, but does this reasoning hold also to
the Tegra+WM8903 combo?

Linus Walleij

RE: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Stephen Warren]

Linus Walleij wrote at Tuesday, August 23, 2011 6:51 AM:
> On Tue, Aug 16, 2011 at 7:12 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> 
> > One issue here: There isn't always a single gpio/pinmux parent; as a
> > concrete example, the ALSA/ASoC driver for Tegra+WM8903 uses GPIOs both
> > from Tegra itself, and from the WM8903 audio codec.
> 
> The Ux500 have pinmuxing on the DB8500 and AB8500 - the latter
> is a PMIC (&misc) connected to the DB8500 via I2C.
> 
> In the pincontrol subsystem I'm brewing, each of these will have
> their own pin controller instance and their own struct gpio_chip as
> well, so:
> 
> DB8500: pinctrl.0, gpio.0
> AB8500: pinctrl.1, gpio.1

Makes sense to far.

> Each GPIO chip may have it's respective pin controller as parent
> I guess, or they may simply be the same struct device * whatdoIknow.

I'm not clear on why the GPIO and pinmux would have any kind of parent
relationship. Perhaps that's how your HW is designed. In Tegra, GPIO
and pinmux are completely separate HW blocks without much of a defined
relationship.

I can certainly see both being implemented by the same code if it makes
sense to do so. On Tegra, I think I'd still lean towards keeping them
as separate devices, since they have separate register spaces and are
documented separately etc. However, I can certainly see that other HW
might have both sets of functionality in one HW block.

> I know this is vaporware, but does this reasoning hold also to
> the Tegra+WM8903 combo?

-- 
nvpublic

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Linus Walleij]

2011/8/23 Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>:
> Linus Walleij wrote at Tuesday, August 23, 2011 6:51 AM:
>> Each GPIO chip may have it's respective pin controller as parent
                               ^^^^^
>> I guess, or they may simply be the same struct device * whatdoIknow.
>
> I'm not clear on why the GPIO and pinmux would have any kind of parent
> relationship. Perhaps that's how your HW is designed. In Tegra, GPIO
> and pinmux are completely separate HW blocks without much of a defined
> relationship.
>
> I can certainly see both being implemented by the same code if it makes
> sense to do so. On Tegra, I think I'd still lean towards keeping them
> as separate devices, since they have separate register spaces and are
> documented separately etc. However, I can certainly see that other HW
> might have both sets of functionality in one HW block.

Makes sense, for U300 I will probably also keep them separate
like this:

pinctrl.0 - deal with muxing
pinctrl.1 - deal with biasing, driving etc
gpio.0 - the GPIO driver using both of the above, no relationship

The only thing they have in common is some relation to the
global GPIO pin space. (When/if we get rid of that - something
better.)

Yours,
Linus Walleij

RE: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Stephen Warren]

Stephen Warren wrote at Monday, August 15, 2011 2:28 PM:
> ...
> This patch modifies Tegra's device tree support to remove the dependency
> on harmony_pinmux_init(), thus making it completely board-independent.

I had the good fortune of meeting Grant at LinuxCon last week and talked
through this patchset a little (thanks!)

The message I got from Grant was that the patches are basically OK. He
did have a couple of concerns:

* Does this cause the compiled DTB to blow up in size.

The DTB goes from ~3-4K to ~8-9K with these patches added. While that
is a large % increase, Grant said that as an absolute value, that size
shouldn't be an issue.

* There's lots of repetition in the .dts representation; can this be improved?

We discussed enhancing the syntax a little, so that you can configure
multiple pins/pingroups from a single node. In particular, the syntax
in my patches was:

ld0 {
    nvidia,function = "displaya";
    nvidia,pull-down;
};
ld1 {
    nvidia,function = "displaya";
    nvidia,pull-down;
};

Which we discussed enhancing to something like:

ld0 {
    additional-pins = "ld1", "ld2", ...;
    nvidia,function = "displaya";
    nvidia,pull-down;
};

or:

meaningless-name { // typically would just use the pin name
    pins = "ld0", "ld1", "ld2", ...;
    nvidia,function = "displaya";
    nvidia,pull-down;
};

* We also briefly discussed that dtc could be modified to support symbolic
constants, so we could use named integers for the function names (perhaps
pin names too). I'll look into how easy it is to modify dtc for this.

I'll look into implementing these enhancements, and others discussed in
this email thread, and repost.

> ...
> Stephen Warren (13):
>   arm/tegra: Prep boards for gpio/pinmux conversion to pdevs
>   arm/tegra: Avoid duplicate gpio/pinmux devices with dt
>   arm/tegra: board-dt: Add AUXDATA for tegra-gpio and tegra-pinmux
>   docs/dt: Document nvidia,tegra20-gpio's nvidia,enabled-gpios property
>   arm/dt: Tegra: Add nvidia,gpios property to GPIO controller
>   docs/dt: Document nvidia,tegra20-pinmux binding
>   arm/dt: Tegra: Add pinmux node
>   gpio/tegra: Convert to a platform device
>   gpio/tegra: Add device tree support
>   arm/tegra: Convert pinmux driver to a platform device
>   arm/tegra: Add device tree support to pinmux driver
>   arm/tegra: board-dt: Remove dependency on non-dt pinmux functions
>   arm/tegra: Remove temporary gpio/pinmux registration workaround
> 
>  .../devicetree/bindings/gpio/gpio_nvidia.txt       |   20 +
>  .../devicetree/bindings/pinmux/pinmux_nvidia.txt   |  294 ++++++++++++
>  arch/arm/boot/dts/tegra-harmony.dts                |  483 ++++++++++++++++++++
>  arch/arm/boot/dts/tegra-seaboard.dts               |  421 +++++++++++++++++
>  arch/arm/boot/dts/tegra20.dtsi                     |    5 +
>  arch/arm/mach-tegra/Makefile                       |    1 -
>  arch/arm/mach-tegra/board-dt.c                     |   12 +-
>  arch/arm/mach-tegra/board-harmony-pinmux.c         |    8 +
>  arch/arm/mach-tegra/board-paz00-pinmux.c           |    8 +
>  arch/arm/mach-tegra/board-seaboard-pinmux.c        |    9 +-
>  arch/arm/mach-tegra/board-trimslice-pinmux.c       |    7 +
>  arch/arm/mach-tegra/devices.c                      |   10 +
>  arch/arm/mach-tegra/devices.h                      |    2 +
>  arch/arm/mach-tegra/pinmux.c                       |  269 +++++++++++
>  drivers/gpio/gpio-tegra.c                          |   57 ++-
>  15 files changed, 1582 insertions(+), 24 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt

-- 
nvpublic

Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

[Olof Johansson]

On Mon, Aug 22, 2011 at 12:56 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Stephen Warren wrote at Monday, August 15, 2011 2:28 PM:
>> ...
>> This patch modifies Tegra's device tree support to remove the dependency
>> on harmony_pinmux_init(), thus making it completely board-independent.
>
> I had the good fortune of meeting Grant at LinuxCon last week and talked
> through this patchset a little (thanks!)
>
> The message I got from Grant was that the patches are basically OK. He
> did have a couple of concerns:
>
> * Does this cause the compiled DTB to blow up in size.
>
> The DTB goes from ~3-4K to ~8-9K with these patches added. While that
> is a large % increase, Grant said that as an absolute value, that size
> shouldn't be an issue.

Agreed, especially if compared with the size of the current in-kernel table.

> * There's lots of repetition in the .dts representation; can this be improved?
>
[...]
> meaningless-name { // typically would just use the pin name
>    pins = "ld0", "ld1", "ld2", ...;
>    nvidia,function = "displaya";
>    nvidia,pull-down;
> };

That sounds quite close to what I was thinking about earlier (with
s/meaningless-name/displaya/ in the above example).

> * We also briefly discussed that dtc could be modified to support symbolic
> constants, so we could use named integers for the function names (perhaps
> pin names too). I'll look into how easy it is to modify dtc for this.

That'd be useful, I think -- there's still the whole issue of the same
pin function being at different mux locations on different pin groups,
so an integer representation might not work.

> I'll look into implementing these enhancements, and others discussed in
> this email thread, and repost.

Cool.


-Olof