i.MX ProcessorsのトピックRe: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55

i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55

Manoj2605 — Wed, 09 Sep 2026 05:04:41 GMT

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

yipingwang — Fri, 11 Sep 2026 01:35:39 GMT

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

drist029ity — Fri, 11 Sep 2026 05:42:20 GMT

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.