diff mbox

[v8,12/12] document: devicetree: bind pinconf with pin single

Message ID 1359825953-15663-13-git-send-email-haojian.zhuang@linaro.org
State Superseded
Headers show

Commit Message

Haojian Zhuang Feb. 2, 2013, 5:25 p.m. UTC
From: Haojian Zhuang <haojian.zhuang@gmail.com>

Add comments with pinconf & gpio range in the document of
pinctrl-single.

Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
---
 .../devicetree/bindings/pinctrl/pinctrl-single.txt |  108 +++++++++++++++++++-
 1 file changed, 107 insertions(+), 1 deletion(-)

Comments

Tony Lindgren Feb. 5, 2013, 4:07 a.m. UTC | #1
* Haojian Zhuang <haojian.zhuang@linaro.org> [130202 09:32]:
> +- pinctrl-single,drive-strength : array of value that are used to configure
> +  drive strength in the pinmux register. They're value of drive strength
> +  current and drive strength mask.
> +
> +		/* drive strength current, mask */
> +		pinctrl-single,power-source = <0x30 0xf0>;
> +

Looks like a typo, this should probably say pinctrl-single,drive-strength
here instead of power-source?

For the cases where there's a value to be set I'm still wondering how does
a client driver change the value if that needs to be changed dynamically?
Can the value be passed as value + PIN_CONFIG_END?

> +- pinctrl-single,bias-disable : array of value that are used to configure the
> +  input bias disabled in the pinmux register. They're value of bias value,
> +  match bias disabled value and bias disabled mask.
> +
> +		/* bias value, match bias disabled value, mask */
> +		pinctrl-single,bias-disable = <2 0 3>;
> +

I still suggest we use "enable" naming instead of "disable" naming.
So pinctrl-single,bias-enable instead of pinctrl-single,bias-disable.

Then let's change the binding slightly to make it more readable:

		/* enable value, disable value, mask */
		pinctrl-single,bias-enable = <2 0 3>;

For example, I have bit 22 cleared to enable MMC PBIAS, or bit 22
set to disable PBIAS:

		                             /* enable disable  mask */
		pinctrl-single,bias-enable = <0x000000 0x400000 0x400000>;

