On Wed, 24 Jun 2026 at 00:12, Michal Simek <[email protected]> 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 <[email protected]> > >>> --- > >>> 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 <[email protected]> >
Michal - do you prefer that I pick this patch on the remoteproc side? > Thanks, > Michal
