[v5,0/4] Basic pinctrl support for StarFive JH7110 RISC-V SoC

  This patch series adds basic pinctrl support for StarFive JH7110 SoC.

Changes since v4:
Patch 1 & 2:
- Added pinmux-node.yaml reference for '-pins$' patternProperties.
- Dropped reference for pinmux properties.

  v4: https://lore.kernel.org/all/20230203141801.59083-1-hal.feng@starfivetech.com/

Changes since v3:
- Rebased on Linus's "devel" branch of linux-pinctrl repo, which was based on
  on tag v6.2-rc1.
- Dropped patch 1.
Patch 2 & 3:
- Added a reference for '-pins$' patternProperties.
- Put "additionalProperties: false" before properties section. (by Rob)
- Improved the description.
- Changed the node name in examples from "gpio" to "pinctrl".
Patch 4:
- Added some missing headers. (by Andreas)

  v3: https://lore.kernel.org/all/20221220005529.34744-1-hal.feng@starfivetech.com/

Changes since v2:
- Rebased on tag v6.1.
Patch 1:
- Renamed pinctrl-starfive-jh7110.h to
  starfive,jh7110-pinctrl.h. (by Krzysztof)
- Separated the register values in the binding header and stored them in
  a new file arch/riscv/boot/dts/starfive/jh7110-pinfunc.h. (by Krzysztof)
- Split patch 1 into sys part and aon part. Merged them into patch 2
  and patch 3 respectively.
Patch 2 & 3:
- Dropped "reg-names" and the description of "interrupts". Dropped quotes
  behind "$ref" and kept consisitent quotes. (by Krzysztof)
- Moved gpio properties behind interrupt properties.
- Moved "required" behind "patternProperties". (by Krzysztof)
- Rewrote the examples of bindings. (by Krzysztof and Emil)
- Added Co-developed-by tag for Emil.
- Dropped unused "clocks" property in patch 3.
Patch 4 & 5:
- Renamed "pinctrl-starfive.*" to "pinctrl-starfive-jh7110.*" and replaced
  all "starfive_" prefix with "jh7110_" in these files. (by Emil)
- Dropped macro GPIO_NUM_PER_WORD. (by Emil)
- Dropped unused flag member in starfive_pinctrl_soc_info structure. (by Emil)
- Renamed "pinctrl-jh7110-sys.c" to "pinctrl-starfive-jh7110-sys.c".
  Renamed "pinctrl-jh7110-aon.c" to "pinctrl-starfive-jh7110-aon.c". (by Emil)
- Added individual Kconfig options for sys and aon pinctrl drivers. (by Emil)
- Made the sys and aon pinctrl drivers be modules. (by Emil)
- Added "JH7110_" prefix for macro SYS_GPO_PDA_0_74_CFG,
  SYS_GPO_PDA_89_94_CFG and AON_GPO_PDA_0_5_CFG. (by Emil)
- Dropped jh7110_sys_pinctrl_probe() and jh7110_aon_pinctrl_probe().
  Got the match data in the common jh7110_pinctrl_probe() and used it
  to probe. (by Emil)
- Dropped the of_match_ptr macro(). (by Emil)
- Set the MODULE_LICENSE as "GPL" according to commit bf7fbeeae6db.

  v2: https://lore.kernel.org/all/20221118011108.70715-1-hal.feng@starfivetech.com/

Changes since v1:
- Rebased on tag v6.1-rc5.
- Dropped patch 22 and 23 since they were merged in v6.1-rc1.
- Removed some unused macros and register values which do not belong to
  bindings. Simplified pinctrl definitions in patch 24. (by Krzysztof)
- Split the bindings into sys pinctrl bindings and aon pinctrl bindings,
  and split patch 25 into two patches.
- Made the bindings follow generic pinctrl bindings. (by Krzysztof)
- Fixed some wrong indentation in bindings, and checked it with
  `make dt_binding_check`.
- Split the patch 26 into two patches which added sys and aon pinctrl
  driver respectively.
- Restructured the pinctrl drivers so made them follow generic pinctrl
  bindings. Rewrote `dt_node_to_map` and extracted the public code to make
  it clearer.

  v1: https://lore.kernel.org/all/20220929143225.17907-1-hal.feng@linux.starfivetech.com/

Jianlong Huang (4):
  dt-bindings: pinctrl: Add StarFive JH7110 sys pinctrl
  dt-bindings: pinctrl: Add StarFive JH7110 aon pinctrl
  pinctrl: starfive: Add StarFive JH7110 sys controller driver
  pinctrl: starfive: Add StarFive JH7110 aon controller driver

 .../pinctrl/starfive,jh7110-aon-pinctrl.yaml  | 124 +++
 .../pinctrl/starfive,jh7110-sys-pinctrl.yaml  | 142 +++
 MAINTAINERS                                   |   8 +-
 drivers/pinctrl/starfive/Kconfig              |  33 +
 drivers/pinctrl/starfive/Makefile             |   4 +
 .../starfive/pinctrl-starfive-jh7110-aon.c    | 177 ++++
 .../starfive/pinctrl-starfive-jh7110-sys.c    | 449 ++++++++
 .../starfive/pinctrl-starfive-jh7110.c        | 982 ++++++++++++++++++
 .../starfive/pinctrl-starfive-jh7110.h        |  70 ++
 .../pinctrl/starfive,jh7110-pinctrl.h         | 137 +++
 10 files changed, 2123 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh7110-aon-pinctrl.yaml
 create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh7110-sys-pinctrl.yaml
 create mode 100644 drivers/pinctrl/starfive/pinctrl-starfive-jh7110-aon.c
 create mode 100644 drivers/pinctrl/starfive/pinctrl-starfive-jh7110-sys.c
 create mode 100644 drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c
 create mode 100644 drivers/pinctrl/starfive/pinctrl-starfive-jh7110.h
 create mode 100644 include/dt-bindings/pinctrl/starfive,jh7110-pinctrl.h
  

