From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
christian.koenig@amd.com,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Harry Wentland" <harry.wentland@amd.com>,
"Nicholas Kazlauskas" <nicholas.kazlauskas@amd.com>
Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, darwish.07@gmail.com
Subject: Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
Date: Wed, 13 Mar 2019 16:54:50 +0100 [thread overview]
Message-ID: <76f769e5-fb95-2cdd-60fc-3e7286cf313f@gmail.com> (raw)
In-Reply-To: <617c0977-940f-c324-2b86-9a873c8ced28@daenzer.net>
Am 13.03.19 um 16:38 schrieb Michel Dänzer:
> On 2019-03-13 2:37 p.m., Christian König wrote:
>> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
>>> On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
>>>> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
>>>>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>>>>>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>>>>>>> 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@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.
>>>>>>>
>>>>> In which case the driver needs to support the ->panic_draw_xy callback,
>>>>> or maybe it's possible to make a generic helper for tiled buffers.
>>>> I'm afraid that won't help, at least not without porting big chunks of
>>>> https://gitlab.freedesktop.org/mesa/mesa/tree/master/src/amd/addrlib
>>>> into the kernel, none of which will be used for anything else.
>>>>
>>>>
>>>>>>> There would need to be a mechanism for switching scanout to a linear,
>>>>>>> CPU accessible framebuffer.
>>>>>> I suppose panic_vmap() could just provide a linear temp buffer
>>>>>> to the panic handler, and panic_unmap() could copy the contents
>>>>>> over to the real fb.
>>>> Copy how? Using a GPU engine?
>>> CPU maybe? Though I suppose that won't work if the buffer isn't CPU
>>> accesible :/
>> Well we do have a debug path for accessing invisible memory with the CPU.
>>
>> E.g. three registers: DATA and auto increment OFFSET_LO/HI. So you can
>> just read/write DATA over and over again if you want to access some memory.
> Right. I assume that'll be very slow, but I guess it could do when the
> memory isn't directly CPU accessible.
Just made a quick test and reading 33423360 bytes (4096x2040x4) using
that interfaces takes about 13 seconds.
IIRC we don't use the auto increment optimization yet, so that can
probably be improved by a factor of 3 or more.
>> But turning of tilling etc is still extremely tricky when the system is
>> already unstable.
> Maybe we could add a little hook to the display code, which just
> disables tiling for scanout and maybe disables non-primary planes, but
> doesn't touch anything else. Harry / Nicholas, does that seem feasible?
>
>
> I'm coming around from "this is never going to work" to "it might
> actually work" with our hardware...
Yeah, agree. It's a bit tricky, but doable.
Takeaway for Noralf is that this whole vmap on panic won't even remotely
work. We need to get the data byte by byte without a page mapping if
that is ever going to fly.
Christian.
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-03-13 15:54 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-11 17:42 [PATCH v2 0/3] drm: Add panic handling Noralf Trønnes
2019-03-11 17:42 ` [PATCH v2 1/3] drm: Add support for panic message output Noralf Trønnes
2019-03-11 19:23 ` Daniel Vetter
2019-03-11 19:29 ` Daniel Vetter
2019-03-11 22:40 ` Noralf Trønnes
2019-03-12 9:53 ` Daniel Vetter
2019-03-12 9:59 ` Daniel Vetter
2019-03-11 22:33 ` Noralf Trønnes
2019-03-12 10:58 ` Daniel Vetter
2019-03-12 13:29 ` Noralf Trønnes
2019-03-13 3:53 ` Ahmed S. Darwish
2019-03-12 22:13 ` Ahmed S. Darwish
2019-03-13 7:49 ` John Ogness
2019-03-13 8:37 ` Daniel Vetter
2019-03-14 2:51 ` Ahmed S. Darwish
2019-03-14 9:32 ` Daniel Vetter
2019-03-14 9:43 ` John Ogness
2019-03-14 9:52 ` John Ogness
2019-03-15 10:56 ` Daniel Vetter
2019-03-13 8:35 ` Daniel Vetter
2019-03-14 4:45 ` Ahmed S. Darwish
2019-03-14 9:35 ` Daniel Vetter
2019-03-13 10:24 ` Noralf Trønnes
2019-03-13 4:05 ` Ahmed S. Darwish
2019-03-11 19:55 ` Sam Ravnborg
2019-03-12 10:47 ` Michel Dänzer
2019-03-12 16:17 ` [Intel-gfx] " Ville Syrjälä
2019-03-12 17:15 ` Noralf Trønnes
2019-03-12 17:25 ` Ville Syrjälä
2019-03-12 17:37 ` Noralf Trønnes
2019-03-12 17:44 ` Noralf Trønnes
2019-03-12 18:02 ` [Intel-gfx] " Ville Syrjälä
2019-03-13 8:29 ` Christian König
2019-03-13 8:43 ` [Intel-gfx] " Daniel Vetter
2019-03-13 9:35 ` Michel Dänzer
2019-03-13 13:31 ` [Intel-gfx] " Ville Syrjälä
2019-03-13 13:37 ` Christian König
2019-03-13 15:38 ` Michel Dänzer
2019-03-13 15:54 ` Christian König [this message]
2019-03-13 16:16 ` [Intel-gfx] " Kazlauskas, Nicholas
2019-03-13 17:30 ` Koenig, Christian
2019-03-13 17:33 ` Michel Dänzer
2019-03-13 17:41 ` Kazlauskas, Nicholas
2019-03-14 9:50 ` Daniel Vetter
2019-03-14 12:44 ` Kazlauskas, Nicholas
2019-03-15 10:58 ` [Intel-gfx] " Daniel Vetter
2019-03-13 17:52 ` Koenig, Christian
2019-03-14 9:40 ` [Intel-gfx] " Daniel Vetter
2019-03-11 17:42 ` [PATCH v2 2/3] drm/cma-helper: Add support for panic screen Noralf Trønnes
2019-03-11 17:42 ` [PATCH v2 3/3] drm/vc4: Support " Noralf Trønnes
2019-03-11 18:53 ` [PATCH v2 0/3] drm: Add panic handling Daniel Vetter
2019-03-17 23:06 ` Ahmed S. Darwish
2019-03-25 8:42 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76f769e5-fb95-2cdd-60fc-3e7286cf313f@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=darwish.07@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=michel@daenzer.net \
--cc=nicholas.kazlauskas@amd.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).