arch: riscv: smp: refactor IPI functions and guard with CONFIG_RISCV_SMP_IPI_CLINT

[ycsin]

Currently, the RISC-V SMP IPI implementation is CLINT-based. However, IPI in RISC-V is not necessarily always done through a CLINT, in SoC with PLIC connected to the MSIP (i.e. Andes AE350's PLIC_SW), IPI has to be routed through the PLIC.

This patch refactor the IPI delivery into functions and guard it with CONFIG_RISCV_SMP_IPI_CLINT, so that for SoC that do not have a sifive,clint0 device, and has a different IPI mechanism, they can implement their own z_riscv_ipi_send() & z_riscv_ipi_clear().

Note

This is an alternative for #65824

• probably should add an entry to the release note

[ycsin]

cc @cwshu @kevinwang821020 @jimmyzhe

[npitre]

Rather than adding another abstraction layer, I'd suggest creating ipi_clint.c
and ipi_plic.c then implement arch_sched_directed_ipi() and friends for each
of them. The cpu_pending_ipi[] array exists only because there is no way to
distinguish different IPI causes using CLINT. It might be the case that the
PLIC version doesn't need it.

[ycsin]

The cpu_pending_ipi[] array exists only because there is no way to
distinguish different IPI causes using CLINT. It might be the case that the
PLIC version doesn't need it.

True, but I think it depends on the way the ipi_plic.c is implemented, unless we are using one interrupt line for each of the IPI type per CPU, we will need cpu_pending_ipi[] to multiplex the interrupt (it is also used in arch_spin_relax()).

In any case, there's quite a bit of work to be done before we can get to ipi_plic.c upstream:

• PLIC interrupt affinity - irq: introduce new irq_set_affinity() API - alternate #77828
• Implement irq_set_pending() in PLIC - should be pretty straightforward
• Determine how are we going to allocate the PLIC IRQs for IPI, potentially with the option to switch between:
  • 1 interrupt per core (total num of irqs: 1 x NUM_CPUs) - this allows plic/clint implementation to share basically all the existing code, the only difference is the signalling 'middleware', which will be abstracted by the z_riscv_ipi_send & z_riscv_ipi_clear in this PR, or
  • 1 interrupt per IPI per core (total num of irqs: NUM_IPIs x NUM_CPUs) - this allows dedicated irq handler for each of the IPI without the need to multiplex the IRQ

As an alternative to #65824 (compile out the entirety of clint IPI code), this PR is more like an incremental step for us to implement the ipi_plic upstream in the future, and meanwhile allow SoC without CLINT to implement their own IPI code if they wish

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.