SM8550: Enable deep suspend#2952
Open
jaewun wants to merge 4 commits into
Open
Conversation
Add the ICE iface-clock and SM8550 ICE resource patches needed by the standalone Qualcomm ICE driver, including the iface-clock resume unwind fix. Enable block inline encryption, UFS crypto, and the Qualcomm ICE driver in the SM8550 kernel config.
Add the UFS core, qcom host, and QMP PHY patches needed for reliable suspend/resume relink on the SM8550 UFS host. The set covers non-MCQ PM completion draining, host-reset IRQ depth balance, hibern8 error propagation, auto-hibern8 versus clk-gating policy, no-retention PHY handling, and RX LineCfg control around link startup.
Add the TSENS and qcom-ipcc patches used by the SM8550 suspend path. The TSENS patch leaves AYN Thor uplow threshold IRQs as non-wakeup. Critical thermal wake remains enabled. The IPCC patch lets the PM core mask the parent IRQ during suspend instead of keeping it enabled with IRQF_NO_SUSPEND.
Default SM8550 devices to mem suspend and wire power, suspend, and lid handling through logind. Also set the UFS command timeout and deep sleep default on the SM8550 kernel command line.
24c94da to
abcc2bc
Compare
Contributor
Author
|
Just fixed line lengths in the commits |
jaewun
added a commit
to thorch-os/thorch
that referenced
this pull request
Jul 2, 2026
Port the final, hardware-validated SM8550 deep-suspend patch set from ROCKNIX/distribution#2952 (26 cumulative loaded-deep passes, 0 UFS errors): - Replace all overlapping UFS/tsens/ICE/ipcc patches with the PR's final revisions (byte-identical to the PR files). - 0005: reworked drain-relink-completions patch; ufshcd_relinking() now also gates the nosync IRQ disable, and the clk-gating hibern8-exit recovery runs inline via the poll timer. - 0006 (new): ICE core-clk unwind on iface-clk failure, split out of 0004 to match the PR's 0204/0206 split. - 0012: gate UFSHCD_QUIRK_BROKEN_AUTO_HIBERN8 on UFSHCD_CAP_HIBERN8_WITH_CLK_GATING instead of setting it unconditionally. - Drop 0008 (no-synchronize-irq host suspend): dropped from the PR after validation showed the disable_hardirq busy-abort branch never fires and the legacy path survived all loaded-deep cycles. - Drop 0010 (geni UART irq mask on suspend): dropped from the PR as conditional / not sufficient for the loaded long-dwell wedge. thorch-bsp: add ufshcd_core.uic_cmd_timeout=3000 to the ABL kernel cmdline to match the PR's EXTRA_CMDLINE (mem_sleep_default=deep already present). Kernel config (BLK_INLINE_ENCRYPTION/SCSI_UFS_CRYPTO/QCOM_INLINE_CRYPTO_ENGINE), the ICE dts patch, and the deep-only systemd sleep pin were already in sync.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR enables the
deepsuspend path for SM8550, with testing focused on AYN Thor.It's believed the main issue is the SM8550 UFS suspend/resume path. SM8550 UFS is marked
no_phy_retention, so the qcom UFS driver usesUFS_PM_LVL_5for system suspend: UFS powerdown with the link off. That means every deep resume does a cold UFS restore. On the non-MCQ path, relink completions can be missed or delayed under load if recovery depends only on the normal threaded IRQ path, so this adds the UFS PM/relink fixes needed to make that path reliable.This also includes related UFS qcom/PHY fixes around hibern8, clk-gating, and link startup. Those are for keeping runtime UFS power management consistent with the SM8550 no-retention PHY behavior and for avoiding cases where failed link transitions are treated as successful. There is likely more work that can be done here, and the patches were designed around real failures that I ran into while testing - it's 100% possible these are mitigations of a deeper underlying root cause that's evaded me so far.
The TSENS/IPCC wake changes are included so non-wake IRQs do not keep the system awake.
The ICE clock/resource patches and UFS inline crypto config are adjacent SM8550 platform enablement. The standalone Qualcomm ICE driver needs the SM8550 ICE clocks and power domain described correctly before UFS inline crypto can be enabled safely. This part was not proven necessary for deep suspend itself; although I'm continuing to test that, and will drop that from this PR if it doesn't prove itself required.
Testing
Built and tested on AYN Thor.
Ran repeated RTC-woken
deepsuspend/resume cycles, including loaded suspend tests with CPU and UFS activity before suspend. After each resume, storage health was checked:/storagestayed read-write, UFSsaved_err/saved_uic_errstayed0, UFS error counters stayed clean, write tests passed, and no emergency read-only remounts or UFS-110failures were seen in the passing runs.Test results
Deep suspend resumes successfully on the tested Thor setup. UFS recovers cleanly after resume.
One UFS host reset per deep resume is expected on this platform because system suspend uses LINK_OFF.
Additional Context
The UFS changes are split by area so review can focus on one behavior at a time.
s2idleis not the target path for this PR; this is focused ondeepsuspend. I expect we may be able to further reduce this PR and still have reliable suspend/resume. And I'll admit it feels like there's a missing piece to this puzzle, so keen to see what others can see, that I'm missing!AI Usage
Did you use AI tools to help write this code? Yes
AI tools were used during the investigation: organizing test notes, comparing candidate patches, reviewing logs, automating sleep tests, tracking A/B results, and cleaning up. The final patch selection was based on hardware testing results and manual review on AYN Thor.