[WIP] arch: riscv: smp: add PLIC-based IPI #81260
Conversation
The currently IPI implementation assumes that CLINT exists in the system, however, that might not be the case as IPI can be implemented with PLIC that supports software-triggering as well, such as the Andes NCEPLIC100. Refactor the CLINT-based IPI implementations into `ipi_clint.c`, and create Kconfig that selects the CLINT implementation when `sifive-clint0` exists and enabled, otherwise default to `RISCV_SMP_IPI_CUSTOM` which allows OOT implementation. This also makes way for the upstreaming of non-clint IPI implementation later. Signed-off-by: Yong Cong Sin <[email protected]>
Add PLIC-based IPI implementation. Signed-off-by: Yong Cong Sin <[email protected]>
ycsin
force-pushed
the
pr/riscv-ipi-plic-alt
branch
from
d8ea9b7 to
998cfd5
Compare
ycsin
requested review from
npitre,
cfriedt,
luchnikov,
fkokosinski and
jimmyzhe
ycsin
added
area: RISCV
There was a problem hiding this comment.
Normally, the device tree should contain stuff that describes the hardware
in a generic way. Here, the fact that FPU and scheduling are assigned IRQ
values in DT is too much software implementation details to live in DT. You
should see the device tree information as something that any operating
system may consume, and another OS implementation could opt to do things
differently,. There are exceptions already, but we should refrain from
adding more of them.
You should consider only listing in the DT all those IRQs that are available
for IPI usage and do the assignment in the source code instead.
|
CI failure is unrelated and fixed by #81367 |
|
DT usage still needs fixing per my earlier comment.
|
Sure, I remember I met some difficulties to generate The FPU part also requires the following PLIC functions that I have yet to work on:
|
|
You may take the simple route and have the device tree simply expose
some IRQ range. Then the C code can just hardcode offsets within that
range.
|
See #81215
See #81256
FPU_SHARINGdepends onriscv_plic_irq_is_pending()&riscv_plic_irq_clear_pending()