From: Conor Dooley <conor.dooley@microchip.com>
The pic64gx has a second pinmux "downstream" of the iomux0 pinmux. The
documentation for the SoC provides no name for this device, but it is
used to swap pins between either GPIO controller #2 or select other
functions, hence the "gpio2" name. Currently there is no documentation
about what each bit actually does that is publicly available, nor (I
believe) what pins are affected. That info is as follows:
pin role (1/0)
--- ----------
E14 MAC_0_MDC/GPIO_2_0
E15 MAC_0_MDIO/GPIO_2_1
F16 MAC_1_MDC/GPIO_2_2
F17 MAC_1_MDIO/GPIO_2_3
D19 SPI_0_CLK/GPIO_2_4
B18 SPI_0_SS0/GPIO_2_5
B10 CAN_0_RXBUS/GPIO_2_6
C14 PCIE_PERST_2#/GPIO_2_7
E18 PCIE_WAKE#/GPIO_2_8
D18 PCIE_PERST_1#/GPIO_2_9
E19 SPI_0_DO/GPIO_2_10
C7 SPI_0_DI/GPIO_2_11
D6 QSPI_SS0/GPIO_2_12
D7 QSPI_CLK (B)/GPIO_2_13
C9 QSPI_DATA0/GPIO_2_14
C10 QSPI_DATA1/GPIO_2_15
A5 QSPI_DATA2/GPIO_2_16
A6 QSPI_DATA3/GPIO_2_17
D8 MMUART_3_RXD/GPIO_2_18
D9 MMUART_3_TXD/GPIO_2_19
B8 MMUART_4_RXD/GPIO_2_20
A8 MMUART_4_TXD/GPIO_2_21
C12 CAN_1_TXBUS/GPIO_2_22
B12 CAN_1_RXBUS/GPIO_2_23
A11 CAN_0_TX_EBL_N/GPIO_2_24
A10 CAN_1_TX_EBL_N/GPIO_2_25
D11 MMUART_2_RXD/GPIO_2_26
C11 MMUART_2_TXD/GPIO_2_27
B9 CAN_0_TXBUS/GPIO_2_28
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
.../microchip,pic64gx-pinctrl-gpio2.yaml | 74 +++++++++++++++++++
1 file changed, 74 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml
new file mode 100644
index 000000000000..be7d4b1948dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC64GX GPIO2 Mux
+
+maintainers:
+ - Conor Dooley <conor.dooley@microchip.com>
+
+description:
+ The "GPIO2 Mux" determines whether GPIO2 or select other functions are
+ available on package pins on PIC64GX. Some of these functions must be
+ mapped to this mux
+
+properties:
+ compatible:
+ const: microchip,pic64gx-pinctrl-gpio2
+
+ reg:
+ maxItems: 1
+
+ pinctrl-use-default: true
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ allOf:
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ pinmux:
+ description: |
+ The list of GPIOs and their mux settings that properties in the
+ node apply to. The upper 16 bits of the value represent the pin
+ and the lower 16 bits determine which function is routed there.
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #define PIC64GX_PINFUNC(pin, func) (((pin) << 16) | (func))
+
+ soc {
+ pinctrl@f00 {
+ compatible = "microchip,pic64gx-pinctrl-gpio2";
+ reg = <0xf00 0x4>;
+ pinctrl-use-default;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio0_gpio2>, <&mdio1_gpio2>, <&spi0_gpio2>, <&qspi_gpio2>,
+ <&mmuart3_gpio2>, <&mmuart4_gpio2>, <&can1_gpio2>, <&can0_gpio2>,
+ <&mmuart2_gpio2>;
+
+ mdio0_gpio: gpio0-gpio-pins {
+ pinmux = <PIC64GX_PINFUNC(0, 0)>, <PIC64GX_PINFUNC(1, 0)>;
+ };
+
+ mdio0_mdio: mdio0-mdio-pins {
+ pinmux = <PIC64GX_PINFUNC(0, 1)>, <PIC64GX_PINFUNC(1, 1)>;
+ };
+ };
+ };
+
+...
--
2.47.3On Fri, Sep 26, 2025 at 4:33 PM Conor Dooley <conor@kernel.org> wrote: > pin role (1/0) > --- ---------- > E14 MAC_0_MDC/GPIO_2_0 > E15 MAC_0_MDIO/GPIO_2_1 > F16 MAC_1_MDC/GPIO_2_2 > F17 MAC_1_MDIO/GPIO_2_3 So this is a group you can name "mac_grp" and a function you can name "mac". > D19 SPI_0_CLK/GPIO_2_4 > B18 SPI_0_SS0/GPIO_2_5 (...) > E19 SPI_0_DO/GPIO_2_10 > C7 SPI_0_DI/GPIO_2_11 These pins would be "spi0_grp", function "spi0". etc. No need for "pinmux" properties just use classix group and function strings. Yours, Linus Walleij
On Wed, Oct 01, 2025 at 01:32:37PM +0200, Linus Walleij wrote: > On Fri, Sep 26, 2025 at 4:33 PM Conor Dooley <conor@kernel.org> wrote: > > > pin role (1/0) > > --- ---------- > > E14 MAC_0_MDC/GPIO_2_0 > > E15 MAC_0_MDIO/GPIO_2_1 > > F16 MAC_1_MDC/GPIO_2_2 > > F17 MAC_1_MDIO/GPIO_2_3 > > So this is a group you can name "mac_grp" and a function > you can name "mac". > > > D19 SPI_0_CLK/GPIO_2_4 > > B18 SPI_0_SS0/GPIO_2_5 > (...) > > E19 SPI_0_DO/GPIO_2_10 > > C7 SPI_0_DI/GPIO_2_11 > > These pins would be "spi0_grp", function "spi0". > > etc. No need for "pinmux" properties just use classix > group and function strings. tbh, I found it hard to understand the "line" between using a pinmux property and where stuff should be described in groups or functions in a driver. What is that line?
On Wed, Oct 1, 2025 at 5:47 PM Conor Dooley <conor@kernel.org> wrote: > tbh, I found it hard to understand the "line" between using a pinmux > property and where stuff should be described in groups or functions in a > driver. What is that line? There is no such line, basically what I like as pin control maintainer is what exists in the documentation with groups and functions. Then various driver maintainers have pushed me around since day 1 because they think it is much more convenient to just have some single value to poke into a register. I have come to accept both because the discussions just go on forever. I'm not a very stern person, "those are my principles, if you don't like them, I have others". Essentially it is a question about what the device tree is for: is it just for (outline) description and configuration of hardware for a specific system, i.e. where everything that is not system-specific should be encoded into the driver, or is it for dumping all kind of various SoC-specific stuff into, without abstraction. There is no clear line there either, and that is part of the problem here. Yours, Linus Walleij
On Mon, Oct 13, 2025 at 12:56:42PM +0200, Linus Walleij wrote: > On Wed, Oct 1, 2025 at 5:47 PM Conor Dooley <conor@kernel.org> wrote: > > > tbh, I found it hard to understand the "line" between using a pinmux > > property and where stuff should be described in groups or functions in a > > driver. What is that line? > > There is no such line, basically what I like as pin control maintainer > is what exists in the documentation with groups and functions. > > Then various driver maintainers have pushed me around since > day 1 because they think it is much more convenient to just > have some single value to poke into a register. > > I have come to accept both because the discussions just > go on forever. I'm not a very stern person, "those are my > principles, if you don't like them, I have others". Right, I see. Currently I have 3 drivers, two being what are here. Both of those I have converted to use functions and groups. The third retains the pinmux property, mostly because of the number of functions that each pin can be routed due to being an FPGA. I'll send the first two in the coming day or two and see what to do about the third. It's got much more going on and no internal pressure to get it working, unlike these the first two that folks have expressed a need for. > Essentially it is a question about what the device tree is for: > is it just for (outline) description and configuration of hardware > for a specific system, i.e. where everything that is not > system-specific should be encoded into the driver, or is it > for dumping all kind of various SoC-specific stuff into, without > abstraction. There is no clear line there either, and that is > part of the problem here. Now that I have some understanding about how this stuff works, I can start whinging about people using these pinmux properties if you want. I'm probably biased by my own laziness and not wanting to write out dozens and dozens of groups etc, but in cases where there's only two or three functions per pin, using functions/groups seems like the way to go..
On Wed, Oct 01, 2025 at 04:47:12PM +0100, Conor Dooley wrote: > On Wed, Oct 01, 2025 at 01:32:37PM +0200, Linus Walleij wrote: > > On Fri, Sep 26, 2025 at 4:33 PM Conor Dooley <conor@kernel.org> wrote: > > > > > pin role (1/0) > > > --- ---------- > > > E14 MAC_0_MDC/GPIO_2_0 > > > E15 MAC_0_MDIO/GPIO_2_1 > > > F16 MAC_1_MDC/GPIO_2_2 > > > F17 MAC_1_MDIO/GPIO_2_3 > > > > So this is a group you can name "mac_grp" and a function > > you can name "mac". > > > > > D19 SPI_0_CLK/GPIO_2_4 > > > B18 SPI_0_SS0/GPIO_2_5 > > (...) > > > E19 SPI_0_DO/GPIO_2_10 > > > C7 SPI_0_DI/GPIO_2_11 > > > > These pins would be "spi0_grp", function "spi0". > > > > etc. No need for "pinmux" properties just use classix > > group and function strings. > > tbh, I found it hard to understand the "line" between using a pinmux > property and where stuff should be described in groups or functions in a > driver. What is that line? You may have noticed that I never really review pinctrl bindings, and it is the lack of experience with this kind of decision that's why I never do it.
© 2016 - 2025 Red Hat, Inc.