| Message ID | 1359825953-15663-13-git-send-email-haojian.zhuang@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* 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
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.
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
* 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
* 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
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
* 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 --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>;