Then I think pretty much the only change to pinconf_get() would be:

	data = pcs->read(pcs->base + offset) & func->conf[i].mask;

	switch (func->conf[i].param) {
	/* 3 parameters */
	case PIN_CONFIG_BIAS_ENABLE:
	case PIN_CONFIG_BIAS_PULL_DOWN:
	case PIN_CONFIG_BIAS_PULL_UP:
	case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
	*config = data;
	if (data == func->conf[i].enable)
		res = 0;
	else
		res = -ENOTSUPP;
	break;
	...

And then the client driver can always assume that if the return value
is 0, the ENABLE value in question is set. And if -ENOTSUPP (or how about
-ENOTSET :) is returned, the ENABLE value is not set?

Then regarding pinconf_set(), don't we also need pinconf_clear() in
addition to pinconf_set()?

Otherwise we need both ENABLE and DISABLE enumeration, which seems
unnecessary to me. So rather than have both PIN_CONFIG_BIAS_ENABLE and
PIN_CONFIG_BIAS_DISABLE, we just need PIN_CONFIG_BIAS_ENABLE.

> +- pinctrl-single,bias-pullup : array of value that are used to configure the
> +  input bias pullup in the pinmux register. They're value of bias value,
> +  match bias pullup value and bias pullup mask.
> +
> +		/* bias value, match bias pullup value, mask */
> +		pinctrl-single,bias-pullup = <0 1 1>;

It seems that you could then use same generic comment in all places
then to make it a bit easier to read:

		/* enable value, disable value, mask */
		pinctrl-single,bias-pullup = <0 1 1>;
...

Regards,

Tony
Haojian Zhuang Feb. 5, 2013, 8:06 a.m. UTC | #2
On Tue, Feb 5, 2013 at 12:07 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Haojian Zhuang <haojian.zhuang@linaro.org> [130202 09:32]:
>> +- pinctrl-single,drive-strength : array of value that are used to configure
>> +  drive strength in the pinmux register. They're value of drive strength
>> +  current and drive strength mask.
>> +
>> +             /* drive strength current, mask */
>> +             pinctrl-single,power-source = <0x30 0xf0>;
>> +
>
> Looks like a typo, this should probably say pinctrl-single,drive-strength
> here instead of power-source?
>
Yes, I should update it to drive strength.

> For the cases where there's a value to be set I'm still wondering how does
> a client driver change the value if that needs to be changed dynamically?
> Can the value be passed as value + PIN_CONFIG_END?
>
pinconf_to_config_packed() can help to bind param & argument into config
variable.

>> +- pinctrl-single,bias-disable : array of value that are used to configure the
>> +  input bias disabled in the pinmux register. They're value of bias value,
>> +  match bias disabled value and bias disabled mask.
>> +
>> +             /* bias value, match bias disabled value, mask */
>> +             pinctrl-single,bias-disable = <2 0 3>;
>> +
>
> I still suggest we use "enable" naming instead of "disable" naming.
> So pinctrl-single,bias-enable instead of pinctrl-single,bias-disable.
>
> Then let's change the binding slightly to make it more readable:
>
>                 /* enable value, disable value, mask */
>                 pinctrl-single,bias-enable = <2 0 3>;
>
> For example, I have bit 22 cleared to enable MMC PBIAS, or bit 22
> set to disable PBIAS:
>
>                                              /* enable disable  mask */
>                 pinctrl-single,bias-enable = <0x000000 0x400000 0x400000>;
>
In Hi3620 SoC, the bias could only be configured pull up or pull down. There's
no any bit for controlling bias enable or bias disable. But user may need to
remove both pullup and pulldown at runtime. In this case, I set bias disable
if there's no pullup & pulldown.

* Without bias enable/disable bit.
            bias-disable = <user input value, expected disable value, mask>;
            bias-pullup = <user input value, expected pullup value, mask>;
      "expected disable value" is the set of not pullup bit and not
pull down bit.
      "expected pullup value" is the set of pullup bit.

* With bias enable/disable bit.
      "expected disable value" is the set of disable bit, NOT pullup
bit and NOT pulldown bit.
      "expected pullup value" is the set of NOT disable bit & pullup bit.

PULLUP --> DISABLE: only need to set the expected disable value in
bias-disable property.
DISABLE --> PULLUP: only need to set the expected pullup value in
bias-pullup property.
PULLUP --> PULLDOWN: set the expected pulldown value. So both pullup
and pulldown
bits are enabled unless user call DISABLE first.. Maybe it's not
right. I can fix it and keep
either pullup or pulldown enabled. It's ok to add pinconf_clear() for
bias as you mentioned.

And I think that we need four parameters with your format.
      <user setting on bias enable/disable, expected enable value,
expected disable value, mask */
Otherwise, how could we know user's setting? Especially, we need to
configure pullup.
In your case, expected pullup enable & expected pullup disable are set
in bias-pullup property.
>                 /* enable value, disable value, mask */
>                 pinctrl-single,bias-pullup = <0 1 1>;

Actually, I'm OK to use enable value. And it needs 4 parameters since
disable value may not be zero.

By the way, bias property would be the format in below with 4 parameters.
* Without bias enable/disable bit.
          bias-enable = <0, 0, 0, set of both pullup and pulldown mask>;

* With bias enable/disable bit.
          bias-enable = <user setting, expected enable, expected
disable, mask of only enable/disable bit>;

Behavior of pinconf_clear():
     - call bias-disable
     - call the expected bias setting.

DISABLE --> PULLUP, user call config BIAS_PULLUP without additional argument.
PULLUP --> PULLDOWN, user call with config BIAS_PULLDOWN without
additional argument.
PULLUP --> DISABLE, user call with config BIAS_ENABLE and 0 for argument.

The switch from PULLUP to DISABLE is a little strange since we have to
call BIAS_ENABLE.
Is it good for you?

> Then I think pretty much the only change to pinconf_get() would be:
>
>         data = pcs->read(pcs->base + offset) & func->conf[i].mask;
>
>         switch (func->conf[i].param) {
>         /* 3 parameters */
>         case PIN_CONFIG_BIAS_ENABLE:
>         case PIN_CONFIG_BIAS_PULL_DOWN:
>         case PIN_CONFIG_BIAS_PULL_UP:
>         case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
>         *config = data;
>         if (data == func->conf[i].enable)
>                 res = 0;
>         else
>                 res = -ENOTSUPP;
>         break;
>         ...
>
> And then the client driver can always assume that if the return value
> is 0, the ENABLE value in question is set. And if -ENOTSUPP (or how about
> -ENOTSET :) is returned, the ENABLE value is not set?
>
Return constant value 0 is better. I'll update.

> Then regarding pinconf_set(), don't we also need pinconf_clear() in
> addition to pinconf_set()?
>
> Otherwise we need both ENABLE and DISABLE enumeration, which seems
> unnecessary to me. So rather than have both PIN_CONFIG_BIAS_ENABLE and
> PIN_CONFIG_BIAS_DISABLE, we just need PIN_CONFIG_BIAS_ENABLE.
I can append pinconf_clear() to handle it.

>
>> +- pinctrl-single,bias-pullup : array of value that are used to configure the
>> +  input bias pullup in the pinmux register. They're value of bias value,
>> +  match bias pullup value and bias pullup mask.
>> +
>> +             /* bias value, match bias pullup value, mask */
>> +             pinctrl-single,bias-pullup = <0 1 1>;
>
> It seems that you could then use same generic comment in all places
> then to make it a bit easier to read:
>
>                 /* enable value, disable value, mask */
>                 pinctrl-single,bias-pullup = <0 1 1>;
Discussed above.
Haojian Zhuang Feb. 5, 2013, 1:51 p.m. UTC | #3
On Tue, Feb 5, 2013 at 4:06 PM, Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
> On Tue, Feb 5, 2013 at 12:07 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Haojian Zhuang <haojian.zhuang@linaro.org> [130202 09:32]:
>>> +- pinctrl-single,drive-strength : array of value that are used to configure
>>> +  drive strength in the pinmux register. They're value of drive strength
>>> +  current and drive strength mask.
>>> +
>>> +             /* drive strength current, mask */
>>> +             pinctrl-single,power-source = <0x30 0xf0>;
>>> +
>>
>> Looks like a typo, this should probably say pinctrl-single,drive-strength
>> here instead of power-source?
>>
> Yes, I should update it to drive strength.
>
>> For the cases where there's a value to be set I'm still wondering how does
>> a client driver change the value if that needs to be changed dynamically?
>> Can the value be passed as value + PIN_CONFIG_END?
>>
> pinconf_to_config_packed() can help to bind param & argument into config
> variable.
>
>>> +- pinctrl-single,bias-disable : array of value that are used to configure the
>>> +  input bias disabled in the pinmux register. They're value of bias value,
>>> +  match bias disabled value and bias disabled mask.
>>> +
>>> +             /* bias value, match bias disabled value, mask */
>>> +             pinctrl-single,bias-disable = <2 0 3>;
>>> +
>>
>> I still suggest we use "enable" naming instead of "disable" naming.
>> So pinctrl-single,bias-enable instead of pinctrl-single,bias-disable.
>>
>> Then let's change the binding slightly to make it more readable:
>>
>>                 /* enable value, disable value, mask */
>>                 pinctrl-single,bias-enable = <2 0 3>;
>>
>> For example, I have bit 22 cleared to enable MMC PBIAS, or bit 22
>> set to disable PBIAS:
>>
>>                                              /* enable disable  mask */
>>                 pinctrl-single,bias-enable = <0x000000 0x400000 0x400000>;
>>
> In Hi3620 SoC, the bias could only be configured pull up or pull down. There's
> no any bit for controlling bias enable or bias disable. But user may need to
> remove both pullup and pulldown at runtime. In this case, I set bias disable
> if there's no pullup & pulldown.
>
> * Without bias enable/disable bit.
>             bias-disable = <user input value, expected disable value, mask>;
>             bias-pullup = <user input value, expected pullup value, mask>;
>       "expected disable value" is the set of not pullup bit and not
> pull down bit.
>       "expected pullup value" is the set of pullup bit.
>
> * With bias enable/disable bit.
>       "expected disable value" is the set of disable bit, NOT pullup
> bit and NOT pulldown bit.
>       "expected pullup value" is the set of NOT disable bit & pullup bit.
>
> PULLUP --> DISABLE: only need to set the expected disable value in
> bias-disable property.
> DISABLE --> PULLUP: only need to set the expected pullup value in
> bias-pullup property.
> PULLUP --> PULLDOWN: set the expected pulldown value. So both pullup
> and pulldown
> bits are enabled unless user call DISABLE first.. Maybe it's not
> right. I can fix it and keep
> either pullup or pulldown enabled. It's ok to add pinconf_clear() for
> bias as you mentioned.
>
> And I think that we need four parameters with your format.
>       <user setting on bias enable/disable, expected enable value,
> expected disable value, mask */
> Otherwise, how could we know user's setting? Especially, we need to
> configure pullup.
> In your case, expected pullup enable & expected pullup disable are set
> in bias-pullup property.
>>                 /* enable value, disable value, mask */
>>                 pinctrl-single,bias-pullup = <0 1 1>;
>
> Actually, I'm OK to use enable value. And it needs 4 parameters since
> disable value may not be zero.
>
> By the way, bias property would be the format in below with 4 parameters.
> * Without bias enable/disable bit.
>           bias-enable = <0, 0, 0, set of both pullup and pulldown mask>;
>
> * With bias enable/disable bit.
>           bias-enable = <user setting, expected enable, expected
> disable, mask of only enable/disable bit>;
>
> Behavior of pinconf_clear():
>      - call bias-disable
>      - call the expected bias setting.
>
> DISABLE --> PULLUP, user call config BIAS_PULLUP without additional argument.
> PULLUP --> PULLDOWN, user call with config BIAS_PULLDOWN without
> additional argument.
> PULLUP --> DISABLE, user call with config BIAS_ENABLE and 0 for argument.
>
> The switch from PULLUP to DISABLE is a little strange since we have to
> call BIAS_ENABLE.
> Is it good for you?
>

Maybe it didn't cover your case. It seems that there's only one bit
for bias in your case.
You can control MMC BIAS enable or disable. And there's neither pullup
nor pulldown.
Is it right?

If so, how about this?

* Without pullup & pulldown bias. With bias enable & disable bit.
(Your MMC bias)
     1) 3 params
           bias-disable = <user setting of bias value, expected bias
disable value, mask>;
           bias-enable = <user setting of bias value, expected bias
enable value, mask>;
     or 2) 4 params
           bias-enable = <user setting of bias value, expected bias
