This is purely for suspend/resume time optimization.
>From 874aa20022a2501a30704163ed31a7baba7de9e5 Mon Sep 17 00:00:00 2001
From: Andres Salomon <[email protected]>
Date: Wed, 5 Mar 2008 16:40:25 -0500
Subject: [PATCH] PM: add config option that allows disabling of VT switch during suspend
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 CONFIG_DISABLE_SUSPEND_VT_SWITCH which allows the user to
select whether or not to do that switch. This has been tested with the
gxfb driver (on a Geode GX dev board and OLPC prototype machines). In
order for the user to even see this option, a framebuffer has to declare
support for it (via CONFIG_FBDEV_SUPPORTS_NOSWITCH).
Signed-off-by: Andres Salomon <[email protected]>
---
drivers/char/Kconfig | 21 +++++++++++++++++++++
drivers/video/geode/Kconfig | 1 +
include/linux/suspend.h | 2 +-
kernel/power/console.c | 2 +-
4 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 47c6be8..7fe0e85 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -58,6 +58,27 @@ config VT_CONSOLE
If unsure, say Y.
+config FBDEV_SUPPORTS_NOSWITCH
+ bool
+ default n
+
+config DISABLE_SUSPEND_VT_SWITCH
+ bool "Disable the console switch prior to suspend (EXPERIMENTAL)"
+ depends on VT_CONSOLE && PM && EXPERIMENTAL && FBDEV_SUPPORTS_NOSWITCH
+ default n
+ ---help---
+ This option disables the automatic switch to VT console that happens
+ prior to Linux going into a suspend/sleep. Your
+ video card/framebuffer must be able to properly restore the
+ display (even if X is doing something crazy!) in this scenario.
+ This is useful for saving precious milliseconds during suspend and
+ resume; however, if your framebuffer lacks support, it could leave
+ your display in a weird state. If you're even seeing this option,
+ it means at least one of your selected framebuffer drivers supports
+ restoring the display.
+
+ If unsure, say N.
+
config HW_CONSOLE
bool
depends on VT && !S390 && !UML
diff --git a/drivers/video/geode/Kconfig b/drivers/video/geode/Kconfig
index c5d8ba4..1497fe4 100644
--- a/drivers/video/geode/Kconfig
+++ b/drivers/video/geode/Kconfig
@@ -29,6 +29,7 @@ config FB_GEODE_GX
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FBDEV_SUPPORTS_NOSWITCH
---help---
Framebuffer driver for the display controller integrated into the
AMD Geode GX processors.
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 1d7d4c5..46080f5 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -11,7 +11,7 @@
#include <linux/mm.h>
#include <asm/errno.h>
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_VT) && defined(CONFIG_VT_CONSOLE)
+#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_VT) && defined(CONFIG_VT_CONSOLE) && !defined(CONFIG_DISABLE_SUSPEND_VT_SWITCH)
extern int pm_prepare_console(void);
extern void pm_restore_console(void);
#else
diff --git a/kernel/power/console.c b/kernel/power/console.c
index 89bcf49..dca98f5 100644
--- a/kernel/power/console.c
+++ b/kernel/power/console.c
@@ -9,7 +9,7 @@
#include <linux/console.h>
#include "power.h"
-#if defined(CONFIG_VT) && defined(CONFIG_VT_CONSOLE)
+#if defined(CONFIG_VT) && defined(CONFIG_VT_CONSOLE) && !defined(CONFIG_DISABLE_SUSPEND_VT_SWITCH)
#define SUSPEND_CONSOLE (MAX_NR_CONSOLES-1)
static int orig_fgconsole, orig_kmsg;
--
1.5.3.7
On Sat, 8 Mar 2008 20:49:27 -0500
Andres Salomon <[email protected]> wrote:
> This is purely for suspend/resume time optimization.
>
>
> >From 874aa20022a2501a30704163ed31a7baba7de9e5 Mon Sep 17 00:00:00 2001
> From: Andres Salomon <[email protected]>
> Date: Wed, 5 Mar 2008 16:40:25 -0500
> Subject: [PATCH] PM: add config option that allows disabling of VT switch during suspend
>
> 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 CONFIG_DISABLE_SUSPEND_VT_SWITCH which allows the user to
> select whether or not to do that switch. This has been tested with the
> gxfb driver (on a Geode GX dev board and OLPC prototype machines). In
> order for the user to even see this option, a framebuffer has to declare
> support for it (via CONFIG_FBDEV_SUPPORTS_NOSWITCH).
>
> Signed-off-by: Andres Salomon <[email protected]>
> ---
> drivers/char/Kconfig | 21 +++++++++++++++++++++
> drivers/video/geode/Kconfig | 1 +
> include/linux/suspend.h | 2 +-
> kernel/power/console.c | 2 +-
> 4 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 47c6be8..7fe0e85 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -58,6 +58,27 @@ config VT_CONSOLE
>
> If unsure, say Y.
>
> +config FBDEV_SUPPORTS_NOSWITCH
> + bool
> + default n
> +
> +config DISABLE_SUSPEND_VT_SWITCH
> + bool "Disable the console switch prior to suspend (EXPERIMENTAL)"
> + depends on VT_CONSOLE && PM && EXPERIMENTAL && FBDEV_SUPPORTS_NOSWITCH
> + default n
> + ---help---
> + This option disables the automatic switch to VT console that happens
> + prior to Linux going into a suspend/sleep. Your
> + video card/framebuffer must be able to properly restore the
> + display (even if X is doing something crazy!) in this scenario.
> + This is useful for saving precious milliseconds during suspend and
> + resume; however, if your framebuffer lacks support, it could leave
> + your display in a weird state. If you're even seeing this option,
> + it means at least one of your selected framebuffer drivers supports
> + restoring the display.
> +
> + If unsure, say N.
It would be far preferable to do this via a kernel boot parameter rather
than via a kernel rebuild.
On Mon, 10 Mar 2008 14:19:39 -0700
Andrew Morton <[email protected]> wrote:
> On Sat, 8 Mar 2008 20:49:27 -0500
> Andres Salomon <[email protected]> wrote:
>
> > This is purely for suspend/resume time optimization.
> >
> >
> > >From 874aa20022a2501a30704163ed31a7baba7de9e5 Mon Sep 17 00:00:00 2001
> > From: Andres Salomon <[email protected]>
> > Date: Wed, 5 Mar 2008 16:40:25 -0500
> > Subject: [PATCH] PM: add config option that allows disabling of VT switch during suspend
> >
> > 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 CONFIG_DISABLE_SUSPEND_VT_SWITCH which allows the user to
> > select whether or not to do that switch. This has been tested with the
> > gxfb driver (on a Geode GX dev board and OLPC prototype machines). In
> > order for the user to even see this option, a framebuffer has to declare
> > support for it (via CONFIG_FBDEV_SUPPORTS_NOSWITCH).
> >
> > Signed-off-by: Andres Salomon <[email protected]>
> > ---
> > drivers/char/Kconfig | 21 +++++++++++++++++++++
> > drivers/video/geode/Kconfig | 1 +
> > include/linux/suspend.h | 2 +-
> > kernel/power/console.c | 2 +-
> > 4 files changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> > index 47c6be8..7fe0e85 100644
> > --- a/drivers/char/Kconfig
> > +++ b/drivers/char/Kconfig
> > @@ -58,6 +58,27 @@ config VT_CONSOLE
> >
> > If unsure, say Y.
> >
> > +config FBDEV_SUPPORTS_NOSWITCH
> > + bool
> > + default n
> > +
> > +config DISABLE_SUSPEND_VT_SWITCH
> > + bool "Disable the console switch prior to suspend (EXPERIMENTAL)"
> > + depends on VT_CONSOLE && PM && EXPERIMENTAL && FBDEV_SUPPORTS_NOSWITCH
> > + default n
> > + ---help---
> > + This option disables the automatic switch to VT console that happens
> > + prior to Linux going into a suspend/sleep. Your
> > + video card/framebuffer must be able to properly restore the
> > + display (even if X is doing something crazy!) in this scenario.
> > + This is useful for saving precious milliseconds during suspend and
> > + resume; however, if your framebuffer lacks support, it could leave
> > + your display in a weird state. If you're even seeing this option,
> > + it means at least one of your selected framebuffer drivers supports
> > + restoring the display.
> > +
> > + If unsure, say N.
>
> It would be far preferable to do this via a kernel boot parameter rather
> than via a kernel rebuild.
>
Well, it shouldn't be supported at _all_ unless the framebuffer driver
supports it; you're asking for it to be converted to something like the
following?
#ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
static int no_vt_switch;
#endif
int pm_prepare_console(void)
{
#ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
if (no_vt_switch)
return 0;
#endif
...
}
#ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
module_param(no_vt_switch, int, 0);
MODULE_PARM_DESC(no_vt_switch, "...");
#endif
If so, that means extra #ifdef's sprinkled throughout the code. Note
that most framebuffer drivers won't be supporting this, and those that
do will almost certainly always want vt switching turned off..
On Mon, 10 Mar 2008 17:44:24 -0400
Andres Salomon <[email protected]> wrote:
> On Mon, 10 Mar 2008 14:19:39 -0700
> Andrew Morton <[email protected]> wrote:
>
> >
> > It would be far preferable to do this via a kernel boot parameter rather
> > than via a kernel rebuild.
> >
>
> Well, it shouldn't be supported at _all_ unless the framebuffer driver
> supports it; you're asking for it to be converted to something like the
> following?
>
>
>
> #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> static int no_vt_switch;
> #endif
>
> int pm_prepare_console(void)
> {
> #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> if (no_vt_switch)
> return 0;
> #endif
> ...
> }
>
> #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> module_param(no_vt_switch, int, 0);
> MODULE_PARM_DESC(no_vt_switch, "...");
> #endif
>
>
> If so, that means extra #ifdef's sprinkled throughout the code. Note
> that most framebuffer drivers won't be supporting this, and those that
> do will almost certainly always want vt switching turned off..
>
I don't think you need any ifdefs or config options at all, do you? Just
add a new module parameter to this driver and some little interface into
the PM core which allows the driver to set no_vt_switch?
On Mon, 10 Mar 2008 14:51:18 -0700
Andrew Morton <[email protected]> wrote:
> On Mon, 10 Mar 2008 17:44:24 -0400
> Andres Salomon <[email protected]> wrote:
>
> > On Mon, 10 Mar 2008 14:19:39 -0700
> > Andrew Morton <[email protected]> wrote:
> >
> > >
> > > It would be far preferable to do this via a kernel boot parameter rather
> > > than via a kernel rebuild.
> > >
> >
> > Well, it shouldn't be supported at _all_ unless the framebuffer driver
> > supports it; you're asking for it to be converted to something like the
> > following?
> >
> >
> >
> > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > static int no_vt_switch;
> > #endif
> >
> > int pm_prepare_console(void)
> > {
> > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > if (no_vt_switch)
> > return 0;
> > #endif
> > ...
> > }
> >
> > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > module_param(no_vt_switch, int, 0);
> > MODULE_PARM_DESC(no_vt_switch, "...");
> > #endif
> >
> >
> > If so, that means extra #ifdef's sprinkled throughout the code. Note
> > that most framebuffer drivers won't be supporting this, and those that
> > do will almost certainly always want vt switching turned off..
> >
>
> I don't think you need any ifdefs or config options at all, do you? Just
> add a new module parameter to this driver and some little interface into
> the PM core which allows the driver to set no_vt_switch?
>
That's a possibility, but doesn't adding hooks into PM core for two
drivers (lxfb and gxfb) seems like overkill? I also don't really see
anyone needing to switch back and forth between VT_SWITCH and
NO_VT_SWITCH other than to work around possible bugs in the register
save/restore code..
On 10/03/08 18:14 -0400, Andres Salomon wrote:
> On Mon, 10 Mar 2008 14:51:18 -0700
> Andrew Morton <[email protected]> wrote:
>
> > On Mon, 10 Mar 2008 17:44:24 -0400
> > Andres Salomon <[email protected]> wrote:
> >
> > > On Mon, 10 Mar 2008 14:19:39 -0700
> > > Andrew Morton <[email protected]> wrote:
> > >
> > > >
> > > > It would be far preferable to do this via a kernel boot parameter rather
> > > > than via a kernel rebuild.
> > > >
> > >
> > > Well, it shouldn't be supported at _all_ unless the framebuffer driver
> > > supports it; you're asking for it to be converted to something like the
> > > following?
> > >
> > >
> > >
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > static int no_vt_switch;
> > > #endif
> > >
> > > int pm_prepare_console(void)
> > > {
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > if (no_vt_switch)
> > > return 0;
> > > #endif
> > > ...
> > > }
> > >
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > module_param(no_vt_switch, int, 0);
> > > MODULE_PARM_DESC(no_vt_switch, "...");
> > > #endif
> > >
> > >
> > > If so, that means extra #ifdef's sprinkled throughout the code. Note
> > > that most framebuffer drivers won't be supporting this, and those that
> > > do will almost certainly always want vt switching turned off..
> > >
> >
> > I don't think you need any ifdefs or config options at all, do you? Just
> > add a new module parameter to this driver and some little interface into
> > the PM core which allows the driver to set no_vt_switch?
> >
>
> That's a possibility, but doesn't adding hooks into PM core for two
> drivers (lxfb and gxfb) seems like overkill? I also don't really see
> anyone needing to switch back and forth between VT_SWITCH and
> NO_VT_SWITCH other than to work around possible bugs in the register
> save/restore code..
I like Andrew's idea. I wager This won't be Geode specific for long.
Either other drivers will get the hint and add real save/restore code
or the GPU subystem code being worked on by the X folks will come along
and make the VT switch obsolete for everybody. Either way, I see hooks
in the PM core as generic love that everybody can benefit from.
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
On Monday, 10 of March 2008, Andres Salomon wrote:
> On Mon, 10 Mar 2008 14:51:18 -0700
> Andrew Morton <[email protected]> wrote:
>
> > On Mon, 10 Mar 2008 17:44:24 -0400
> > Andres Salomon <[email protected]> wrote:
> >
> > > On Mon, 10 Mar 2008 14:19:39 -0700
> > > Andrew Morton <[email protected]> wrote:
> > >
> > > >
> > > > It would be far preferable to do this via a kernel boot parameter rather
> > > > than via a kernel rebuild.
> > > >
> > >
> > > Well, it shouldn't be supported at _all_ unless the framebuffer driver
> > > supports it; you're asking for it to be converted to something like the
> > > following?
> > >
> > >
> > >
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > static int no_vt_switch;
> > > #endif
> > >
> > > int pm_prepare_console(void)
> > > {
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > if (no_vt_switch)
> > > return 0;
> > > #endif
> > > ...
> > > }
> > >
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > module_param(no_vt_switch, int, 0);
> > > MODULE_PARM_DESC(no_vt_switch, "...");
> > > #endif
> > >
> > >
> > > If so, that means extra #ifdef's sprinkled throughout the code. Note
> > > that most framebuffer drivers won't be supporting this, and those that
> > > do will almost certainly always want vt switching turned off..
> > >
> >
> > I don't think you need any ifdefs or config options at all, do you? Just
> > add a new module parameter to this driver and some little interface into
> > the PM core which allows the driver to set no_vt_switch?
> >
>
> That's a possibility, but doesn't adding hooks into PM core for two
> drivers (lxfb and gxfb) seems like overkill? I also don't really see
> anyone needing to switch back and forth between VT_SWITCH and
> NO_VT_SWITCH other than to work around possible bugs in the register
> save/restore code..
FWIW, I prefer the original .config option idea.
Thanks,
Rafael
On Mon, 10 Mar 2008 18:14:46 -0400 Andres Salomon <[email protected]> wrote:
> On Mon, 10 Mar 2008 14:51:18 -0700
> Andrew Morton <[email protected]> wrote:
>
> > On Mon, 10 Mar 2008 17:44:24 -0400
> > Andres Salomon <[email protected]> wrote:
> >
> > > On Mon, 10 Mar 2008 14:19:39 -0700
> > > Andrew Morton <[email protected]> wrote:
> > >
> > > >
> > > > It would be far preferable to do this via a kernel boot parameter rather
> > > > than via a kernel rebuild.
> > > >
> > >
> > > Well, it shouldn't be supported at _all_ unless the framebuffer driver
> > > supports it; you're asking for it to be converted to something like the
> > > following?
> > >
> > >
> > >
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > static int no_vt_switch;
> > > #endif
> > >
> > > int pm_prepare_console(void)
> > > {
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > if (no_vt_switch)
> > > return 0;
> > > #endif
> > > ...
> > > }
> > >
> > > #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH
> > > module_param(no_vt_switch, int, 0);
> > > MODULE_PARM_DESC(no_vt_switch, "...");
> > > #endif
> > >
> > >
> > > If so, that means extra #ifdef's sprinkled throughout the code. Note
> > > that most framebuffer drivers won't be supporting this, and those that
> > > do will almost certainly always want vt switching turned off..
> > >
> >
> > I don't think you need any ifdefs or config options at all, do you? Just
> > add a new module parameter to this driver and some little interface into
> > the PM core which allows the driver to set no_vt_switch?
> >
>
> That's a possibility, but doesn't adding hooks into PM core for two
> drivers (lxfb and gxfb) seems like overkill?
It's just a few bytes of code?
> I also don't really see
> anyone needing to switch back and forth between VT_SWITCH and
> NO_VT_SWITCH other than to work around possible bugs in the register
> save/restore code..
Making driver behaviour depend upon compile-time settings is really to be
avoided. A distributor has to choose one setting or the other, and a) that
means that some people will get the wrong setting and b) there's a decent
chance that the distributor will get it wrong.
On Mon 2008-03-10 14:19:39, Andrew Morton wrote:
> On Sat, 8 Mar 2008 20:49:27 -0500
> Andres Salomon <[email protected]> wrote:
>
> > This is purely for suspend/resume time optimization.
> >
> >
> > >From 874aa20022a2501a30704163ed31a7baba7de9e5 Mon Sep 17 00:00:00 2001
> > From: Andres Salomon <[email protected]>
> > Date: Wed, 5 Mar 2008 16:40:25 -0500
> > Subject: [PATCH] PM: add config option that allows disabling of VT switch during suspend
> >
> > 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 CONFIG_DISABLE_SUSPEND_VT_SWITCH which allows the user to
> > select whether or not to do that switch. This has been tested with the
> > gxfb driver (on a Geode GX dev board and OLPC prototype machines). In
> > order for the user to even see this option, a framebuffer has to declare
> > support for it (via CONFIG_FBDEV_SUPPORTS_NOSWITCH).
...
> It would be far preferable to do this via a kernel boot parameter rather
> than via a kernel rebuild.
Actually, it would be better to get this right automatically, without
any config options.
And no, this is not only gxfb/lxfb. At least Sharp Zaurus and FIC
neo1973 can suspend without switching consoles...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > > > If so, that means extra #ifdef's sprinkled throughout the code. Note
> > > > that most framebuffer drivers won't be supporting this, and those that
> > > > do will almost certainly always want vt switching turned off..
> > > >
> > >
> > > I don't think you need any ifdefs or config options at all, do you? Just
> > > add a new module parameter to this driver and some little interface into
> > > the PM core which allows the driver to set no_vt_switch?
> > >
> >
> > That's a possibility, but doesn't adding hooks into PM core for two
> > drivers (lxfb and gxfb) seems like overkill? I also don't really see
> > anyone needing to switch back and forth between VT_SWITCH and
> > NO_VT_SWITCH other than to work around possible bugs in the register
> > save/restore code..
>
> I like Andrew's idea. I wager This won't be Geode specific for long.
> Either other drivers will get the hint and add real save/restore code
> or the GPU subystem code being worked on by the X folks will come along
> and make the VT switch obsolete for everybody. Either way, I see hooks
> in the PM core as generic love that everybody can benefit from.
Exactly. We'd like _all_ drivers to behave like this.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 10 Mar 2008 23:28:18 +0100 "Rafael J. Wysocki" <[email protected]> wrote:
> > > > If so, that means extra #ifdef's sprinkled throughout the code. Note
> > > > that most framebuffer drivers won't be supporting this, and those that
> > > > do will almost certainly always want vt switching turned off..
> > > >
> > >
> > > I don't think you need any ifdefs or config options at all, do you? Just
> > > add a new module parameter to this driver and some little interface into
> > > the PM core which allows the driver to set no_vt_switch?
> > >
> >
> > That's a possibility, but doesn't adding hooks into PM core for two
> > drivers (lxfb and gxfb) seems like overkill? I also don't really see
> > anyone needing to switch back and forth between VT_SWITCH and
> > NO_VT_SWITCH other than to work around possible bugs in the register
> > save/restore code..
>
> FWIW, I prefer the original .config option idea.
Please explain your reasoning?