Re: [PATCH] remoteproc: xlnx: refactor start & stop ops

[Michal Simek <michal.simek@amd.com>]

On 6/24/26 16:02, Mathieu Poirier wrote:
> On Wed, 24 Jun 2026 at 00:12, Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 6/23/26 00:29, Shah, Tanmay wrote:
>>> Hello,
>>>
>>>
>>> On 6/22/2026 7:25 AM, Michal Simek wrote:
>>>>
>>>>
>>>> On 6/19/26 18:38, Tanmay Shah wrote:
>>>>> Current _start and _stop ops are implemented using various APIs from the
>>>>> platform management firmware driver. Instead provide respective RPU
>>>>> start and stop API in the firmware driver and move the logic to interact
>>>>> with the PM firmware in the firmware driver. The remoteproc driver
>>>>> doesn't
>>>>> need to know actual logic, but only the final result i.e. RPU start/stop
>>>>> was success or not. This refactor keeps the remoteproc driver simple and
>>>>> moves firmware interaction logic to the firmware driver.
>>>>>
>>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>>> ---
>>>>>     drivers/firmware/xilinx/zynqmp.c        | 93 +++++++++++++++++++++++++
>>>>>     drivers/remoteproc/xlnx_r5_remoteproc.c | 68 ++----------------
>>>>>     include/linux/firmware/xlnx-zynqmp.h    | 12 ++++
>>>>>     3 files changed, 110 insertions(+), 63 deletions(-)
>>>>>
>>>>> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/
>>>>> xilinx/zynqmp.c
>>>>> index af838b2dc327..f9a3a95b0638 100644
>>>>> --- a/drivers/firmware/xilinx/zynqmp.c
>>>>> +++ b/drivers/firmware/xilinx/zynqmp.c
>>>>> @@ -1513,6 +1513,99 @@ int zynqmp_pm_request_wake(const u32 node,
>>>>>     }
>>>>>     EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
>>>>>     +/**
>>>>> + * zynqmp_pm_start_rpu - Boot Real-time Processing Unit (Cortex-R) on
>>>>> SoC
>>>>> + *
>>>>> + * @node: power-domains id of the core
>>>>> + * @bootaddr: Boot address of elf
>>>>> + *
>>>>> + * Return: status, either success or error+reason
>>>>> + */
>>>>> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
>>>>> +{
>>>>> +    enum rpu_boot_mem bootmem;
>>>>> +    int ret;
>>>>> +
>>>>> +    /*
>>>>> +     * The exception vector pointers (EVP) refer to the base-address of
>>>>> +     * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
>>>>> +     * starts at the base-address and subsequent vectors are on 4-byte
>>>>> +     * boundaries.
>>>>> +     *
>>>>> +     * Exception vectors can start either from 0x0000_0000 (LOVEC) or
>>>>> +     * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip
>>>>> Memory)
>>>>
>>>> here
>>>>
>>>>> +     *
>>>>> +     * Usually firmware will put Exception vectors at LOVEC.
>>>>> +     *
>>>>> +     * It is not recommend that you change the exception vector.
>>>>> +     * Changing the EVP to HIVEC will result in increased interrupt
>>>>> latency
>>>>> +     * and jitter. Also, if the OCM is secured and the Cortex-R5F
>>>>> processor
>>>>> +     * is non-secured, then the Cortex-R5F processor cannot access the
>>>>> +     * HIVEC exception vectors in the OCM.
>>>>> +     */
>>>>> +    bootmem = (bootaddr >= 0xFFFC0000) ?
>>>>
>>>> and here you have different values without any explanation why.
>>>>
>>>
>>> The value in the comment is correct, but the check is done for all of
>>> OCM address range. This is just refactoring of the interfaces and not
>>> the actual logic. There is a separate patch which actually refactors the
>>> logic, I will send it later. I would like to keep this as it is because
>>> this was originally there, and the intent of the commit is not to modify it.
>>
>> ok.
>>
>> Acked-by: Michal Simek <michal.simek@amd.com>
>>
> 
> Michal - do you prefer that I pick this patch on the remoteproc side?

yes please.

Thanks,
Michal