enable value, expected bias disable value, mask>;

     So I will need both config BIAS_ENABLE & config BIAS_DISABLE.
Driver switches between BIAS_ENABLE & BIAS_DISABLE.

* Without bias enable & disable bit. With bias pullup & pulldown bit.
(Hi3620 bias)
     1) 3 params
           bias-disable = <user setting of bias value, expected
disable value (w/o pullup & pulldown), mask (pullup & pulldown)>;
           bias-pullup = <user setting of bias value, expected bias
pullup value, mask of pullup>;
           bias-pulldown ...
     or 2) 4 params
           bias-enable = <user setting of bias value, expected enable
value (w pullup & pulldown), expected disable value (w/o pullup &
pulldown), mask (pullup & pulldown)>;
           bias-pullup = <user setting of bias value, expected bias
pullup value, expected bias pullup disable value, mask of pullup>;
           bias-pulldown ...
     Driver switches among BIAS_DISABLE, BIAS_PULLDOWN, BIAS_PULLUP.
It seems that BIAS_ENABLE is redundant operation at here.

* With bias enable & disable bit. With bias pullup & pulldown bit.
(MMP/PXA bias)
     1) 3 params
          bias-disable = <user setting of bias value, expected disable
value (single bit), mask (enable/disable)>;
          bias-pullup = <user setting of bias value, expected pullup
