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" ? > Thanks, > Tanmay > > > > > Best regards, > > Krzysztof >
