From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Takashi Iwai <tiwai@suse.de>,
dri-devel <dri-devel@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
David Herrmann <dh.herrmann@gmail.com>
Subject: Re: Atomicity in KMS panic notifier
Date: Wed, 7 May 2014 17:15:23 +0100 [thread overview]
Message-ID: <20140507171523.48990630@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <CAKMK7uHcYvuViEeyxLc75+kMVPPaKMr8svJQysk124--cjGL+g@mail.gmail.com>
> Imo trying to fix the current mess and making ->set_config work in
> atomic contexts is pointless. drm_can_sleep is trying to make that
> possible in some ways, and it's horrible since using it means
> busy-loops in atomic contexts outside of panic handlers won't get
> reported any more. Also the interactions with the console_lock (which
> due to some bonghits is protecting almost everything in fbcon/fbdev
> nowadays) would also be almost completely removed.
Unfortunately years ago some Finnish student didn't design his console
driver to be lock friendly and then fbcon/fbdev inherited it.
If you are writing a new console driver please don't use fbcon, use a
text console that writes to a simple n x m text framebuffer with dirty
bits and wakes a waitqueue or work queue of some sort when it changes.
Then just redraw updated bits every vblank frame if its actually changed.
Not only will the lock problems go away it'll blow away the existing
scrolling text performance on any DRM driver except gma500.
Alan
prev parent reply other threads:[~2014-05-07 16:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 13:02 Takashi Iwai
2014-05-05 14:29 ` Daniel Vetter
2014-05-05 14:48 ` Takashi Iwai
2014-05-05 14:52 ` Daniel Vetter
2014-05-05 15:04 ` Takashi Iwai
2014-05-06 13:27 ` Takashi Iwai
2014-05-06 13:32 ` David Herrmann
2014-05-06 13:38 ` Takashi Iwai
2014-05-06 13:53 ` David Herrmann
2014-05-06 14:07 ` Takashi Iwai
2014-05-07 16:15 ` One Thousand Gnomes [this message]
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=20140507171523.48990630@alan.etchedpixels.co.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=daniel@ffwll.ch \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®