[PATCH v4 1/4] dt: add of_get_child_count helper function

[PATCH v4 1/4] dt: add of_get_child_count helper function

[Dong Aisheng]

From: Dong Aisheng <dong.aisheng@linaro.org>

Currently most code to get child count in kernel are almost same,
add a helper to implement this function for dt to use.

Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>

---
Rob missed this patch for 3.4 kernel.
Based on Rob's suggestion, we can get it go in with pinctrl driver.
Since Rob once had applied it, i added Rob's ack.
See:
https://lkml.org/lkml/2012/4/14/239

changes v3->v4:
 * addressed Grant's suggestion to use for_each_child_of_node.

changes v2->v3:
 Addressed some people's comments:
 * do not use assignment as expression
 * return 0 for non-dt case

Changes v1->v2:
 * change the name from of_get_child_number to of_get_child_count
---
 include/linux/of.h |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index e3f942d..1c14976 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -193,6 +193,17 @@ extern struct device_node *of_get_next_child(const struct device_node *node,
 	for (child = of_get_next_child(parent, NULL); child != NULL; \
 	     child = of_get_next_child(parent, child))
 
+static inline int of_get_child_count(const struct device_node *np)
+{
+	struct device_node *child = NULL;
+	int num = 0;
+
+	for_each_child_of_node(np, child)
+		num++;
+
+	return num;
+}
+
 extern struct device_node *of_find_node_with_property(
 	struct device_node *from, const char *prop_name);
 #define for_each_node_with_property(dn, prop_name) \
@@ -300,6 +311,11 @@ static inline bool of_have_populated_dt(void)
 #define for_each_child_of_node(parent, child) \
 	while (0)
 
+static inline int of_get_child_count(const struct device_node *np)
+{
+	return 0;
+}
+
 static inline int of_device_is_compatible(const struct device_node *device,
 					  const char *name)
 {
-- 
1.7.0.4

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Dong Aisheng]

From: Dong Aisheng <dong.aisheng@linaro.org>

The driver has mux and config support while the gpio is still
not supported.
For select input setting, the driver will handle it internally
and do not need user to take care of it.

The pinctrl-imx core driver will parse the dts file and dynamically
create the pinmux functions and groups.

Each IMX SoC pinctrl driver should register pins with a pin register map
including mux register and config register and select input map to core
for proper operations.

Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>

---
ChangeLog: v2->v3:
* add missed SION bit set from device tree
  Thanks for Richard Zhao's reminder.
ChangeLog: v1->v2:
* Change the binding a bit.
  For fsl,pins property, change it from pin name strings to pin function id
  which represents a pin working on a specific function. Then we can remove
  fsl,mux property since the pin function id already contains the mux setting.
  Also remove other pin config property in the first patch.
  Because in the future, we will switch to use dtc macro, then using a lot of
  propertys to represent the each pin config like pull, speed and etc seems
  needless.
  Then each pin entry in dts file becomes a pair of PIN_FUNC_ID and CONFIG:
  fsl,pins = <PIN_FUNC_ID CONFIG ..>
  See binding doc for details.
* Sascha raised a question that pins in the same group may have different
  pad setting for example I2C_CLK needs pull up while I2C_DAT not.
  The v1 driver can aslo handle this issue but needs split the different
  pad setting pins into different groups which loses a bit flexibility.
  Also suggested by Richard Zhao and Jason Liu, we may still want the iomux
  v3 simililar using way that allows each pin has the abiblity to configure
  its pad which seems reasonable because from HW point of view, FSL IMX are
  indeed pin based SoC which should be able to set per pin.
  So the main changes in this v2 patch are change to support per pin config.
  Then the using of iomux is almost the same as the existing iomux v3 for
  non dt imx platforms. See binding doc for example.

  After introduce the new way, there're mainly two known issues:
  1) Since many pins in the same group may have the same pad config setting,
     thus there may be some data redundance, however, since it's one word
     and it's purely describe hw i would think it's not a big issue.
  2) Need a magic number to indicate no pad config need. In current iomux v3,
     It's 1<<16 which is not used by IMX5, i used 1<<31 for both MX5 and MX6.
     However, it's definitely possibile that in the future, the bit 31 may also
     be used, that means we may need change the binding doc or just handle it in
     driver for different SoCs.
  3) Due to core limitation, the current pinconf_group_set/get only support
     get/set the same config(a u32 value)for all the pins in the same group,
     so i removed the imx_group_set/get functions support, instead, using
     imx_pin_get/set.
     About this limitation, we may need some futher discussion on if we may
     need to enhance it to be more flexible to support configure different
     pins in the same group.
* Refactor probe handling based on Stephen's suggestion.
* Enhanced the binding doc and split it into two part, pinctrl-imx common part
  and pinctrl-soc driver part.
* Change functions name from imx_pmx_* to imx_pinctrl_*.
* Other fixes based on Sascha, Stephen, Linus, Shawn's comments.
---
 .../bindings/pinctrl/fsl,imx-pinctrl.txt           |   93 +++
 drivers/pinctrl/Kconfig                            |    5 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/pinctrl-imx.c                      |  627 ++++++++++++++++++++
 drivers/pinctrl/pinctrl-imx.h                      |  106 ++++
 5 files changed, 832 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-imx.c
 create mode 100644 drivers/pinctrl/pinctrl-imx.h

diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
new file mode 100644
index 0000000..e00c7fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
@@ -0,0 +1,93 @@
+* Freescale IOMUX Controller (IOMUXC) for i.MX
+
+The IOMUX Controller (IOMUXC), together with the IOMUX, enables the IC
+to share one PAD to several functional blocks. The sharing is done by
+multiplexing the PAD input/output signals. For each PAD there are up to
+8 muxing options (called ALT modes). Since different modules require
+different PAD settings (like pull up, keeper, etc) the IOMUXC controls
+also the PAD settings parameters.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Freescale IMX pin configuration node is a node of a group of pins which can be
+used for a specific device or function. This node represents both mux and config
+of the pins in that group. The 'mux' selects the function mode(also named mux
+mode) this pin can work on and the 'config' configures various pad settings
+such as pull-up, open drain, drive strength, etc.
+
+Required properties for iomux controller:
+- compatible: "fsl,<soc>-iomuxc"
+  Please refer to each fsl,<soc>-pinctrl.txt binding doc for supported SoCs.
+
+Required properties for pin configuration node:
+- fsl,pins: two integers array, represents a group of pins mux and config
+  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+  pin working on a specific function, CONFIG is the pad setting value like
+  pull-up on this pin. Please refer to fsl,<soc>-pinctrl.txt for the valid
+  pins and functions of each SoC.
+
+Bits used for CONFIG:
+NO_PAD_CTL(1 << 31): indicate this pin does not need config.
+
+SION(1 << 30): Software Input On Field.
+Force the selected mux mode input path no matter of MUX_MODE functionality.
+By default the input path is determined by functionality of the selected
+mux mode (regular).
+
+Other bits are used for PAD setting.
+
+NOTE:
+Some requirements for using fsl,imx-pinctrl binding:
+1. We have pin function node defined under iomux controller node to represent
+   what pinmux functions this SoC supports.
+2. The pin configuration node intends to work on a specific function should
+   to be defined under that specific function node.
+   The function node's name should represent well about what function
+   this group of pins in this pin configuration node are working on.
+3. The driver can use the function node's name and pin configuration node's
+   name describe the pin function and group hierarchy.
+   For example, Linux IMX pinctrl driver takes the function node's name
+   as the function name and pin configuration node's name as group name to
+   create the map table.
+4. Each pin configuration node should have a phandle, devices can set pins
+   configurations by referring to the phandle of that pin configuration node.
+
+Examples:
+usdhc@0219c000 { /* uSDHC4 */
+	fsl,card-wired;
+	vmmc-supply = <&reg_3p3v>;
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc4_1>;
+};
+
+iomuxc at 020e0000 {
+	compatible = "fsl,imx6q-iomuxc";
+	reg = <0x020e0000 0x4000>;
+
+	/* shared pinctrl settings */
+	usdhc4 {
+		pinctrl_usdhc4_1: usdhc4grp-1 {
+			fsl,pins = <1386 0x17059	/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
+				    1392 0x17059	/* MX6Q_PAD_SD4_CLK__USDHC4_CLK	*/
+				    1462 0x17059	/* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
+				    1470 0x17059	/* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
+				    1478 0x17059	/* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
+				    1486 0x17059	/* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
+				    1493 0x17059	/* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
+				    1501 0x17059	/* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
+				    1509 0x17059	/* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
+				    1517 0x17059>;	/* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
+		};
+	};
+	....
+};
+Refer to the IOMUXC controller chapter in imx6q datasheet,
+0x17059 means enable hysteresis, 47KOhm Pull Up, 50Mhz speed,
+80Ohm driver strength and Fast Slew Rate.
+User should refer to each SoC spec to set the correct value.
+
+TODO: when dtc macro support is available, we can change above raw data
+to dt macro which can get better readability in dts file.
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index f73a5ea..aad2882 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -26,6 +26,11 @@ config DEBUG_PINCTRL
 	help
 	  Say Y here to add some extra checks and diagnostics to PINCTRL calls.
 
+config PINCTRL_IMX
+	bool
+	select PINMUX
+	select PINCONF
+
 config PINCTRL_PXA3xx
 	bool
 	select PINMUX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 8e3c95a..a01a97c 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -9,6 +9,7 @@ ifeq ($(CONFIG_OF),y)
 obj-$(CONFIG_PINCTRL)		+= devicetree.o
 endif
 obj-$(CONFIG_GENERIC_PINCONF)	+= pinconf-generic.o
+obj-$(CONFIG_PINCTRL_IMX)	+= pinctrl-imx.o
 obj-$(CONFIG_PINCTRL_PXA3xx)	+= pinctrl-pxa3xx.o
 obj-$(CONFIG_PINCTRL_MMP2)	+= pinctrl-mmp2.o
 obj-$(CONFIG_PINCTRL_PXA168)	+= pinctrl-pxa168.o
diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
new file mode 100644
index 0000000..8faf613
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-imx.c
@@ -0,0 +1,627 @@
+/*
+ * Core driver for the imx pin controller
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Linaro Ltd.
+ *
+ * Author: Dong Aisheng <dong.aisheng@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/machine.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/slab.h>
+
+#include "core.h"
+#include "pinctrl-imx.h"
+
+#define IMX_PMX_DUMP(info, p, m, c, n)		\
+{						\
+	int i, j;				\
+	printk("Format: Pin Mux Config\n");	\
+	for (i = 0; i < n; i++) {		\
+		j = p[i];			\
+		printk("%s %d 0x%lx\n",		\
+			info->pins[j].name,	\
+			m[i], c[i]);		\
+	}					\
+}
+
+/* The bits in CONFIG cell defined in binding doc*/
+#define IMX_NO_PAD_CTL	0x80000000	/* no pin config need */
+#define IMX_PAD_SION 0x40000000		/* set SION */
+
+/**
+ * @dev: a pointer back to containing device
+ * @base: the offset to the controller in virtual memory
+ */
+struct imx_pinctrl {
+	struct device *dev;
+	struct pinctrl_dev *pctl;
+	void __iomem *base;
+	const struct imx_pinctrl_soc_info *info;
+};
+
+static const struct imx_pin_reg *imx_find_pin_reg(
+				const struct imx_pinctrl_soc_info *info,
+				unsigned pin, bool is_mux, unsigned mux)
+{
+	const struct imx_pin_reg *pin_reg = NULL;
+	int i;
+
+	for (i = 0; i < info->npin_regs; i++) {
+		pin_reg = &info->pin_regs[i];
+		if (pin_reg->pid != pin)
+			continue;
+		if (!is_mux)
+			break;
+		else if (pin_reg->mux_mode == (mux & IMX_MUX_MASK))
+			break;
+	}
+
+	if (!pin_reg) {
+		dev_err(info->dev, "Pin(%s): unable to find pin reg map\n",
+			info->pins[pin].name);
+		return NULL;
+	}
+
+	return pin_reg;
+}
+
+static const inline struct imx_pin_group *imx_pinctrl_find_group_by_name(
+				const struct imx_pinctrl_soc_info *info,
+				const char *name)
+{
+	const struct imx_pin_group *grp = NULL;
+	int i;
+
+	for (i = 0; i < info->ngroups; i++) {
+		if (!strcmp(info->groups[i].name, name)) {
+			grp = &info->groups[i];
+			break;
+		}
+	}
+
+	return grp;
+}
+
+static int imx_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+
+	return info->ngroups;
+}
+
+static const char *imx_get_group_name(struct pinctrl_dev *pctldev,
+				       unsigned selector)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+
+	return info->groups[selector].name;
+}
+
+static int imx_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
+			       const unsigned **pins,
+			       unsigned *npins)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+
+	if (selector >= info->ngroups)
+		return -EINVAL;
+
+	*pins = info->groups[selector].pins;
+	*npins = info->groups[selector].npins;
+
+	return 0;
+}
+
+static void imx_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,
+		   unsigned offset)
+{
+	seq_printf(s, "%s", dev_name(pctldev->dev));
+}
+
+static int imx_dt_node_to_map(struct pinctrl_dev *pctldev,
+			struct device_node *np,
+			struct pinctrl_map **map, unsigned *num_maps)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+	const struct imx_pin_group *grp;
+	struct pinctrl_map *new_map;
+	struct device_node *parent;
+	int map_num = 1;
+	int i;
+
+	/*
+	 * first find the group of this node and check if we need create
+	 * config maps for pins
+	 */
+	grp = imx_pinctrl_find_group_by_name(info, np->name);
+	if (!grp) {
+		dev_err(info->dev, "unable to find group for node %s\n",
+			np->name);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < grp->npins; i++) {
+		if (!(grp->configs[i] & IMX_NO_PAD_CTL))
+			map_num++;
+	}
+
+	new_map = kmalloc(sizeof(struct pinctrl_map) * map_num, GFP_KERNEL);
+	if (!new_map)
+		return -ENOMEM;
+
+	*map = new_map;
+	*num_maps = map_num;
+
+	/* create mux map */
+	parent = of_get_parent(np);
+	if (!parent)
+		return -EINVAL;
+	new_map[0].type = PIN_MAP_TYPE_MUX_GROUP;
+	new_map[0].data.mux.function = parent->name;
+	new_map[0].data.mux.group = np->name;
+	of_node_put(parent);
+
+	/* create config map */
+	new_map++;
+	for (i = 0; i < grp->npins; i++) {
+		if (!(grp->configs[i] & IMX_NO_PAD_CTL)) {
+			new_map[i].type = PIN_MAP_TYPE_CONFIGS_PIN;
+			new_map[i].data.configs.group_or_pin =
+					pin_get_name(pctldev, grp->pins[i]);
+			new_map[i].data.configs.configs = &grp->configs[i];
+			new_map[i].data.configs.num_configs = 1;
+		}
+	}
+
+	dev_dbg(pctldev->dev, "maps: function %s group %s num %d\n",
+		new_map->data.mux.function, new_map->data.mux.group, map_num);
+
+	return 0;
+}
+
+static void imx_dt_free_map(struct pinctrl_dev *pctldev,
+				struct pinctrl_map *map, unsigned num_maps)
+{
+	int i;
+
+	for (i = 0; i < num_maps; i++)
+		kfree(map);
+}
+
+static struct pinctrl_ops imx_pctrl_ops = {
+	.get_groups_count = imx_get_groups_count,
+	.get_group_name = imx_get_group_name,
+	.get_group_pins = imx_get_group_pins,
+	.pin_dbg_show = imx_pin_dbg_show,
+	.dt_node_to_map = imx_dt_node_to_map,
+	.dt_free_map = imx_dt_free_map,
+
+};
+
+static int imx_pmx_enable(struct pinctrl_dev *pctldev, unsigned selector,
+			   unsigned group)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+	const struct imx_pin_reg *pin_reg;
+	const unsigned *pins, *mux;
+	unsigned int npins, pin_id;
+	int i;
+
+	/*
+	 * Configure the mux mode for each pin in the group for a specific
+	 * function.
+	 */
+	pins = info->groups[group].pins;
+	npins = info->groups[group].npins;
+	mux = info->groups[group].mux_mode;
+
+	WARN_ON(!pins || !npins || !mux);
+
+	dev_dbg(ipctl->dev, "enable function %s group %s\n",
+		info->functions[selector].name, info->groups[group].name);
+
+	for (i = 0; i < npins; i++) {
+		pin_id = pins[i];
+
+		pin_reg = imx_find_pin_reg(info, pin_id, 1, mux[i]);
+		if (!pin_reg)
+			return -EINVAL;
+
+		if (!pin_reg->mux_reg) {
+			dev_err(ipctl->dev, "Pin(%s) does not support mux function\n",
+				info->pins[pin_id].name);
+			return -EINVAL;
+		}
+
+		writel(mux[i], ipctl->base + pin_reg->mux_reg);
+		dev_dbg(ipctl->dev, "write: offset 0x%x val 0x%x\n",
+			pin_reg->mux_reg, mux[i]);
+
+		/* some pins also need select input setting, set it if found */
+		if (pin_reg->input_reg) {
+			writel(pin_reg->input_val, ipctl->base + pin_reg->input_reg);
+			dev_dbg(ipctl->dev,
+				"==>select_input: offset 0x%x val 0x%x\n",
+				pin_reg->input_reg, pin_reg->input_val);
+		}
+	}
+
+	return 0;
+}
+
+static void imx_pmx_disable(struct pinctrl_dev *pctldev, unsigned func_selector,
+			    unsigned group_selector)
+{
+	/* nothing to do here */
+}
+
+static int imx_pmx_get_funcs_count(struct pinctrl_dev *pctldev)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+
+	return info->nfunctions;
+}
+
+static const char *imx_pmx_get_func_name(struct pinctrl_dev *pctldev,
+					  unsigned selector)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+
+	return info->functions[selector].name;
+}
+
+static int imx_pmx_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
+			       const char * const **groups,
+			       unsigned * const num_groups)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+
+	*groups = info->functions[selector].groups;
+	*num_groups = info->functions[selector].num_groups;
+
+	return 0;
+}
+
+static struct pinmux_ops imx_pmx_ops = {
+	.get_functions_count = imx_pmx_get_funcs_count,
+	.get_function_name = imx_pmx_get_func_name,
+	.get_function_groups = imx_pmx_get_groups,
+	.enable = imx_pmx_enable,
+	.disable = imx_pmx_disable,
+};
+
+static int imx_pinconf_get(struct pinctrl_dev *pctldev,
+			     unsigned pin_id, unsigned long *config)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+	const struct imx_pin_reg *pin_reg;
+
+	pin_reg = imx_find_pin_reg(info, pin_id, 0, 0);
+	if (!pin_reg)
+		return -EINVAL;
+
+	if (!pin_reg->conf_reg) {
+		dev_err(info->dev, "Pin(%s) does not support config function\n",
+			info->pins[pin_id].name);
+		return -EINVAL;
+	}
+
+	*config = readl(ipctl->base + pin_reg->conf_reg);
+
+	return 0;
+}
+
+static int imx_pinconf_set(struct pinctrl_dev *pctldev,
+			     unsigned pin_id, unsigned long config)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+	const struct imx_pin_reg *pin_reg;
+
+	pin_reg = imx_find_pin_reg(info, pin_id, 0, 0);
+	if (!pin_reg)
+		return -EINVAL;
+
+	if (!pin_reg->conf_reg) {
+		dev_err(info->dev, "Pin(%s) does not support config function\n",
+			info->pins[pin_id].name);
+		return -EINVAL;
+	}
+
+	dev_dbg(ipctl->dev, "pinconf set pin %s\n",
+		info->pins[pin_id].name);
+
+	writel(config, ipctl->base + pin_reg->conf_reg);
+	dev_dbg(ipctl->dev, "write: offset 0x%x val 0x%lx\n",
+		pin_reg->conf_reg, config);
+
+	return 0;
+}
+
+static void imx_pinconf_dbg_show(struct pinctrl_dev *pctldev,
+				   struct seq_file *s, unsigned pin_id)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+	const struct imx_pin_reg *pin_reg;
+	unsigned long config;
+
+	pin_reg = imx_find_pin_reg(info, pin_id, 0, 0);
+	if (!pin_reg || !pin_reg->conf_reg) {
+		seq_printf(s, "N/A");
+		return;
+	}
+
+	config = readl(ipctl->base + pin_reg->conf_reg);
+	seq_printf(s, "0x%lx", config);
+}
+
+static void imx_pinconf_group_dbg_show(struct pinctrl_dev *pctldev,
+					 struct seq_file *s, unsigned group)
+{
+	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+	const struct imx_pinctrl_soc_info *info = ipctl->info;
+	struct imx_pin_group *grp;
+	unsigned long config;
+	const char *name;
+	int i, ret;
+
+	if (group > info->ngroups)
+		return;
+
+	seq_printf(s, "\n");
+	grp = &info->groups[group];
+	for (i = 0; i < grp->npins; i++) {
+		name = pin_get_name(pctldev, grp->pins[i]);
+		ret = imx_pinconf_get(pctldev, grp->pins[i], &config);
+		if (ret)
+			return;
+		seq_printf(s, "%s: 0x%lx", name, config);
+	}
+}
+
+struct pinconf_ops imx_pinconf_ops = {
+	.pin_config_get = imx_pinconf_get,
+	.pin_config_set = imx_pinconf_set,
+	.pin_config_dbg_show = imx_pinconf_dbg_show,
+	.pin_config_group_dbg_show = imx_pinconf_group_dbg_show,
+};
+
+static struct pinctrl_desc imx_pinctrl_desc = {
+	.pctlops = &imx_pctrl_ops,
+	.pmxops = &imx_pmx_ops,
+	.confops = &imx_pinconf_ops,
+	.owner = THIS_MODULE,
+};
+
+/* decode pin id and mux from pin function id got from device tree*/
+static int imx_pinctrl_get_pin_id_and_mux(const struct imx_pinctrl_soc_info *info,
+				unsigned int pin_func_id, unsigned int *pin_id,
+				unsigned int *mux)
+{
+	if (pin_func_id > info->npin_regs)
+		return -EINVAL;
+
+	*pin_id = info->pin_regs[pin_func_id].pid;
+	*mux = info->pin_regs[pin_func_id].mux_mode;
+
+	return 0;
+}
+
+static int __devinit imx_pinctrl_parse_groups(struct device_node *np,
+				struct imx_pin_group *grp,
+				struct imx_pinctrl_soc_info *info,
+				u32 index)
+{
+	unsigned int pin_func_id;
+	int ret, size;
+	const const __be32 *list;
+	int i, j;
+	u32 config;
+
+	dev_dbg(info->dev, "group(%d): %s\n", index, np->name);
+
+	/* Initialise group */
+	grp->name = np->name;
+
+	/*
+	 * the binding format is fsl,pins = <PIN_FUNC_ID CONFIG ...>,
+	 * do sanity check and calculate pins number
+	 */
+	list = of_get_property(np, "fsl,pins", &size);
+	/* we do not check return since it's safe node passed down */
+	size /= sizeof(*list);
+	if (!size || size % 2) {
+		dev_err(info->dev, "wrong pins number or pins and configs should be pairs\n");
+		return -EINVAL;
+	}
+
+	grp->npins = size / 2;
+	grp->pins = devm_kzalloc(info->dev, grp->npins * sizeof(unsigned int),
+				GFP_KERNEL);
+	grp->mux_mode = devm_kzalloc(info->dev, grp->npins * sizeof(unsigned int),
+				GFP_KERNEL);
+	grp->configs = devm_kzalloc(info->dev, grp->npins * sizeof(unsigned long),
+				GFP_KERNEL);
+	for (i = 0, j = 0; i < size; i += 2, j++) {
+		pin_func_id = be32_to_cpu(*list++);
+		ret = imx_pinctrl_get_pin_id_and_mux(info, pin_func_id,
+					&grp->pins[j], &grp->mux_mode[j]);
+		if (ret) {
+			dev_err(info->dev, "get invalid pin function id\n");
+			return -EINVAL;
+		}
+		/* SION bit is in mux register */
+		config = be32_to_cpu(*list++);
+		if (config & IMX_PAD_SION)
+			grp->mux_mode[j] |= IOMUXC_CONFIG_SION;
+		grp->configs[j] = config & ~IMX_PAD_SION;
+	}
+
+#ifdef DEBUG
+	IMX_PMX_DUMP(info, grp->pins, grp->mux_mode, grp->configs, grp->npins);
+#endif
+	return 0;
+}
+
+static int __devinit imx_pinctrl_parse_functions(struct device_node *np,
+			struct imx_pinctrl_soc_info *info, u32 index)
+{
+	struct device_node *child;
+	struct imx_pmx_func *func;
+	struct imx_pin_group *grp;
+	int ret;
+	static u32 grp_index;
+	u32 i = 0;
+
+	dev_dbg(info->dev, "parse function(%d): %s\n", index, np->name);
+
+	func = &info->functions[index];
+
+	/* Initialise function */
+	func->name = np->name;
+	func->num_groups = of_get_child_count(np);
+	if (func->num_groups <= 0) {
+		dev_err(info->dev, "no groups defined\n");
+		return -EINVAL;
+	}
+	func->groups = devm_kzalloc(info->dev,
+			func->num_groups * sizeof(char *), GFP_KERNEL);
+
+	for_each_child_of_node(np, child) {
+		func->groups[i] = child->name;
+		grp = &info->groups[grp_index++];
+		ret = imx_pinctrl_parse_groups(child, grp, info, i++);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int __devinit imx_pinctrl_probe_dt(struct platform_device *pdev,
+				struct imx_pinctrl_soc_info *info)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *child;
+	int ret;
+	u32 nfuncs = 0;
+	u32 i = 0;
+
+	if (!np)
+		return -ENODEV;
+
+	nfuncs = of_get_child_count(np);
+	if (nfuncs <= 0) {
+		dev_err(&pdev->dev, "no functions defined\n");
+		return -EINVAL;
+	}
+
+	info->nfunctions = nfuncs;
+	info->functions = devm_kzalloc(&pdev->dev, nfuncs * sizeof(struct imx_pmx_func),
+					GFP_KERNEL);
+	if (!info->functions)
+		return -ENOMEM;
+
+	info->ngroups = 0;
+	for_each_child_of_node(np, child)
+		info->ngroups += of_get_child_count(child);
+	info->groups = devm_kzalloc(&pdev->dev, info->ngroups * sizeof(struct imx_pin_group),
+					GFP_KERNEL);
+	if (!info->groups)
+		return -ENOMEM;
+
+	for_each_child_of_node(np, child) {
+		ret = imx_pinctrl_parse_functions(child, info, i++);
+		if (ret) {
+			dev_err(&pdev->dev, "failed to parse function\n");
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+int __devinit imx_pinctrl_probe(struct platform_device *pdev,
+				struct imx_pinctrl_soc_info *info)
+{
+	struct imx_pinctrl *ipctl;
+	struct resource *res;
+	int ret;
+
+	if (!info || !info->pins || !info->npins
+		  || !info->pin_regs || !info->npin_regs) {
+		dev_err(&pdev->dev, "wrong pinctrl info\n");
+		return -EINVAL;
+	}
+	info->dev = &pdev->dev;
+
+	/* Create state holders etc for this driver */
+	ipctl = devm_kzalloc(&pdev->dev, sizeof(*ipctl), GFP_KERNEL);
+	if (!ipctl)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENOENT;
+
+	ipctl->base = devm_request_and_ioremap(&pdev->dev, res);
+	if (!ipctl->base)
+		return -EBUSY;
+
+	imx_pinctrl_desc.name = dev_name(&pdev->dev);
+	imx_pinctrl_desc.pins = info->pins;
+	imx_pinctrl_desc.npins = info->npins;
+
+	ret = imx_pinctrl_probe_dt(pdev, info);
+	if (ret) {
+		dev_err(&pdev->dev, "fail to probe dt properties\n");
+		return ret;
+	}
+
+	ipctl->info = info;
+	ipctl->dev = info->dev;
+	platform_set_drvdata(pdev, ipctl);
+	ipctl->pctl = pinctrl_register(&imx_pinctrl_desc, &pdev->dev, ipctl);
+	if (!ipctl->pctl) {
+		dev_err(&pdev->dev, "could not register IMX pinctrl driver\n");
+		return -EINVAL;
+	}
+
+	dev_info(&pdev->dev, "initialized IMX pinctrl driver\n");
+
+	return 0;
+}
+
+int __devexit imx_pinctrl_remove(struct platform_device *pdev)
+{
+	struct imx_pinctrl *ipctl = platform_get_drvdata(pdev);
+
+	pinctrl_unregister(ipctl->pctl);
+
+	return 0;
+}
diff --git a/drivers/pinctrl/pinctrl-imx.h b/drivers/pinctrl/pinctrl-imx.h
new file mode 100644
index 0000000..c8ce541
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-imx.h
@@ -0,0 +1,106 @@
+/*
+ * IMX pinmux core definitions
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Linaro Ltd.
+ *
+ * Author: Dong Aisheng <dong.aisheng@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DRIVERS_PINCTRL_IMX_H
+#define __DRIVERS_PINCTRL_IMX_H
+
+struct platform_device;
+
+/**
+ * struct imx_pin_group - describes an IMX pin group
+ * @name: the name of this specific pin group
+ * @pins: an array of discrete physical pins used in this group, taken
+ *	from the driver-local pin enumeration space
+ * @npins: the number of pins in this group array, i.e. the number of
+ *	elements in .pins so we can iterate over that array
+ * @mux_mode: the mux mode for each pin in this group. The size of this
+ *	array is the same as pins.
+ * @configs: the config for each pin in this group. The size of this
+ *	array is the same as pins.
+ */
+struct imx_pin_group {
+	const char *name;
+	unsigned int *pins;
+	unsigned npins;
+	unsigned int *mux_mode;
+	unsigned long *configs;
+};
+
+/**
+ * struct imx_pmx_func - describes IMX pinmux functions
+ * @name: the name of this specific function
+ * @groups: corresponding pin groups
+ * @num_groups: the number of groups
+ */
+struct imx_pmx_func {
+	const char *name;
+	const char **groups;
+	unsigned num_groups;
+};
+
+/**
+ * struct imx_pin_reg - describe a pin reg map
+ * The last 3 members are used for select input setting
+ * @pid: pin id
+ * @mux_reg: mux register offset
+ * @conf_reg: config register offset
+ * @mux_mode: mux mode
+ * @input_reg: select input register offset for this mux if any
+ *  0 if no select input setting needed.
+ * @input_val: the value set to select input register
+ */
+struct imx_pin_reg {
+	unsigned int pid;
+	unsigned int mux_reg;
+	unsigned int conf_reg;
+	unsigned int mux_mode;
+	unsigned int input_reg;
+	unsigned int input_val;
+};
+
+struct imx_pinctrl_soc_info {
+	struct device *dev;
+	const struct pinctrl_pin_desc *pins;
+	unsigned int npins;
+	const struct imx_pin_reg *pin_regs;
+	unsigned int npin_regs;
+	struct imx_pin_group *groups;
+	unsigned int ngroups;
+	struct imx_pmx_func *functions;
+	unsigned int nfunctions;
+};
+
+#define NO_MUX		0x0
+#define NO_PAD		0x0
+
+#define IMX_PIN_REG(id, conf, mux, mode, input, val)	\
+	{						\
+		.pid = id,				\
+		.conf_reg = conf,			\
+		.mux_reg = mux,				\
+		.mux_mode  = mode,			\
+		.input_reg = input,			\
+		.input_val = val,			\
+	}
+
+#define IMX_PINCTRL_PIN(pin) PINCTRL_PIN(pin, #pin)
+
+#define PAD_CTL_MASK(len)	((1 << len) - 1)
+#define IMX_MUX_MASK	0x7
+#define IOMUXC_CONFIG_SION	(0x1 << 4)
+
+int imx_pinctrl_probe(struct platform_device *pdev,
+			struct imx_pinctrl_soc_info *info);
+int imx_pinctrl_remove(struct platform_device *pdev);
+#endif /* __DRIVERS_PINCTRL_IMX_H */
-- 
1.7.0.4

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Dong Aisheng]

From: Dong Aisheng <dong.aisheng@linaro.org>

This driver is shared between many platforms. Currently only imx6q has
pinctrl support, to avoid breaking other platforms that do not have pinctrl
support to run this driver, enable pinctrl dummy state for them before
they also convert to pinctrl subsystem.

Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
---
This patch depends on:
pinctrl: add pinctrl_provide_dummies interface for platforms to use
http://www.spinics.net/lists/arm-kernel/msg171538.html

ChangeLog v2->v3:
 * patch name updated.
   v1 name is ARM: imx6q: switch to use pinctrl driver
 * using pinctrl dummy state to avoid breaking other platforms to use this
   driver.

ChangeLog v1->v2:
 * using updated binding
---
 arch/arm/boot/dts/imx6q-arm2.dts               |    4 +++
 arch/arm/boot/dts/imx6q.dtsi                   |   32 ++++++++++++++++++++++++
 arch/arm/mach-imx/Kconfig                      |    2 +
 arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c |    2 +
 arch/arm/mach-imx/mach-cpuimx51.c              |    2 +
 arch/arm/mach-imx/mach-cpuimx51sd.c            |    2 +
 arch/arm/mach-imx/mach-eukrea_cpuimx25.c       |    2 +
 arch/arm/mach-imx/mach-mx25_3ds.c              |    2 +
 arch/arm/mach-imx/mach-mx35_3ds.c              |    2 +
 arch/arm/mach-imx/mach-mx51_3ds.c              |    2 +
 arch/arm/mach-imx/mach-mx51_babbage.c          |    2 +
 arch/arm/mach-imx/mach-mx51_efikamx.c          |    2 +
 arch/arm/mach-imx/mach-mx51_efikasb.c          |    2 +
 arch/arm/mach-imx/mach-mx53_ard.c              |    2 +
 arch/arm/mach-imx/mach-mx53_evk.c              |    2 +
 arch/arm/mach-imx/mach-mx53_loco.c             |    2 +
 arch/arm/mach-imx/mach-mx53_smd.c              |    2 +
 arch/arm/mach-imx/mach-pcm043.c                |    2 +
 arch/arm/mach-imx/mach-vpr200.c                |    2 +
 drivers/mmc/host/sdhci-esdhc-imx.c             |    9 ++++++
 20 files changed, 79 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
index ce1c823..34dd9cd 100644
--- a/arch/arm/boot/dts/imx6q-arm2.dts
+++ b/arch/arm/boot/dts/imx6q-arm2.dts
@@ -37,12 +37,16 @@
 				cd-gpios = <&gpio6 11 0>;
 				wp-gpios = <&gpio6 14 0>;
 				vmmc-supply = <&reg_3p3v>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_usdhc3_1>;
 				status = "okay";
 			};
 
 			usdhc at 0219c000 { /* uSDHC4 */
 				fsl,card-wired;
 				vmmc-supply = <&reg_3p3v>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_usdhc4_1>;
 				status = "okay";
 			};
 
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 4905f51..a89f294 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -386,7 +386,39 @@
 			};
 
 			iomuxc at 020e0000 {
+				compatible = "fsl,imx6q-iomuxc";
 				reg = <0x020e0000 0x4000>;
+
+				/* shared pinctrl settings */
+				usdhc3 {
+					pinctrl_usdhc3_1: usdhc3grp-1 {
+						fsl,pins = <1273 0x17059	/* MX6Q_PAD_SD3_CMD__USDHC3_CMD */
+							    1281 0x10059	/* MX6Q_PAD_SD3_CLK__USDHC3_CLK	*/
+							    1289 0x17059	/* MX6Q_PAD_SD3_DAT0__USDHC3_DAT0 */
+							    1297 0x17059	/* MX6Q_PAD_SD3_DAT1__USDHC3_DAT1 */
+							    1305 0x17059	/* MX6Q_PAD_SD3_DAT2__USDHC3_DAT2 */
+							    1312 0x17059	/* MX6Q_PAD_SD3_DAT3__USDHC3_DAT3 */
+							    1265 0x17059	/* MX6Q_PAD_SD3_DAT4__USDHC3_DAT4 */
+							    1257 0x17059	/* MX6Q_PAD_SD3_DAT5__USDHC3_DAT5 */
+							    1249 0x17059	/* MX6Q_PAD_SD3_DAT6__USDHC3_DAT6 */
+							    1241 0x17059>;	/* MX6Q_PAD_SD3_DAT7__USDHC3_DAT7 */
+					};
+				};
+
+				usdhc4 {
+					pinctrl_usdhc4_1: usdhc4grp-1 {
+						fsl,pins = <1386 0x17059	/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
+							    1392 0x10059	/* MX6Q_PAD_SD4_CLK__USDHC4_CLK	*/
+							    1462 0x17059	/* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
+							    1470 0x17059	/* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
+							    1478 0x17059	/* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
+							    1486 0x17059	/* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
+							    1493 0x17059	/* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
+							    1501 0x17059	/* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
+							    1509 0x17059	/* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
+							    1517 0x17059>;	/* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
+					};
+				};
 			};
 
 			dcic at 020e4000 { /* DCIC1 */
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 7561eca..e0fc67c 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -842,6 +842,8 @@ config SOC_IMX6Q
 	select HAVE_IMX_MMDC
 	select HAVE_IMX_SRC
 	select HAVE_SMP
+	select PINCTRL
+	select PINCTRL_IMX6Q
 	select USE_OF
 
 	help
diff --git a/arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c b/arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c
index fd8bf8a..12bbb62 100644
--- a/arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c
+++ b/arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c
@@ -25,6 +25,7 @@
 #include <linux/gpio.h>
 #include <linux/interrupt.h>
 #include <linux/leds.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
 #include <linux/input.h>
 #include <video/platform_lcd.h>
@@ -251,6 +252,7 @@ void __init eukrea_mbimxsd35_baseboard_init(void)
 			ARRAY_SIZE(eukrea_mbimxsd_pads)))
 		printk(KERN_ERR "error setting mbimxsd pads !\n");
 
+	pinctrl_provide_dummies();
 	imx35_add_imx_uart1(&uart_pdata);
 	imx35_add_ipu_core(&mx3_ipu_data);
 	imx35_add_mx3_sdc_fb(&mx3fb_pdata);
diff --git a/arch/arm/mach-imx/mach-cpuimx51.c b/arch/arm/mach-imx/mach-cpuimx51.c
index 944025d..2c67d7f 100644
--- a/arch/arm/mach-imx/mach-cpuimx51.c
+++ b/arch/arm/mach-imx/mach-cpuimx51.c
@@ -22,6 +22,7 @@
 #include <linux/delay.h>
 #include <linux/io.h>
 #include <linux/interrupt.h>
+#include <linux/pinctrl/machine.h>
 
 #include <mach/eukrea-baseboards.h>
 #include <mach/common.h>
@@ -243,6 +244,7 @@ static void __init eukrea_cpuimx51_init(void)
 	mxc_iomux_v3_setup_multiple_pads(eukrea_cpuimx51_pads,
 					ARRAY_SIZE(eukrea_cpuimx51_pads));
 
+	pinctrl_provide_dummies();
 	imx51_add_imx_uart(0, &uart_pdata);
 	imx51_add_mxc_nand(&eukrea_cpuimx51_nand_board_info);
 
diff --git a/arch/arm/mach-imx/mach-cpuimx51sd.c b/arch/arm/mach-imx/mach-cpuimx51sd.c
index 9fbe923..5d5a872 100644
--- a/arch/arm/mach-imx/mach-cpuimx51sd.c
+++ b/arch/arm/mach-imx/mach-cpuimx51sd.c
@@ -25,6 +25,7 @@
 #include <linux/i2c-gpio.h>
 #include <linux/spi/spi.h>
 #include <linux/can/platform/mcp251x.h>
+#include <linux/pinctrl/machine.h>
 
 #include <mach/eukrea-baseboards.h>
 #include <mach/common.h>
@@ -265,6 +266,7 @@ static void __init eukrea_cpuimx51sd_init(void)
 
 	mxc_iomux_v3_setup_multiple_pads(eukrea_cpuimx51sd_pads,
 					ARRAY_SIZE(eukrea_cpuimx51sd_pads));
+	pinctrl_provide_dummies();
 
 #if defined(CONFIG_CPU_FREQ_IMX)
 	get_cpu_op = mx51_get_cpu_op;
diff --git a/arch/arm/mach-imx/mach-eukrea_cpuimx25.c b/arch/arm/mach-imx/mach-eukrea_cpuimx25.c
index 76a97a5..b90b795 100644
--- a/arch/arm/mach-imx/mach-eukrea_cpuimx25.c
+++ b/arch/arm/mach-imx/mach-eukrea_cpuimx25.c
@@ -23,6 +23,7 @@
 #include <linux/clk.h>
 #include <linux/irq.h>
 #include <linux/gpio.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/ulpi.h>
@@ -131,6 +132,7 @@ static void __init eukrea_cpuimx25_init(void)
 			ARRAY_SIZE(eukrea_cpuimx25_pads)))
 		printk(KERN_ERR "error setting cpuimx25 pads !\n");
 