value, mask (pullup)>;
          bias-pulldown ...
     or 2) 4 params
          bias-enable = <user setting of bias value, expected enable
value, expected disable value, mask>;
          bias-pullup = <user setting of bias value, expected bias
pullup value, expected bias pullup disable value, mask of pullup>;
          bias-pulldown ...
     Driver switches among BIAS_DISABLE, BIAS_PULLDOWN, BIAS_PULLUP.
It seems that BIAS_ENABLE is redundant operation at here. Because user
won't only enable bias without pullup or pulldown.

There're two usage for all three cases. Which one do you like?

Best Regards
Haojian
Tony Lindgren Feb. 5, 2013, 11:21 p.m. UTC | #4
* Haojian Zhuang <haojian.zhuang@gmail.com> [130205 00:09]:
> On Tue, Feb 5, 2013 at 12:07 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
> > For the cases where there's a value to be set I'm still wondering how does
> > a client driver change the value if that needs to be changed dynamically?
> > Can the value be passed as value + PIN_CONFIG_END?
> >
> pinconf_to_config_packed() can help to bind param & argument into config
> variable.

OK good to hear you've looked into that.
...
 
> And I think that we need four parameters with your format.
>       <user setting on bias enable/disable, expected enable value,
> expected disable value, mask */
> Otherwise, how could we know user's setting? Especially, we need to
> configure pullup.
> In your case, expected pullup enable & expected pullup disable are set
> in bias-pullup property.
> >                 /* enable value, disable value, mask */
> >                 pinctrl-single,bias-pullup = <0 1 1>;
> 
> Actually, I'm OK to use enable value. And it needs 4 parameters since
> disable value may not be zero.