On Thu, Feb 9, 2023 at 3:37 PM Hal Feng <hal.feng@starfivetech.com> wrote:

> This patch series adds basic pinctrl support for StarFive JH7110 SoC.

This v4 version applied, the driver is in good shape and all bindings ACKed,
nice work on this driver!

Yours,
Linus Walleij
  

On Fri, 10 Feb 2023 23:45:05 +0100, Linus Walleij wrote:
> On Thu, Feb 9, 2023 at 3:37 PM Hal Feng <hal.feng@starfivetech.com> wrote:
> 
> > This patch series adds basic pinctrl support for StarFive JH7110 SoC.
> 
> This v4 version applied, the driver is in good shape and all bindings ACKed,
> nice work on this driver!

v4? Is this a typo? This series is v5.
Anyway, thank you so much!

Best regards,
Hal
  

On Sat, 11 Feb 2023 at 09:25, Hal Feng <hal.feng@starfivetech.com> wrote:
> On Fri, 10 Feb 2023 23:45:05 +0100, Linus Walleij wrote:
> > On Thu, Feb 9, 2023 at 3:37 PM Hal Feng <hal.feng@starfivetech.com> wrote:
> >
> > > This patch series adds basic pinctrl support for StarFive JH7110 SoC.
> >
> > This v4 version applied, the driver is in good shape and all bindings ACKed,
> > nice work on this driver!
>
> v4? Is this a typo? This series is v5.
> Anyway, thank you so much!

Hi Hal and Linus

I'm curious if there is a plan to address Icenowy's concerns here:
https://lore.kernel.org/linux-gpio/52dcbe48dbf5f2561713a9642943353216fef15a.camel@icenowy.me/

The problem is that input from "GPIO" pins is configured a little
differently on the StarFive SoCs. Instead of having a register pr.
pin(grroup) there is a register pr. control line to the peripherals,
and into these you write the pin number + 2 of the pin you want the
peripheral to react to. Why +2? That's because 0 is a special "always
low" signal and similarly 1 is a special "always high" signal.

With the current bindings one hacky way to solve this is to treat
those two special values as kind of "virtual pins" that will always be
high or low. So that would be something like

pinmux = <GPIOMUX(GPIO_ALWAYS_LOW, GPOUT_IGNORED, GPOEN_DISABLE,
GPI_SYS_USB_OVERCURRENT)>;

..but this means we might need to mux these two virtual pins to
multiple peripherals. I'm not sure the pinmux framework is prepared
for that.

/Emil

> Best regards,
> Hal
  

On Mon, Feb 20, 2023 at 11:16 AM Emil Renner Berthing
<emil.renner.berthing@canonical.com> wrote:

> Hi Hal and Linus
>
> I'm curious if there is a plan to address Icenowy's concerns here:
> https://lore.kernel.org/linux-gpio/52dcbe48dbf5f2561713a9642943353216fef15a.camel@icenowy.me/
>
> The problem is that input from "GPIO" pins is configured a little
> differently on the StarFive SoCs. Instead of having a register pr.
> pin(grroup) there is a register pr. control line to the peripherals,
> and into these you write the pin number + 2 of the pin you want the
> peripheral to react to. Why +2? That's because 0 is a special "always
> low" signal and similarly 1 is a special "always high" signal.
>
> With the current bindings one hacky way to solve this is to treat
> those two special values as kind of "virtual pins" that will always be
> high or low. So that would be something like
>
> pinmux = <GPIOMUX(GPIO_ALWAYS_LOW, GPOUT_IGNORED, GPOEN_DISABLE,
> GPI_SYS_USB_OVERCURRENT)>;
>
> ..but this means we might need to mux these two virtual pins to
> multiple peripherals. I'm not sure the pinmux framework is prepared
> for that.

I am not a fan of the magic numbers approach to pin muxing at all and I
often point out that I prefer that you use strings and connect groups with
functions using strings.

The above mentioned problems is one of the reasons.

As maintainer I have been repeatedly hammered down by maintainers
who think magic numbers is good for them, usually because it saves
space in the DTS file and is easier to code a driver for. So this alternative
approach is acceptable, as a compromise.

My apologies if I didn't point this out as sternly as I often do for
StarFive. Really sorry. I guess I have just started to give up on insisting,
as so many people like their magic numbers.

If you switch to stop using the "pinmux" property and instead use
string arrays function and groups as defined in
Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
this should fix it, the old pinmux device trees can be supported
as fallback, if pinmux is present but function and groups are
missing.

So that is my suggestion.

Usually people don't like this suggestion, so I suspect you might
not like it either and come up with something else to work around
it.

Yours,
Linus Walleij