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

["Shah, Tanmay" <tanmays@amd.com>]

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.

Thanks,
Tanmay

> The rest looks good to me. It is a step in a right direction.
> 
> Thanks,
> Michal
>