OK. Four values makes sense to me so we can configure the default
pinconf value like we already do for pinmux.
 
> By the way, bias property would be the format in below with 4 parameters.
> * Without bias enable/disable bit.
>           bias-enable = <0, 0, 0, set of both pullup and pulldown mask>;
> 
> * With bias enable/disable bit.
>           bias-enable = <user setting, expected enable, expected
> disable, mask of only enable/disable bit>;
> 
> Behavior of pinconf_clear():
>      - call bias-disable
>      - call the expected bias setting.

Hmm I was thinking pinconf_clear() would get passed the same parameters
as pinconf_set() except it just does the opposite. But maybe I'm not
following you here.
 
> DISABLE --> PULLUP, user call config BIAS_PULLUP without additional argument.
> PULLUP --> PULLDOWN, user call with config BIAS_PULLDOWN without
> additional argument.
> PULLUP --> DISABLE, user call with config BIAS_ENABLE and 0 for argument.
> 
> The switch from PULLUP to DISABLE is a little strange since we have to
> call BIAS_ENABLE.
> Is it good for you?

I'm not sure I follow your example here, but sounds like the PULLUP to
DISABLE case can be maybe handled by covering both bits in the mask?
 
> > Then regarding pinconf_set(), don't we also need pinconf_clear() in
> > addition to pinconf_set()?
> >
> > Otherwise we need both ENABLE and DISABLE enumeration, which seems
> > unnecessary to me. So rather than have both PIN_CONFIG_BIAS_ENABLE and
> > PIN_CONFIG_BIAS_DISABLE, we just need PIN_CONFIG_BIAS_ENABLE.
> I can append pinconf_clear() to handle it.
 
OK great, I guess then we should have everything in place to make it
usable from client drivers also.

Regards,

Tony
Tony Lindgren Feb. 5, 2013, 11:30 p.m. UTC | #5
* Haojian Zhuang <haojian.zhuang@gmail.com> [130205 05:55]:
> 
> Maybe it didn't cover your case. It seems that there's only one bit
> for bias in your case.
> You can control MMC BIAS enable or disable. And there's neither pullup
> nor pulldown.
> Is it right?

Yes for this register there are no pulls. But I there are others that
have pull bits.

>      So I will need both config BIAS_ENABLE & config BIAS_DISABLE.
> Driver switches between BIAS_ENABLE & BIAS_DISABLE.

I'd like to avoid mapping both enable and disable for everything
which seems bloated..
 
>      or 2) 4 params
>            bias-enable = <user setting of bias value, expected enable
> value (w pullup & pulldown), expected disable value (w/o pullup &
> pulldown), mask (pullup & pulldown)>;
>            bias-pullup = <user setting of bias value, expected bias
> pullup value, expected bias pullup disable value, mask of pullup>;
>            bias-pulldown ...
>      Driver switches among BIAS_DISABLE, BIAS_PULLDOWN, BIAS_PULLUP.
> It seems that BIAS_ENABLE is redundant operation at here.

..so this 4 params option makes sense to me assuming it works
for your case.
 
> There're two usage for all three cases. Which one do you like?

It seems that the 4 params option is most generic to me.

Regards,

