Message-ID: <20240723-supervise-drown-d5d3b303e7fd@wendy>
Date: Tue, 23 Jul 2024 12:27:09 +0100
From: Conor Dooley <conor.dooley@...rochip.com>
To: <linux-kernel@...r.kernel.org>
CC: <conor@...nel.org>, <conor.dooley@...rochip.com>, Marc Zyngier
	<maz@...nel.org>, Daire McNamara <daire.mcnamara@...rochip.com>, "Linus
 Walleij" <linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>,
	"Rob Herring" <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>, Paul Walmsley
	<paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
	<linux-riscv@...ts.infradead.org>, <linux-gpio@...r.kernel.org>,
	<devicetree@...r.kernel.org>
Subject: [RFC v7 0/6] PolarFire SoC GPIO support

Hey all,

Lewis is no longer at Microchip, so I've taken over the GPIO controller
patchset that he had been working on prior to that:
https://lore.kernel.org/linux-gpio/20220815120834.1562544-1-lewis.hanly@microchip.com/

However, you'll note that I've got more than a GPIO controller patch in
this series now. One thing that was wrong with Lewis' series was that it
could only, depending on the iteration of the series, support GPIOs that
had their interrupts muxed or GPIOs that had dedicated interrupts at the
parent interrupt controller. I found that to be problematic, because the
hardware itself always has a mix of muxed and dedicated interrupts and
so there was always a controller rendered unusable for interrupts.

I've attempted to fix this by remodelling how the interrupt hierarchy in
the devicetree is described, with a mux added between the GPIO
controllers and the platform's interrupt controller. This is a better
match for the hardware, or more accurately *is* a match, and avoids the
issues I pointed out here:
https://lore.kernel.org/linux-gpio/23a69be6-96d3-1c28-f1aa-555e38ff991e@microchip.com/

Stealing from the irqchip driver patch, here's some more information on
the interrupt configuration on this SoC, for the 3 GPIO controllers:
- GPIO controller 0 has 14 GPIOs
- GPIO controller 1 has 24 GPIOs
- GPIO controller 2 has 32 GPIOs

All GPIOs are capable of generating interrupts, for a total of 70.
There are only 41 interrupts available however, so a configurable mux is
used to ensure all GPIOs can be used for interrupt generation. 38 of the
41 interrupts are in what the documentation calls "direct mode", as they
provide an exclusive connection from a GPIO to the PLIC. The 3 remaining
interrupts are used to mux the interrupts which do not have an exclusive
connection, one for each GPIO controller. A register is used to set this
configuration of this mux, depending on how the "MSS Configurator"
(FPGA configuration tool) has set things up. This is done by the
platform's firmware, so access from Linux is read-only.

The mux has a single register, where bits 0 to 13 mux between GPIO
controller 1's 14 GPIOs and GPIO controller 2's first 14 GPIOs. The
remaining bits mux between the first 18 GPIOs of controller 1 and the
last 18 GPIOS of controller 2. If a bit in the mux's control register is
set, the corresponding interrupt line for GPIO controller 0 or 1 will be
put in "non-direct" mode. If cleared, GPIO controller 2's will.

I'm downgrading the series to RFC status, and have not implemented
feedback received on the GPIO controller itself (which was mostly about
using regmap), because I would really like to hear from people on the
interrupt side of things, in case a significant re-write of the driver
is required. I've split the changes I made to the interrupt handling
portions of the GPIO driver into a patch of their own to make that more
obvious. Clearly that would need to be squashed, and any feedback
implemented, before the driver would be acceptable.

I previously enquired, a year ago when I actually wrote the irqchip
driver, about how to implement this mux and tried to follow Marc's
suggestions about how I should ago about doing so:
https://lore.kernel.org/all/87wn11oo5o.wl-maz@kernel.org/

Marc, I know you're no longer maintaining irqchip drivers, but I'd
appreciate if you in particular could take a look and see whether I
implemented your suggestions correctly - in particular the
irq_domain_disconnect_hierarchy() stuff.

My main issue with what I've conjured up here are that the hwirq number
that I get when calling irqd_to_hwirq() in the mask/unmask callbacks
in the gpio driver runs as far as 95, but each GPIO controller only can
have up 32 interrupts, so there are % 32 operations done in those
drivers to make the number a valid GPIO. In my naivety, I had expected
that the hwirqs seen by the irq_chip in the GPIO controller driver would
run from 0 to 31, but instead the hwirq numbers are that of the GPIO
controller irq_chip's parent (so my new mux).

I'm not sure if this sort of knowledge about how the parent works is
acceptable to have in the GPIO controller driver, but more pertinently
it screams "fundamental mistake" to me, and that my implementation of
the alloc irq_domain_ops callback is just broken. Unfortunately, I have
been unable to figure out a way to avoid that, while also (what I think
is) correctly using the irq_domain_disconnect_hierarchy() stuff in
the alloc callback.

So yeah, is doing something along these lines acceptable, or if not,
pointers as to how to resolve the problem would be highly appreciated.

And there's also a nastly looking of_iomap() in the irqchip driver. I
know this is unacceptable, some regions were described entirely
incorrectly in the original devicetree for this SoC, and I'm trying
to work on my problems one by one! Please ignore that for now.

Cheers,
Conor.

CC: Marc Zyngier <maz@...nel.org>
CC: Conor Dooley <conor.dooley@...rochip.com>
CC: Daire McNamara <daire.mcnamara@...rochip.com>
CC: Linus Walleij <linus.walleij@...aro.org>
CC: Bartosz Golaszewski <brgl@...ev.pl>
CC: Rob Herring <robh@...nel.org>
CC: Krzysztof Kozlowski <krzk+dt@...nel.org>
CC: Thomas Gleixner <tglx@...utronix.de>
CC: Paul Walmsley <paul.walmsley@...ive.com>
CC: Palmer Dabbelt <palmer@...belt.com>
CC: linux-riscv@...ts.infradead.org
CC: linux-gpio@...r.kernel.org
CC: devicetree@...r.kernel.org
CC: linux-kernel@...r.kernel.org

Conor Dooley (5):
  dt-bindings: gpio: fix microchip,mpfs-gpio interrupt descriptions
  dt-bindings: interrupt-controller: document PolarFire SoC's gpio
    interrupt mux
  irqchip: add mpfs gpio interrupt mux
  gpio: mpfs: pass gpio line number as irq data
  riscv: dts: microchip: update gpio interrupts to better match the SoC

Lewis Hanly (1):
  gpio: mpfs: add polarfire soc gpio support

 .../bindings/gpio/microchip,mpfs-gpio.yaml    |  28 +-
 .../microchip,mpfs-gpio-irq-mux.yaml          |  79 ++++
 .../boot/dts/microchip/mpfs-icicle-kit.dts    |   8 -
 arch/riscv/boot/dts/microchip/mpfs.dtsi       |  50 ++-
 drivers/gpio/Kconfig                          |   7 +
 drivers/gpio/Makefile                         |   1 +
 drivers/gpio/gpio-mpfs.c                      | 349 ++++++++++++++++++
 drivers/irqchip/Kconfig                       |  11 +
 drivers/irqchip/Makefile                      |   1 +
 drivers/irqchip/irq-mpfs-mux.c                | 333 +++++++++++++++++
 10 files changed, 840 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/microchip,mpfs-gpio-irq-mux.yaml
 create mode 100644 drivers/gpio/gpio-mpfs.c
 create mode 100644 drivers/irqchip/irq-mpfs-mux.c

-- 
2.43.2

Powered by blists - more mailing lists