Hello all,

This series adds support for the Microchip Inter-Processor Communication
(IPC) mailbox controller, as well as an IPC remoteproc platform driver.

Microchip's family of RISC-V SoCs typically has one or more clusters
that can be configured to run in Asymmetric Multi-Processing (AMP) mode.

The Microchip IPC is used to send messages between processors using
an interrupt signaling mechanism. The driver uses the RISC-V Supervisor
Binary Interface (SBI) to communicate with software running in machine
mode (M-mode) to access the IPC hardware block.

Additional details on the Microchip vendor extension and the IPC
function IDs described in the driver can be found in the following
documentation:

https://github.com/linux4microchip/microchip-sbi-ecall-extension

The IPC remoteproc platform driver allows for starting and stopping
firmware on the remote cluster(s) and facilitates RPMsg communication.
The remoteproc attach/detach operations are also supported for use cases
where the firmware is loaded by the Hart Software Services
(zero-stage bootloader) before Linux boots.

Error Recovery and Power Management features are not currently
supported in the remoteproc platform driver.

The PIC64GX MPU has a Mi-V IHC block, this will be added to the PIC64GX
dts after the initial upstreaming:

https://patchwork.kernel.org/project/linux-riscv/patch/20240725121609.13101-18-pierre-henry.moussay@microchip.com/

Thanks,
Valentina

Valentina Fernandez (5):
  riscv: asm: vendorid_list: Add Microchip Technology to the vendor list
  dt-bindings: mailbox: add binding for Microchip IPC mailbox driver
  mailbox: add Microchip IPC support
  dt-bindings: remoteproc: add binding for Microchip IPC remoteproc
  remoteproc: add support for Microchip IPC remoteproc platform driver

 .../bindings/mailbox/microchip,sbi-ipc.yaml   | 115 ++++
 .../remoteproc/microchip,ipc-remoteproc.yaml  |  84 +++
 arch/riscv/include/asm/vendorid_list.h        |   1 +
 drivers/mailbox/Kconfig                       |  12 +
 drivers/mailbox/Makefile                      |   2 +
 drivers/mailbox/mailbox-mchp-ipc-sbi.c        | 539 ++++++++++++++++++
 drivers/remoteproc/Kconfig                    |  12 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/mchp_ipc_remoteproc.c      | 461 +++++++++++++++
 include/linux/mailbox/mchp-ipc.h              |  23 +
 10 files changed, 1250 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
 create mode 100644 Documentation/devicetree/bindings/remoteproc/microchip,ipc-remoteproc.yaml
 create mode 100644 drivers/mailbox/mailbox-mchp-ipc-sbi.c
 create mode 100644 drivers/remoteproc/mchp_ipc_remoteproc.c
 create mode 100644 include/linux/mailbox/mchp-ipc.h

-- 
2.34.1

Hi Valentina,

On 9/12/24 10:00, Valentina Fernandez wrote:
> Additional details on the Microchip vendor extension and the IPC
> function IDs described in the driver can be found in the following
> documentation:
> 
> https://github.com/linux4microchip/microchip-sbi-ecall-extension
> 
> The IPC remoteproc platform driver allows for starting and stopping
> firmware on the remote cluster(s) and facilitates RPMsg communication.
> The remoteproc attach/detach operations are also supported for use cases
> where the firmware is loaded by the Hart Software Services
> (zero-stage bootloader) before Linux boots.

Would you mind help clarifying the need for SBI_EXT_RPROC_STATE/STOP/...?
If I'm not mistaken, the HW you are targeting is described in
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/SupportingCollateral/Asymmetric_Multi-Processing_on_PIC64GX_White_Paper.pdf
(typo in the page 4, U51 -> E51)
In SBI, do you put hart1-3 and hart4 into 2 separate domains? If not,
I don't see why you can't just use HSM extension from SBI to kick rproc.
Also, how stable is this microchip-sbi-ecall-extension? Is it subject
to changes down the road? I don't see a probe() like SBI function, so
the kernel kind of assume it can call those microchip extensions without
causing unintended effects. This means those extension FIDs must be
stable and can no longer change once this code is in. Perhaps checking-in
the microchip SBI extensions to major SBI implementations such as openSBI
first would be better?

Bo

