Skip to content

SM8550: defer rsinput haptics playback out of atomic context - #3116

Merged
loki666 merged 1 commit into
ROCKNIX:nextfrom
xiaodoudou:sm8550-haptics-defer-playback
Aug 5, 2026
Merged

SM8550: defer rsinput haptics playback out of atomic context#3116
loki666 merged 1 commit into
ROCKNIX:nextfrom
xiaodoudou:sm8550-haptics-defer-playback

Conversation

@xiaodoudou

@xiaodoudou xiaodoudou commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Summary

  • What is the goal of this PR? Fix a crash in the rsinput force-feedback bridge that is reachable on stock builds: qcom_spmi_haptics_global_playback() is called from the rsinput FF callback, which runs below input_event() with the input device event lock held and interrupts disabled. It invokes haptics_erase() directly, which takes a mutex and synchronously cancels delayed work, so it can sleep: "BUG: scheduling while atomic" during game rumble. Every ingredient (1000/1002 qcom-haptics, 1003-rsinput-add-ff) is already on next, so any SM8550 device can hit this today in a rumble-heavy game.

The fix records the latest playback request atomically and applies it from a workqueue, serialises upload, playback and gain with a mutex in process context, and drains pending playback work before the haptics device suspends.

Credit: this was found, root-caused, fixed and hardware-validated by @gh123man in gh123man/armada-packages#1 while stress-testing the SM8550 deep-suspend series with active haptics. The commit carries his authorship; this PR only ports the patch into ROCKNIX's SM8550 patch set.

Testing

  • How was this tested? The patch applies cleanly to Linux 7.1.2 with the full SM8550 device patch set (verified against a clean tree, no fuzz, no offsets). Hardware validation is @gh123man's, on a Retroid Pocket 6 running the same downstream driver stack: repeated in-game deep-suspend cycles with active haptics, plus synthetic and real FF exercise in No Man's Sky, with no atomic-context warning or BUG after the fix (details in the Armada PR). Not yet device-tested on a ROCKNIX build; the bug itself is reproducible on stock with rumble-heavy games, no suspend involved.
  • Test results: see the validation section of Port ROCKNIX deep-sleep and charger-wake kernel fixes gh123man/armada-packages#1.

Additional Context

  • This is part of continuing the suspend/resume work from SM8550 deep suspend/resume #2954. That PR was closed over maintenance weight, so the continuation strategy is to shrink the eventual suspend PR to the minimum by landing everything that stands on its own first, the same shape as SM8550: mask the IPCC mailbox irq on suspend (parity with SM8750) #3115. This piece qualifies twice over: it fixes a stock-reachable crash with no suspend story needed, and it removes one patch from the future suspend series (the drain-before-suspend hunk only becomes active once real device suspend lands; it is inert under fake suspend).
  • Risk is contained: both touched drivers (qcom-hv-haptics, the rsinput bridge) are ROCKNIX-carried downstream code, not upstream kernel surface, and devices without rsinput force feedback see no behavior change. Playback submission moves to a workqueue, so rumble start/stop gains sub-millisecond scheduling latency; a sequence counter ensures the latest requested state always wins.

AI Usage

Did you use AI tools to help write this code? PARTIALLY

The fix was authored and hardware-validated by @gh123man in the Armada PR referenced above. AI tools were used to port the patch into ROCKNIX's SM8550 patch layout, verify it applies against 7.1.2, and draft this PR description.

@xiaodoudou
xiaodoudou force-pushed the sm8550-haptics-defer-playback branch from 8794088 to 4996fdb Compare August 5, 2026 03:18
@xiaodoudou
xiaodoudou marked this pull request as draft August 5, 2026 03:19
@xiaodoudou

xiaodoudou commented Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Marking as draft while I validate this on device: I will run similar tests on ROCKNIX with Steam and rumble-heavy games, first without the patch to confirm the atomic-context issue occurs there too, then with it to confirm it no longer does.

@gh123man

gh123man commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Glad you found this fix on my branch.
Can confirm this fix is validated on real hardware. The other patches on my branch are still in development. Am planning to try to upstream them to rocknix if I end up stabilizing them.

