[PATCH v2 1/3] drm: Add support for panic message output

[Michel Dänzer]

On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper iterates
> over each DRM device and it's crtc's to find suitable framebuffers.
> 
> All the other dumpers are run before this one except mtdoops.
> Only atomic drivers are supported.
> 
> Signed-off-by: Noralf Trønnes <noralf at tronnes.org>
> ---
>  [...]
> 
> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> index f0b34c977ec5..f3274798ecfe 100644
> --- a/include/drm/drm_framebuffer.h
> +++ b/include/drm/drm_framebuffer.h
> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>  		     struct drm_file *file_priv, unsigned flags,
>  		     unsigned color, struct drm_clip_rect *clips,
>  		     unsigned num_clips);
> +
> +	/**
> +	 * @panic_vmap:
> +	 *
> +	 * Optional callback for panic handling.
> +	 *
> +	 * For vmapping the selected framebuffer in a panic context. Must
> +	 * be super careful about locking (only trylocking allowed).
> +	 *
> +	 * RETURNS:
> +	 *
> +	 * NULL if it didn't work out, otherwise an opaque cookie which is
> +	 * passed to @panic_draw_xy. It can be anything: vmap area, structure
> +	 * with more details, just a few flags, ...
> +	 */
> +	void *(*panic_vmap)(struct drm_framebuffer *fb);

FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
drivers:

Framebuffers are normally tiled, writing to them with the CPU results in
garbled output.

With a discrete GPU having a large amount of VRAM, the framebuffer may
not be directly CPU accessible at all.


There would need to be a mechanism for switching scanout to a linear,
CPU accessible framebuffer.


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer