Message-ID: <20250926-manpower-glacial-e9756c82b427@spud>
Date: Fri, 26 Sep 2025 15:33:08 +0100
From: Conor Dooley <conor@...nel.org>
To: linus.walleij@...aro.org
Cc: conor@...nel.org,
	Conor Dooley <conor.dooley@...rochip.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: [RFC 0/5] microchip mpfs/pic64gx pinctrl questions

From: Conor Dooley <conor.dooley@...rochip.com>

Hey Linus, or whoever else,

Working on some pinctrl drivers for my devices, and I had two questions,
so I am sending this as an RFC in the hopes of getting an answer before
progressing further with the third pin controller on the platform.

Firstly, both of the drivers I have produced so far have only pinmuxing
functions and no pincfg role - they only determine internal routing in
the SoC. I've got an identical dt_node_to_map implementation in both
drivers, as all they are doing is populating the pin and mux bit setting
from dt. I used what the recently added spacemit k1 was doing as a
guide, but removed the loop since there's no pincfg stuff that can
differ between pins. I notice there are generic implementations of
dt_node_to_map but I didn't get them to work. Have I missed a trick here
(either on the dt side, or in the driver) that would let me use a generic
function instead of having my own implementation, either in the driver
or in how I've set up the dt side?
I got to this point by partially writing the third driver first, based
on that spacemit k1 driver's approach, so I might've blinded myself to
the correct/simple approach to things as a result of having to handle
the pincfg stuff etc in dt_node_to_map there.

Secondly, particularly if there's not some neat way to simplify things
in dt_node_to_map, should I merge the two drivers, at least partially?
They're effectively only different in their pinctrl_pin_desc and how the
regmap is generated in probe (from a syscon regmap versus
regmap_init_mmio). I've kept the bindings apart, as despite similarity,
they're really only similar due to simplicity.

None of this is in any sort of final state, it's either WIP in and off
itself or depends on other stuff that's not yet accepted, so please
excuse any build warnings etc.

Cheers,
Conor.

CC: Linus Walleij <linus.walleij@...aro.org>
CC: Rob Herring <robh@...nel.org>
CC: Krzysztof Kozlowski <krzk+dt@...nel.org>
CC: linux-kernel@...r.kernel.org
CC: linux-gpio@...r.kernel.org
CC: devicetree@...r.kernel.org

Conor Dooley (5):
  dt-bindings: pinctrl: add polarfire soc iomux0 pinmux
  dt-bindings: pinctrl: add pic64gx "gpio2" pinmux
  pinctrl: add polarfire soc iomux0 pinmux driver
  pinctrl: add pic64gx "gpio2" pinmux driver
  riscv: dts: microchip: add pinctrl nodes for iomux0

 .../microchip,mpfs-pinctrl-iomux0.yaml        |  77 +++++
 .../microchip,pic64gx-pinctrl-gpio2.yaml      |  74 +++++
 .../microchip,mpfs-mss-top-sysreg.yaml        |  17 +-
 .../dts/microchip/mpfs-icicle-kit-fabric.dtsi |  56 ++++
 .../boot/dts/microchip/mpfs-icicle-kit.dts    |   1 -
 .../boot/dts/microchip/mpfs-pinctrl.dtsi      | 117 ++++++++
 arch/riscv/boot/dts/microchip/mpfs.dtsi       |   9 +
 drivers/pinctrl/Kconfig                       |  14 +
 drivers/pinctrl/Makefile                      |   2 +
 drivers/pinctrl/pinctrl-mpfs-iomux0.c         | 252 ++++++++++++++++
 drivers/pinctrl/pinctrl-pic64gx-gpio2.c       | 283 ++++++++++++++++++
 11 files changed, 900 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/microchip,mpfs-pinctrl-iomux0.yaml
 create mode 100644 Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml
 create mode 100644 arch/riscv/boot/dts/microchip/mpfs-pinctrl.dtsi
 create mode 100644 drivers/pinctrl/pinctrl-mpfs-iomux0.c
 create mode 100644 drivers/pinctrl/pinctrl-pic64gx-gpio2.c

-- 
2.47.3

Powered by blists - more mailing lists