On 4/23/2026 12:26 PM, Krzysztof Kozlowski wrote:
> On 23/04/2026 17:14, Shah, Tanmay wrote:
>> Hello,
>>
>> Thanks for reviews. Please see my comments below.
>>
>> On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
>>> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>>>> Add auto-boot property to notify that remote processor is setup and
>>>> ready to boot. Linux can attempt to boot or attach to already running
>>>> remote processor. "firmware-name" property is used to mention default
>>>> firmware to boot when linux starts the remote processor.
>>>>
>>>> Signed-off-by: Tanmay Shah <[email protected]>
>>>> ---
>>>> .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> index ee63c03949c9..0d27260e3baa 100644
>>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> @@ -135,6 +135,14 @@ patternProperties:
>>>> - description: vring1
>>>> additionalItems: true
>>>>
>>>> + auto-boot:
>>>
>>> Last months, I have been asking AMD to follow writing-bindings doc or
>>> other DT guidelines way too many times.
>>>
>>> Or you just sent us downstream... Do you see anywhere such property?
>>> What properties do you see? How are they named?
>>>
>>
>> I should have put note about this. Current auto-boot properties are
>> named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
>> there. Can we have a common auto-boot property? Similar to
>> firmware-name? If we agree to it then what's the correct location? New
>> file remoteproc.yaml is okay?
>
> Common properties go to dtschema, so it would need to go there, but the
> point is that it's way too generic - every component with FW could be
> called "auto-boot". This should stay vendor property, IMO.
>
Ack, I will rename it to xlnx,auto-boot.
>>
>>>> + type: boolean
>>>> + description: remote core is either already running or ready to
>>>> boot
>>>
>>> And why is this property of a board?
>>>
>>
>> Not sure what indicates it is? The property is under remoteproc child
>> device that is SOC level property. Remote core is on same SOC wher linux
>> core is running.
>
> So it is implied by SoC compatible? Please provide some arguments why it
> cannot be implied by the SoC compatible. I gave you one way out, but if
> you disagree then no problem.
>
So on some SoC, the bootloader supports loading and starting of the
remote processor. But it is totally user's choice. User can choose to
load & start one core of a cluster via bootloader and leave another core
powered-off.
That is why it is not possible to decide based on SoC compatible.
If we don't want to make it a device-tree property then I can implement
in a different way. New way will detect if the remote is running or not
via EMMI/SCMI call to the firmware, and take a decision based on that.
If this new way works, then I don't think we need auto-boot property at all.
Let me know your thoughts.
>>
>>>> +
>>>> + firmware-name:
>>>> + maxItems: 1
>>>> + description: default firmware to load
>>>
>>> Can you load non-default firmware later? IOW, why adding description
>>> here, what is special?
>>>
>>
>> The rootfs contains other firmware demos, and it is possible to stop the
>> default firmware, load other fw elf and re-run the remote core.
>> I don't have strong preference on the description part, I will remove it
>> if redundant.
>
> No, it's fine, I wanted to be sure that such use case makes sense.
>
> Best regards,
> Krzysztof