On 16/09/2024 23:28, Bo Gan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
> the content is safe
> 
> Hi Valentina,
Hi Bo,
> 
> On 9/12/24 10:00, Valentina Fernandez wrote:
>> Additional details on the Microchip vendor extension and the IPC
>> function IDs described in the driver can be found in the following
>> documentation:
>>
>> https://github.com/linux4microchip/microchip-sbi-ecall-extension
>>
>> The IPC remoteproc platform driver allows for starting and stopping
>> firmware on the remote cluster(s) and facilitates RPMsg communication.
>> The remoteproc attach/detach operations are also supported for use cases
>> where the firmware is loaded by the Hart Software Services
>> (zero-stage bootloader) before Linux boots.
> 
> Would you mind help clarifying the need for SBI_EXT_RPROC_STATE/STOP/...?
Sure, I provided a detailed explanation below.
> If I'm not mistaken, the HW you are targeting is described in
> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ 
> ProductDocuments/SupportingCollateral/Asymmetric_Multi- 
> Processing_on_PIC64GX_White_Paper.pdf
> (typo in the page 4, U51 -> E51)
Yes, this is the HW that these drivers are targeted for.
> In SBI, do you put hart1-3 and hart4 into 2 separate domains? If not,
> I don't see why you can't just use HSM extension from SBI to kick rproc.

The first AMP context (harts 1-3) is in one OpenSBI domain. The second 
AMP context may or may not be in an OpenSBI domain. Typical AMP use case 
applications have Linux SMP in one AMP context and an RTOS or BM 
application running in the other context.

BM/RTOS applications running in m-mode won't have OpenSBI, which means 
they may not necessarily have an HSM. However, if the BM/RTOS is running 
in s-mode, then we do register them in another OpenSBI domain.

We use the SBI_EXT_RPROC_START and SBI_EXT_RPROC_STOP functions to 
handle both scenarios.

> Also, how stable is this microchip-sbi-ecall-extension? Is it subject
> to changes down the road?

All the FIDs described in the microchip-sbi-ecall-extension repository 
are stable and agreed upon between different business units within 
Microchip, so they will not change. There might be additional FIDs added 
in the future to extend functionality if ever needed, but we won't 
change existing FIDs.
I don't see a probe() like SBI function, so
> the kernel kind of assume it can call those microchip extensions without
> causing unintended effects. This means those extension FIDs must be
> stable and can no longer change once this code is in. Perhaps checking-in
> the microchip SBI extensions to major SBI implementations such as openSBI
> first would be better?
Are you referring to the remoteproc driver? If that's the case, then 
yes, I believe we should call 
sbi_probe_extension(SBI_EXT_MICROCHIP_TECHNOLOGY) within the probe 
function. I will look into this for v2.

Thanks,
Valentina
> 
> Bo

On Tue, Sep 17, 2024 at 10:45:02AM +0000, Valentina.FernandezAlanis@microchip.com wrote:
> On 16/09/2024 23:28, Bo Gan wrote:
> > Perhaps checking-in
> > the microchip SBI extensions to major SBI implementations such as openSBI
> > first would be better?

It's worth pointing out that the "major SBI implementations" do not
support the platform this is currently being used on.

Hi Valentina,

On Thu, 12 Sept 2024 at 10:48, Valentina Fernandez
<valentina.fernandezalanis@microchip.com> wrote:
>
> Hello all,
>
> This series adds support for the Microchip Inter-Processor Communication
> (IPC) mailbox controller, as well as an IPC remoteproc platform driver.
>
> Microchip's family of RISC-V SoCs typically has one or more clusters
> that can be configured to run in Asymmetric Multi-Processing (AMP) mode.
>
> The Microchip IPC is used to send messages between processors using
> an interrupt signaling mechanism. The driver uses the RISC-V Supervisor
> Binary Interface (SBI) to communicate with software running in machine
> mode (M-mode) to access the IPC hardware block.
>
> Additional details on the Microchip vendor extension and the IPC
> function IDs described in the driver can be found in the following
> documentation:
>
> https://github.com/linux4microchip/microchip-sbi-ecall-extension
>
> The IPC remoteproc platform driver allows for starting and stopping
> firmware on the remote cluster(s) and facilitates RPMsg communication.
> The remoteproc attach/detach operations are also supported for use cases
> where the firmware is loaded by the Hart Software Services
> (zero-stage bootloader) before Linux boots.
>
> Error Recovery and Power Management features are not currently
> supported in the remoteproc platform driver.
>
> The PIC64GX MPU has a Mi-V IHC block, this will be added to the PIC64GX
> dts after the initial upstreaming:
>
> https://patchwork.kernel.org/project/linux-riscv/patch/20240725121609.13101-18-pierre-henry.moussay@microchip.com/
>
> Thanks,
> Valentina
>
> Valentina Fernandez (5):
>   riscv: asm: vendorid_list: Add Microchip Technology to the vendor list
>   dt-bindings: mailbox: add binding for Microchip IPC mailbox driver
>   mailbox: add Microchip IPC support
>   dt-bindings: remoteproc: add binding for Microchip IPC remoteproc
>   remoteproc: add support for Microchip IPC remoteproc platform driver
>
>  .../bindings/mailbox/microchip,sbi-ipc.yaml   | 115 ++++
>  .../remoteproc/microchip,ipc-remoteproc.yaml  |  84 +++
>  arch/riscv/include/asm/vendorid_list.h        |   1 +
>  drivers/mailbox/Kconfig                       |  12 +
>  drivers/mailbox/Makefile                      |   2 +
>  drivers/mailbox/mailbox-mchp-ipc-sbi.c        | 539 ++++++++++++++++++
>  drivers/remoteproc/Kconfig                    |  12 +
>  drivers/remoteproc/Makefile                   |   1 +
>  drivers/remoteproc/mchp_ipc_remoteproc.c      | 461 +++++++++++++++
>  include/linux/mailbox/mchp-ipc.h              |  23 +

