Den 12.03.2019 11.58, skrev Daniel Vetter:
On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
Den 11.03.2019 20.23, skrev Daniel Vetter:
On Mon, Mar 11, 2019 at 06:42:16PM +0100, 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@tronnes.org
<snip>
+static void drm_panic_kmsg_render_screen(struct drm_plane *plane,
struct kmsg_dumper *dumper)+{
- struct drm_framebuffer *fb = plane->state->fb;
- bool first_iteration = true;
- struct drm_panic_ctx ctx;
- static char text[1024];
- size_t len;
- ctx.vmap = fb->funcs->panic_vmap(fb);
- /* Print some info when testing */
- if (dumper->max_reason == KMSG_DUMP_OOPS) {
struct drm_format_name_buf format_name;pr_info("%s: [FB:%d] %ux%u format=%s vmap=%p\n",__func__, fb->base.id, fb->width, fb->height,drm_get_format_name(fb->format->format, &format_name),ctx.vmap);- }
- if (!ctx.vmap)
return;For some framebuffers it might be useful to not require vmap, but instead have some page-by-page kind of access helper. Since preemptively setting up a vmap for all the non-continous buffers is a bit much, and we really can't set up the vmap in the panic handler.
Maybe we should call this panic_prepare/panic_finish and s/vmap/cookie/, to make it entirely opaque?
But a bit overengineering perhaps :-)
I guess i915 wants something else than vmap, but I have no idea how a page-by-page solution is to be implemented.
i915 should be mostly fine, since we have a GTT for remapping and can make it look continuous. It might not be in the part of the GTT accessible by the cpu though.
Wrt implementation: My idea would be to extract the pixel writing function and export it to drivers. The driver would then implement a ->panic_draw_xy function which looks up the right page, computes it address, computes the x/y offset within (taking into account tiling and stuff like that), and then uses the helper function to draw the right pixel value for the format at the given address.
That's why I suggested that drivers need to either implement ->panic_prepare or ->panic_draw_xy. Since for this approach you might not need a ->panic_prepare/cleanup implementation, since it's all done in ->panic_draw_xy on a pixel-by-pixel basis.
When we get bootsplash, we will at least have a kernel address during that phase for all drivers supporting it.
Hm, not following what you mean here. Why is bootsplash special?
Special in the sense that it's framebuffer will be linear and already have a virtual address for its backing buffer since that's a prerequisite for it to render the splash image.
Noralf.