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

[Mathieu Poirier]

On Wed, 24 Jun 2026 at 00:12, Michal Simek <michal.simek at 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 at 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 at amd.com>
>

Michal - do you prefer that I pick this patch on the remoteproc side?

> Thanks,
> Michal