On 13/12/2025 05:42, Tanmay Shah wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hello, Please find my comment below:
>
> On 11/21/25 8:21 AM, Valentina Fernandez wrote:
>> Microchip family of RISC-V SoCs typically have one or more application
>> clusters. These clusters can be configured to run in an Asymmetric
>> Multi Processing (AMP) mode.
>>
>> Add a dt-binding for these application clusters.
>>
>> Signed-off-by: Valentina Fernandez<[email protected]>
>> ---
>> .../microchip,ipc-sbi-remoteproc.yaml | 95 +++++++++++++++++++
>> 1 file changed, 95 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/remoteproc/microchip,ipc-sbi-remoteproc.yaml
>>
>> diff --git
>> a/Documentation/devicetree/bindings/remoteproc/microchip,ipc-sbi-remoteproc.yaml
>>
>> b/Documentation/devicetree/bindings/remoteproc/microchip,ipc-sbi-remoteproc.yaml
>> new file mode 100644
>> index 000000000000..348902f9a202
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/remoteproc/microchip,ipc-sbi-remoteproc.yaml
>> @@ -0,0 +1,95 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id:http://devicetree.org/schemas/remoteproc/microchip,ipc-sbi-remoteproc.yaml#
>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip IPC Remote Processor
>> +
>> +description:
>> + Microchip family of RISC-V SoCs typically have one or more
>> + clusters. These clusters can be configured to run in an Asymmetric
>> + Multi Processing (AMP) mode where clusters are split in independent
>> + software contexts.
>> +
>> +maintainers:
>> + - Valentina Fernandez<[email protected]>
>> +
>> +properties:
>> + compatible:
>> + const: microchip,ipc-sbi-remoteproc
>> +
>> + mboxes:
>> + description:
>> + Microchip IPC mailbox specifier. To be used for communication with
>> + a remote cluster. The specifier format is as per the bindings,
>> + Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
>> + maxItems: 1
>> +
>> + memory-region:
>> + minItems: 1
>> + maxItems: 5
>> + description:
>> + List of phandles to the reserved memory regions associated wih the
>> remoteproc
>> + device. This is variable and describes the memories shared with the
>> remote cluster
>> + (e.g. firmware, resource table, rpmsg vrings, etc.)
>> + items:
>> + anyOf:
>> + - description: region used for the resource table when firmware is
>> started by the bootloader
>> + - description: region used for the remote cluster firmware image
>> section
>> + - description: virtio device (vdev) buffer
>> + - description: virtqueue for sending messages to the remote cluster
>> (vring0)
> This is in-accurate as per the implementation:
> https://github.com/torvalds/linux/blob/a919610db43b34621d0c3b333e12db9002caf5da/drivers/rpmsg/virtio_rpmsg_bus.c#L878
>
> Also the implementation can be changed. The description doesn't need to
> mention
> if vring0 is used for rx or tx.
>
>> + - description: virtqueue for receiving messages from the remote
>> cluster (vring1)
> Same here.
Thanks for the feedback. I'll fix that on v3
>> +
>> + memory-region-names:
>> + minItems: 1
>> + maxItems: 5
>> + items:
>> + anyOf:
>> + - const: rsc-table
>> + - const: firmware
>> + - const: buffer
>> + - const: vring0
>> + - const: vring1
>> +
>> +required:
>> + - compatible
>> + - mboxes
>> + - memory-region
>> + - memory-region-names
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + // Early boot mode example - firmware started by bootloader
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + remoteproc {
>> + compatible = "microchip,ipc-sbi-remoteproc";
>> + mboxes= <&ihc 8>;
> In the driver, this "mboxes" id is used for powering on/off remote processor.
>
> I think, "power-domains" is more suitable property over "mboxes" for this
> purpose.
>
> It is possible to only load, start and stop remote processor without any
> communication. So ideally "mboxes" can be optional, but in this case it can't
> be
> because remote's power-domain id is used from "mboxes" id. Even if both are
> the
> same number, they should be different properties and should be used for
> different purpose.
>
> Thanks,
> Tanmay
You are correct that, technically, the mbox property should be optional.
Unfortunately, I don't think using the "power-domains" property makes
sense in this particular case. On all currently supported platforms, all
remote clusters share the same power domain, which means we
can't power them on or off individually. As a result, we are only able to
load firmware into memory and control the execution of the firmware
running in the remote cluster(via start/stop ops).
To remove the mbox dependency, I believe another approach could
be to use a cpu phandle property to obtain the primary boot hart
associated with the remote CPU cluster instead of using the mailbox
channel.
I am preparing a v3 with this change, along with other comments,
for further feedback.
Thanks,
Valentina
>> + memory-region = <&rsctable>, <&vdev0buffer>,
>> + <&vdev0vring0>, <&vdev0vring1>;
>> + memory-region-names = "rsc-table", "buffer",
>> + "vring0", "vring1";
>> + };
>> + };
>> +
>> + - |
>> + // Late boot mode example - firmware started by Linux (remoteproc)
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + remoteproc {
>> + compatible = "microchip,ipc-sbi-remoteproc";
>> + mboxes= <&ihc 8>;
>> + memory-region = <&cluster_firmware>, <&vdev0buffer>,
>> + <&vdev0vring0>, <&vdev0vring1>;
>> + memory-region-names = "firmware", "buffer",
>> + "vring0", "vring1";
>> + };
>> + };
>> +...
