i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 Hi Team, We are working on an i.MX 95 platform and would like to use the MIPI DSI peripheral initially from the M7 core, and then hand over the resource to the A55 core at runtime. From our understanding, the peripheral resources and their ownership are initially defined for each Logical Machine/processor in the mx95evk.cfg file generated/configured through the System Manager tools. We would like to clarify the following: Dynamic Resource Handover: Is it possible to dynamically transfer the MIPI DSI peripheral resource from M7 to A55 at runtime? For example, M7 would initially own and use MIPI DSI, then release it, after which A55 would take ownership and use the same peripheral. Dynamic Resource Allocation: If runtime handover is supported, what is the recommended mechanism/API to change the resource ownership or access permissions dynamically? Is this handled through the System Manager, TRDC, or another mechanism? GPIO Sharing: Is it possible for the same GPIO port/resource to be accessed by both M7 and A55 simultaneously? If so, are there any TRDC configuration requirements or software synchronization mechanisms that need to be implemented to safely share the GPIO resource? We would appreciate any guidance on the recommended approach for implementing dynamic peripheral handover and/or resource sharing between M7 and A55 on the i.MX 95. Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 I discussed with the AE team, please refer to the following update.
On i.MX 95, resource ownership and TRDC permissions are defined statically at build time in the SM config (mx95evk.cfg → generated config_.h) and applied by the System Manager (SM) when a MIX powers up. *There is no SCMI/SM message that transfers ownership of a peripheral from one Logical Machine (LM) to another at runtime.
However, SM documentation names "handing a display over from one LM to another" as the exact motivating use case for the SM_SCMI_PERM_EXCLUSIVE model. So the handover is achievable, just not by "moving" ownership.
Q1 & Q2 — MIPI DSI M7 → A55 handover: how to do it
The LMM (Logical Machine Management) SCMI protocol only boots / resets / shuts down / suspends / wakes LMs — it has no RESOURCE_ASSIGN or OWNERSHIP_TRANSFER message. Instead, use a temporal-division handoff:
Grant BOTH LMs access up-front in mx95evk.cfg. By default the EVK config assigns MIPI_DSI, MIPI_PHY, DC_DISPENG, BLK_CTRL_DISPLAYMIX, the display clocks/power (PD_DISPLAY, CLK_DISP*) as OWNER of the AP (LM2) only — you must also add them to the M7 LM (LM1) to allow M7-first usage.
Mark the SM-managed resources (clocks, power, reset) as SM_SCMI_PERM_EXCLUSIVE (api=all) so requests from the two LMs are not silently aggregated/overwritten.
At handover, M7 quiesces DSI/DCIF, then signals A55 via application-level IPC (MU mailbox or SCMI notification). A55 (Linux/DRM DSI+DPU stack) then brings up the same IP.
The handoff sequencing is the customer's software responsibility (temporal division). The SM only guarantees the HW is drivable from either side because both LMs were pre-granted access. TRDC ownership cannot be rewritten at runtime — only the SM programs TRDC, and only from the static config at MIX power-up.
TRDC config that controls this (expressed in the .cfg):
MDAC_am=… — Master-Domain Assignment (maps a bus master to a domain ID)
MBC_am=s.b — Memory Block Check — this is where peripheral access is gated
MRC_am=… — Memory Region Check (large memory regions like DDR)
Each LM binds to a DID, e.g. SM did=2, AP(LM2) did=3, M7(LM1) did=4.
Q3 — Shared GPIO between M7 and A55
Yes, TRDC can grant both the M7 domain and the A55 domain concurrent access to the same GPIO instance (enable its MBC block for both DIDs). But there is a critical caveat and two supported patterns:
Caveat: i.MX 95 GPIO has no hardware arbitration — PDR/DR/GDIR registers are physically shared, so uncoordinated read-modify-write from both cores races.
Pattern A (disjoint pins + SW sync): Assign specific pins to each core by convention (the config already splits pins per LM). Since the data/direction register banks are still shared, protect concurrent RMW with a hardware semaphore / MU, or ensure the cores never touch the same register bank concurrently.
Pattern B (SM-arbitrated, recommended for truly shared instances): Route through the always-on GPIO1, which is owned by the SM and whose documented role is "arbitrates shared access." IOMUXC/IOMUX_GPR are likewise SM-arbitrated. Pinmux/daisy is set via the SCMI pin-control protocol with per-agent permissions; GPIO data ops are direct MMIO.
Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 Hello, On the i.MX 95, the MIPI DSI resource can be used by the M7 initially and later handed over to the A55. The resource access and ownership should be configured through the System Manager/TRDC configuration, while the actual runtime handover should be handled by software. TRDC controls which Logical Machine/domain is allowed to access the peripheral, but it does not manage synchronization between M7 and A55. Therefore, M7 should first complete all DSI operations, stop using the peripheral, and notify A55 through an inter-core mechanism such as MU/IPC before A55 takes control. Similarly, GPIO resources can be made accessible to both M7 and A55 through the appropriate TRDC configuration, but simultaneous access must be synchronized by software. For the DSI use case, the recommended approach is to have only one core actively use the peripheral at a time and use MU/IPC for the handover. Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 Hi team, We are working with an i.MX 95 19x19 EVK and are trying to implement an LVDS display handover between the M7 and A55/Linux, with the following intended architecture: M7: Initially owns and drives the LVDS display. A55/Linux: Subsequently takes control of the display after Linux boots. Current Implementation As an initial phase of development, we have configured the LVDS display to be initialized and controlled by the M7. The M7 successfully initializes the display and fills the framebuffer with a blue color, which is correctly displayed on the LVDS panel. We modified the following resources from their default A55 ownership to M7 ownership, while providing access to A55: DC DC0 DC1 DC_CMDSEQ DC_DISPENG DC_DISPENG_INT DC_FL0 DC_FL1 DC_INT_CTL DC_PIXENGINE DC_XPC DC_YUV0 DC_YUV1 DC_YUV2 DC_YUV3 BLK_CTRL_DISPLAYMIX LVDS MIPI_PHY LDB_PLL CLOCK_DISP1PIX VIDEO_PLL1 PIN_I2C2_SCL PIN_I2C2_SDA LPI2C2 Observed Behavior The behavior is currently as follows: The M7 boots and successfully initializes the display. The blue-filled framebuffer is displayed correctly on the LVDS panel. The display remains visible while the M7 is running. The A55/Linux boot process then starts. After the Linux kernel starts, the display goes blank. When using the following device tree:fdtfile imx95-19x19-evk-it6263-lvds1.dtb Linux consistently stops progressing during kernel boot. We do not observe an obvious kernel panic or a clear error message on the console. The boot process simply stops progressing. Resource Ownership Investigation Based on our understanding, resource ownership is statically configured through the System Manager configuration, and ownership cannot be dynamically transferred between Logical Machines through an SCMI message. We therefore investigated whether the display resources could be assigned to both the M7 and A55. However, some of the critical DC resources do not appear to support dual ownership, particularly: DC DC_XPC DC_YUV0 DC_YUV1 DC_YUV2 DC_YUV3 DC_FL0 DC_FL1 DC_2DBLIT This raises the possibility that Linux may be attempting to access one or more display resources that are exclusively owned by the M7 during its DRM/DPU or IT6263/LVDS initialization. Questions Could you please help us clarify the following? 1. Is it expected for Linux to hang if resources such as DC, DC_XPC, DC_YUV*, DC_FL*, or DC_2DBLIT are exclusively owned by the M7? 2. Which display resources are accessed by A55/Linux during Linux boot and during DRM/DPU and IT6263/LVDS initialization? In particular, we would like to understand the exact resources accessed by: Linux DRM/DPU Display Controller (DC) IT6263 driver LVDS/LDB driver Display clock/PLL configuration 3. Is there a supported System Manager resource ownership configuration that allows the following sequence? M7 initializes and drives the LVDS display. A55/Linux boots normally. A55/Linux subsequently takes control of the display. Both Logical Machines can access the resources required for the handover. 4. If the DC resources cannot be shared between the M7 and A55, what is the recommended architecture for M7 display and A55/Linux coexistence or display handover? 5. Does A55/Linux require ownership of the complete DC resource hierarchy even if Linux is not intended to actively drive the display during the initial stage of boot? 6. Are any additional configuration changes required in the following areas for this use case? System Manager resource configuration TRDC permissions SCMI configuration Linux device tree Display/LVDS configuration 7. Could the Linux boot hang be caused by A55/Linux attempting to access a display resource that is owned by the M7, particularly during initialization of the IT6263/LVDS display path? Our primary objective at this stage is to identify the exact display resources that Linux accesses during early boot and during DRM/DPU and IT6263/LVDS initialization, and determine whether those resources can coexist with M7 ownership. We have attached the System Manager configuration (.cfg) file and Linux boot log for reference. Any guidance on the supported resource ownership configuration, display resource dependencies, or recommended architecture for implementing M7/A55 LVDS display handover would be greatly appreciated. Thank you. Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 We have AN15131 to resolve this problem, there is also source code attached in this AN.
However, this AN's status is "Web Publishing Pending", it haven't been released on nxp.com.
Please wait for it for some days.
查看全文