I would advise splitting the two patchsets, i.e one for the mailbox
driver and another one for the remoteproc.  I would also start with
the mailbox and then go with the remoteproc.

Thanks,
Mathieu

>  10 files changed, 1250 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/microchip,ipc-remoteproc.yaml
>  create mode 100644 drivers/mailbox/mailbox-mchp-ipc-sbi.c
>  create mode 100644 drivers/remoteproc/mchp_ipc_remoteproc.c
>  create mode 100644 include/linux/mailbox/mchp-ipc.h
>
> --
> 2.34.1
>

Hi Valentina,

On Thu, 12 Sept 2024 at 10:48, Valentina Fernandez
<valentina.fernandezalanis@microchip.com> wrote:
>
> Hello all,
>
> This series adds support for the Microchip Inter-Processor Communication
> (IPC) mailbox controller, as well as an IPC remoteproc platform driver.
>
> Microchip's family of RISC-V SoCs typically has one or more clusters
> that can be configured to run in Asymmetric Multi-Processing (AMP) mode.
>
> The Microchip IPC is used to send messages between processors using
> an interrupt signaling mechanism. The driver uses the RISC-V Supervisor
> Binary Interface (SBI) to communicate with software running in machine
> mode (M-mode) to access the IPC hardware block.
>
> Additional details on the Microchip vendor extension and the IPC
> function IDs described in the driver can be found in the following
> documentation:
>
> https://github.com/linux4microchip/microchip-sbi-ecall-extension
>
> The IPC remoteproc platform driver allows for starting and stopping
> firmware on the remote cluster(s) and facilitates RPMsg communication.
> The remoteproc attach/detach operations are also supported for use cases
> where the firmware is loaded by the Hart Software Services
> (zero-stage bootloader) before Linux boots.
>
> Error Recovery and Power Management features are not currently
> supported in the remoteproc platform driver.
>
> The PIC64GX MPU has a Mi-V IHC block, this will be added to the PIC64GX
> dts after the initial upstreaming:
>
> https://patchwork.kernel.org/project/linux-riscv/patch/20240725121609.13101-18-pierre-henry.moussay@microchip.com/
>
> Thanks,
> Valentina
>
> Valentina Fernandez (5):
>   riscv: asm: vendorid_list: Add Microchip Technology to the vendor list
>   dt-bindings: mailbox: add binding for Microchip IPC mailbox driver
>   mailbox: add Microchip IPC support
>   dt-bindings: remoteproc: add binding for Microchip IPC remoteproc
>   remoteproc: add support for Microchip IPC remoteproc platform driver
>
>  .../bindings/mailbox/microchip,sbi-ipc.yaml   | 115 ++++
>  .../remoteproc/microchip,ipc-remoteproc.yaml  |  84 +++
>  arch/riscv/include/asm/vendorid_list.h        |   1 +
>  drivers/mailbox/Kconfig                       |  12 +
>  drivers/mailbox/Makefile                      |   2 +
>  drivers/mailbox/mailbox-mchp-ipc-sbi.c        | 539 ++++++++++++++++++
>  drivers/remoteproc/Kconfig                    |  12 +
>  drivers/remoteproc/Makefile                   |   1 +
>  drivers/remoteproc/mchp_ipc_remoteproc.c      | 461 +++++++++++++++
>  include/linux/mailbox/mchp-ipc.h              |  23 +
>  10 files changed, 1250 insertions(+)

It might be easier to split this patchset in two and proceed
incrementally, i.e upstream the mailbox driver first and then the
remoteproc part.

Regards,
Mathieu

>  create mode 100644 Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/microchip,ipc-remoteproc.yaml
>  create mode 100644 drivers/mailbox/mailbox-mchp-ipc-sbi.c
>  create mode 100644 drivers/remoteproc/mchp_ipc_remoteproc.c
>  create mode 100644 include/linux/mailbox/mchp-ipc.h
>
> --
> 2.34.1
>