On Thu, Apr 26, 2012 at 10:40:25PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aish...@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.aish...@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.
> ---

> > +Examples:
> > +usdhc@0219c000 { /* uSDHC4 */
> > +     fsl,card-wired;
> > +     vmmc-supply = <&reg_3p3v>;
> > +     status = "okay";
> > +     pinctrl-names = "default";
> > +     pinctrl-0 = <&pinctrl_usdhc4_1>;
> > +};
> > +
> > +iomuxc@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

> From: Dong Aisheng <dong.aish...@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;

> From: Dong Aisheng <dong.aish...@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.

> From: Dong Aisheng <dong.aish...@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.aish...@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@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 */

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.aish...@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.

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.aish...@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.aish...@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@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

On Thu, Apr 26, 2012 at 10:40:25PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aish...@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.aish...@linaro.org>

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

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

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

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

> 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.

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

> Signed-off-by: Dong Aisheng <dong.aish...@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.

> 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.

> > > +   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@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.

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.aish...@linaro.org>

> > Signed-off-by: Dong Aisheng <dong.aish...@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...

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

> 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.

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

On Thu, Apr 26, 2012 at 10:40:27PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aish...@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.aish...@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 +

> 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.

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

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.aish...@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.aish...@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.

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.