SM8550 deep suspend/resume#2954
Conversation
|
awesome! I can help testing if you provide steps to test |
|
Thanks for your work! Already testing on an Odin2 portal — the suspend patch works so far, going to run a few more tests (repeated suspend/resume, wake stability etc). |
|
Works really well for me as well RP6. just once after resuming the device did not recognize the input but after sleeping and resuming again it worked. I haven't been able to reproduce it ever since. EDIT: I lost input recognition again, after suspending and resuming again it's restored. there must be some kind of race condition |
|
@shuuri-labs can you rebase your branch on origin/next? |
7921026 to
68626b6
Compare
aa0946e to
8752710
Compare
|
I'm pretty sure we can drop the ICE patches to simplify things here, they were introduced early on in testing as a correctness patch but in retrospect they dont appear load bearing. I also ran into the controller issues mentioned above and it seems like the controller continues sending interrupts, and storms a whole lot of interupts during wake and the irq eventually gets disabled as "nobody cared". Might be able to replicate by pressing buttons during suspend/wake? Will dig up my old notes on that when I get home next week. |
shuuri-labs
changed the title
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. [shuuri-labs: rebased 0201 hunk 9 for 7.1.2, ufshcd_intr() gained the active_uic_cmd thread-handoff condition upstream]
Add the TSENS patch used by the SM8550 suspend path. The TSENS patch leaves AYN Thor uplow threshold IRQs as non-wakeup. Critical thermal wake remains enabled. [shuuri-labs: split the IPCC patch into its own commit to restore its original authorship; it was first added in an earlier revision of this PR]
The ADSP charger firmware pushes an unsolicited BATTMGR_NOTIFICATION (opcode 0x7) about 0.5s after suspend entry. It rings the IPCC mailbox irq, which upstream is IRQF_NO_SUSPEND, so it is never masked and wakes the device every few minutes. Drop IRQF_NO_SUSPEND so the mailbox irq is masked across system suspend. Lifted from ROCKNIX SM8750 (AYN Odin 3), which shares the battmgr/pmic_glink charger model and sleeps cleanly.
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.
8752710 to
af78668
Compare
|
@jaewun sweet, thanks for letting me know. I've dropped the ICE set from the branch (the crypto configs went with it, so this PR no longer touches the kernel config at all). As for the controller - I originally carried your MCU suspend/resume + geni UART mask patches and that's mostly what I've tested, so it makes sense that I haven't really seen this issue yet. I removed them when rebasing off your clean set, so at some point I can run the buttons-during-suspend repro on the RP6 and report what pm_wakeup_irq and the irq counters show with the new set. Depending on the results, we can either re-add your older patches or something more targeted (from your your notes) EDIT: actually, since @dcu reported facing the controller issue before my rebase, the now dropped patches probably didn't help. I'll do my investigation anyway, but probably we'll just wait for your notes for a fix :) |
I have not seen those issues again though, not sure what changed or it is just pure luck |
jaewun's patch scoped the of_machine_is_compatible() check to ayn,thor. RP6's root compatible is "retroidpocket,rp6", "qcom,qcs8550", "qcom,sm8550" with no ayn,thor entry, so the fix silently did nothing there. Broaden the check to the SoC-level compatible so it covers every SM8550 board.
af78668 to
c0a0434
Compare
5 participants
Summary
This PR enables the
deepsuspend path (S2RAM) for SM8550, tested on the Retroid Pocket 6.It is @jaewun's #2952 series, cherry-picked with authorship intact and rebased onto current
next(7.1.2). Rebase adjustments, noted in the commit messages:ufshcd_intr()gained theactive_uic_cmdthread-handoff condition upstreamSo this is the same suspend content as #2952, in a form that merges cleanly on
nexttoday.Two commits are mine:
BATTMGR_NOTIFICATION(opcode 0x7) about 0.5s after suspend entry, and withIRQF_NO_SUSPENDthe mailbox irq is never masked, so the device wakes itself every few minutes. Lifted from ROCKNIX's SM8750 patch, which shares the battmgr/pmic_glink charger model.ayn,thortoqcom,sm8550. The RP6's compatible list has noayn,thorentry, so the Thor-only check silently does nothing there and the TSENS threshold IRQs keep waking the device. The SoC-level compatible covers every SM8550 board, Thor included. Critical thermal wake stays enabled.s2idlestays disabled (mem_sleep_default=deepplusSuspendStatepinned tomem): a failed deep attempt that falls through to s2idle has wedged SM8550 devices in testing, so a failed deep should no-op instead.Compared to the previous revision of this PR: the old patch lineage is replaced by the #2952 versions (which add the mphy hibern8-park and RX LineCfg fixes), and the rsinput MCU suspend/resume and geni UART patches are dropped to match #2952. Given the controller irq-storm behaviour jaewun describes in the comments, those three are the likely re-add candidates once we have his notes and an RP6 repro; keeping them out for now so the fix can be evidence-based.
Testing
Built and tested on the Retroid Pocket 6: repeated RTC-woken
deepsuspend/resume cycles, including longer unattended runs. Wake sources checked via/sys/power/pm_wakeup_irq(withPM_SLEEP_DEBUGenabled in my local builds) and/sys/kernel/debug/wakeup_sources, real time-in-suspend confirmed viaCLOCK_BOOTTIMEvsCLOCK_MONOTONICdrift.Note: that testing was against the previous revision of this branch. The kernel patches here are byte-identical to what I build daily against stock 7.1.2, but a full rebuild and retest of this exact set on the RP6 is still to come, including the buttons-during-suspend controller repro. I'll report back here.
Thor coverage is jaewun's testing in #2952.
Test results
Deep suspend resumes reliably on the tested RP6 setup with no self-wakes. Before the IPCC fix the device could not stay asleep past 5 to 10 minutes; with it, clean ~14 minute RTC-bounded suspends with matching boottime drift. 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
This PR and #2952 are the same series. The difference is the rebase onto current
next, the ICE drop, and the two RP6-facing commits. Happy to fold this into #2952 instead if that's preferred.AI Usage
Did you use AI tools to help write this code? Yes.
AI tools were used during the investigation and packaging: correlating wakeup-source and suspend-stat logs to pin the wake to the opcode 0x7 IPCC push, comparing candidate patches across the SM8550 and SM8650 trees, and assembling this branch. The IPCC fix itself is lifted verbatim from ROCKNIX's SM8750 patch, and the final selection was validated by hardware testing on the RP6.