From: Pavel Machek <pavel@ucw.cz>
To: akpm@linux-foundation.org,
kernel list <linux-kernel@vger.kernel.org>,
Linux-pm mailing list <linux-pm@lists.osdl.org>
Cc: mm-commits@vger.kernel.org, dilinger@queued.net, adaplas@pol.net,
dilinger@debian.org, jordan.crouse@amd.com, rjw@sisk.pl
Subject: Re: + pm-gxfb-add-hook-to-pm-console-layer-that-allows-disabling-of-suspend-vt-switch.patch added to -mm tree
Date: Wed, 12 Mar 2008 09:51:49 +0100 [thread overview]
Message-ID: <20080312085149.GA3993@ucw.cz> (raw)
In-Reply-To: <200803120527.m2C5RmWl011967@imap1.linux-foundation.org>
Hi!
> Subject: PM/gxfb: add hook to PM console layer that allows disabling of suspend VT switch
> From: Andres Salomon <dilinger@queued.net>
>
> Prior to suspend, we allocate and switch to a new VT; after suspend, we switch
> back to the original VT. This can be slow, and is completely unnecessary if
> the framebuffer we're using can restore video properly.
>
> This adds a hook that allows drivers to select whether or not to do this vt
> switch, and changes the gxfb driver to call this hook. It also adds a module
> param to gxfb to allow controlling of the vt switch (defaulting to no switch).
>
> (Note: I'm not convinced that console_sem is the best way to protect this, but
> we should probably have some form of locking..)
I guess this is okay for now, but we probably want to make it more
elaborate in future.
Console switch is there to make sure kernel (not X) owns the graphical
hardware.
That is unneccessary for gxfb since X never owns graphics hardware,
good. (I do not see why it is optional, then. Do you really want to
see tty1?)
Now, question is what happens with two graphics cards, one of them
driven by X. Fortunately that is uncommon.
Also, it would be nice to make the logic the other way around. Move vt
switching to the drivers that need it because X can be expected to own
the hardware.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next parent reply other threads:[~2008-03-12 8:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200803120527.m2C5RmWl011967@imap1.linux-foundation.org>
2008-03-12 8:51 ` Pavel Machek [this message]
2008-03-12 14:45 ` + pm-gxfb-add-hook-to-pm-console-layer-that-allows-disabling-of-suspend-vt-switch.patch added to -mm tree Jordan Crouse
2008-03-13 7:43 ` + pm-gxfb-add-hook-to-pm-console-layer-that-allows-disabling-of-suspen d-vt-switch.patch " Pavel Machek
2008-03-13 14:57 ` Andres Salomon
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=20080312085149.GA3993@ucw.cz \
--to=pavel@ucw.cz \
--cc=adaplas@pol.net \
--cc=akpm@linux-foundation.org \
--cc=dilinger@debian.org \
--cc=dilinger@queued.net \
--cc=jordan.crouse@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=mm-commits@vger.kernel.org \
--cc=rjw@sisk.pl \
/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