From: John Ogness <john.ogness@linutronix.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: daniel.vetter@ffwll.ch,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
dri-devel@lists.freedesktop.org,
"Ahmed S. Darwish" <darwish.07@gmail.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 1/3] drm: Add support for panic message output
Date: Thu, 14 Mar 2019 10:52:08 +0100 [thread overview]
Message-ID: <87y35hlr5j.fsf@linutronix.de> (raw)
In-Reply-To: <875zsln642.fsf@linutronix.de> (John Ogness's message of "Thu, 14 Mar 2019 10:43:41 +0100")
On 2019-03-14, John Ogness <john.ogness@linutronix.de> wrote:
> On 2019-03-14, Daniel Vetter <daniel@ffwll.ch> wrote:
>> That's why we came up with the trylock + immediate bail out design if
>> that fails. Plus really only render the oops int whatever is the
>> current display buffer, so that we don't have to do any hw
>> programming at all.
>
> I think this is your best option. The real work will be identifying
> any/all spin locking that currently exists. For all of those, the code
> needs to change to:
>
> 1. trylock if oops_in_progress, otherwise spinlock
On second thought, you shouldn't use oops_in_progress. It would be
better if DRM had its own flag to signify that it is currently being
used in kmsg_dump context.
> 2. if trylock fails, the code must have a sane failure
>
> The 2nd point will be the difficult one. For example, you may have
> functions without a return value taking spinlocks. But now those
> functions could fail.
John Ogness
_______________________________________________
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-14 9:52 UTC|newest]
Thread overview: 57+ 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 [this message]
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 ` [Intel-gfx] " Christian König
2019-03-13 16:16 ` 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-12 9:09 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-03-12 9:12 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-03-12 9:50 ` ✓ Fi.CI.BAT: success " Patchwork
2019-03-12 10:12 ` ✗ Fi.CI.BAT: failure for drm: Add panic handling (rev2) Patchwork
2019-03-17 23:06 ` [PATCH v2 0/3] drm: Add panic handling 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=87y35hlr5j.fsf@linutronix.de \
--to=john.ogness@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=darwish.07@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/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