[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1b90b0f-f7a7-4117-9d36-046c4ca9c19a@kernel.org>
Date: Tue, 29 Jul 2025 08:27:53 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Junhui Liu <junhui.liu@...moral.tech>,
Bjorn Andersson <andersson@...nel.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Chen Wang <unicorn_wang@...look.com>,
Inochi Amaoto <inochiama@...il.com>, Philipp Zabel <p.zabel@...gutronix.de>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
<palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Alexandre Ghiti <alex@...ti.fr>
Cc: linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
sophgo@...ts.linux.dev, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 1/2] dt-bindings: remoteproc: Add C906L rproc for
Sophgo CV1800B SoC
On 28/07/2025 19:13, Junhui Liu wrote:
>>
>>> + description:
>>> + This property is required only if the rpmsg/virtio functionality is used.
>>> + (see mailbox/sophgo,cv1800b-mailbox.yaml)
>>> + items:
>>> + - description: mailbox channel to send data to C906L
>>> + - description: mailbox channel to receive data from C906L
>>> +
>>> + memory-region:
>>> + description:
>>> + List of phandles to reserved memory regions used by the remote processor.
>>> + The first region is required and provides the firmware region for the
>>> + remote processor. The following regions (vdev buffer, vrings) are optional
>>> + and are only required if rpmsg/virtio functionality is used.
>>> + minItems: 1
>>
>> Why isn't this constrained?
>
> Do you mean a maxItems should be added here?
> >>
>>> + items:
>>> + - description: firmware region
>>> + - description: vdev buffer
>>> + - description: vring0
>>> + - description: vring1
>>> + additionalItems: true
>>
>> No, drop. This needs to be constrained.
>
> My intention is that RPMsg/OpenAMP is not the only use case for
We don't allow such syntax, that's not negotiable. Why 322 redundant
memory regions are fine now?
> remoteproc. There are scenarios where the remoteproc is just used for
> booting the remote processor without any communication with Linux. In
> such case, only the firmware region is needed, and the other regions may
> not be necessary.
>
> Additionally, the remote processor might reserve extra memory for custom
> buffers or other firmware-specific purposes beyond virtio/rpmsg.
> Therefore, I think only the firmware region should be required and
> constrained, while allowing flexibility for additional/custom memory
> regions as needed.
So how does this work exactly without the rest? Remote processor boots
and works fine? How do you communicate with it?
Please describe exactly the usecase.
Best regards,
Krzysztof
Powered by blists - more mailing lists