2392008_en-US

[#1]

i.MX943 S2R Resume Time Regression from LF6.12 to LF6.18 BSP: Root Cause and Workaround

Platform: i.MX943 | Kernel: Linux 6.18 (LF6.18 BSP) | Category: Power Management

---

Overview

If you have migrated from LF6.12 to LF6.18 on i.MX943 and noticed that your board takes significantly longer to resume from Suspend-to-RAM (S2R), this article explains why the behavior changed, what is behind it, and what you can do to reduce the observable latency.

---

Observed Symptom

On the IMX943LP5EVK-19, the total resume latency — measured from the ONOFF key (SW5) falling edge to a GPIO toggled in user space — differs noticeably between the two BSP releases:

Scenario	LF6.18	LF6.12
Default BSP (PCIe enabled)	~3420 ms	~1420 ms
PCIe disabled	~1060 ms	~257 ms
Delta (PCIe on vs. off)	~2360 ms	~1163 ms

The data shows that PCIe is the dominant contributor to the extra resume time in LF6.18. Additionally, a ~500 ms gap was observed between the kernel log messages Restarting tasks: Done and random: crng reseeded on system resumption, indicating a secondary delay in the post-resume path.

---

Root Cause

Primary Cause — PCIe FLR Moved to the Resume Path

A critical bug fix was introduced in LF6.18 to address a system panic during suspend on i.MX943 when PCIe-attached ENETC Ethernet ports were active.

Before the fix (LF6.12): The ENETC driver called pcie_flr() (PCIe Function Level Reset) during the suspend phase. Under certain timing conditions, pci_pm_suspend_noirq() would access the PCIe device before the FLR had completed, causing a call trace and system reboot. This is a real, critical bug — though not consistently reproducible without specific peripheral configurations.

What the fix does (LF6.18): To eliminate the race condition, the FLR was moved from the suspend path to the very beginning of the resume path. This is the correct and safe approach, but it comes with a latency cost:

• pcie_flr() internally uses msleep(), an asynchronous sleep that adds >100 ms of delay per call.
• On i.MX943, multiple ENETC ports are present. Since these FLR operations execute sequentially, the delays accumulate — resulting in the ~2360 ms overhead observed with PCIe enabled.

Important: The LF6.12 resume time measurements were taken against a kernel with a latent suspend panic bug. Those numbers do not represent a stable baseline. The LF6.18 figures reflect correct, stable behavior.

Secondary Cause — Post-Resume Entropy Reseeding Delay

A ~500 ms delay between Restarting tasks: Done and random: crng reseeded on system resumption was also identified. This is caused by the kernel's random number generator (CRNG) reseeding process briefly blocking after tasks are unfrozen during resume.

---

Why This Cannot Simply Be Reverted

Reverting the PCIe FLR fix to recover the LF6.12 resume speed would re-expose the system to random panics during suspend — an unacceptable trade-off for any production design. The longer resume time is therefore an intentional and necessary consequence of making suspend/resume reliable on i.MX943.

---

Recommended Workaround

To address the secondary ~500 ms CRNG reseeding delay, write 1 to /sys/power/freeze_filesystems before entering suspend:

echo 1 > /sys/power/freeze_filesystems
echo mem > /sys/power/state

This has been confirmed to eliminate the post-resume entropy delay.

Note: Investigation also shows that the PCIe-related portion of the resume overhead (~2360 ms) is attributable to sequential FLR execution across multiple ENETC ports. Parallelizing these operations is a potential future optimization, but no timeline is committed at this point.

---

How to Measure Resume Latency on Your Board

Use the following script on i.MX943 to reproduce the measurement:

# Configure GPIO_IO31 as output, pull down
/unit_tests/memtool -32 0x43810044=0x80000000
/unit_tests/memtool -32 0x43810054=0x80000000
/unit_tests/memtool -32 0x43810040=0x0

# Enter suspend
echo mem > /sys/power/state

# After wakeup (press ONOFF/SW5), pull GPIO_IO31 high
/unit_tests/memtool -32 0x43810040=0x80000000

Measure the interval between the ONOFF falling edge and the GPIO rising edge using an oscilloscope or BCU power tool.

---

Summary

Item	Detail
Affected platform	i.MX943 (IMX943LP5EVK-19)
Affected BSP	LF6.18 and later
Primary cause	PCIe FLR moved to resume path to fix suspend panic
Secondary cause	CRNG reseeding delay (~500 ms) post-resume
Recommended workaround	echo 1 > /sys/power/freeze_filesystems
PCIe resume overhead	~2360 ms (sequential FLR across ENETC ports) — by design

The increased resume time in LF6.18 is expected behavior resulting from a necessary stability fix. The LF6.12 baseline was measured against a kernel with a latent suspend panic bug and should not be used as a performance reference.

Upgrading from LF6.12 to LF6.18 on i.MX943 brings a noticeable increase in S2R resume latency — from ~1420 ms up to ~3420 ms under default BSP configuration. This is not a regression to be fixed, but an intentional consequence of a critical suspend panic fix introduced in LF6.18. This article explains the root cause behind the PCIe FLR timing change, the secondary CRNG reseeding delay, and provides a confirmed workaround to reduce observable resume time.

i.MX Processors