Skip to content

Mask the IPCC mailbox IRQ on suspend for SM8550 too - #27

Merged
virtudude merged 1 commit into
armada-os:mainfrom
jesherman:fix/sm8550-ipcc-mask-on-suspend
Aug 5, 2026
Merged

Mask the IPCC mailbox IRQ on suspend for SM8550 too#27
virtudude merged 1 commit into
armada-os:mainfrom
jesherman:fix/sm8550-ipcc-mask-on-suspend

Conversation

@jesherman

@jesherman jesherman commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Extends the existing IPCC suspend fix to cover SM8550. Ports ROCKNIX #3115 (merged).

What

0504 drops IRQF_NO_SUSPEND from the IPCC summary interrupt so it can be masked across suspend — but only when the node is "qcom,sm8750-ipcc". SM8550's node is "qcom,sm8550-ipcc", so it still requests the irq with IRQF_NO_SUSPEND and it is never masked.

This adds SM8550 to that check. Every other SoC keeps IRQF_NO_SUSPEND and is unaffected.

Why

On SM8550 the ADSP charger firmware pushes an unsolicited BATTMGR_NOTIFICATION about half a second after suspend entry. With the mailbox irq unmasked, that notification wakes the SoC straight back up — upstream identifies it as the single biggest blocker to SM8550 staying asleep.

Any future SM8550 suspend work needs this regardless of what else it does, so it is worth having in place early.

Downsides

None that I can see:

  • No behavior change on current builds. Every SM8550 device runs ARMADA_SUSPEND_MODE=fake, so the system never reaches a real suspend where the flag applies.
  • No new maintenance surface. This widens a condition in a patch already carried here; it does not add a patch or touch a new file.
  • Safe to drop later. If a kernel bump ever makes it fail to apply, removing it just restores today's behavior.

Testing

Built against 7.1.5 on an AYANEO Pocket EVO: 120 patches applied, 0 failed, drivers/mailbox/qcom-ipcc.o compiles clean.

The wake behavior itself can't be verified on a shipping build, since SM8550 stays on fake suspend and the code path isn't reached. Upstream verified it on a Retroid Pocket 6.

🤖 Generated with Claude Code

0504 currently drops IRQF_NO_SUSPEND only when the IPCC node is
"qcom,sm8750-ipcc", so SM8550 still requests the summary interrupt with
IRQF_NO_SUSPEND and it is never masked across suspend.

On SM8550 the ADSP charger firmware pushes an unsolicited
BATTMGR_NOTIFICATION roughly half a second after suspend entry. With the
mailbox irq unmasked that notification pulls the SoC straight back out,
which upstream ROCKNIX identifies as the single biggest blocker to SM8550
staying asleep.

Extend the existing compatible check to cover "qcom,sm8550-ipcc". Every
other SoC keeps IRQF_NO_SUSPEND, so established behavior on the shared
driver is unchanged.

This is the same fix ROCKNIX merged in PR #3115, which removes the flag
unconditionally; keeping armada's compatible gate preserves the existing
caution for SM8250 and SM8650.

No behavior change on current builds: every SM8550 device here runs
ARMADA_SUSPEND_MODE=fake, so the system never reaches a real suspend where
the flag matters. This is groundwork for when SM8550 suspend is enabled.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@virtudude
virtudude merged commit 5b9e655 into armada-os:main Aug 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants