The pincontroller integarted in Loongson 2K0300 is able to configure
function multiplexing for all the pins. It could also configure drive
strength on basis of functions, which means all pins set to the same
function share drive-strength setting. Drive-strength configuration
isn't available for all functions, either.
This binding utilizes two levels of subnodes, where the outer represents
function and the inner represents groups. Drive-strength is allowed in
the outer since it's shared among all groups configured to the function.
Signed-off-by: Yao Zi <ziyao@disroot.org>
---
.../pinctrl/loongson,ls2k0300-pinctrl.yaml | 92 +++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
new file mode 100644
index 000000000000..cbd74cb45342
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/loongson,ls2k0300-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2K0300 SoC Pinctrl Controller
+
+maintainers:
+ - Yao Zi <ziyao@disroot.org>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ const: loongson,ls2k0300-pinctrl
+
+ reg:
+ items:
+ - description: Pin function-multiplexing configuration registers
+ - description: Pin drive-strength configuration registers
+
+ reg-names:
+ items:
+ - const: mux
+ - const: drive
+
+patternProperties:
+ '^func-':
+ type: object
+
+ $ref: pincfg-node.yaml#
+
+ properties:
+ drive-strength:
+ description:
+ Maximum sink or source current as defined in pincfg-node.yaml. Note
+ that drive strength could only be configured on function basis, i.e.,
+ all pins multiplexed to the same function share the same
+ configuration.
+
+ This could only be configured for several functions, including jtag,
+ dvo, uart, gmac, sdio, spi, i2s, timer, usb and emmc.
+ enum: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
+
+ additionalProperties: false
+
+ patternProperties:
+ '-pins$':
+ type: object
+ $ref: pinmux-node.yaml#
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents GPIO pin number and multiplexing
+ setting. Configuration for each pin takes one cell. The pin
+ number locates at the high 24 bits, and the setting locates at
+ the low 8 bits.
+
+ additionalProperties: false
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@1fe00420 {
+ compatible = "loongson,ls2k0300-pinctrl";
+ reg = <0x16000490 0x20>, <0x16000110 0x4>;
+ reg-names = "mux", "drive";
+
+ func-uart {
+ drive-strength = <2>;
+
+ uart0-pins {
+ pinmux = <((40 << 8) | 0x3)>, <((41 << 8) | 0x3)>;
+ };
+
+ uart1_pins: uart1-pins {
+ pinmux = <((42 << 8) | 0x3)>, <((43 << 8) | 0x3)>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 7960e65d7dfc..dd50571b4072 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14414,6 +14414,12 @@ S: Maintained
F: Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
F: drivers/thermal/loongson2_thermal.c
+LOONGSON-2K0300 SOC PINCTRL DRIVER
+M: Yao Zi <ziyao@disroot.org>
+L: linux-gpio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
+
LOONGSON EDAC DRIVER
M: Zhao Qunqin <zhaoqunqin@loongson.cn>
L: linux-edac@vger.kernel.org
--
2.50.1On Mon, Aug 11, 2025 at 6:39 PM Yao Zi <ziyao@disroot.org> wrote:
> The pincontroller integarted in Loongson 2K0300 is able to configure
> function multiplexing for all the pins. It could also configure drive
> strength on basis of functions, which means all pins set to the same
> function share drive-strength setting. Drive-strength configuration
> isn't available for all functions, either.
>
> This binding utilizes two levels of subnodes, where the outer represents
> function and the inner represents groups. Drive-strength is allowed in
> the outer since it's shared among all groups configured to the function.
>
> Signed-off-by: Yao Zi <ziyao@disroot.org>
(...)
> +patternProperties:
> + '^func-':
> + type: object
> +
> + $ref: pincfg-node.yaml#
> +
> + properties:
> + drive-strength:
> + description:
> + Maximum sink or source current as defined in pincfg-node.yaml. Note
> + that drive strength could only be configured on function basis, i.e.,
> + all pins multiplexed to the same function share the same
> + configuration.
> +
> + This could only be configured for several functions, including jtag,
> + dvo, uart, gmac, sdio, spi, i2s, timer, usb and emmc.
> + enum: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
As Rob points out this is really odd, or rather the first time I see
something like this.
It is clear from the driver that these are all set by writing bits
in a 32bit register, with 2 or 3 bits dedicated to each function.
Its a bit weird, like each function has driver totempoles/stages
before the mux instead of after (which is the normal). But
I guess it is engineered like that then!
It now looks like this:
+ func-uart {
+ drive-strength = <2>;
+
+ uart0-pins {
+ pinmux = <((40 << 8) | 0x3)>, <((41 << 8) | 0x3)>;
+ };
I think this is better:
uart0_default: uart0-pins {
function = "uart0";
drive-strength = <2>;
pinmux = <((40 << 8) | 0x3)>, <((41 << 8) | 0x3)>;
};
This is consistent with the bindings if you include both
$ref: pinmux-node.yaml#
$ref: pincfg-node.yaml#
And will configure it all in one go.
Sure you need a lookup for the function strings in the driver
but it's OK.
It's odd to have "function" without "group" but it seems legal
and works fine for your usecase. The normal would be to
skip pinmux, have just pins = <40, 41>; and look up the
function value for each function for a pin from a table that
cross-reference in this case "uart0" to 3. But I
guess you don't wanna do that so pinmux is fine too.
<((40 << 8) | 0x3)>, <((41 << 8) | 0x3)> is a bit odd, maybe
you want to also include an explanatory macro in the bindings.
Yours,
Linus Walleij
On Tue, Oct 14, 2025 at 12:48:31AM +0200, Linus Walleij wrote:
> On Mon, Aug 11, 2025 at 6:39 PM Yao Zi <ziyao@disroot.org> wrote:
>
> > The pincontroller integarted in Loongson 2K0300 is able to configure
> > function multiplexing for all the pins. It could also configure drive
> > strength on basis of functions, which means all pins set to the same
> > function share drive-strength setting. Drive-strength configuration
> > isn't available for all functions, either.
> >
> > This binding utilizes two levels of subnodes, where the outer represents
> > function and the inner represents groups. Drive-strength is allowed in
> > the outer since it's shared among all groups configured to the function.
> >
> > Signed-off-by: Yao Zi <ziyao@disroot.org>
> (...)
> > +patternProperties:
> > + '^func-':
> > + type: object
> > +
> > + $ref: pincfg-node.yaml#
> > +
> > + properties:
> > + drive-strength:
> > + description:
> > + Maximum sink or source current as defined in pincfg-node.yaml. Note
> > + that drive strength could only be configured on function basis, i.e.,
> > + all pins multiplexed to the same function share the same
> > + configuration.
> > +
> > + This could only be configured for several functions, including jtag,
> > + dvo, uart, gmac, sdio, spi, i2s, timer, usb and emmc.
> > + enum: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
>
> As Rob points out this is really odd, or rather the first time I see
> something like this.
>
> It is clear from the driver that these are all set by writing bits
> in a 32bit register, with 2 or 3 bits dedicated to each function.
>
> Its a bit weird, like each function has driver totempoles/stages
> before the mux instead of after (which is the normal). But
> I guess it is engineered like that then!
Yes, it occurs strange to me at the first sight, too.
>
> It now looks like this:
>
> + func-uart {
> + drive-strength = <2>;
> +
> + uart0-pins {
> + pinmux = <((40 << 8) | 0x3)>, <((41 << 8) | 0x3)>;
> + };
>
> I think this is better:
>
> uart0_default: uart0-pins {
> function = "uart0";
> drive-strength = <2>;
> pinmux = <((40 << 8) | 0x3)>, <((41 << 8) | 0x3)>;
> };
>
> This is consistent with the bindings if you include both
> $ref: pinmux-node.yaml#
> $ref: pincfg-node.yaml#
>
> And will configure it all in one go.
To confirm my understanding, would you like to drop the outside node
(which now refers to pincfg-node.yaml) and refer to both
pinmux-node.yaml and pincfg-node.yaml in the single level of subnode?
i.e.
pinctrl {
uart0_defaults: uart0-pins {
function = "uart0";
drive-strength = <2>;
pinmux = <...>;
};
};
> Sure you need a lookup for the function strings in the driver
> but it's OK.
>
> It's odd to have "function" without "group" but it seems legal
> and works fine for your usecase. The normal would be to
> skip pinmux, have just pins = <40, 41>; and look up the
> function value for each function for a pin from a table that
> cross-reference in this case "uart0" to 3. But I
> guess you don't wanna do that so pinmux is fine too.
Thanks, glad to hear it's okay.
> <((40 << 8) | 0x3)>, <((41 << 8) | 0x3)> is a bit odd, maybe
> you want to also include an explanatory macro in the bindings.
Sure, I will add a macro like the one included in the DTS change.
> Yours,
> Linus Walleij
>
Thank you and Rob for the help! Will adapt the suggestions in v2.
Best regards,
Yao Zi
Hi Yao,
On Tue, Oct 14, 2025 at 4:23 AM Yao Zi <ziyao@disroot.org> wrote:
> To confirm my understanding, would you like to drop the outside node
> (which now refers to pincfg-node.yaml) and refer to both
> pinmux-node.yaml and pincfg-node.yaml in the single level of subnode?
> i.e.
>
> pinctrl {
> uart0_defaults: uart0-pins {
> function = "uart0";
> drive-strength = <2>;
> pinmux = <...>;
> };
> };
Yes this looks really good.
As you see it is also very easy for a human to read and understand
this device tree.
If you want you can take it a step further and use just "pins"
instead of "pinmux" and infer the function part of pinmux
from the function listed there such as "uart0" so you only encode
the information once. But it results in a bit of tables inside
your driver.
Thanks,
Linus Walleij
On Mon, Aug 11, 2025 at 04:37:48PM +0000, Yao Zi wrote:
> The pincontroller integarted in Loongson 2K0300 is able to configure
> function multiplexing for all the pins. It could also configure drive
> strength on basis of functions, which means all pins set to the same
> function share drive-strength setting. Drive-strength configuration
> isn't available for all functions, either.
>
> This binding utilizes two levels of subnodes, where the outer represents
> function and the inner represents groups. Drive-strength is allowed in
> the outer since it's shared among all groups configured to the function.
>
> Signed-off-by: Yao Zi <ziyao@disroot.org>
> ---
> .../pinctrl/loongson,ls2k0300-pinctrl.yaml | 92 +++++++++++++++++++
> MAINTAINERS | 6 ++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
> new file mode 100644
> index 000000000000..cbd74cb45342
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
> @@ -0,0 +1,92 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/loongson,ls2k0300-pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Loongson-2K0300 SoC Pinctrl Controller
> +
> +maintainers:
> + - Yao Zi <ziyao@disroot.org>
> +
> +allOf:
> + - $ref: pinctrl.yaml#
> +
> +properties:
> + compatible:
> + const: loongson,ls2k0300-pinctrl
> +
> + reg:
> + items:
> + - description: Pin function-multiplexing configuration registers
> + - description: Pin drive-strength configuration registers
> +
> + reg-names:
> + items:
> + - const: mux
> + - const: drive
> +
> +patternProperties:
> + '^func-':
> + type: object
> +
> + $ref: pincfg-node.yaml#
> +
> + properties:
> + drive-strength:
> + description:
> + Maximum sink or source current as defined in pincfg-node.yaml. Note
> + that drive strength could only be configured on function basis, i.e.,
> + all pins multiplexed to the same function share the same
> + configuration.
> +
> + This could only be configured for several functions, including jtag,
> + dvo, uart, gmac, sdio, spi, i2s, timer, usb and emmc.
> + enum: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
How do you know what pin this drive strength corresponds to without any
other properties? Node names generally aren't important, so you
shouldn't be using that.
> +
> + additionalProperties: false
> +
> + patternProperties:
> + '-pins$':
> + type: object
> + $ref: pinmux-node.yaml#
Generally the pin config and muxing are in 1 node if you can control
both.
> +
> + properties:
> + pinmux:
> + description:
> + Integer array, represents GPIO pin number and multiplexing
> + setting. Configuration for each pin takes one cell. The pin
> + number locates at the high 24 bits, and the setting locates at
> + the low 8 bits.
> +
> + additionalProperties: false
> +
> + required:
> + - pinmux
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + pinctrl@1fe00420 {
> + compatible = "loongson,ls2k0300-pinctrl";
> + reg = <0x16000490 0x20>, <0x16000110 0x4>;
> + reg-names = "mux", "drive";
> +
> + func-uart {
> + drive-strength = <2>;
> +
> + uart0-pins {
> + pinmux = <((40 << 8) | 0x3)>, <((41 << 8) | 0x3)>;
> + };
> +
> + uart1_pins: uart1-pins {
> + pinmux = <((42 << 8) | 0x3)>, <((43 << 8) | 0x3)>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7960e65d7dfc..dd50571b4072 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14414,6 +14414,12 @@ S: Maintained
> F: Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
> F: drivers/thermal/loongson2_thermal.c
>
> +LOONGSON-2K0300 SOC PINCTRL DRIVER
> +M: Yao Zi <ziyao@disroot.org>
> +L: linux-gpio@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
> +
> LOONGSON EDAC DRIVER
> M: Zhao Qunqin <zhaoqunqin@loongson.cn>
> L: linux-edac@vger.kernel.org
> --
> 2.50.1
>
On Mon, Aug 18, 2025 at 12:58:27PM -0500, Rob Herring wrote:
> On Mon, Aug 11, 2025 at 04:37:48PM +0000, Yao Zi wrote:
> > The pincontroller integarted in Loongson 2K0300 is able to configure
> > function multiplexing for all the pins. It could also configure drive
> > strength on basis of functions, which means all pins set to the same
> > function share drive-strength setting. Drive-strength configuration
> > isn't available for all functions, either.
> >
> > This binding utilizes two levels of subnodes, where the outer represents
> > function and the inner represents groups. Drive-strength is allowed in
> > the outer since it's shared among all groups configured to the function.
> >
> > Signed-off-by: Yao Zi <ziyao@disroot.org>
> > ---
> > .../pinctrl/loongson,ls2k0300-pinctrl.yaml | 92 +++++++++++++++++++
> > MAINTAINERS | 6 ++
> > 2 files changed, 98 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
> > new file mode 100644
> > index 000000000000..cbd74cb45342
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
> > @@ -0,0 +1,92 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pinctrl/loongson,ls2k0300-pinctrl.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Loongson-2K0300 SoC Pinctrl Controller
> > +
> > +maintainers:
> > + - Yao Zi <ziyao@disroot.org>
> > +
> > +allOf:
> > + - $ref: pinctrl.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: loongson,ls2k0300-pinctrl
> > +
> > + reg:
> > + items:
> > + - description: Pin function-multiplexing configuration registers
> > + - description: Pin drive-strength configuration registers
> > +
> > + reg-names:
> > + items:
> > + - const: mux
> > + - const: drive
> > +
> > +patternProperties:
> > + '^func-':
> > + type: object
> > +
> > + $ref: pincfg-node.yaml#
> > +
> > + properties:
> > + drive-strength:
> > + description:
> > + Maximum sink or source current as defined in pincfg-node.yaml. Note
> > + that drive strength could only be configured on function basis, i.e.,
> > + all pins multiplexed to the same function share the same
> > + configuration.
> > +
> > + This could only be configured for several functions, including jtag,
> > + dvo, uart, gmac, sdio, spi, i2s, timer, usb and emmc.
> > + enum: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
>
> How do you know what pin this drive strength corresponds to without any
> other properties? Node names generally aren't important, so you
> shouldn't be using that.
Thanks for the hint... yes I'm matching the node name to identify
functions in this revision of driver. Could I introduce a "function"
property to the outer node for identification of the function?
> > +
> > + additionalProperties: false
> > +
> > + patternProperties:
> > + '-pins$':
> > + type: object
> > + $ref: pinmux-node.yaml#
>
> Generally the pin config and muxing are in 1 node if you can control
> both.
On 2K0300, drive-strength could only be configured for each function,
not each pin, i.e. all pins configured to the same function share the
same drive-strength configuration.
Putting the driver-strength property in the outer node describes the
situation: a property in the outer node is function-specific and shared
between all groups (represented by inner nodes) configured to this
function.
Do you think it's better to move pin config (the driver-strength
property) to the inner node in this case? If so, should the new
"function" property for identifying functions reliably be in the inner
node or the outer node? Thanks for your explanation,
Best regards,
Yao Zi
> > +
> > + properties:
> > + pinmux:
> > + description:
> > + Integer array, represents GPIO pin number and multiplexing
> > + setting. Configuration for each pin takes one cell. The pin
> > + number locates at the high 24 bits, and the setting locates at
> > + the low 8 bits.
> > +
> > + additionalProperties: false
> > +
> > + required:
> > + - pinmux
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + pinctrl@1fe00420 {
> > + compatible = "loongson,ls2k0300-pinctrl";
> > + reg = <0x16000490 0x20>, <0x16000110 0x4>;
> > + reg-names = "mux", "drive";
> > +
> > + func-uart {
> > + drive-strength = <2>;
> > +
> > + uart0-pins {
> > + pinmux = <((40 << 8) | 0x3)>, <((41 << 8) | 0x3)>;
> > + };
> > +
> > + uart1_pins: uart1-pins {
> > + pinmux = <((42 << 8) | 0x3)>, <((43 << 8) | 0x3)>;
> > + };
> > + };
> > + };
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 7960e65d7dfc..dd50571b4072 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -14414,6 +14414,12 @@ S: Maintained
> > F: Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
> > F: drivers/thermal/loongson2_thermal.c
> >
> > +LOONGSON-2K0300 SOC PINCTRL DRIVER
> > +M: Yao Zi <ziyao@disroot.org>
> > +L: linux-gpio@vger.kernel.org
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml
> > +
> > LOONGSON EDAC DRIVER
> > M: Zhao Qunqin <zhaoqunqin@loongson.cn>
> > L: linux-edac@vger.kernel.org
> > --
> > 2.50.1
> >
>
On Tue, Aug 19, 2025 at 6:37 AM Yao Zi <ziyao@disroot.org> wrote: > > On Mon, Aug 18, 2025 at 12:58:27PM -0500, Rob Herring wrote: > > On Mon, Aug 11, 2025 at 04:37:48PM +0000, Yao Zi wrote: > > > The pincontroller integarted in Loongson 2K0300 is able to configure > > > function multiplexing for all the pins. It could also configure drive > > > strength on basis of functions, which means all pins set to the same > > > function share drive-strength setting. Drive-strength configuration > > > isn't available for all functions, either. > > > > > > This binding utilizes two levels of subnodes, where the outer represents > > > function and the inner represents groups. Drive-strength is allowed in > > > the outer since it's shared among all groups configured to the function. > > > > > > Signed-off-by: Yao Zi <ziyao@disroot.org> > > > --- > > > .../pinctrl/loongson,ls2k0300-pinctrl.yaml | 92 +++++++++++++++++++ > > > MAINTAINERS | 6 ++ > > > 2 files changed, 98 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml > > > new file mode 100644 > > > index 000000000000..cbd74cb45342 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml > > > @@ -0,0 +1,92 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/pinctrl/loongson,ls2k0300-pinctrl.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Loongson-2K0300 SoC Pinctrl Controller > > > + > > > +maintainers: > > > + - Yao Zi <ziyao@disroot.org> > > > + > > > +allOf: > > > + - $ref: pinctrl.yaml# > > > + > > > +properties: > > > + compatible: > > > + const: loongson,ls2k0300-pinctrl > > > + > > > + reg: > > > + items: > > > + - description: Pin function-multiplexing configuration registers > > > + - description: Pin drive-strength configuration registers > > > + > > > + reg-names: > > > + items: > > > + - const: mux > > > + - const: drive > > > + > > > +patternProperties: > > > + '^func-': > > > + type: object > > > + > > > + $ref: pincfg-node.yaml# > > > + > > > + properties: > > > + drive-strength: > > > + description: > > > + Maximum sink or source current as defined in pincfg-node.yaml. Note > > > + that drive strength could only be configured on function basis, i.e., > > > + all pins multiplexed to the same function share the same > > > + configuration. > > > + > > > + This could only be configured for several functions, including jtag, > > > + dvo, uart, gmac, sdio, spi, i2s, timer, usb and emmc. > > > + enum: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12] > > > > How do you know what pin this drive strength corresponds to without any > > other properties? Node names generally aren't important, so you > > shouldn't be using that. > > Thanks for the hint... yes I'm matching the node name to identify > functions in this revision of driver. Could I introduce a "function" > property to the outer node for identification of the function? Yes, that should be defined somewhere. > > > + > > > + additionalProperties: false > > > + > > > + patternProperties: > > > + '-pins$': > > > + type: object > > > + $ref: pinmux-node.yaml# > > > > Generally the pin config and muxing are in 1 node if you can control > > both. > > On 2K0300, drive-strength could only be configured for each function, > not each pin, i.e. all pins configured to the same function share the > same drive-strength configuration. > > Putting the driver-strength property in the outer node describes the > situation: a property in the outer node is function-specific and shared > between all groups (represented by inner nodes) configured to this > function. > > Do you think it's better to move pin config (the driver-strength > property) to the inner node in this case? If so, should the new > "function" property for identifying functions reliably be in the inner > node or the outer node? Thanks for your explanation, I don't know. I'll defer to Linus on this one who is more familiar with the variations of h/w out there. Rob
On Tue, Aug 19, 2025 at 11:37:20AM +0000, Yao Zi wrote: > On Mon, Aug 18, 2025 at 12:58:27PM -0500, Rob Herring wrote: > > On Mon, Aug 11, 2025 at 04:37:48PM +0000, Yao Zi wrote: > > > The pincontroller integarted in Loongson 2K0300 is able to configure > > > function multiplexing for all the pins. It could also configure drive > > > strength on basis of functions, which means all pins set to the same > > > function share drive-strength setting. Drive-strength configuration > > > isn't available for all functions, either. > > > > > > This binding utilizes two levels of subnodes, where the outer represents > > > function and the inner represents groups. Drive-strength is allowed in > > > the outer since it's shared among all groups configured to the function. > > > > > > Signed-off-by: Yao Zi <ziyao@disroot.org> > > > --- > > > .../pinctrl/loongson,ls2k0300-pinctrl.yaml | 92 +++++++++++++++++++ > > > MAINTAINERS | 6 ++ > > > 2 files changed, 98 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml > > > new file mode 100644 > > > index 000000000000..cbd74cb45342 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k0300-pinctrl.yaml > > > @@ -0,0 +1,92 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/pinctrl/loongson,ls2k0300-pinctrl.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Loongson-2K0300 SoC Pinctrl Controller > > > + > > > +maintainers: > > > + - Yao Zi <ziyao@disroot.org> > > > + > > > +allOf: > > > + - $ref: pinctrl.yaml# > > > + > > > +properties: > > > + compatible: > > > + const: loongson,ls2k0300-pinctrl > > > + > > > + reg: > > > + items: > > > + - description: Pin function-multiplexing configuration registers > > > + - description: Pin drive-strength configuration registers > > > + > > > + reg-names: > > > + items: > > > + - const: mux > > > + - const: drive > > > + > > > +patternProperties: > > > + '^func-': > > > + type: object > > > + > > > + $ref: pincfg-node.yaml# > > > + > > > + properties: > > > + drive-strength: > > > + description: > > > + Maximum sink or source current as defined in pincfg-node.yaml. Note > > > + that drive strength could only be configured on function basis, i.e., > > > + all pins multiplexed to the same function share the same > > > + configuration. > > > + > > > + This could only be configured for several functions, including jtag, > > > + dvo, uart, gmac, sdio, spi, i2s, timer, usb and emmc. > > > + enum: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12] > > > > How do you know what pin this drive strength corresponds to without any > > other properties? Node names generally aren't important, so you > > shouldn't be using that. > > Thanks for the hint... yes I'm matching the node name to identify > functions in this revision of driver. Could I introduce a "function" > property to the outer node for identification of the function? > > > > + > > > + additionalProperties: false > > > + > > > + patternProperties: > > > + '-pins$': > > > + type: object > > > + $ref: pinmux-node.yaml# > > > > Generally the pin config and muxing are in 1 node if you can control > > both. > > On 2K0300, drive-strength could only be configured for each function, > not each pin, i.e. all pins configured to the same function share the > same drive-strength configuration. > > Putting the driver-strength property in the outer node describes the > situation: a property in the outer node is function-specific and shared > between all groups (represented by inner nodes) configured to this > function. > > Do you think it's better to move pin config (the driver-strength > property) to the inner node in this case? If so, should the new > "function" property for identifying functions reliably be in the inner > node or the outer node? Thanks for your explanation, Hi Rob, could you please comment further on my questions? Thanks for your time. > Best regards, > Yao Zi Regards, Yao Zi
© 2016 - 2026 Red Hat, Inc.