Tony
Haojian Zhuang Feb. 6, 2013, 3:07 p.m. UTC | #6
On 6 February 2013 07:30, Tony Lindgren <tony@atomide.com> wrote:
> * Haojian Zhuang <haojian.zhuang@gmail.com> [130205 05:55]:
>>
>> Maybe it didn't cover your case. It seems that there's only one bit
>> for bias in your case.
>> You can control MMC BIAS enable or disable. And there's neither pullup
>> nor pulldown.
>> Is it right?
>
> Yes for this register there are no pulls. But I there are others that
> have pull bits.
>
>>      So I will need both config BIAS_ENABLE & config BIAS_DISABLE.
>> Driver switches between BIAS_ENABLE & BIAS_DISABLE.
>
> I'd like to avoid mapping both enable and disable for everything
> which seems bloated..
>

pinctrl-coh901 driver already uses PIN_CONFIG_BIAS_DISABLE without argument.

I think that it's better to use both BIAS_ENABLE & BIAS_DISABLE. Otherwise,
I need to update pinctrl-coh901 driver with updating the interface.
The work is a little
large.

Maybe we can use another name, PIN_CONFIG_BIAS_AUTOPULL. Then we can
distinguish it from PULL_UP & PULL_DOWN without any confusion. What's your
opinion?

Regards
Haojian
Tony Lindgren Feb. 6, 2013, 5:16 p.m. UTC | #7
* Haojian Zhuang <haojian.zhuang@linaro.org> [130206 07:11]:
> On 6 February 2013 07:30, Tony Lindgren <tony@atomide.com> wrote:
> > * Haojian Zhuang <haojian.zhuang@gmail.com> [130205 05:55]:
> >>
> >> Maybe it didn't cover your case. It seems that there's only one bit
> >> for bias in your case.
> >> You can control MMC BIAS enable or disable. And there's neither pullup
> >> nor pulldown.
> >> Is it right?
> >
> > Yes for this register there are no pulls. But I there are others that
> > have pull bits.
> >
> >>      So I will need both config BIAS_ENABLE & config BIAS_DISABLE.
> >> Driver switches between BIAS_ENABLE & BIAS_DISABLE.
> >
> > I'd like to avoid mapping both enable and disable for everything
> > which seems bloated..
> >
> 
> pinctrl-coh901 driver already uses PIN_CONFIG_BIAS_DISABLE without argument.
> 
> I think that it's better to use both BIAS_ENABLE & BIAS_DISABLE. Otherwise,
> I need to update pinctrl-coh901 driver with updating the interface.
> The work is a little
> large.

Well how about just let's keep the existing PIN_CONFIG_BIAS_DISABLE
and PIN_CONFIG_BIAS_ENABLE for compability, but let's still standardize
on PIN_CONFIG_XXX_ENABLE for all the new ones to avoid bloat?

> Maybe we can use another name, PIN_CONFIG_BIAS_AUTOPULL. Then we can
> distinguish it from PULL_UP & PULL_DOWN without any confusion. What's your
> opinion?

Sounds OK to me if you need that.

Regards,

Tony
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 2c81e45..eeb2e93 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -1,7 +1,9 @@ 
 One-register-per-pin type device tree based pinctrl driver
 
 Required properties:
-- compatible : "pinctrl-single"
+- compatible : "pinctrl-single" or "pinconf-single".
+  "pinctrl-single" means that pinconf isn't supported.
+  "pinconf-single" means that generic pinconf is supported.
 
 - reg : offset and length of the register set for the mux registers
 
@@ -14,9 +16,61 @@  Optional properties:
 - pinctrl-single,function-off : function off mode for disabled state if
   available and same for all registers; if not specified, disabling of
   pin functions is ignored
+
 - pinctrl-single,bit-per-mux : boolean to indicate that one register controls
   more than one pin
 
