Repository navigation
drm/vc4: Wire up the panic scanout buffer - #7636
Merged
Merged
Conversation
Collaborator
Author
|
@6by9 I wanted to test |
Contributor
|
Comparing against b558053 that added drm_panic support for rcar-du, that only adds get_scanout_buffer for the primary plane, not overlays or cursors. Seeing as that is all 4 users of |
vc4 provided no get_scanout_buffer(), so drm_panic_register() skipped every plane and nothing was drawn when the kernel panicked - and with CONFIG_DRM_PANIC_DEBUG the dri/N/drm_panic_plane_x files never appeared either. Framebuffers are drm_gem_dma objects, so the generic DMA helper does the job: it hands the panic handler the already mapped CPU address, without vmapping in panic context. Imported dmabufs and non-linear modifiers are rejected by the helper, so a compositor's buffers are still skipped, but the fbdev console - the case that matters when the machine dies - works. Only the primary planes get it, as every other user of drm_fb_dma_get_scanout_buffer() does, which costs a second copy of the helper funcs per generation. Tested on a Pi 500: one plane per CRTC registers, and a panic (as well as the debugfs trigger) paints the panic screen, including the full backtrace with drm.panic_screen=kmsg. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
force-pushed
the
drmpanic
branch
from
September 21, 2026 16:01
76f8ad9 to
7183125
Compare
Collaborator
Author
|
Updated to match other drivers. |
6by9
approved these changes
Sep 21, 2026
pelwell
approved these changes
Sep 21, 2026
popcornmix
added a commit
to raspberrypi/rpi-firmware
that referenced
this pull request
Sep 22, 2026
kernel: drm/vc4: Wire up the panic scanout buffer See: raspberrypi/linux#7636
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Sep 29, 2026
kernel: drm/vc4: Wire up the panic scanout buffer See: raspberrypi/linux#7636
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.
vc4 provided no get_scanout_buffer(), so drm_panic_register() skipped every plane and nothing was drawn when the kernel panicked - and with CONFIG_DRM_PANIC_DEBUG the dri/N/drm_panic_plane_x files never appeared either.
Framebuffers are drm_gem_dma objects, so the generic DMA helper does the job: it hands the panic handler the already mapped CPU address, without vmapping in panic context. Imported dmabufs and non-linear modifiers are rejected by the helper, so a compositor's buffers are still skipped, but the fbdev console - the case that matters when the machine dies - works.
Tested on a Pi 500: 56 planes register, and a panic (as well as the debugfs trigger) paints the panic screen, including the full backtrace with drm.panic_screen=kmsg.