Repository navigation
Conversation
A472 with the hardware-power selector stops the J514S panel's display controller. The controller still accepts a present while it is off, but it never completes it. Nothing kept presents away from it: the A472 off is queued after the blank drains, and any present admitted later went out to the stopped controller. Lid-close sleep did that. The DRM suspend helper blanks the panel and turns the controller off, and a present admitted after it (swap 1307 in the captured log) was accepted and then held the IOMFB queue. The sleep drain reported "display updates still pending at suspend", the mailbox hold could not settle, and at resume the A472 on queued behind the present: "display controller on failed: -110". Ten seconds of running time after the present started, the queue timeout declared the coprocessor crashed, and every later atomic commit failed with EINVAL. The panel stayed dark until a reboot. DPMS off never showed it, as nothing presents after a compositor's DPMS off. Hold the panel's presents from just before the A472 off is queued until the A472 on succeeds. A present admitted earlier keeps its place ahead of the A472 off and goes out to a running controller. Admission refuses a held present as it refuses a paused one: an atomic commit completes with a synthetic vblank, and a brightness level stays pending for the backlight restore that follows the A472 on. The hold is separate from the presentation pause, which the mailbox hold for system sleep releases at resume, before DRM resume turns the controller back on. A failed A472 on keeps the hold, and the next power-on tries again. The sleep drain no longer waits for a backlight level that a panel whose controller is off cannot take; the restore presents it. Add KUnit cases for the admission, the order around the A472 off, and the hold outlasting the presentation pause. Signed-off-by: Jvaxx <82868042+Jvaxx@users.noreply.github.com>
Member
|
Fixed in omacom/linux-aurora#274 |
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.
This fixes a lid-close resume failure I hit with #380 on a J514S (14" M3 Pro, os-fw 14.7) with the default
panel_hw_off=Y. It is stacked on #380 as a single commit, so you can squash it into that branch or rework it however you prefer.Unpatched #380: the first lid-close resume left the panel dark and the DCP marked as crashed, and only a reboot recovered it. With
panel_hw_off=Nit was fine.A present admitted after the A472 off (swap 1307) reaches the stopped controller, which accepts it but never completes it. That blocks the IOMFB queue, so the A472 on at resume times out behind it and the queue timeout marks the DCP crashed. The commit holds the panel's presents from just before the A472 off until an A472 on succeeds. The commit message has the details.
Tested with the fix (
Y, on #35879d6375f, m1n197820568, Mesa #23, Hyprland 0.56; the tested module also carried a local logging-only patch):energy_now, one ~1 h run each: J514S (MacBook Pro M3 Pro): bring-up, DCP displays and G15 GPU #358 2.01 W, M3 Pro 1.4W sleep #380N1.62 W,Y+ fix 0.54 W. TheN→Ystep (≈ 1.08 W) matches your 1.09 W. One overnight run came out at 1.07 W, which I can't explain yet.Not verified:
apple-dcp-panel-holdhas only been compiled, not run.I'm happy to share the logs or a diagnostics patch, or to test changes.