On 05/10/2023 10:18, Maxime Ripard wrote:
Hi,
On Tue, Oct 03, 2023 at 04:22:45PM +0200, Jocelyn Falempe wrote:
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 89e2706cac56..e538c87116d3 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -43,6 +43,7 @@ struct dma_buf_attachment;
struct drm_display_mode;
struct drm_mode_create_dumb;
struct drm_printer;
+struct drm_scanout_buffer;
struct sg_table;
/**
@@ -408,6 +409,19 @@ struct drm_driver {
*/
void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
+ /**
+ * @get_scanout_buffer:
+ *
+ * Get the current scanout buffer, to display a panic message with drm_panic.
+ * It is called from a panic callback, and must follow its restrictions.
+ *
+ * Returns:
+ *
+ * Zero on success, negative errno on failure.
+ */
+ int (*get_scanout_buffer)(struct drm_device *dev,
+ struct drm_scanout_buffer *sb);
+
What is the format of that buffer? What is supposed to happen if the
planes / CRTC are setup in a way that is incompatible with the buffer
format?
Currently, it only supports linear format, either in system memory, or
iomem.
But really what is needed is the screen size, and a way to write pixels
to it.
For more complex GPU, I don't know if it's easier to reprogram the GPU
to linear format, or to add a simple "tiled" support to drm_panic.
What would you propose as a panic interface to handle those complex format ?
Sometime it's also just not possible to write pixels to the screen, like
if the panic occurs in the middle of suspend/resume, or during a
mode-setting, and the hardware state is broken. In this case it's ok to
return an error, and nothing will get displayed.
Best regards,
--
Jocelyn
I've said it in that other series, but I really think we should be
having a proper state on the side to deal with those properly.
Maxime
