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

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

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>

Thanks,
Michal