riscv: smp: support IPI via PLIC

[ycsin]

Is your enhancement proposal related to a problem? Please describe.

The RISC-V's SMP implementation assumed the existence of a CLINT. However, that is not always the case, the MSIP context of a core could be connected to a PLIC, i.e. the Andes AE350 SoC, and IPI has to be routed through the PLIC instead of the CLINT.

Describe the solution you'd like

Support PLIC-based SMP IPI upstream, potentially with the option to not compile the IPI implementation altogether to allow out-of-tree implementation, i.e.:

# pseudo
choice RISCV_SMP_IPI_IMPLEMENTATION
        depends on SMP
        default RISCV_SMP_IPI_CLINT if CLINT
        default RISCV_SMP_IPI_PLIC if PLIC
        default RISCV_SMP_IPI_CUSTOM # RISC-V is weird?

Describe alternatives you've considered

At the very least, we need a way to disable the in-tree CLINT-based SMP IPI implementation, so that PLIC-based SMP IPI can be implemented out-of-tree.

Additional context

In-flight PRs to make the PLIC-based SMP IPI possible:

• To allow non-CLINT SMP IPI - arch: riscv: Add support for custom SOC IPI, per-core init #65824
• To enable a PLIC interrupt on any core - drivers: intc: plic: implement irq affinity configuration #78681
• To generate a software interrupt via PLIC - drivers: intc: plic: implement riscv_plic_irq_set_pending() #78611
• Something to pin a PLIC interrupt to a CPU, possibly via devicetree

[jimmyzhe]

Many thanks for your hard work, these enhancements are really fit for the Andes platform.

In Andes internal project, we use the PLIC for SMP IPI, but the main difference is that we implement IPI using the MBOX driver for AMP platform.
For Andes AMP platform, like the QiLai 4+1 AMP SoC, we implemented the mbox_andes_plic_sw driver to handle these two use cases:

1. SMP IPI in the 4-core cluster
2. Communication with the extra core via MBOX/OpenAMP

Although the mbox_andes_plic_sw is an MBOX driver, it actually uses the same hardware (nceplic100) as the intc_plic .

Now thanks to #78611, I plan to rework mbox_andes_plic_sw to be based on the intc_plic driver. This allows the SMP IPI to use the intc_plic directly, and the MBOX driver is only used for AMP communication.

I haven’t started the implementation, but the Andes MBOX devicetree may be like this

  plic_sw: interrupt-controller@e6400000 {
    compatible = "sifive,plic-1.0.0", "andestech,nceplic100";
    ...
    mbox: mbox-controller@0 {
      compatible = "andestech,mbox-plic";
      #mbox-cells = <1>;
      channel-max = <27>;
      interrupts =  <5 1>, <6 1>,
                    <7 1>, <8 1>,
                    ...
                    <30 1>, <31 1>;
      interrupt-parent = <&plic_sw>;
    };
  };

The mbox node can preallocate PLIC interrupt sources for the mbox channel, and other interrupt sources can be used for SMP IPI. This approach may be compatible with ipi_plic.

I would like to see ipi_clint and ipi_plic in upstream, If the Andes mbox driver conflicts with ipi_plic, it can be adjusted for it.