+	pinctrl_provide_dummies();
 	imx25_add_imx_uart0(&uart_pdata);
 	imx25_add_mxc_nand(&eukrea_cpuimx25_nand_board_info);
 	imx25_add_imxdi_rtc(NULL);
diff --git a/arch/arm/mach-imx/mach-mx25_3ds.c b/arch/arm/mach-imx/mach-mx25_3ds.c
index f267342..347467c 100644
--- a/arch/arm/mach-imx/mach-mx25_3ds.c
+++ b/arch/arm/mach-imx/mach-mx25_3ds.c
@@ -29,6 +29,7 @@
 #include <linux/irq.h>
 #include <linux/gpio.h>
 #include <linux/platform_device.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/usb/otg.h>
 
 #include <mach/hardware.h>
@@ -233,6 +234,7 @@ static void __init mx25pdk_init(void)
 	mxc_iomux_v3_setup_multiple_pads(mx25pdk_pads,
 			ARRAY_SIZE(mx25pdk_pads));
 
+	pinctrl_provide_dummies();
 	imx25_add_imx_uart0(&uart_pdata);
 	imx25_add_fsl_usb2_udc(&otg_device_pdata);
 	imx25_add_mxc_ehci_hs(&usbh2_pdata);
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c b/arch/arm/mach-imx/mach-mx35_3ds.c
index 6ae51c6..b8cfc6a 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -31,6 +31,7 @@
 #include <linux/platform_device.h>
 #include <linux/memory.h>
 #include <linux/gpio.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/usb/otg.h>
 
 #include <linux/mtd/physmap.h>