+- pinctrl-single,drive-strength : array of value that are used to configure
+  drive strength in the pinmux register. They're value of drive strength
+  current and drive strength mask.
+
+		/* drive strength current, mask */
+		pinctrl-single,power-source = <0x30 0xf0>;
+
+- pinctrl-single,bias-disable : array of value that are used to configure the
+  input bias disabled in the pinmux register. They're value of bias value,
+  match bias disabled value and bias disabled mask.
+
+		/* bias value, match bias disabled value, mask */
+		pinctrl-single,bias-disable = <2 0 3>;
+
+- pinctrl-single,bias-pullup : array of value that are used to configure the
+  input bias pullup in the pinmux register. They're value of bias value,
+  match bias pullup value and bias pullup mask.
+
+		/* bias value, match bias pullup value, mask */
+		pinctrl-single,bias-pullup = <0 1 1>;
+
+- pinctrl-single,bias-pulldown : array of value that are used to configure the
+  input bias pulldown in the pinmux register. They're value of bias value,
+  match bias pulldown value and bias pulldown mask.
+
+		/* bias value, match bias pulldown value, mask */
+		pinctrl-single,bias-pulldown = <2 2 2>;
+
+- pinctrl-single,input-schmitt : array of value that are used to configure
+  input schmitt in the pinmux register. In some silicons, there're two input
+  schmitt value (rising-edge & falling-edge) in the pinmux register.
+
+		/* input schmitt value, mask */
+		pinctrl-single,input-schmitt = <0x30 0x70>;
+
+- pinctrl-single,input-schmitt-disable : array of value that are used to
+  configure input schmitt disabled in the pinmux register. They're value of
+  input schmitt field, match disable value & mask.
+
+		/* input schmitt value, match disable value, mask */
+		pinctrl-single,input-schmitt-disable = <0x30 0x40 0x70>;
+
+- pinctrl-single,gpio-range : list of value that are used to configure a GPIO
+  range. They're value of subnode phandle, pin base in pinctrl device, pin
+  number in this range, GPIO function value of this GPIO range.
+  The number of parameters is depend on #pinctrl-single,gpio-range-cells
+  property.
+
+		/* pin base, nr pins & gpio function */
+		pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
+
 This driver assumes that there is only one register for each pin (unless the
 pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
 specified in the pinctrl-bindings.txt document in this directory.
@@ -42,6 +96,20 @@  Where 0xdc is the offset from the pinctrl register base address for the
 device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
 be used when applying this change to the register.
 
+
+Optional sub-node: In case some pins could be configured as GPIO in the pinmux
+register, those pins could be defined as a GPIO range. This sub-node is required
+by pinctrl-single,gpio-range property.
+
+Required properties in sub-node:
+- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in
+  pinctrl-single,gpio-range property.
+
+	range: gpio-range {
+		#pinctrl-single,gpio-range-cells = <3>;
+	};
+
+
 Example:
 
 /* SoC common file */
@@ -76,6 +144,29 @@  control_devconf0: pinmux@48002274 {
 	pinctrl-single,function-mask = <0x5F>;
 };
 
+/* third controller instance for pins in gpio domain */
+pmx_gpio: pinmux@d401e000 {
+	compatible = "pinconf-single";
+	reg = <0xd401e000 0x0330>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges;
+
+	pinctrl-single,register-width = <32>;
+	pinctrl-single,function-mask = <7>;
+
+	/* sparse GPIO range could be supported */
+	pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
+				&range 12 1 0 &range 13 29 1
+				&range 43 1 0 &range 44 49 1
+				&range 94 1 1 &range 96 2 1>;
+
+	range: gpio-range {
+		#pinctrl-single,gpio-range-cells = <3>;
+	};
+};
+
+
 /* board specific .dts file */
 
 &pmx_core {
@@ -96,6 +187,16 @@  control_devconf0: pinmux@48002274 {
 		>;
 	};
 
+	uart0_pins: pinmux_uart0_pins {
+		pinctrl-single,pins = <
+			0x208 0		/* UART0_RXD (IOCFG138) */
+			0x20c 0		/* UART0_TXD (IOCFG139) */
+		>;
+		pinctrl-single,bias-pulldown = <0 2 2>;
+		pinctrl-single,bias-pullup = <0 1 1>;
+		pinctrl-single,bias-disable = <0 0 3>;
+	};
+
 	/* map uart2 pins */
 	uart2_pins: pinmux_uart2_pins {
 		pinctrl-single,pins = <
@@ -122,6 +223,11 @@  control_devconf0: pinmux@48002274 {
 
 };
 
+&uart1 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&uart0_pins>;
+};
+
 &uart2 {
        pinctrl-names = "default";
        pinctrl-0 = <&uart2_pins>;