On 4/28/2026 9:30 AM, Mathieu Poirier wrote:
> On Fri, Apr 24, 2026 at 12:52:40PM -0500, Shah, Tanmay wrote:
>>
>>
>> On 4/24/2026 11:53 AM, Krzysztof Kozlowski wrote:
>>> On 23/04/2026 19:59, Shah, Tanmay wrote:
>>>> 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.
>>>
>>> OK. The problem is that "user" is a bit vague and usually user choice
>>> goes to user-space.
>>>
>>> The property will be set or unset for ALL of given boards. So all of the
>>> DTS->DTB. That's why it should be clear why all such boards should
>>> behave like you described. If this is truly user, as in user-space,
>>> choice, then DT is not the way.
>>>
>>
>> Okay 'user' may not be the right choice of word. I should say 'hardware
>> configuration'. On same SoC, some cores can be configured to boot
>> automatically before Linux boots, and some won't. So if device-tree is
>> about hardware configuration, then we need a way to show which core is
>> configured to boot before linux. This configuration is board agnostic.
>> So I think auto-boot in device-tree makes sense.
>>
>> The only advantage on this platform is, it has a way to detect if the
>> core is running or not runtime and don't have to rely on device-tree.
>>
>>>
>>>>
>>>> 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.
>>>
>>> This works for me and solves my questions from DT point of view, but I
>>> cannot judge whether this makes sense for you.
>>>
>>
>> I say I will keep it open ended for now. I will avoid introducing
>> auto-boot in the device-tree for now, and send a patch without it. In
>> future if for some other reason this property is needed, will send new
>> patch later.
>>
>
> In light of this conversation, should I still review this patchset or it was
> made obsolete by "[PATCH] remoteproc: xlnx: check remote node state" ?
>
>
Hi,
Yes it was made obsolete by the mentioned patch.
Please wait for v2, which depends on the mentioned patch and removes
need of the auto-boot property from the device-tree.
Thanks,
Tanmay
>> Thanks,
>> Tanmay
>>
>>>
>>> Best regards,
>>> Krzysztof
>>
