From: John Ogness <john.ogness@linutronix.de>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
DRI Development <dri-devel@lists.freedesktop.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Daniel Vetter <daniel.vetter@intel.com>,
Jocelyn Falempe <jfalempe@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Lukas Wunner <lukas@wunner.de>, Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [RFC] drm/panic: Add drm panic locking
Date: Tue, 05 Mar 2024 09:20:04 +0106 [thread overview]
Message-ID: <87o7bt6qpf.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20240301103903.2538083-1-daniel.vetter@ffwll.ch>
Hi Daniel,
Great to see this moving forward!
On 2024-03-01, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> But for the initial cut of a drm panic printing support I don't think
> we need that, because the critical sections are extremely small and
> only happen once per display refresh. So generally just 60 tiny locked
> sections per second, which is nothing compared to a serial console
> running a 115kbaud doing really slow mmio writes for each byte. So for
> now the raw spintrylock in drm panic notifier callback should be good
> enough.
Is there a reason you do not use the irqsave/irqrestore variants? By
leaving interrupts enabled, there is the risk that a panic from any
interrupt handler may block the drm panic handler.
John Ogness
next prev parent reply other threads:[~2024-03-05 8:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 10:05 [RFC] drm/panic: Add drm panic locking Daniel Vetter
2024-03-01 10:39 ` Daniel Vetter
2024-03-01 13:03 ` Jocelyn Falempe
2024-03-14 14:09 ` Daniel Vetter
2024-03-05 8:14 ` John Ogness [this message]
2024-03-14 14:06 ` 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=87o7bt6qpf.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jfalempe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tzimmermann@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.