[PATCH v3 0/7] MIPS P8700 variant of the ACLINT IPI controller

Vladimir Kondratiev posted 7 patches 4 months ago
.../thead,c900-aclint-sswi.yaml               |  64 ++++++++--
arch/riscv/include/asm/irq.h                  |   2 +
arch/riscv/kernel/irq.c                       |  34 ++++++
drivers/irqchip/Kconfig                       |  15 ++-
drivers/irqchip/Makefile                      |   2 +-
...d-c900-aclint-sswi.c => irq-aclint-sswi.c} | 114 ++++++++++++------
drivers/irqchip/irq-riscv-aplic-direct.c      |  16 +--
include/linux/cpuhotplug.h                    |   2 +-
8 files changed, 179 insertions(+), 70 deletions(-)
rename drivers/irqchip/{irq-thead-c900-aclint-sswi.c => irq-aclint-sswi.c} (63%)
[PATCH v3 0/7] MIPS P8700 variant of the ACLINT IPI controller
Posted by Vladimir Kondratiev 4 months ago
RISC-V draft specification for the ACLINT IPI controller describes
an "SSWI" device that allows to send IPI by writing register from the
S-mode (Linux kernel), as opposed to the "MSWI" device that does the
same from the M-mode. Sending IPI through the M-mode requires extra
SBI call, SSWI is much faster.

Support for the SSWI exists for the Thead board, it is almost as by
specification save for reading one custom CSR.

Soon to be released Mobileye SoC based on the MIPS P8700 RISC-V CPU has
variant of the ACLINT SSWI device that follows the spec exactly.

To support P8700, refactor Thead implementation, factoring out
generic code that complies with the draft spec, and provide
Thead and MIPS specific variants.

In addition, MIPS P8700 uses non contiguous hart indexes, and thus
requires "riscv,hart-indexes" property.

Patches 1 and 2 refactor "hart index" support, replacing
APLIC specific implementation with generic helper

Patch 3 adds dt-bindings

Patch 4 refactors Thead-specific SSWI, adding MIPS variant

Patch 5 adds "riscv,hart-indexes" support

Patches 6 and 7 do some minor improvements for the SSWI

Changed from v1:
1. RISC-V spec for the ACLINT is in a draft state, then can't
use "riscv," prefix. Restcucture commits to add MIPS specific
ACLINT-SSWI variant instead.

Changed from v2:
1. fix path prefix as in
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-subject
2. Optimize CONFIG to keep single ACLINT_SSWI supporting all
variants
3. Rename T-HEAD specific CPU hotplug state

Vladimir Kondratiev (7):
  riscv: helper to parse hart index
  irqchip/riscv-aplic: use riscv_get_hart_index()
  dt-bindings: interrupt-controller: add MIPS P8700 aclint-sswi
  irqchip: MIPS P800 variant of aclint-sswi
  irqchip/aslint-sswi: resolve hart index
  irqchip/aclint-sswi: reduce data scope
  irqchip/aclint-sswi: remove extra includes

 .../thead,c900-aclint-sswi.yaml               |  64 ++++++++--
 arch/riscv/include/asm/irq.h                  |   2 +
 arch/riscv/kernel/irq.c                       |  34 ++++++
 drivers/irqchip/Kconfig                       |  15 ++-
 drivers/irqchip/Makefile                      |   2 +-
 ...d-c900-aclint-sswi.c => irq-aclint-sswi.c} | 114 ++++++++++++------
 drivers/irqchip/irq-riscv-aplic-direct.c      |  16 +--
 include/linux/cpuhotplug.h                    |   2 +-
 8 files changed, 179 insertions(+), 70 deletions(-)
 rename drivers/irqchip/{irq-thead-c900-aclint-sswi.c => irq-aclint-sswi.c} (63%)


base-commit: 2c4a1f3fe03edab80db66688360685031802160a
-- 
2.43.0
Re: [PATCH v3 0/7] MIPS P8700 variant of the ACLINT IPI controller
Posted by Thomas Gleixner 3 months, 2 weeks ago
On Thu, Jun 12 2025 at 17:39, Vladimir Kondratiev wrote:
> Patches 1 and 2 refactor "hart index" support, replacing
> APLIC specific implementation with generic helper
>
> Patch 3 adds dt-bindings
>
> Patch 4 refactors Thead-specific SSWI, adding MIPS variant
>
> Patch 5 adds "riscv,hart-indexes" support
>
> Patches 6 and 7 do some minor improvements for the SSWI

It seems I'm the only one who cares about this series aside of Conor
looking at the DT part and of course Vladimir himself.

This whole thing looks reasonable to me and I'm not longer waiting for
those who keep me busy with their own patches and fail to look at stuff
which affects the architecture/drivers they depend on. I don't want to
hear complaints about any fallout of this further down the road.

Oh well.

Thanks,

        tglx