@@ -380,6 +381,7 @@ static void __init mx35_3ds_init(void)
 
 	mxc_iomux_v3_setup_multiple_pads(mx35pdk_pads, ARRAY_SIZE(mx35pdk_pads));
 
+	pinctrl_provide_dummies();
 	imx35_add_fec(NULL);
 	imx35_add_imx2_wdt(NULL);
 	platform_add_devices(devices, ARRAY_SIZE(devices));
diff --git a/arch/arm/mach-imx/mach-mx51_3ds.c b/arch/arm/mach-imx/mach-mx51_3ds.c
index 83eab41..9a8a6f2 100644
--- a/arch/arm/mach-imx/mach-mx51_3ds.c
+++ b/arch/arm/mach-imx/mach-mx51_3ds.c
@@ -14,6 +14,7 @@
 #include <linux/platform_device.h>
 #include <linux/spi/spi.h>
 #include <linux/gpio.h>
+#include <linux/pinctrl/machine.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -139,6 +140,7 @@ static void __init mx51_3ds_init(void)
 
 	mxc_iomux_v3_setup_multiple_pads(mx51_3ds_pads,
 					ARRAY_SIZE(mx51_3ds_pads));
+	pinctrl_provide_dummies();
 
 	imx51_add_imx_uart(0, &uart_pdata);
 	imx51_add_imx_uart(1, &uart_pdata);
diff --git a/arch/arm/mach-imx/mach-mx51_babbage.c b/arch/arm/mach-imx/mach-mx51_babbage.c
index e4b822e..9adc94b 100644
--- a/arch/arm/mach-imx/mach-mx51_babbage.c
+++ b/arch/arm/mach-imx/mach-mx51_babbage.c
@@ -17,6 +17,7 @@
 #include <linux/delay.h>
 #include <linux/io.h>
 #include <linux/input.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/spi/flash.h>
 #include <linux/spi/spi.h>
 
