public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: "Shah, Tanmay" <tanmays@amd.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>, <tanmay.shah@amd.com>
Cc: "Padhi, Beleswar" <b-padhi@ti.com>, <michal.simek@amd.com>,
	<andersson@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-remoteproc@vger.kernel.org>
Subject: Re: [PATCH] remoteproc: xlnx: check remote node state
Date: Mon, 27 Apr 2026 13:51:12 -0500	[thread overview]
Message-ID: <00a41c39-81b1-4f7b-8681-8bf0dd59918a@amd.com> (raw)
In-Reply-To: <ae-iTAk0KvtPvMSB@p14s>



On 4/27/2026 12:52 PM, Mathieu Poirier wrote:
> Good morning
> 
> On Mon, Apr 27, 2026 at 11:15:29AM -0500, Shah, Tanmay wrote:
>> Hello Beleswar,
>>
>> Thanks for reviews. Please find my answer below:
>>
>> On 4/24/2026 10:51 PM, Padhi, Beleswar wrote:
>>> Hi Tanmay,
>>>
>>> In $subject-line, s/remote node/remoteproc
>>>
>>
>> Ack. 'node' is platform management firmware term, which might not be
>> right here. subject line already contains remoteproc so no need to have
>> it again. Instead, will replace 'node' with 'core'. new subject:
>>
>> remoteproc: xlnx: check remote core state.
>>
> 
> Much better.
>  
>>> On 4/25/2026 8:32 AM, Tanmay Shah wrote:
>>>> The remote state is set to RPROC_DETACHED if the resource table is found
>>>> in the memory. However, this can be wrong if the remote is not started,
>>>> but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
>>>> to the firmware to request the state of the RPU node. If the RPU is
>>>> actually out of reset and running, only then move the remote state to
>>>> RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
>>>
>>>
>>> This is a good additional check. However, one thing to note is

[...]

>>>> +
>>>> +        /*
>>>> +         * If RPU state is power on and out of reset i.e. running, then
>>>> +         * assign RPROC_DETACHED state. If the RPU is not out of reset
>>>> +         * then do not attempt to attach to the remote processor.
>>>> +         */
>>>> +        if (status == PM_NODE_RUNNING) {
>>>> +            if (zynqmp_r5_get_rsc_table_va(r5_core))
>>>> +                dev_dbg(r5_core->dev, "rsc tbl not found\n");
>>>
>>>
>>> Do you still want to set state = RPROC_DETACHED if resource table is not
>>> found in the
>>> memory?
>>>
>>
>> Yes. Not all the firmware that is running on remote core is expected to
>> have the resource table. The firmware might not use RPMsg at all, and in
>> that case resource table becomes irrelevant. However, we still need to
>> make sure that running core is not reported as offline.
> 
> Please add the above explanation to the inlined comment.  Otherwise I'm good
> with this patch but I'll need an RB from Michael before moving forward.  
> 

Ack.

> Do you see this as a bug fix?  Is there a point adding this patch to the stable
> kernels?
> 

That's a good point. I should add Fixes tag as well, for the commit that
introduced attach-detach feature.

I will do that in v2.

Thanks,
Tanmay

>>
>> Thanks.
>>
>>> Thanks,
>>> Beleswar
>>>
>>>> +            r5_core->rproc->state = RPROC_DETACHED;
>>>> +        }
>>>>       }
>>>>         return 0;
>>>> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/
>>>> firmware/xlnx-zynqmp.h
>>>> index d70dcd462b44..7e27b0f7bf7e 100644
>>>> --- a/include/linux/firmware/xlnx-zynqmp.h
>>>> +++ b/include/linux/firmware/xlnx-zynqmp.h
>>>> @@ -542,6 +542,18 @@ enum pm_gem_config_type {
>>>>       GEM_CONFIG_FIXED = 2,
>>>>   };
>>>>   +/**
>>>> + * enum pm_node_status - Device node status provided by xilpm fw
>>>> + * @PM_NODE_UNUSED: Device is not used
>>>> + * @PM_NODE_RUNNING: Device is power-on and out of reset
>>>> + * @PM_NODE_HALT: Device is power-on but in the reset state
>>>> + */
>>>> +enum pm_node_status {
>>>> +    PM_NODE_UNUSED = 0,
>>>> +    PM_NODE_RUNNING = 1,
>>>> +    PM_NODE_HALT = 12,
>>>> +};
>>>> +
>>>>   /**
>>>>    * struct zynqmp_pm_query_data - PM query data
>>>>    * @qid:    query ID
>>>> @@ -630,6 +642,8 @@ int zynqmp_pm_set_rpu_mode(u32 node_id, enum
>>>> rpu_oper_mode rpu_mode);
>>>>   int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode);
>>>>   int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
>>>>                     u32 *const requirements, u32 *const usage);
>>>> +int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
>>>> +                  u32 *const requirements, u32 *const usage);
>>>>   int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config,
>>>> u32 value);
>>>>   int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
>>>>                    u32 value);
>>>> @@ -939,6 +953,13 @@ static inline int zynqmp_pm_get_node_status(const
>>>> u32 node, u32 *const status,
>>>>       return -ENODEV;
>>>>   }
>>>>   +static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32
>>>> *const status,
>>>> +                        u32 *const requirements,
>>>> +                        u32 *const usage)
>>>> +{
>>>> +    return -ENODEV;
>>>> +}
>>>> +
>>>>   static inline int zynqmp_pm_set_sd_config(u32 node,
>>>>                         enum pm_sd_config_type config,
>>>>                         u32 value)
>>>>
>>>> base-commit: 6f860d238b44da8ac57be25289b9f4410691c4e2
>>



      reply	other threads:[~2026-04-27 18:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-25  3:02 [PATCH] remoteproc: xlnx: check remote node state Tanmay Shah
2026-04-25  3:51 ` Padhi, Beleswar
2026-04-27 16:15   ` Shah, Tanmay
2026-04-27 17:52     ` Mathieu Poirier
2026-04-27 18:51       ` Shah, Tanmay [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=00a41c39-81b1-4f7b-8681-8bf0dd59918a@amd.com \
    --to=tanmays@amd.com \
    --cc=andersson@kernel.org \
    --cc=b-padhi@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=michal.simek@amd.com \
    --cc=tanmay.shah@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox