From: Daniel Vetter <daniel@ffwll.ch>
To: John Ogness <john.ogness@linutronix.de>
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: Fri, 15 Mar 2019 11:56:43 +0100 [thread overview]
Message-ID: <20190315105643.GW2665@phenom.ffwll.local> (raw)
In-Reply-To: <87y35hlr5j.fsf@linutronix.de>
On Thu, Mar 14, 2019 at 10:52:08AM +0100, John Ogness wrote:
> 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.
We use oops_in_progress because the fbcon design is a terrible layer cake.
I agree that for the new code we shouldn't use it: New code paths that do
trylock only.
> > 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.
Nah, imo no code reuse for the oops path. If you do that you sooner or
later end up pulling in the 100kloc of modeset code, and we've been there.
Doesn't work. New, absolutely minimal oops code, with as little of it
shared with normal kms code.
That's also why we absolutely have to be able to test this stuff without a
real oops.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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-15 10:56 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
2019-03-15 10:56 ` Daniel Vetter [this message]
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=20190315105643.GW2665@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=bigeasy@linutronix.de \
--cc=daniel.vetter@ffwll.ch \
--cc=darwish.07@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=john.ogness@linutronix.de \
/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