@xiaodoudou

xiaodoudou commented Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Glad you found this fix on my branch. Can confirm this fix is validated on real hardware. The other patches on my branch are still in development. Am planning to try to upstream them to rocknix if I end up stabilizing them.

Planned to reproduce it and test it againts fresh next branch + this PR to see correction.

I am currently working on continuation of the suspend, that why I spot this commit as detached from it ;-).

@xiaodoudou

xiaodoudou commented Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Tested this on my AYN Odin 2.

First try was the honest way: installed No Man's Sky on stock 20260801 and
played, since that's where @gh123man hit it. Two problems: the Odin 2 is
frankly too weak to run NMS properly, and after a laggy session the log
analysis showed nothing. The shipped kernel has CONFIG_DEBUG_ATOMIC_SLEEP
off, so the BUG only fires when the path actually sleeps, and casual rumble
apparently doesn't create enough pressure.

So I wrote two small python scripts to do it properly:

  • a dumb hammer that loops play/stop on the FF effect at a fixed rate
  • a "haptic game simulation": random gunfire bursts, damage hits and
    explosions retuning the live effect in place (EVIOCSFF on a playing
    effect, the way SDL games do), FF_GAIN changes, weapon switches that
    erase and re-upload, random lulls

(InputPlumber hides the physical gamepad node, so it has to be stopped to
reach /dev/input/eventX directly.)

On stock 20260801 that changes everything: first
BUG: scheduling while atomic within a minute, 122 of them across two
sessions, and the game simulation triggers it alone, single process, no
tricks. Two distinct traces:

mutex_lock
haptics_load_constant_effect
haptics_upload_effect
qcom_spmi_haptics_global_upload
rsinput_rumble_upload
input_ff_upload
evdev_do_ioctl

schedule_timeout
cancel_delayed_work_sync
haptics_upload_effect
qcom_spmi_haptics_global_upload
rsinput_rumble_upload
input_ff_upload
evdev_do_ioctl

First one is the upload taking the driver mutex under the bridge's own
spin_lock_irq, second is an in-place retune waiting on the queued stop
work. I also saw preempt_count corruption down to a 0xffffffff
underflow. Nastiest part: the device just keeps running afterwards, so this
is silent kernel state corruption, not a visible crash.

With the patch (current next + this PR, same device, same scripts,
same seed): game simulation ran 2676 shots / 204 hits, plus 62k combined
hammer cycles across the gamepad and haptics nodes. Zero BUG, Oops or
atomic warning in the log.

Happy to share the scripts if anyone wants to reproduce.

@xiaodoudou
xiaodoudou marked this pull request as ready for review August 5, 2026 06:38
@gh123man @xiaodoudou
SM8550: defer rsinput haptics playback out of atomic context
6c25748 
qcom_spmi_haptics_global_playback() is reached from the rsinput
force-feedback callback, which runs below input_event() with the input
device event lock held and interrupts disabled. It calls
haptics_erase() directly, which takes a mutex and synchronously
cancels delayed work, so it can sleep: "BUG: scheduling while atomic"
during game rumble.

Record the latest request atomically and apply it from a workqueue,
serialise upload, playback and gain with a mutex in process context,
and drain both the playback work and the delayed stop work before the
haptics device suspends.

Ported from gh123man/armada-packages#1, where it was found,
root-caused and validated on hardware while testing the SM8550
deep-suspend series. Not a suspend fix in itself: the crash is
reachable on any device carrying 1003-rsinput-add-ff.patch whenever a
game rumbles, no suspend involved.
@xiaodoudou
xiaodoudou force-pushed the sm8550-haptics-defer-playback branch from 4996fdb to 6c25748 Compare August 5, 2026 06:39
loki666
loki666 approved these changes Aug 5, 2026
View reviewed changes

@loki666 loki666 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@loki666
loki666 added this pull request to the merge queue Aug 5, 2026
Merged via the queue into ROCKNIX:next with commit 41ff21d Aug 5, 2026
2 checks passed
@xiaodoudou xiaodoudou mentioned this pull request Aug 6, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@loki666 loki666 loki666 approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@xiaodoudou @gh123man @loki666