Hi Jocelyn
Am 20.08.26 um 19:49 schrieb Jocelyn Falempe:
On 18/08/2026 14:27, Thomas Zimmermann wrote:
Split DRM's current panic handling into a core and a helper module.
The core is still part of DRM's core library. The panic helpers are
part of DRM's KMS helper module (for now).
The motivation behind this series is to get panic handling's drawing
code out of the DRM core. At some point it should share a single
module with DRM's other drawing and format conversion.
With the series applied, panic hanlding follows DRM's established
design pattern of having a DRM core interface with an dedicated
implementation in each driver. Drivers share common code in helper
modules. For panic handling, the DRM core still contains the panic
entry points, the parameters and the debugfs interface. All drawing
is now located in the panic helpers.
Patches 1 to 4 improve several issues in the current panic code. It
makes sense to fix them before moving the core around.
Patches 5 to 8 put handling of all panic state and locking into a
single place, drm_panic_display_panic_screen(). It is maintained by
panic handling's DRM core code. This also enables the test cases to
work more independently from the kernel's configuration.
Patches 9 to 11 split the panic-handling code into the core and panic
helpers. The former maintain all state, locking and public interfaces.
The latter handles drawing and details of the involved framebuffers.
DRM devices that offer panic handling provide a single callback, struct
drm_plane_funcs.display_panic_screen. A new initializer macro makes it
point to the existing panic-drawing implementation. Hence there's no
change in features or functionality. If panic handling is configured
off, it all clears out to NULL.
Patch 12 reworks the test cases slighly, so that they can be build as
a separate module. Do 'modprobe drm_panic_helper_test' to run them.
Tested under bochs with debugfs and test cases.
Overall the series looks good to me, and I like the split between the
helper and the core.
I would just drop the first two patches, as I don't see much
difference between static allocation or kmalloc() at init, and I think
that memset() the buffers to 0 is not useful in this case.
Ok. Geert also expressed a dislike for these changes.
I have a number of changes done from the Sashiko review and will post an
update to the series early next week.
Thanks for reviewing.
Best regards
Thomas
Best regards,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