@@ -353,6 +354,7 @@ void __init imx51_babbage_common_init(void)
 {
 	mxc_iomux_v3_setup_multiple_pads(mx51babbage_pads,
 					 ARRAY_SIZE(mx51babbage_pads));
+	pinctrl_provide_dummies();
 }
 
 /*
diff --git a/arch/arm/mach-imx/mach-mx51_efikamx.c b/arch/arm/mach-imx/mach-mx51_efikamx.c
index 586e9f8..8486569 100644
--- a/arch/arm/mach-imx/mach-mx51_efikamx.c
+++ b/arch/arm/mach-imx/mach-mx51_efikamx.c
@@ -22,6 +22,7 @@
 #include <linux/input.h>
 #include <linux/delay.h>
 #include <linux/io.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/spi/flash.h>
 #include <linux/spi/spi.h>
 #include <linux/mfd/mc13892.h>
@@ -237,6 +238,7 @@ static void __init mx51_efikamx_init(void)
 
 	mxc_iomux_v3_setup_multiple_pads(mx51efikamx_pads,
 					ARRAY_SIZE(mx51efikamx_pads));
+	pinctrl_provide_dummies();
 	efika_board_common_init();
 
 	mx51_efikamx_board_id();
diff --git a/arch/arm/mach-imx/mach-mx51_efikasb.c b/arch/arm/mach-imx/mach-mx51_efikasb.c
index 24aded9..dfd9952 100644
--- a/arch/arm/mach-imx/mach-mx51_efikasb.c
+++ b/arch/arm/mach-imx/mach-mx51_efikasb.c
@@ -22,6 +22,7 @@
 #include <linux/input.h>
 #include <linux/delay.h>
 #include <linux/io.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/spi/flash.h>
 #include <linux/spi/spi.h>
 #include <linux/mfd/mc13892.h>
@@ -260,6 +261,7 @@ static void __init efikasb_board_init(void)
 
 	mxc_iomux_v3_setup_multiple_pads(mx51efikasb_pads,
 					ARRAY_SIZE(mx51efikasb_pads));
+	pinctrl_provide_dummies();
 	efika_board_common_init();
 
 	mx51_efikasb_board_id();
diff --git a/arch/arm/mach-imx/mach-mx53_ard.c b/arch/arm/mach-imx/mach-mx53_ard.c
index 0564198..d251da4 100644
--- a/arch/arm/mach-imx/mach-mx53_ard.c
+++ b/arch/arm/mach-imx/mach-mx53_ard.c
@@ -22,6 +22,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/gpio.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/smsc911x.h>
 #include <linux/regulator/machine.h>
 #include <linux/regulator/fixed.h>
@@ -226,6 +227,7 @@ void __init imx53_ard_common_init(void)
 	mxc_iomux_v3_setup_multiple_pads(mx53_ard_pads,
 					 ARRAY_SIZE(mx53_ard_pads));
 	weim_cs_config();
+	pinctrl_provide_dummies();
 }
 
 static struct platform_device *devices[] __initdata = {
diff --git a/arch/arm/mach-imx/mach-mx53_evk.c b/arch/arm/mach-imx/mach-mx53_evk.c
index 5a72188..9ca7010 100644
--- a/arch/arm/mach-imx/mach-mx53_evk.c
+++ b/arch/arm/mach-imx/mach-mx53_evk.c
@@ -23,6 +23,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/gpio.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/spi/flash.h>
 #include <linux/spi/spi.h>
 #include <mach/common.h>
@@ -134,6 +135,7 @@ void __init imx53_evk_common_init(void)
 {
 	mxc_iomux_v3_setup_multiple_pads(mx53_evk_pads,
 					 ARRAY_SIZE(mx53_evk_pads));
+	pinctrl_provide_dummies();
 }
 
 static void __init mx53_evk_board_init(void)
diff --git a/arch/arm/mach-imx/mach-mx53_loco.c b/arch/arm/mach-imx/mach-mx53_loco.c
index 37f67ca..4c11cc1 100644
--- a/arch/arm/mach-imx/mach-mx53_loco.c
+++ b/arch/arm/mach-imx/mach-mx53_loco.c
@@ -23,6 +23,7 @@
 #include <linux/delay.h>
 #include <linux/gpio.h>
 #include <linux/i2c.h>
+#include <linux/pinctrl/machine.h>
 
 #include <mach/common.h>
 #include <mach/hardware.h>
@@ -266,6 +267,7 @@ void __init imx53_qsb_common_init(void)
 {
 	mxc_iomux_v3_setup_multiple_pads(mx53_loco_pads,
 					 ARRAY_SIZE(mx53_loco_pads));
+	pinctrl_provide_dummies();
 }
 
 static struct i2c_board_info mx53loco_i2c_devices[] = {
diff --git a/arch/arm/mach-imx/mach-mx53_smd.c b/arch/arm/mach-imx/mach-mx53_smd.c
index 8e972c5..d621022 100644
--- a/arch/arm/mach-imx/mach-mx53_smd.c
+++ b/arch/arm/mach-imx/mach-mx53_smd.c
@@ -22,6 +22,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/gpio.h>
+#include <linux/pinctrl/machine.h>
 
 #include <mach/common.h>
 #include <mach/hardware.h>
@@ -128,6 +129,7 @@ void __init imx53_smd_common_init(void)
 {
 	mxc_iomux_v3_setup_multiple_pads(mx53_smd_pads,
 					 ARRAY_SIZE(mx53_smd_pads));
+	pinctrl_provide_dummies();
 }
 
 static void __init mx53_smd_board_init(void)
diff --git a/arch/arm/mach-imx/mach-pcm043.c b/arch/arm/mach-imx/mach-pcm043.c
index 237474f..c0ec1b8 100644
--- a/arch/arm/mach-imx/mach-pcm043.c
+++ b/arch/arm/mach-imx/mach-pcm043.c
@@ -25,6 +25,7 @@
 #include <linux/delay.h>
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
+#include <linux/pinctrl/machine.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/ulpi.h>
 
@@ -361,6 +362,7 @@ static void __init pcm043_init(void)
 
 	mxc_iomux_v3_setup_multiple_pads(pcm043_pads, ARRAY_SIZE(pcm043_pads));
 
+	pinctrl_provide_dummies();
 	imx35_add_fec(NULL);
 	platform_add_devices(devices, ARRAY_SIZE(devices));
 	imx35_add_imx2_wdt(NULL);
diff --git a/arch/arm/mach-imx/mach-vpr200.c b/arch/arm/mach-imx/mach-vpr200.c
index 033257e..cf9afcb 100644
--- a/arch/arm/mach-imx/mach-vpr200.c
+++ b/arch/arm/mach-imx/mach-vpr200.c
@@ -23,6 +23,7 @@
 #include <linux/mtd/physmap.h>
 #include <linux/memory.h>
 #include <linux/gpio.h>
+#include <linux/pinctrl/machine.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -271,6 +272,7 @@ static void __init vpr200_board_init(void)
 
 	mxc_iomux_v3_setup_multiple_pads(vpr200_pads, ARRAY_SIZE(vpr200_pads));
 
+	pinctrl_provide_dummies();
 	imx35_add_fec(NULL);
 	imx35_add_imx2_wdt(NULL);
 	imx_add_gpio_keys(&vpr200_gpio_keys_data);
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 6193a0d..039bc19 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -24,6 +24,7 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/of_gpio.h>
+#include <linux/pinctrl/consumer.h>
 #include <mach/esdhc.h>
 #include "sdhci-pltfm.h"
 #include "sdhci-esdhc.h"
@@ -68,6 +69,7 @@ struct pltfm_imx_data {
 	int flags;
 	u32 scratchpad;
 	enum imx_esdhc_type devtype;
+	struct pinctrl *pinctrl;
 	struct esdhc_platform_data boarddata;
 };
 
@@ -467,6 +469,12 @@ static int __devinit sdhci_esdhc_imx_probe(struct platform_device *pdev)
 	clk_prepare_enable(clk);
 	pltfm_host->clk = clk;
 
+	imx_data->pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+	if (IS_ERR(imx_data->pinctrl)) {
+		err = PTR_ERR(imx_data->pinctrl);
+		goto pin_err;
+	}
+
 	if (!is_imx25_esdhc(imx_data))
 		host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
@@ -559,6 +567,7 @@ no_card_detect_irq:
 		gpio_free(boarddata->wp_gpio);
 no_card_detect_pin:
 no_board_data:
+pin_err:
 	clk_disable_unprepare(pltfm_host->clk);
 	clk_put(pltfm_host->clk);
 err_clk_get:
-- 
1.7.0.4

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 22:40 Thu 26 Apr     , Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> The driver has mux and config support while the gpio is still
> not supported.
> For select input setting, the driver will handle it internally
> and do not need user to take care of it.
> 
> The pinctrl-imx core driver will parse the dts file and dynamically
> create the pinmux functions and groups.
> 
> Each IMX SoC pinctrl driver should register pins with a pin register map
> including mux register and config register and select input map to core
> for proper operations.
> 
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
> 
> ---
> ChangeLog: v2->v3:
> * add missed SION bit set from device tree
>   Thanks for Richard Zhao's reminder.
> ChangeLog: v1->v2:
> * Change the binding a bit.
>   For fsl,pins property, change it from pin name strings to pin function id
>   which represents a pin working on a specific function. Then we can remove
>   fsl,mux property since the pin function id already contains the mux setting.
>   Also remove other pin config property in the first patch.
>   Because in the future, we will switch to use dtc macro, then using a lot of
>   propertys to represent the each pin config like pull, speed and etc seems
>   needless.
>   Then each pin entry in dts file becomes a pair of PIN_FUNC_ID and CONFIG:
>   fsl,pins = <PIN_FUNC_ID CONFIG ..>
>   See binding doc for details.
> * Sascha raised a question that pins in the same group may have different
>   pad setting for example I2C_CLK needs pull up while I2C_DAT not.
>   The v1 driver can aslo handle this issue but needs split the different
>   pad setting pins into different groups which loses a bit flexibility.
>   Also suggested by Richard Zhao and Jason Liu, we may still want the iomux
>   v3 simililar using way that allows each pin has the abiblity to configure
>   its pad which seems reasonable because from HW point of view, FSL IMX are
>   indeed pin based SoC which should be able to set per pin.
>   So the main changes in this v2 patch are change to support per pin config.
>   Then the using of iomux is almost the same as the existing iomux v3 for
>   non dt imx platforms. See binding doc for example.
> 
>   After introduce the new way, there're mainly two known issues:
>   1) Since many pins in the same group may have the same pad config setting,
>      thus there may be some data redundance, however, since it's one word
>      and it's purely describe hw i would think it's not a big issue.
>   2) Need a magic number to indicate no pad config need. In current iomux v3,
>      It's 1<<16 which is not used by IMX5, i used 1<<31 for both MX5 and MX6.
>      However, it's definitely possibile that in the future, the bit 31 may also
>      be used, that means we may need change the binding doc or just handle it in
>      driver for different SoCs.
>   3) Due to core limitation, the current pinconf_group_set/get only support
>      get/set the same config(a u32 value)for all the pins in the same group,
>      so i removed the imx_group_set/get functions support, instead, using
>      imx_pin_get/set.
>      About this limitation, we may need some futher discussion on if we may
>      need to enhance it to be more flexible to support configure different
>      pins in the same group.
> * Refactor probe handling based on Stephen's suggestion.
> * Enhanced the binding doc and split it into two part, pinctrl-imx common part
>   and pinctrl-soc driver part.
> * Change functions name from imx_pmx_* to imx_pinctrl_*.
> * Other fixes based on Sascha, Stephen, Linus, Shawn's comments.
> ---
>  .../bindings/pinctrl/fsl,imx-pinctrl.txt           |   93 +++
>  drivers/pinctrl/Kconfig                            |    5 +
>  drivers/pinctrl/Makefile                           |    1 +
>  drivers/pinctrl/pinctrl-imx.c                      |  627 ++++++++++++++++++++
>  drivers/pinctrl/pinctrl-imx.h                      |  106 ++++
>  5 files changed, 832 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
>  create mode 100644 drivers/pinctrl/pinctrl-imx.c
>  create mode 100644 drivers/pinctrl/pinctrl-imx.h
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> new file mode 100644
> index 0000000..e00c7fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> @@ -0,0 +1,93 @@
> +* Freescale IOMUX Controller (IOMUXC) for i.MX
> +
> +The IOMUX Controller (IOMUXC), together with the IOMUX, enables the IC
> +to share one PAD to several functional blocks. The sharing is done by
> +multiplexing the PAD input/output signals. For each PAD there are up to
> +8 muxing options (called ALT modes). Since different modules require
> +different PAD settings (like pull up, keeper, etc) the IOMUXC controls
> +also the PAD settings parameters.
> +
> +Please refer to pinctrl-bindings.txt in this directory for details of the
> +common pinctrl bindings used by client devices, including the meaning of the
> +phrase "pin configuration node".
> +
> +Freescale IMX pin configuration node is a node of a group of pins which can be
> +used for a specific device or function. This node represents both mux and config
> +of the pins in that group. The 'mux' selects the function mode(also named mux
> +mode) this pin can work on and the 'config' configures various pad settings
> +such as pull-up, open drain, drive strength, etc.
> +
> +Required properties for iomux controller:
> +- compatible: "fsl,<soc>-iomuxc"
> +  Please refer to each fsl,<soc>-pinctrl.txt binding doc for supported SoCs.
> +
> +Required properties for pin configuration node:
> +- fsl,pins: two integers array, represents a group of pins mux and config
> +  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
> +  pin working on a specific function, CONFIG is the pad setting value like
> +  pull-up on this pin. Please refer to fsl,<soc>-pinctrl.txt for the valid
> +  pins and functions of each SoC.
> +
> +Bits used for CONFIG:
> +NO_PAD_CTL(1 << 31): indicate this pin does not need config.
> +
> +SION(1 << 30): Software Input On Field.
> +Force the selected mux mode input path no matter of MUX_MODE functionality.
> +By default the input path is determined by functionality of the selected
> +mux mode (regular).
> +
> +Other bits are used for PAD setting.
> +
> +NOTE:
> +Some requirements for using fsl,imx-pinctrl binding:
> +1. We have pin function node defined under iomux controller node to represent
> +   what pinmux functions this SoC supports.
> +2. The pin configuration node intends to work on a specific function should
> +   to be defined under that specific function node.
> +   The function node's name should represent well about what function
> +   this group of pins in this pin configuration node are working on.
> +3. The driver can use the function node's name and pin configuration node's
> +   name describe the pin function and group hierarchy.
> +   For example, Linux IMX pinctrl driver takes the function node's name
> +   as the function name and pin configuration node's name as group name to
> +   create the map table.
> +4. Each pin configuration node should have a phandle, devices can set pins
> +   configurations by referring to the phandle of that pin configuration node.
> +
> +Examples:
> +usdhc at 0219c000 { /* uSDHC4 */
> +	fsl,card-wired;
> +	vmmc-supply = <&reg_3p3v>;
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc4_1>;
> +};
> +
> +iomuxc at 020e0000 {
> +	compatible = "fsl,imx6q-iomuxc";
> +	reg = <0x020e0000 0x4000>;
> +
> +	/* shared pinctrl settings */
> +	usdhc4 {
> +		pinctrl_usdhc4_1: usdhc4grp-1 {
> +			fsl,pins = <1386 0x17059	/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
> +				    1392 0x17059	/* MX6Q_PAD_SD4_CLK__USDHC4_CLK	*/
> +				    1462 0x17059	/* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
> +				    1470 0x17059	/* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
> +				    1478 0x17059	/* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
> +				    1486 0x17059	/* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
> +				    1493 0x17059	/* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
> +				    1501 0x17059	/* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
> +				    1509 0x17059	/* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
> +				    1517 0x17059>;	/* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
honestly I don't like this it's obscure need to decode manually

I propose to use phandle

as example on uart you will want or not the rst/cts so you will have quite a
lot of bindings

so you can describe the pin configuration (function) and refer it by phandle
in the group

Best Regards,
J.

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Dong Aisheng]

On Thu, Apr 26, 2012 at 10:40:25PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> The driver has mux and config support while the gpio is still
> not supported.
> For select input setting, the driver will handle it internally
> and do not need user to take care of it.
> 
> The pinctrl-imx core driver will parse the dts file and dynamically
> create the pinmux functions and groups.
> 
> Each IMX SoC pinctrl driver should register pins with a pin register map
> including mux register and config register and select input map to core
> for proper operations.
> 
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
> 
> ---
> ChangeLog: v2->v3:
> * add missed SION bit set from device tree
>   Thanks for Richard Zhao's reminder.
> ChangeLog: v1->v2:
> * Change the binding a bit.
>   For fsl,pins property, change it from pin name strings to pin function id
>   which represents a pin working on a specific function. Then we can remove
>   fsl,mux property since the pin function id already contains the mux setting.
>   Also remove other pin config property in the first patch.
>   Because in the future, we will switch to use dtc macro, then using a lot of
>   propertys to represent the each pin config like pull, speed and etc seems
>   needless.
>   Then each pin entry in dts file becomes a pair of PIN_FUNC_ID and CONFIG:
>   fsl,pins = <PIN_FUNC_ID CONFIG ..>
>   See binding doc for details.
> * Sascha raised a question that pins in the same group may have different
>   pad setting for example I2C_CLK needs pull up while I2C_DAT not.
>   The v1 driver can aslo handle this issue but needs split the different
>   pad setting pins into different groups which loses a bit flexibility.
>   Also suggested by Richard Zhao and Jason Liu, we may still want the iomux
>   v3 simililar using way that allows each pin has the abiblity to configure
>   its pad which seems reasonable because from HW point of view, FSL IMX are
>   indeed pin based SoC which should be able to set per pin.
>   So the main changes in this v2 patch are change to support per pin config.
>   Then the using of iomux is almost the same as the existing iomux v3 for
>   non dt imx platforms. See binding doc for example.
> 
>   After introduce the new way, there're mainly two known issues:
>   1) Since many pins in the same group may have the same pad config setting,
>      thus there may be some data redundance, however, since it's one word
>      and it's purely describe hw i would think it's not a big issue.
>   2) Need a magic number to indicate no pad config need. In current iomux v3,
>      It's 1<<16 which is not used by IMX5, i used 1<<31 for both MX5 and MX6.
>      However, it's definitely possibile that in the future, the bit 31 may also
>      be used, that means we may need change the binding doc or just handle it in
>      driver for different SoCs.
>   3) Due to core limitation, the current pinconf_group_set/get only support
>      get/set the same config(a u32 value)for all the pins in the same group,
>      so i removed the imx_group_set/get functions support, instead, using
>      imx_pin_get/set.
>      About this limitation, we may need some futher discussion on if we may
>      need to enhance it to be more flexible to support configure different
>      pins in the same group.
> * Refactor probe handling based on Stephen's suggestion.
> * Enhanced the binding doc and split it into two part, pinctrl-imx common part
>   and pinctrl-soc driver part.
> * Change functions name from imx_pmx_* to imx_pinctrl_*.
> * Other fixes based on Sascha, Stephen, Linus, Shawn's comments.
> ---
Hi Shawn & Sascha,

Please help review if this can meet your requirement.

Regards
Dong Aisheg

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Jean-Christophe PLAGNIOL-VILLARD]

> > +Examples:
> > +usdhc at 0219c000 { /* uSDHC4 */
> > +	fsl,card-wired;
> > +	vmmc-supply = <&reg_3p3v>;
> > +	status = "okay";
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_usdhc4_1>;
> > +};
> > +
> > +iomuxc at 020e0000 {
> > +	compatible = "fsl,imx6q-iomuxc";
> > +	reg = <0x020e0000 0x4000>;
> > +
> > +	/* shared pinctrl settings */
> > +	usdhc4 {
> > +		pinctrl_usdhc4_1: usdhc4grp-1 {
> > +			fsl,pins = <1386 0x17059	/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
> > +				    1392 0x17059	/* MX6Q_PAD_SD4_CLK__USDHC4_CLK	*/
> > +				    1462 0x17059	/* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
> > +				    1470 0x17059	/* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
> > +				    1478 0x17059	/* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
> > +				    1486 0x17059	/* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
> > +				    1493 0x17059	/* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
> > +				    1501 0x17059	/* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
> > +				    1509 0x17059	/* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
> > +				    1517 0x17059>;	/* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
> honestly I don't like this it's obscure need to decode manually
> 
> I propose to use phandle
> 
> as example on uart you will want or not the rst/cts so you will have quite a
> lot of bindings
> 
> so you can describe the pin configuration (function) and refer it by phandle
> in the group
We have on Imx mxc at91 and other SoC controler hich you configure per pin

which means one pin have multiple function and the same function is on
multiple pins

so the groups are just a list of possible pins

Instead of re-inventing bindings we do need to come with a common binding whre
it's possible

So instead I proppose (send in the v2) to use common way to describe the group

1) we describe one function per pin

	functions {
		rxd_pb12 {
			atmel,pin-id = <44>;
			atmel,mux = <0>;
		};

		txd_pb13 {
			atmel,pin-id = <45>;
			atmel,pull = <2>;
			atmel,mux = <0>;
		};

		txd0_pb19 {
			atmel,pin-id = <51>;
			atmel,pull = <2>;
			atmel,mux = <0>;
		};

		rxd0_pb18 {
			atmel,pin-id = <50>;
			atmel,mux = <0>;
		};

		rts0_pb17 {
			atmel,pin-id = <49>;
			atmel,mux = <1>;
		};

		cts0_pb15 {
			atmel,pin-id = <47>;
			atmel,mux = <1>;
		};
	};


advantage if you need to set a pull-up or any pin parameter different on your board
you can overwrite it without re-creating a group

This is controller specific

and then we have the common bindings to describe the group
by using phandle of the functions to describe the group

	groups {
		dbgu {
			pinctrl,functions = < &rxd_pb12
					      &txd_pb13 >;
		};

		uart0_rxd_txd {
			pinctrl,functions = < &rxd0_pb18
					      &txd0_pb19 >;
		};

		uart0_rts_cts {
			pinctrl,functions = < &rxd0_pb18
					      &txd0_pb19
					      &rts0_pb17
					      &cts0_pb15 >;
		};
	};

this will be handle by a generic code in c

Best Regards,
J.

[PATCH v4 1/4] dt: add of_get_child_count helper function

[Stephen Warren]

On 04/26/2012 08:40 AM, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> Currently most code to get child count in kernel are almost same,
> add a helper to implement this function for dt to use.

> diff --git a/include/linux/of.h b/include/linux/of.h

> +static inline int of_get_child_count(const struct device_node *np)
> +{
> +	struct device_node *child = NULL;

You don't actually need to initialize child here. It doesn't really
matter here, but in a more complex function, it might hide a
used-before-initialized error.

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Stephen Warren]

On 04/26/2012 08:40 AM, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> This driver is shared between many platforms. Currently only imx6q has
> pinctrl support, to avoid breaking other platforms that do not have pinctrl
> support to run this driver, enable pinctrl dummy state for them before
> they also convert to pinctrl subsystem.

The series,

Acked-by: Stephen Warren <swarren@wwwdotorg.org>

(My ack isn't meant to override or influence any discussions between
Freescale maintainers re: the binding, but more that the binding seems
to be /a/ reasonable solution, and is specified well enough that I
understand what's going on there)

[PATCH v4 1/4] dt: add of_get_child_count helper function

[Dong Aisheng]

On Fri, Apr 27, 2012 at 12:24:11AM +0800, Stephen Warren wrote:
> On 04/26/2012 08:40 AM, Dong Aisheng wrote:
> > From: Dong Aisheng <dong.aisheng@linaro.org>
> > 
> > Currently most code to get child count in kernel are almost same,
> > add a helper to implement this function for dt to use.
> 
> > diff --git a/include/linux/of.h b/include/linux/of.h
> 
> > +static inline int of_get_child_count(const struct device_node *np)
> > +{
> > +	struct device_node *child = NULL;
> 
> You don't actually need to initialize child here. It doesn't really
> matter here, but in a more complex function, it might hide a
> used-before-initialized error.
> 
Correct, i could change it.

Regards
Dong Aisheng

[PATCH v5 1/1] dt: add of_get_child_count helper function

[Dong Aisheng]

From: Dong Aisheng <dong.aisheng@linaro.org>

Currently most code to get child count in kernel are almost same,
add a helper to implement this function for dt to use.

Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>

---
Rob missed this patch for 3.4 kernel.
Based on Rob's suggestion, we can get it go in with pinctrl driver.
Since Rob once had applied it, i added Rob's ack.
See:
https://lkml.org/lkml/2012/4/14/239

changes v4->v5:
 * do not initialize child node pointer based on Stephen's suggestion.

changes v3->v4:
 * addressed Grant's suggestion to use for_each_child_of_node.

changes v2->v3:
 Addressed some people's comments:
 * do not use assignment as expression
 * return 0 for non-dt case

Changes v1->v2:
 * change the name from of_get_child_number to of_get_child_count
---
 include/linux/of.h |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index e3f942d..2ec1083 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -193,6 +193,17 @@ extern struct device_node *of_get_next_child(const struct device_node *node,
 	for (child = of_get_next_child(parent, NULL); child != NULL; \
 	     child = of_get_next_child(parent, child))
 
+static inline int of_get_child_count(const struct device_node *np)
+{
+	struct device_node *child;
+	int num = 0;
+
+	for_each_child_of_node(np, child)
+		num++;
+
+	return num;
+}
+
 extern struct device_node *of_find_node_with_property(
 	struct device_node *from, const char *prop_name);
 #define for_each_node_with_property(dn, prop_name) \
@@ -300,6 +311,11 @@ static inline bool of_have_populated_dt(void)
 #define for_each_child_of_node(parent, child) \
 	while (0)
 
+static inline int of_get_child_count(const struct device_node *np)
+{
+	return 0;
+}
+
 static inline int of_device_is_compatible(const struct device_node *device,
 					  const char *name)
 {
-- 
1.7.0.4

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Dong Aisheng]

On Thu, Apr 26, 2012 at 10:44:46PM +0800, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 22:40 Thu 26 Apr     , Dong Aisheng wrote:
> > From: Dong Aisheng <dong.aisheng@linaro.org>
> > 
> > The driver has mux and config support while the gpio is still
> > not supported.
> > For select input setting, the driver will handle it internally
> > and do not need user to take care of it.
> > 
> > The pinctrl-imx core driver will parse the dts file and dynamically
> > create the pinmux functions and groups.
> > 
> > Each IMX SoC pinctrl driver should register pins with a pin register map
> > including mux register and config register and select input map to core
> > for proper operations.
> > 
> > Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
> > 
> > ---
> > ChangeLog: v2->v3:
> > * add missed SION bit set from device tree
> >   Thanks for Richard Zhao's reminder.
> > ChangeLog: v1->v2:
> > * Change the binding a bit.
> >   For fsl,pins property, change it from pin name strings to pin function id
> >   which represents a pin working on a specific function. Then we can remove
> >   fsl,mux property since the pin function id already contains the mux setting.
> >   Also remove other pin config property in the first patch.
> >   Because in the future, we will switch to use dtc macro, then using a lot of
> >   propertys to represent the each pin config like pull, speed and etc seems
> >   needless.
> >   Then each pin entry in dts file becomes a pair of PIN_FUNC_ID and CONFIG:
> >   fsl,pins = <PIN_FUNC_ID CONFIG ..>
> >   See binding doc for details.
> > * Sascha raised a question that pins in the same group may have different
> >   pad setting for example I2C_CLK needs pull up while I2C_DAT not.
> >   The v1 driver can aslo handle this issue but needs split the different
> >   pad setting pins into different groups which loses a bit flexibility.
> >   Also suggested by Richard Zhao and Jason Liu, we may still want the iomux
> >   v3 simililar using way that allows each pin has the abiblity to configure
> >   its pad which seems reasonable because from HW point of view, FSL IMX are
> >   indeed pin based SoC which should be able to set per pin.
> >   So the main changes in this v2 patch are change to support per pin config.
> >   Then the using of iomux is almost the same as the existing iomux v3 for
> >   non dt imx platforms. See binding doc for example.
> > 
> >   After introduce the new way, there're mainly two known issues:
> >   1) Since many pins in the same group may have the same pad config setting,
> >      thus there may be some data redundance, however, since it's one word
> >      and it's purely describe hw i would think it's not a big issue.
> >   2) Need a magic number to indicate no pad config need. In current iomux v3,
> >      It's 1<<16 which is not used by IMX5, i used 1<<31 for both MX5 and MX6.
> >      However, it's definitely possibile that in the future, the bit 31 may also
> >      be used, that means we may need change the binding doc or just handle it in
> >      driver for different SoCs.
> >   3) Due to core limitation, the current pinconf_group_set/get only support
> >      get/set the same config(a u32 value)for all the pins in the same group,
> >      so i removed the imx_group_set/get functions support, instead, using
> >      imx_pin_get/set.
> >      About this limitation, we may need some futher discussion on if we may
> >      need to enhance it to be more flexible to support configure different
> >      pins in the same group.
> > * Refactor probe handling based on Stephen's suggestion.
> > * Enhanced the binding doc and split it into two part, pinctrl-imx common part
> >   and pinctrl-soc driver part.
> > * Change functions name from imx_pmx_* to imx_pinctrl_*.
> > * Other fixes based on Sascha, Stephen, Linus, Shawn's comments.
> > ---
> >  .../bindings/pinctrl/fsl,imx-pinctrl.txt           |   93 +++
> >  drivers/pinctrl/Kconfig                            |    5 +
> >  drivers/pinctrl/Makefile                           |    1 +
> >  drivers/pinctrl/pinctrl-imx.c                      |  627 ++++++++++++++++++++
> >  drivers/pinctrl/pinctrl-imx.h                      |  106 ++++
> >  5 files changed, 832 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> >  create mode 100644 drivers/pinctrl/pinctrl-imx.c
> >  create mode 100644 drivers/pinctrl/pinctrl-imx.h
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> > new file mode 100644
> > index 0000000..e00c7fc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
> > @@ -0,0 +1,93 @@
> > +* Freescale IOMUX Controller (IOMUXC) for i.MX
> > +
> > +The IOMUX Controller (IOMUXC), together with the IOMUX, enables the IC
> > +to share one PAD to several functional blocks. The sharing is done by
> > +multiplexing the PAD input/output signals. For each PAD there are up to
> > +8 muxing options (called ALT modes). Since different modules require
> > +different PAD settings (like pull up, keeper, etc) the IOMUXC controls
> > +also the PAD settings parameters.
> > +
> > +Please refer to pinctrl-bindings.txt in this directory for details of the
> > +common pinctrl bindings used by client devices, including the meaning of the
> > +phrase "pin configuration node".
> > +
> > +Freescale IMX pin configuration node is a node of a group of pins which can be
> > +used for a specific device or function. This node represents both mux and config
> > +of the pins in that group. The 'mux' selects the function mode(also named mux
> > +mode) this pin can work on and the 'config' configures various pad settings
> > +such as pull-up, open drain, drive strength, etc.
> > +
> > +Required properties for iomux controller:
> > +- compatible: "fsl,<soc>-iomuxc"
> > +  Please refer to each fsl,<soc>-pinctrl.txt binding doc for supported SoCs.
> > +
> > +Required properties for pin configuration node:
> > +- fsl,pins: two integers array, represents a group of pins mux and config
> > +  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
> > +  pin working on a specific function, CONFIG is the pad setting value like
> > +  pull-up on this pin. Please refer to fsl,<soc>-pinctrl.txt for the valid
> > +  pins and functions of each SoC.
> > +
> > +Bits used for CONFIG:
> > +NO_PAD_CTL(1 << 31): indicate this pin does not need config.
> > +
> > +SION(1 << 30): Software Input On Field.
> > +Force the selected mux mode input path no matter of MUX_MODE functionality.
> > +By default the input path is determined by functionality of the selected
> > +mux mode (regular).
> > +
> > +Other bits are used for PAD setting.
> > +
> > +NOTE:
> > +Some requirements for using fsl,imx-pinctrl binding:
> > +1. We have pin function node defined under iomux controller node to represent
> > +   what pinmux functions this SoC supports.
> > +2. The pin configuration node intends to work on a specific function should
> > +   to be defined under that specific function node.
> > +   The function node's name should represent well about what function
> > +   this group of pins in this pin configuration node are working on.
> > +3. The driver can use the function node's name and pin configuration node's
> > +   name describe the pin function and group hierarchy.
> > +   For example, Linux IMX pinctrl driver takes the function node's name
> > +   as the function name and pin configuration node's name as group name to
> > +   create the map table.
> > +4. Each pin configuration node should have a phandle, devices can set pins
> > +   configurations by referring to the phandle of that pin configuration node.
> > +
> > +Examples:
> > +usdhc at 0219c000 { /* uSDHC4 */
> > +	fsl,card-wired;
> > +	vmmc-supply = <&reg_3p3v>;
> > +	status = "okay";
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_usdhc4_1>;
> > +};
> > +
> > +iomuxc at 020e0000 {
> > +	compatible = "fsl,imx6q-iomuxc";
> > +	reg = <0x020e0000 0x4000>;
> > +
> > +	/* shared pinctrl settings */
> > +	usdhc4 {
> > +		pinctrl_usdhc4_1: usdhc4grp-1 {
> > +			fsl,pins = <1386 0x17059	/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
> > +				    1392 0x17059	/* MX6Q_PAD_SD4_CLK__USDHC4_CLK	*/
> > +				    1462 0x17059	/* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
> > +				    1470 0x17059	/* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
> > +				    1478 0x17059	/* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
> > +				    1486 0x17059	/* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
> > +				    1493 0x17059	/* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
> > +				    1501 0x17059	/* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
> > +				    1509 0x17059	/* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
> > +				    1517 0x17059>;	/* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
> honestly I don't like this it's obscure need to decode manually
> 
> I propose to use phandle
> 
> as example on uart you will want or not the rst/cts so you will have quite a
> lot of bindings
> 
> so you can describe the pin configuration (function) and refer it by phandle
> in the group
> 
Hmm, i can't say you're wrong.
What you suggested may be suitable for your SoCs, before i know more about your SoC
details, i may not comment too much.

The binding i used here basically follows the exist iomux v3 convention which we're
using for non dt platforms, i think most people working on fsl platform may would
want a similar using as before since iomux v3 is very easy to use for imx soc.
You can refer to: iomux-mx51.h.

After dt macro support is available(which is still in progress), we may
convert the raw data above to raw data then user do not need to decode
the setting anymore.

Regards
Dong Aisheng

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Shawn Guo]

On Thu, Apr 26, 2012 at 10:40:25PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> The driver has mux and config support while the gpio is still
> not supported.
> For select input setting, the driver will handle it internally
> and do not need user to take care of it.
> 
> The pinctrl-imx core driver will parse the dts file and dynamically
> create the pinmux functions and groups.
> 
> Each IMX SoC pinctrl driver should register pins with a pin register map
> including mux register and config register and select input map to core
> for proper operations.
> 
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
> 
Acked-by: Shawn Guo <shawn.guo@linaro.org>

[PATCH v3 3/4] pinctrl: pinctrl-imx: add imx6q pinctrl driver

[Shawn Guo]

On Thu, Apr 26, 2012 at 10:40:26PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>

Acked-by: Shawn Guo <shawn.guo@linaro.org>

> ---
> ChangeLog v1-v2:
> * add binding doc for pinctrl-imx6q
> * refactor the probe
> ---

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Shawn Guo]

On Thu, Apr 26, 2012 at 05:15:36PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> We have on Imx mxc at91 and other SoC controler hich you configure per pin
> 
> which means one pin have multiple function and the same function is on
> multiple pins
> 
> so the groups are just a list of possible pins
> 
> Instead of re-inventing bindings we do need to come with a common binding whre
> it's possible
> 
> So instead I proppose (send in the v2) to use common way to describe the group
> 
Let's see how many nodes we will have in device tree.  For imx6q
example, there are 332 pins and each pin has up to 8 function selects.
We will end up with having 332 x 8 = 2656 sub nodes under node
"functions".  Device tree simply cannot afford such a bloating.

Regards,
Shawn

> 1) we describe one function per pin
> 
> 	functions {
> 		rxd_pb12 {
> 			atmel,pin-id = <44>;
> 			atmel,mux = <0>;
> 		};
> 
> 		txd_pb13 {
> 			atmel,pin-id = <45>;
> 			atmel,pull = <2>;
> 			atmel,mux = <0>;
> 		};
> 
> 		txd0_pb19 {
> 			atmel,pin-id = <51>;
> 			atmel,pull = <2>;
> 			atmel,mux = <0>;
> 		};
> 
> 		rxd0_pb18 {
> 			atmel,pin-id = <50>;
> 			atmel,mux = <0>;
> 		};
> 
> 		rts0_pb17 {
> 			atmel,pin-id = <49>;
> 			atmel,mux = <1>;
> 		};
> 
> 		cts0_pb15 {
> 			atmel,pin-id = <47>;
> 			atmel,mux = <1>;
> 		};
> 	};
> 
> 
> advantage if you need to set a pull-up or any pin parameter different on your board
> you can overwrite it without re-creating a group
> 
> This is controller specific
> 
> and then we have the common bindings to describe the group
> by using phandle of the functions to describe the group
> 
> 	groups {
> 		dbgu {
> 			pinctrl,functions = < &rxd_pb12
> 					      &txd_pb13 >;
> 		};
> 
> 		uart0_rxd_txd {
> 			pinctrl,functions = < &rxd0_pb18
> 					      &txd0_pb19 >;
> 		};
> 
> 		uart0_rts_cts {
> 			pinctrl,functions = < &rxd0_pb18
> 					      &txd0_pb19
> 					      &rts0_pb17
> 					      &cts0_pb15 >;
> 		};
> 	};
> 
> this will be handle by a generic code in c
> 
> Best Regards,
> J.

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:48 Fri 27 Apr     , Shawn Guo wrote:
> On Thu, Apr 26, 2012 at 05:15:36PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > We have on Imx mxc at91 and other SoC controler hich you configure per pin
> > 
> > which means one pin have multiple function and the same function is on
> > multiple pins
> > 
> > so the groups are just a list of possible pins
> > 
> > Instead of re-inventing bindings we do need to come with a common binding whre
> > it's possible
> > 
> > So instead I proppose (send in the v2) to use common way to describe the group
> > 
> Let's see how many nodes we will have in device tree.  For imx6q
> example, there are 332 pins and each pin has up to 8 function selects.
> We will end up with having 332 x 8 = 2656 sub nodes under node
> "functions".  Device tree simply cannot afford such a bloating.
device tree can offord it

except you are going to have hundereds of duplicated pinctrl configuration
as different board will have different mux which is impossbile to maintain
either

and I do not expect we add all the configuration possible but just the common
one

Best Regards,
J.

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Jean-Christophe PLAGNIOL-VILLARD]

> > > +   this group of pins in this pin configuration node are working on.
> > > +3. The driver can use the function node's name and pin configuration node's
> > > +   name describe the pin function and group hierarchy.
> > > +   For example, Linux IMX pinctrl driver takes the function node's name
> > > +   as the function name and pin configuration node's name as group name to
> > > +   create the map table.
> > > +4. Each pin configuration node should have a phandle, devices can set pins
> > > +   configurations by referring to the phandle of that pin configuration node.
> > > +
> > > +Examples:
> > > +usdhc at 0219c000 { /* uSDHC4 */
> > > +	fsl,card-wired;
> > > +	vmmc-supply = <&reg_3p3v>;
> > > +	status = "okay";
> > > +	pinctrl-names = "default";
> > > +	pinctrl-0 = <&pinctrl_usdhc4_1>;
> > > +};
> > > +
> > > +iomuxc at 020e0000 {
> > > +	compatible = "fsl,imx6q-iomuxc";
> > > +	reg = <0x020e0000 0x4000>;
> > > +
> > > +	/* shared pinctrl settings */
> > > +	usdhc4 {
> > > +		pinctrl_usdhc4_1: usdhc4grp-1 {
> > > +			fsl,pins = <1386 0x17059	/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
> > > +				    1392 0x17059	/* MX6Q_PAD_SD4_CLK__USDHC4_CLK	*/
> > > +				    1462 0x17059	/* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
> > > +				    1470 0x17059	/* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
> > > +				    1478 0x17059	/* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
> > > +				    1486 0x17059	/* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
> > > +				    1493 0x17059	/* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
> > > +				    1501 0x17059	/* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
> > > +				    1509 0x17059	/* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
> > > +				    1517 0x17059>;	/* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
> > honestly I don't like this it's obscure need to decode manually
> > 
> > I propose to use phandle
> > 
> > as example on uart you will want or not the rst/cts so you will have quite a
> > lot of bindings
> > 
> > so you can describe the pin configuration (function) and refer it by phandle
> > in the group
> > 
> Hmm, i can't say you're wrong.
> What you suggested may be suitable for your SoCs, before i know more about your SoC
> details, i may not comment too much.
> 
> The binding i used here basically follows the exist iomux v3 convention which we're
> using for non dt platforms, i think most people working on fsl platform may would
> want a similar using as before since iomux v3 is very easy to use for imx soc.
> You can refer to: iomux-mx51.h.
> 
> After dt macro support is available(which is still in progress), we may
> convert the raw data above to raw data then user do not need to decode
> the setting anymore.
this is not an excuse to duplicate bindings

Best Regards,
J.

[PATCH v3 3/4] pinctrl: pinctrl-imx: add imx6q pinctrl driver

[Sascha Hauer]

On Thu, Apr 26, 2012 at 10:40:26PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
> ---
> ChangeLog v1-v2:
> * add binding doc for pinctrl-imx6q
> * refactor the probe
> ---
>  .../bindings/pinctrl/fsl,imx6q-pinctrl.txt         | 1605 ++++++++++++++
>  drivers/pinctrl/Kconfig                            |    8 +
>  drivers/pinctrl/Makefile                           |    1 +
>  drivers/pinctrl/pinctrl-imx6q.c                    | 2331 ++++++++++++++++++++
>  4 files changed, 3945 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
>  create mode 100644 drivers/pinctrl/pinctrl-imx6q.c
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
> new file mode 100644
> index 0000000..13d474f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
> @@ -0,0 +1,1605 @@
> +* Freescale IMX6Q IOMUX Controller
> +
> +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
> +and usage.
> +
> +Required properties:
> +- compatible: "fsl,imx6q-iomuxc"
> +- fsl,pins: two integers array, represents a group of pins mux and config
> +  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
> +  pin working on a specific function, CONFIG is the pad setting value like
> +  pull-up for this pin. Please refer to imx6q datasheet for the valid pad
> +  config settings.

Wouldn't it make sense to document the CONFIG bits here? Something like

Pull keeper enabled (pke)	(1 << 7)
...

Not all bits are available on all pins, refer to the datasheet...

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:25 Fri 27 Apr     , Shawn Guo wrote:
> On Fri, Apr 27, 2012 at 08:28:16AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 13:48 Fri 27 Apr     , Shawn Guo wrote:
> > > On Thu, Apr 26, 2012 at 05:15:36PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > We have on Imx mxc at91 and other SoC controler hich you configure per pin
> > > > 
> > > > which means one pin have multiple function and the same function is on
> > > > multiple pins
> > > > 
> > > > so the groups are just a list of possible pins
> > > > 
> > > > Instead of re-inventing bindings we do need to come with a common binding whre
> > > > it's possible
> > > > 
> > > > So instead I proppose (send in the v2) to use common way to describe the group
> > > > 
> > > Let's see how many nodes we will have in device tree.  For imx6q
> > > example, there are 332 pins and each pin has up to 8 function selects.
> > > We will end up with having 332 x 8 = 2656 sub nodes under node
> > > "functions".  Device tree simply cannot afford such a bloating.
> > device tree can offord it
> > 
> No.  Device tree maintainers has told that.  Looking into the clock DT
> binding discussion, you will find that Grant does not like to have
> even 100~200 nodes to represent an entire clock tree in the DT.
> 
> With your proposal (actually this has been proposed long time before),
> to represent the pins for a 24bit display, it easily consumes 28 nodes
> on mach-mxs, while my binding only needs one node.  So in short, the
> proposal has been discussed and it's not a sensible one.
except duplicate bindings instead having common one make no sense either

so imx, at91 and ST (STB SoC and other does have the same type of pin IP

to not come with a common bindig means we are doint the same crap as before

with switch to DT

Best Regards,
J.

[PATCH v3 3/4] pinctrl: pinctrl-imx: add imx6q pinctrl driver

[Dong Aisheng]

On Fri, Apr 27, 2012 at 02:45:19PM +0800, Sascha Hauer wrote:
> On Thu, Apr 26, 2012 at 10:40:26PM +0800, Dong Aisheng wrote:
> > From: Dong Aisheng <dong.aisheng@linaro.org>
> > 
> > Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
> > ---
> > ChangeLog v1-v2:
> > * add binding doc for pinctrl-imx6q
> > * refactor the probe
> > ---
> >  .../bindings/pinctrl/fsl,imx6q-pinctrl.txt         | 1605 ++++++++++++++
> >  drivers/pinctrl/Kconfig                            |    8 +
> >  drivers/pinctrl/Makefile                           |    1 +
> >  drivers/pinctrl/pinctrl-imx6q.c                    | 2331 ++++++++++++++++++++
> >  4 files changed, 3945 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
> >  create mode 100644 drivers/pinctrl/pinctrl-imx6q.c
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
> > new file mode 100644
> > index 0000000..13d474f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
> > @@ -0,0 +1,1605 @@
> > +* Freescale IMX6Q IOMUX Controller
> > +
> > +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
> > +and usage.
> > +
> > +Required properties:
> > +- compatible: "fsl,imx6q-iomuxc"
> > +- fsl,pins: two integers array, represents a group of pins mux and config
> > +  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
> > +  pin working on a specific function, CONFIG is the pad setting value like
> > +  pull-up for this pin. Please refer to imx6q datasheet for the valid pad
> > +  config settings.
> 
> Wouldn't it make sense to document the CONFIG bits here? Something like
> 
> Pull keeper enabled (pke)	(1 << 7)
> ...
> 
Yes, it makes sense for me to add it.

> Not all bits are available on all pins, refer to the datasheet...
> 

Regards
Dong Aisheng

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Shawn Guo]

On Fri, Apr 27, 2012 at 08:28:16AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:48 Fri 27 Apr     , Shawn Guo wrote:
> > On Thu, Apr 26, 2012 at 05:15:36PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > We have on Imx mxc at91 and other SoC controler hich you configure per pin
> > > 
> > > which means one pin have multiple function and the same function is on
> > > multiple pins
> > > 
> > > so the groups are just a list of possible pins
> > > 
> > > Instead of re-inventing bindings we do need to come with a common binding whre
> > > it's possible
> > > 
> > > So instead I proppose (send in the v2) to use common way to describe the group
> > > 
> > Let's see how many nodes we will have in device tree.  For imx6q
> > example, there are 332 pins and each pin has up to 8 function selects.
> > We will end up with having 332 x 8 = 2656 sub nodes under node
> > "functions".  Device tree simply cannot afford such a bloating.
> device tree can offord it
> 
No.  Device tree maintainers has told that.  Looking into the clock DT
binding discussion, you will find that Grant does not like to have
even 100~200 nodes to represent an entire clock tree in the DT.

With your proposal (actually this has been proposed long time before),
to represent the pins for a 24bit display, it easily consumes 28 nodes
on mach-mxs, while my binding only needs one node.  So in short, the
proposal has been discussed and it's not a sensible one.

Regards,
Shawn

> except you are going to have hundereds of duplicated pinctrl configuration
> as different board will have different mux which is impossbile to maintain
> either
> 
> and I do not expect we add all the configuration possible but just the common
> one
> 
> Best Regards,
> J.

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Sascha Hauer]

On Thu, Apr 26, 2012 at 04:44:46PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > +			fsl,pins = <1386 0x17059	/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
> > +				    1392 0x17059	/* MX6Q_PAD_SD4_CLK__USDHC4_CLK	*/
> > +				    1462 0x17059	/* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
> > +				    1470 0x17059	/* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
> > +				    1478 0x17059	/* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
> > +				    1486 0x17059	/* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
> > +				    1493 0x17059	/* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
> > +				    1501 0x17059	/* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
> > +				    1509 0x17059	/* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
> > +				    1517 0x17059>;	/* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
> honestly I don't like this it's obscure need to decode manually
> 
> I propose to use phandle
> 
> as example on uart you will want or not the rst/cts so you will have quite a
> lot of bindings
> 
> so you can describe the pin configuration (function) and refer it by phandle
> in the group

I don't exactly know where are you aiming at. I think that you want a
collection of pin groups somewhere and want to refer to it in the device
nodes. No, please don't. There's no way to come up with a common group
needed for example for the IPU (image processing unit). What pins you
want to use here depends on the number of data lines you have on your
panel and what type of panel you have. You can always use the remaining
pins for somethin else. SPI is another example. The SPI unit has some
dedicated chip select lines. The exact number of used chip selects is
board specific.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Sascha Hauer]

On Thu, Apr 26, 2012 at 10:40:27PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> This driver is shared between many platforms. Currently only imx6q has
> pinctrl support, to avoid breaking other platforms that do not have pinctrl
> support to run this driver, enable pinctrl dummy state for them before
> they also convert to pinctrl subsystem.
> 
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
> ---
> This patch depends on:
> pinctrl: add pinctrl_provide_dummies interface for platforms to use
> http://www.spinics.net/lists/arm-kernel/msg171538.html
> 
> ChangeLog v2->v3:
>  * patch name updated.
>    v1 name is ARM: imx6q: switch to use pinctrl driver
>  * using pinctrl dummy state to avoid breaking other platforms to use this
>    driver.
> 
> ChangeLog v1->v2:
>  * using updated binding
> ---
>  arch/arm/boot/dts/imx6q-arm2.dts               |    4 +++
>  arch/arm/boot/dts/imx6q.dtsi                   |   32 ++++++++++++++++++++++++
>  arch/arm/mach-imx/Kconfig                      |    2 +
>  arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c |    2 +
>  arch/arm/mach-imx/mach-cpuimx51.c              |    2 +
>  arch/arm/mach-imx/mach-cpuimx51sd.c            |    2 +
>  arch/arm/mach-imx/mach-eukrea_cpuimx25.c       |    2 +
>  arch/arm/mach-imx/mach-mx25_3ds.c              |    2 +
>  arch/arm/mach-imx/mach-mx35_3ds.c              |    2 +
>  arch/arm/mach-imx/mach-mx51_3ds.c              |    2 +
>  arch/arm/mach-imx/mach-mx51_babbage.c          |    2 +
>  arch/arm/mach-imx/mach-mx51_efikamx.c          |    2 +
>  arch/arm/mach-imx/mach-mx51_efikasb.c          |    2 +
>  arch/arm/mach-imx/mach-mx53_ard.c              |    2 +
>  arch/arm/mach-imx/mach-mx53_evk.c              |    2 +
>  arch/arm/mach-imx/mach-mx53_loco.c             |    2 +
>  arch/arm/mach-imx/mach-mx53_smd.c              |    2 +
>  arch/arm/mach-imx/mach-pcm043.c                |    2 +
>  arch/arm/mach-imx/mach-vpr200.c                |    2 +

Here you are patching only the boards which happen to use the esdhc
controller, so we need to patch other boards when another driver gains
pinctrl. Let's add the provide_dummies call to the SoCs instead which
do not have pinctrl yet.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Shawn Guo]

On Fri, Apr 27, 2012 at 09:11:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> except duplicate bindings instead having common one make no sense either
> 
> so imx, at91 and ST (STB SoC and other does have the same type of pin IP
> 
> to not come with a common bindig means we are doint the same crap as before
> 
> with switch to DT
> 
It can be every different in hardware details from one pin based
controller to another.  mxs pinctrl is another pin based IP, and Dong
tried to approach a binding working good for both imx and mxs, but in
the end we agree imx binding does not work so good for mxs, and vice
versa.  And that's why pinctrl core binding design leaves out the
platform specific binding.

-- 
Regards,
Shawn

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Shawn Guo]

On Fri, Apr 27, 2012 at 04:29:31PM +0800, Dong Aisheng wrote:
> You meant add provide_dummies call in imx*_soc_init call?
> We could do it but there might be a case that some boards are converted
> to use pinctrl while others still not but they're based on the same soc.
> For examples, 4 mx53 boards and we may not be able to convert them all at
> the same time.
> 
Only non-DT boot will call imx*_soc_init, while DT boot will not.  And
imx pinctrl only supports DT.

-- 
Regards,
Shawn

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Dong Aisheng]

On Fri, Apr 27, 2012 at 03:35:04PM +0800, Sascha Hauer wrote:
> On Thu, Apr 26, 2012 at 10:40:27PM +0800, Dong Aisheng wrote:
> > From: Dong Aisheng <dong.aisheng@linaro.org>
> > 
> > This driver is shared between many platforms. Currently only imx6q has
> > pinctrl support, to avoid breaking other platforms that do not have pinctrl
> > support to run this driver, enable pinctrl dummy state for them before
> > they also convert to pinctrl subsystem.
> > 
> > Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
> > ---
> > This patch depends on:
> > pinctrl: add pinctrl_provide_dummies interface for platforms to use
> > http://www.spinics.net/lists/arm-kernel/msg171538.html
> > 
> > ChangeLog v2->v3:
> >  * patch name updated.
> >    v1 name is ARM: imx6q: switch to use pinctrl driver
> >  * using pinctrl dummy state to avoid breaking other platforms to use this
> >    driver.
> > 
> > ChangeLog v1->v2:
> >  * using updated binding
> > ---
> >  arch/arm/boot/dts/imx6q-arm2.dts               |    4 +++
> >  arch/arm/boot/dts/imx6q.dtsi                   |   32 ++++++++++++++++++++++++
> >  arch/arm/mach-imx/Kconfig                      |    2 +
> >  arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c |    2 +
> >  arch/arm/mach-imx/mach-cpuimx51.c              |    2 +
> >  arch/arm/mach-imx/mach-cpuimx51sd.c            |    2 +
> >  arch/arm/mach-imx/mach-eukrea_cpuimx25.c       |    2 +
> >  arch/arm/mach-imx/mach-mx25_3ds.c              |    2 +
> >  arch/arm/mach-imx/mach-mx35_3ds.c              |    2 +
> >  arch/arm/mach-imx/mach-mx51_3ds.c              |    2 +
> >  arch/arm/mach-imx/mach-mx51_babbage.c          |    2 +
> >  arch/arm/mach-imx/mach-mx51_efikamx.c          |    2 +
> >  arch/arm/mach-imx/mach-mx51_efikasb.c          |    2 +
> >  arch/arm/mach-imx/mach-mx53_ard.c              |    2 +
> >  arch/arm/mach-imx/mach-mx53_evk.c              |    2 +
> >  arch/arm/mach-imx/mach-mx53_loco.c             |    2 +
> >  arch/arm/mach-imx/mach-mx53_smd.c              |    2 +
> >  arch/arm/mach-imx/mach-pcm043.c                |    2 +
> >  arch/arm/mach-imx/mach-vpr200.c                |    2 +
> 
> Here you are patching only the boards which happen to use the esdhc
> controller, so we need to patch other boards when another driver gains

Yes, theoretically, if a board does not have drivers running with pinctrl,
it may not need change.

There're so many boards under arch/arm/mach-imx/*:
b29396 at shlinux2:~/upstream/linux-pinctrl$ ls arch/arm/mach-imx/mach-
mach-apf9328.c             mach-imx27_visstrim_m10.c  mach-mx31lilly.c           mach-mx51_efikamx.o        mach-pcm037_eet.c
mach-armadillo5x0.c        mach-imx6q.c               mach-mx31lilly.o           mach-mx51_efikasb.c        mach-pcm037_eet.o
mach-armadillo5x0.o        mach-imx6q.o               mach-mx31lite.c            mach-mx51_efikasb.o        mach-pcm037.o
mach-bug.c                 mach-kzm_arm11_01.c        mach-mx31lite.o            mach-mx53_ard.c            mach-pcm038.c
mach-bug.o                 mach-kzm_arm11_01.o        mach-mx31moboard.c         mach-mx53_ard.o            mach-pcm043.c
mach-cpuimx27.c            mach-mx1ads.c              mach-mx31moboard.o         mach-mx53_evk.c            mach-pcm043.o
mach-cpuimx35.c            mach-mx21ads.c             mach-mx35_3ds.c            mach-mx53_evk.o            mach-qong.c
mach-cpuimx51.c            mach-mx25_3ds.c            mach-mx35_3ds.o            mach-mx53_loco.c           mach-qong.o
mach-cpuimx51.o            mach-mx27_3ds.c            mach-mx50_rdp.c            mach-mx53_loco.o           mach-scb9328.c
mach-cpuimx51sd.c          mach-mx27ads.c             mach-mx51_3ds.c            mach-mx53_smd.c            mach-vpr200.c
mach-cpuimx51sd.o          mach-mx31_3ds.c            mach-mx51_3ds.o            mach-mx53_smd.o            mach-vpr200.o
mach-eukrea_cpuimx25.c     mach-mx31_3ds.o            mach-mx51_babbage.c        mach-mxt_td60.c
mach-imx27ipcam.c          mach-mx31ads.c             mach-mx51_babbage.o        mach-pca100.c
mach-imx27lite.c           mach-mx31ads.o             mach-mx51_efikamx.c        mach-pcm037.c

Some of them i'm not familiar and i don't know whether they may use pinctrl
so i just patched the affected ones.

One lazy method may be just patch all board files without pinctrl support
and it will not cause any error.

What's your suggestion?

> pinctrl. Let's add the provide_dummies call to the SoCs instead which
> do not have pinctrl yet.
> 
You meant add provide_dummies call in imx*_soc_init call?
We could do it but there might be a case that some boards are converted
to use pinctrl while others still not but they're based on the same soc.
For examples, 4 mx53 boards and we may not be able to convert them all at
the same time.

Regards
Dong Aisheng

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Sascha Hauer]

On Fri, Apr 27, 2012 at 04:29:31PM +0800, Dong Aisheng wrote:
> mach-imx27ipcam.c          mach-mx31ads.c             mach-mx51_babbage.o        mach-pca100.c
> mach-imx27lite.c           mach-mx31ads.o             mach-mx51_efikamx.c        mach-pcm037.c
> 
> Some of them i'm not familiar and i don't know whether they may use pinctrl
> so i just patched the affected ones.
> 
> One lazy method may be just patch all board files without pinctrl support
> and it will not cause any error.
> 
> What's your suggestion?
> 
> > pinctrl. Let's add the provide_dummies call to the SoCs instead which
> > do not have pinctrl yet.
> > 
> You meant add provide_dummies call in imx*_soc_init call?
> We could do it but there might be a case that some boards are converted
> to use pinctrl while others still not but they're based on the same soc.
> For examples, 4 mx53 boards and we may not be able to convert them all at
> the same time.

My point is that none of the mx5 boards have pinctrl since there is no
SoC driver for it.
For DT based boards pinctrl should be mandatory once the SoC has pinctrl
support. All non DT boards probably won't get pinctrl anyway.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Sascha Hauer]

On Fri, Apr 27, 2012 at 04:54:46PM +0800, Dong Aisheng wrote:
> On Fri, Apr 27, 2012 at 04:31:42PM +0800, Sascha Hauer wrote:
> > On Fri, Apr 27, 2012 at 04:29:31PM +0800, Dong Aisheng wrote:
> > > mach-imx27ipcam.c          mach-mx31ads.c             mach-mx51_babbage.o        mach-pca100.c
> > > mach-imx27lite.c           mach-mx31ads.o             mach-mx51_efikamx.c        mach-pcm037.c
> > > 
> > > Some of them i'm not familiar and i don't know whether they may use pinctrl
> > > so i just patched the affected ones.
> > > 
> > > One lazy method may be just patch all board files without pinctrl support
> > > and it will not cause any error.
> > > 
> > > What's your suggestion?
> > > 
> > > > pinctrl. Let's add the provide_dummies call to the SoCs instead which
> > > > do not have pinctrl yet.
> > > > 
> > > You meant add provide_dummies call in imx*_soc_init call?
> > > We could do it but there might be a case that some boards are converted
> > > to use pinctrl while others still not but they're based on the same soc.
> > > For examples, 4 mx53 boards and we may not be able to convert them all at
> > > the same time.
> > 
> > My point is that none of the mx5 boards have pinctrl since there is no
> > SoC driver for it.
> > For DT based boards pinctrl should be mandatory once the SoC has pinctrl
> > support. All non DT boards probably won't get pinctrl anyway.
> > 
> Ok, so i would be fine for me to change it in imx*_soc_init.
> BTW, there're:
> imx1_soc_init()
> imx25_soc_init()
> imx27_soc_init()
> imx31_soc_init()
> imx35_soc_init()
> imx50_soc_init()
> imx51_soc_init()
> imx53_soc_init()
> 
> I'm not sure about mx1, mx27, mx31
> Do you think if i could add them all?

Of course. Or do you see a pinctrl driver for any i.MX except i.MX6?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Shawn Guo]

On Thu, Apr 26, 2012 at 10:40:25PM +0800, Dong Aisheng wrote:
> +/**
> + * struct imx_pin_reg - describe a pin reg map
> + * The last 3 members are used for select input setting
> + * @pid: pin id
> + * @mux_reg: mux register offset
> + * @conf_reg: config register offset
> + * @mux_mode: mux mode
> + * @input_reg: select input register offset for this mux if any
> + *  0 if no select input setting needed.
> + * @input_val: the value set to select input register
> + */
> +struct imx_pin_reg {
> +	unsigned int pid;
> +	unsigned int mux_reg;
> +	unsigned int conf_reg;
> +	unsigned int mux_mode;
> +	unsigned int input_reg;
> +	unsigned int input_val;
> +};

Since the array of this struct is big, I would suggest define the type
of the members as size-efficient as possible, for example, u16 is enough
for pid, and reg offset, while u8 is enough for mux_mode?

-- 
Regards,
Shawn

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Dong Aisheng]

On Fri, Apr 27, 2012 at 04:31:42PM +0800, Sascha Hauer wrote:
> On Fri, Apr 27, 2012 at 04:29:31PM +0800, Dong Aisheng wrote:
> > mach-imx27ipcam.c          mach-mx31ads.c             mach-mx51_babbage.o        mach-pca100.c
> > mach-imx27lite.c           mach-mx31ads.o             mach-mx51_efikamx.c        mach-pcm037.c
> > 
> > Some of them i'm not familiar and i don't know whether they may use pinctrl
> > so i just patched the affected ones.
> > 
> > One lazy method may be just patch all board files without pinctrl support
> > and it will not cause any error.
> > 
> > What's your suggestion?
> > 
> > > pinctrl. Let's add the provide_dummies call to the SoCs instead which
> > > do not have pinctrl yet.
> > > 
> > You meant add provide_dummies call in imx*_soc_init call?
> > We could do it but there might be a case that some boards are converted
> > to use pinctrl while others still not but they're based on the same soc.
> > For examples, 4 mx53 boards and we may not be able to convert them all at
> > the same time.
> 
> My point is that none of the mx5 boards have pinctrl since there is no
> SoC driver for it.
> For DT based boards pinctrl should be mandatory once the SoC has pinctrl
> support. All non DT boards probably won't get pinctrl anyway.
> 
Ok, so i would be fine for me to change it in imx*_soc_init.
BTW, there're:
imx1_soc_init()
imx25_soc_init()
imx27_soc_init()
imx31_soc_init()
imx35_soc_init()
imx50_soc_init()
imx51_soc_init()
imx53_soc_init()

I'm not sure about mx1, mx27, mx31
Do you think if i could add them all?

Regards
Dong Aisheng

[PATCH v3 4/4] mmc: sdhci-imx-esdhc: convert to use pinctrl subsystem

[Dong Aisheng]

On Fri, Apr 27, 2012 at 04:47:44PM +0800, Sascha Hauer wrote:
> On Fri, Apr 27, 2012 at 04:54:46PM +0800, Dong Aisheng wrote:
> > On Fri, Apr 27, 2012 at 04:31:42PM +0800, Sascha Hauer wrote:
> > > On Fri, Apr 27, 2012 at 04:29:31PM +0800, Dong Aisheng wrote:
> > > > mach-imx27ipcam.c          mach-mx31ads.c             mach-mx51_babbage.o        mach-pca100.c
> > > > mach-imx27lite.c           mach-mx31ads.o             mach-mx51_efikamx.c        mach-pcm037.c
> > > > 
> > > > Some of them i'm not familiar and i don't know whether they may use pinctrl
> > > > so i just patched the affected ones.
> > > > 
> > > > One lazy method may be just patch all board files without pinctrl support
> > > > and it will not cause any error.
> > > > 
> > > > What's your suggestion?
> > > > 
> > > > > pinctrl. Let's add the provide_dummies call to the SoCs instead which
> > > > > do not have pinctrl yet.
> > > > > 
> > > > You meant add provide_dummies call in imx*_soc_init call?
> > > > We could do it but there might be a case that some boards are converted
> > > > to use pinctrl while others still not but they're based on the same soc.
> > > > For examples, 4 mx53 boards and we may not be able to convert them all at
> > > > the same time.
> > > 
> > > My point is that none of the mx5 boards have pinctrl since there is no
> > > SoC driver for it.
> > > For DT based boards pinctrl should be mandatory once the SoC has pinctrl
> > > support. All non DT boards probably won't get pinctrl anyway.
> > > 
> > Ok, so i would be fine for me to change it in imx*_soc_init.
> > BTW, there're:
> > imx1_soc_init()
> > imx25_soc_init()
> > imx27_soc_init()
> > imx31_soc_init()
> > imx35_soc_init()
> > imx50_soc_init()
> > imx51_soc_init()
> > imx53_soc_init()
> > 
> > I'm not sure about mx1, mx27, mx31
> > Do you think if i could add them all?
> 
> Of course. Or do you see a pinctrl driver for any i.MX except i.MX6?
> 
My understanding is that besides if have pinctrl driver, calling provide_dummies
also depends on whether it really has drivers using pinctrl.
Anyway, will update it soon.
Thanks for the confirm.

Regards
Dong Aisheng

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:11 Fri 27 Apr     , Shawn Guo wrote:
> On Fri, Apr 27, 2012 at 09:11:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > except duplicate bindings instead having common one make no sense either
> > 
> > so imx, at91 and ST (STB SoC and other does have the same type of pin IP
> > 
> > to not come with a common bindig means we are doint the same crap as before
> > 
> > with switch to DT
> > 
> It can be every different in hardware details from one pin based
> controller to another.  mxs pinctrl is another pin based IP, and Dong
> tried to approach a binding working good for both imx and mxs, but in
> the end we agree imx binding does not work so good for mxs, and vice
> versa.  And that's why pinctrl core binding design leaves out the
> platform specific binding.
agreed on the pin level configuration but not for the group management
there all the same
of simple group of pins

for this we must have a common way to describe it and handle it in c

Best Regards,
J.

[PATCH v3 2/4] pinctrl: pinctrl-imx: add imx pinctrl core driver

[Dong Aisheng]

On Fri, Apr 27, 2012 at 04:54:05PM +0800, Shawn Guo wrote:
> On Thu, Apr 26, 2012 at 10:40:25PM +0800, Dong Aisheng wrote:
> > +/**
> > + * struct imx_pin_reg - describe a pin reg map
> > + * The last 3 members are used for select input setting
> > + * @pid: pin id
> > + * @mux_reg: mux register offset
> > + * @conf_reg: config register offset
> > + * @mux_mode: mux mode
> > + * @input_reg: select input register offset for this mux if any
> > + *  0 if no select input setting needed.
> > + * @input_val: the value set to select input register
> > + */
> > +struct imx_pin_reg {
> > +	unsigned int pid;
> > +	unsigned int mux_reg;
> > +	unsigned int conf_reg;
> > +	unsigned int mux_mode;
> > +	unsigned int input_reg;
> > +	unsigned int input_val;
> > +};
> 
> Since the array of this struct is big, I would suggest define the type
> of the members as size-efficient as possible, for example, u16 is enough
> for pid, and reg offset, while u8 is enough for mux_mode?
> 
Yes, reasonable.
Will change to that in v4.

Regards
Dong Aisheng

[PATCH v5 1/1] dt: add of_get_child_count helper function

[Stephen Warren]

On 04/26/2012 09:36 PM, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> Currently most code to get child count in kernel are almost same,
> add a helper to implement this function for dt to use.
> 
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>

Acked-by: Stephen Warren <swarren@wwwdotorg.org>

[PATCH v5 1/1] dt: add of_get_child_count helper function

[Linus Walleij]

On Fri, Apr 27, 2012 at 5:36 AM, Dong Aisheng <b29396@freescale.com> wrote:

> From: Dong Aisheng <dong.aisheng@linaro.org>
>
> Currently most code to get child count in kernel are almost same,
> add a helper to implement this function for dt to use.
>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
>
> ---
> Rob missed this patch for 3.4 kernel.
> Based on Rob's suggestion, we can get it go in with pinctrl driver.
> Since Rob once had applied it, i added Rob's ack.
> See:
> https://lkml.org/lkml/2012/4/14/239

OK I've applied this to the pinctrl tree with Stephens ACK.

Yours,
Linus Walleij