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@xxxxxxxxxxx>
>>>
<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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
