VT switchless suspend/resume

VT switchless suspend/resume

[Jesse Barnes]

Finally got around to updating these patches here at FOSDEM.  I made the
core PM support for this into a function so multiple drivers can
indicate their support and we'll be conservative about doing the switch
if no drivers call in or if any driver indicates it can't support VT
switchless suspend/resume.  Please check the logic in my
pm_vt_switch_required function; I try to handle several cases:
  1) no driver calls the routine (should VT switch)
  2) driver requires it but then unbinds and clears its req, a
     subsequent driver that doesn't require VT switching should have its
     switchless behavior honored (shouldn't VT switch)
  3) multiple drivers call in with different reqs (should VT switch)
  4) multiple or single drivers call in that don't require VT switching
     (shouldn't VT switch)

Still need to add calls to some other drivers, so if this looks ok I can
do that.

Thanks,
Jesse

[PATCH] PM: make VT switching to the suspend console optional v2

[Jesse Barnes]

KMS drivers can potentially restore the display configuration without
userspace help.  Such drivers can can call a new funciton,
pm_vt_switch_required(false) if they support this feature.  In that
case, the PM layer won't VT switch to the suspend console at suspend
time and then back to the original VT on resume, but rather leave things
alone for a nicer looking suspend and resume sequence.

v2: make a function so we can handle multiple drivers (Alan)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 include/linux/pm.h     |    2 ++
 kernel/power/console.c |   59 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+)

diff --git a/include/linux/pm.h b/include/linux/pm.h
index 03d7bb1..5c2b131 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -35,6 +35,8 @@ extern void (*pm_idle)(void);
 extern void (*pm_power_off)(void);
 extern void (*pm_power_off_prepare)(void);
 
+extern void pm_vt_switch_required(bool required);
+
 /*
  * Device power management
  */
diff --git a/kernel/power/console.c b/kernel/power/console.c
index b1dc456..67c4de3 100644
--- a/kernel/power/console.c
+++ b/kernel/power/console.c
@@ -4,6 +4,7 @@
  * Originally from swsusp.
  */
 
+#include <linux/console.h>
 #include <linux/vt_kern.h>
 #include <linux/kbd_kern.h>
 #include <linux/vt.h>
@@ -14,8 +15,63 @@
 
 static int orig_fgconsole, orig_kmsg;
 
+DEFINE_SPINLOCK(vt_switch_lock);
+static int vt_switch_required = -1;
+
+/**
+ * pm_vt_switch_required - indicate VT switch at suspend requirements
+ * @required: if true, caller needs VT switch at suspend/resume time
+ *
+ * The different console drivers may or may not require VT switches across
+ * suspend/resume, depending on how they handle restoring video state and
+ * what may be running.
+ *
+ * Drivers can indicate support for switchless suspend/resume, which can
+ * save time and flicker, by using this routine and passing 'false' as
+ * the argument.  If any loaded driver needs VT switching, or the
+ * no_console_suspend argument has been passed on the command line, VT
+ * switches will occur.
+ */
+void pm_vt_switch_required(bool required)
+{
+	spin_lock(&vt_switch_lock);
+	if (vt_switch_required == -1) {
+		/* First call, set up real value */
+		if (!required)
+			vt_switch_required = 0;
+		if (required)
+			vt_switch_required = 1;
+	} else {
+		/*
+		 * Subsequent caller, make sure we handle the case
+		 * where a driver binds, needs VT switch, but then unbinds
+		 * later and a switchless driver is present.
+		 */
+		if (!required && vt_switch_required > 0)
+			vt_switch_required--;
+		else if (required)
+			vt_switch_required++;
+	}
+	spin_unlock(&vt_switch_lock);
+}
+EXPORT_SYMBOL(pm_vt_switch_required);
+
+static bool pm_vt_switch(void)
+{
+	bool ret = true;
+
+	spin_lock(&vt_switch_lock);
+	if (!vt_switch_required && console_suspend_enabled)
+		ret = false;
+	spin_unlock(&vt_switch_lock);
+	return ret;
+}
+
 int pm_prepare_console(void)
 {
+	if (!pm_vt_switch())
+		return 0;
+
 	orig_fgconsole = vt_move_to_console(SUSPEND_CONSOLE, 1);
 	if (orig_fgconsole < 0)
 		return 1;
@@ -26,6 +82,9 @@ int pm_prepare_console(void)
 
 void pm_restore_console(void)
 {
+	if (!pm_vt_switch())
+		return;
+
 	if (orig_fgconsole >= 0) {
 		vt_move_to_console(orig_fgconsole, 0);
 		vt_kmsg_redirect(orig_kmsg);
-- 
1.7.9.5

Re: [PATCH] PM: make VT switching to the suspend console optional v2

[Rafael J. Wysocki]

On Saturday, February 02, 2013 04:34:08 PM Jesse Barnes wrote:
> KMS drivers can potentially restore the display configuration without
> userspace help.  Such drivers can can call a new funciton,
> pm_vt_switch_required(false) if they support this feature.  In that
> case, the PM layer won't VT switch to the suspend console at suspend
> time and then back to the original VT on resume, but rather leave things
> alone for a nicer looking suspend and resume sequence.
> 
> v2: make a function so we can handle multiple drivers (Alan)
> 
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> ---
>  include/linux/pm.h     |    2 ++
>  kernel/power/console.c |   59 ++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index 03d7bb1..5c2b131 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -35,6 +35,8 @@ extern void (*pm_idle)(void);
>  extern void (*pm_power_off)(void);
>  extern void (*pm_power_off_prepare)(void);
>  
> +extern void pm_vt_switch_required(bool required);
> +
>  /*
>   * Device power management
>   */
> diff --git a/kernel/power/console.c b/kernel/power/console.c
> index b1dc456..67c4de3 100644
> --- a/kernel/power/console.c
> +++ b/kernel/power/console.c
> @@ -4,6 +4,7 @@
>   * Originally from swsusp.
>   */
>  
> +#include <linux/console.h>
>  #include <linux/vt_kern.h>
>  #include <linux/kbd_kern.h>
>  #include <linux/vt.h>
> @@ -14,8 +15,63 @@
>  
>  static int orig_fgconsole, orig_kmsg;
>  
> +DEFINE_SPINLOCK(vt_switch_lock);
> +static int vt_switch_required = -1;
> +
> +/**
> + * pm_vt_switch_required - indicate VT switch at suspend requirements
> + * @required: if true, caller needs VT switch at suspend/resume time
> + *
> + * The different console drivers may or may not require VT switches across
> + * suspend/resume, depending on how they handle restoring video state and
> + * what may be running.
> + *
> + * Drivers can indicate support for switchless suspend/resume, which can
> + * save time and flicker, by using this routine and passing 'false' as
> + * the argument.  If any loaded driver needs VT switching, or the
> + * no_console_suspend argument has been passed on the command line, VT
> + * switches will occur.
> + */

It seems to me that we'll need a separate counter for the number of registered
drivers and do the switch if that number is equal to the number of drivers that
have passed false to this thing.

In which case we can simplify this slightly and introduce
pm_vt_swtich_not_required(void) and then the only drivers that need to bother
will be the ones known to not require the switch.

Otherwise it will be kind of error prone I'm afraid.

Thanks,
Rafael


> +void pm_vt_switch_required(bool required)
> +{
> +	spin_lock(&vt_switch_lock);
> +	if (vt_switch_required == -1) {
> +		/* First call, set up real value */
> +		if (!required)
> +			vt_switch_required = 0;
> +		if (required)
> +			vt_switch_required = 1;
> +	} else {
> +		/*
> +		 * Subsequent caller, make sure we handle the case
> +		 * where a driver binds, needs VT switch, but then unbinds
> +		 * later and a switchless driver is present.
> +		 */
> +		if (!required && vt_switch_required > 0)
> +			vt_switch_required--;
> +		else if (required)
> +			vt_switch_required++;
> +	}
> +	spin_unlock(&vt_switch_lock);
> +}
> +EXPORT_SYMBOL(pm_vt_switch_required);
> +
> +static bool pm_vt_switch(void)
> +{
> +	bool ret = true;
> +
> +	spin_lock(&vt_switch_lock);
> +	if (!vt_switch_required && console_suspend_enabled)
> +		ret = false;
> +	spin_unlock(&vt_switch_lock);
> +	return ret;
> +}
> +
>  int pm_prepare_console(void)
>  {
> +	if (!pm_vt_switch())
> +		return 0;
> +
>  	orig_fgconsole = vt_move_to_console(SUSPEND_CONSOLE, 1);
>  	if (orig_fgconsole < 0)
>  		return 1;
> @@ -26,6 +82,9 @@ int pm_prepare_console(void)
>  
>  void pm_restore_console(void)
>  {
> +	if (!pm_vt_switch())
> +		return;
> +
>  	if (orig_fgconsole >= 0) {
>  		vt_move_to_console(orig_fgconsole, 0);
>  		vt_kmsg_redirect(orig_kmsg);
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH] PM: make VT switching to the suspend console optional v2

[Rafael J. Wysocki]

On Saturday, February 02, 2013 08:39:21 PM Rafael J. Wysocki wrote:
> On Saturday, February 02, 2013 04:34:08 PM Jesse Barnes wrote:
> > KMS drivers can potentially restore the display configuration without
> > userspace help.  Such drivers can can call a new funciton,
> > pm_vt_switch_required(false) if they support this feature.  In that
> > case, the PM layer won't VT switch to the suspend console at suspend
> > time and then back to the original VT on resume, but rather leave things
> > alone for a nicer looking suspend and resume sequence.
> > 
> > v2: make a function so we can handle multiple drivers (Alan)
> > 
> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > ---
> >  include/linux/pm.h     |    2 ++
> >  kernel/power/console.c |   59 ++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 61 insertions(+)
> > 
> > diff --git a/include/linux/pm.h b/include/linux/pm.h
> > index 03d7bb1..5c2b131 100644
> > --- a/include/linux/pm.h
> > +++ b/include/linux/pm.h
> > @@ -35,6 +35,8 @@ extern void (*pm_idle)(void);
> >  extern void (*pm_power_off)(void);
> >  extern void (*pm_power_off_prepare)(void);
> >  
> > +extern void pm_vt_switch_required(bool required);
> > +
> >  /*
> >   * Device power management
> >   */
> > diff --git a/kernel/power/console.c b/kernel/power/console.c
> > index b1dc456..67c4de3 100644
> > --- a/kernel/power/console.c
> > +++ b/kernel/power/console.c
> > @@ -4,6 +4,7 @@
> >   * Originally from swsusp.
> >   */
> >  
> > +#include <linux/console.h>
> >  #include <linux/vt_kern.h>
> >  #include <linux/kbd_kern.h>
> >  #include <linux/vt.h>
> > @@ -14,8 +15,63 @@
> >  
> >  static int orig_fgconsole, orig_kmsg;
> >  
> > +DEFINE_SPINLOCK(vt_switch_lock);
> > +static int vt_switch_required = -1;
> > +
> > +/**
> > + * pm_vt_switch_required - indicate VT switch at suspend requirements
> > + * @required: if true, caller needs VT switch at suspend/resume time
> > + *
> > + * The different console drivers may or may not require VT switches across
> > + * suspend/resume, depending on how they handle restoring video state and
> > + * what may be running.
> > + *
> > + * Drivers can indicate support for switchless suspend/resume, which can
> > + * save time and flicker, by using this routine and passing 'false' as
> > + * the argument.  If any loaded driver needs VT switching, or the
> > + * no_console_suspend argument has been passed on the command line, VT
> > + * switches will occur.
> > + */
> 
> It seems to me that we'll need a separate counter for the number of registered
> drivers and do the switch if that number is equal to the number of drivers that
> have passed false to this thing.
> 
> In which case we can simplify this slightly and introduce
> pm_vt_swtich_not_required(void)

Sorry, that won't be sufficient.  Rather something like pm_vt_switch_get()
(indicating "I'll do the switch, thanks") and pm_vt_switch_put() (indicating
"now you need to do the switch yourself").

> and then the only drivers that need to bother
> will be the ones known to not require the switch.
> 
> Otherwise it will be kind of error prone I'm afraid.

Thanks,
Rafael


> > +void pm_vt_switch_required(bool required)
> > +{
> > +	spin_lock(&vt_switch_lock);
> > +	if (vt_switch_required == -1) {
> > +		/* First call, set up real value */
> > +		if (!required)
> > +			vt_switch_required = 0;
> > +		if (required)
> > +			vt_switch_required = 1;
> > +	} else {
> > +		/*
> > +		 * Subsequent caller, make sure we handle the case
> > +		 * where a driver binds, needs VT switch, but then unbinds
> > +		 * later and a switchless driver is present.
> > +		 */
> > +		if (!required && vt_switch_required > 0)
> > +			vt_switch_required--;
> > +		else if (required)
> > +			vt_switch_required++;
> > +	}
> > +	spin_unlock(&vt_switch_lock);
> > +}
> > +EXPORT_SYMBOL(pm_vt_switch_required);
> > +
> > +static bool pm_vt_switch(void)
> > +{
> > +	bool ret = true;
> > +
> > +	spin_lock(&vt_switch_lock);
> > +	if (!vt_switch_required && console_suspend_enabled)
> > +		ret = false;
> > +	spin_unlock(&vt_switch_lock);
> > +	return ret;
> > +}
> > +
> >  int pm_prepare_console(void)
> >  {
> > +	if (!pm_vt_switch())
> > +		return 0;
> > +
> >  	orig_fgconsole = vt_move_to_console(SUSPEND_CONSOLE, 1);
> >  	if (orig_fgconsole < 0)
> >  		return 1;
> > @@ -26,6 +82,9 @@ int pm_prepare_console(void)
> >  
> >  void pm_restore_console(void)
> >  {
> > +	if (!pm_vt_switch())
> > +		return;
> > +
> >  	if (orig_fgconsole >= 0) {
> >  		vt_move_to_console(orig_fgconsole, 0);
> >  		vt_kmsg_redirect(orig_kmsg);
> > 
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH] PM: make VT switching to the suspend console optional v2

[Jesse Barnes]

On Sat, 02 Feb 2013 21:50:35 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > + * Drivers can indicate support for switchless suspend/resume, which can
> > > + * save time and flicker, by using this routine and passing 'false' as
> > > + * the argument.  If any loaded driver needs VT switching, or the
> > > + * no_console_suspend argument has been passed on the command line, VT
> > > + * switches will occur.
> > > + */
> > 
> > It seems to me that we'll need a separate counter for the number of registered
> > drivers and do the switch if that number is equal to the number of drivers that
> > have passed false to this thing.
> > 
> > In which case we can simplify this slightly and introduce
> > pm_vt_swtich_not_required(void)
> 
> Sorry, that won't be sufficient.  Rather something like pm_vt_switch_get()
> (indicating "I'll do the switch, thanks") and pm_vt_switch_put() (indicating
> "now you need to do the switch yourself").

I thought of both of your approaches before posting this one, but each
have other problems.  And I found a bug in mine last night.

So I think I need a separate count of drivers that need the switch, and
ones that don't.  Then if either no driver has registered or if the
need_switch count is nonzero, we'll do the switch.  Otherwise, if the
dont_need_switch is nonzero, we can avoid the switch.  I think that'll
handle all the cases I outlined.

My code as posted will fail if one driver needs a switch but then two
switch free drivers register.

Jesse

Re: [PATCH] PM: make VT switching to the suspend console optional v2

[Rafael J. Wysocki]

On Sunday, February 03, 2013 09:56:09 AM Jesse Barnes wrote:
> On Sat, 02 Feb 2013 21:50:35 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > + * Drivers can indicate support for switchless suspend/resume, which can
> > > > + * save time and flicker, by using this routine and passing 'false' as
> > > > + * the argument.  If any loaded driver needs VT switching, or the
> > > > + * no_console_suspend argument has been passed on the command line, VT
> > > > + * switches will occur.
> > > > + */
> > > 
> > > It seems to me that we'll need a separate counter for the number of registered
> > > drivers and do the switch if that number is equal to the number of drivers that
> > > have passed false to this thing.
> > > 
> > > In which case we can simplify this slightly and introduce
> > > pm_vt_swtich_not_required(void)
> > 
> > Sorry, that won't be sufficient.  Rather something like pm_vt_switch_get()
> > (indicating "I'll do the switch, thanks") and pm_vt_switch_put() (indicating
> > "now you need to do the switch yourself").
> 
> I thought of both of your approaches before posting this one, but each
> have other problems.  And I found a bug in mine last night.
> 
> So I think I need a separate count of drivers that need the switch, and
> ones that don't.  Then if either no driver has registered or if the
> need_switch count is nonzero, we'll do the switch.  Otherwise, if the
> dont_need_switch is nonzero, we can avoid the switch.  I think that'll
> handle all the cases I outlined.

Yes, it should cover them all I think.

> My code as posted will fail if one driver needs a switch but then two
> switch free drivers register.

I see.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

VT switchless suspend/resume

[Jesse Barnes]

Updated with the fix from Ville.

Re: VT switchless suspend/resume

[Paulo Zanoni]

2013/2/19 Jesse Barnes <jbarnes@virtuousgeek.org>:
> Updated with the fix from Ville.

Very briefly tested on SNB (LVDS) and HSW (eDP + DP). Suspend-to-ram +
resume still work.

>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni

Re: VT switchless suspend/resume

[Paulo Zanoni]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

Hi

2013/2/19 Paulo Zanoni <przanoni@gmail.com>:
> 2013/2/19 Jesse Barnes <jbarnes@virtuousgeek.org>:
>> Updated with the fix from Ville.
>
> Very briefly tested on SNB (LVDS) and HSW (eDP + DP). Suspend-to-ram +
> resume still work.

So, today I looked at the patches I didn't review last week and they
all looked correct, so I was ready to give a "Reviewed-by" stamp on
all of them. I decided to do one more testing and I noticed that with
this series, dmesg gives me some error messages that don't happen
without the series. On a SNB machine with LVDS+DP, after resume I get
error messages saying that DP link training failed (even though the DP
monitor is working).

The dmesg file is attached.

Thanks,
Paulo

>
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni



-- 
Paulo Zanoni

[-- Attachment #2: dmesg.tar.gz --]
[-- Type: application/x-gzip, Size: 49472 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: VT switchless suspend/resume

[Jesse Barnes]

On Mon, 25 Feb 2013 16:19:53 -0300
Paulo Zanoni <przanoni@gmail.com> wrote:

> Hi
> 
> 2013/2/19 Paulo Zanoni <przanoni@gmail.com>:
> > 2013/2/19 Jesse Barnes <jbarnes@virtuousgeek.org>:
> >> Updated with the fix from Ville.
> >
> > Very briefly tested on SNB (LVDS) and HSW (eDP + DP). Suspend-to-ram +
> > resume still work.
> 
> So, today I looked at the patches I didn't review last week and they
> all looked correct, so I was ready to give a "Reviewed-by" stamp on
> all of them. I decided to do one more testing and I noticed that with
> this series, dmesg gives me some error messages that don't happen
> without the series. On a SNB machine with LVDS+DP, after resume I get
> error messages saying that DP link training failed (even though the DP
> monitor is working).
> 
> The dmesg file is attached.

Hm ugly... any ideas why?  This really shouldn't have affected
anything; we just do a mode set from the kernel first instead of
waiting on the VT switch...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: VT switchless suspend/resume

[Jesse Barnes]

On Mon, 25 Feb 2013 13:31:42 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Mon, 25 Feb 2013 16:19:53 -0300
> Paulo Zanoni <przanoni@gmail.com> wrote:
> 
> > Hi
> > 
> > 2013/2/19 Paulo Zanoni <przanoni@gmail.com>:
> > > 2013/2/19 Jesse Barnes <jbarnes@virtuousgeek.org>:
> > >> Updated with the fix from Ville.
> > >
> > > Very briefly tested on SNB (LVDS) and HSW (eDP + DP). Suspend-to-ram +
> > > resume still work.
> > 
> > So, today I looked at the patches I didn't review last week and they
> > all looked correct, so I was ready to give a "Reviewed-by" stamp on
> > all of them. I decided to do one more testing and I noticed that with
> > this series, dmesg gives me some error messages that don't happen
> > without the series. On a SNB machine with LVDS+DP, after resume I get
> > error messages saying that DP link training failed (even though the DP
> > monitor is working).
> > 
> > The dmesg file is attached.
> 
> Hm ugly... any ideas why?  This really shouldn't have affected
> anything; we just do a mode set from the kernel first instead of
> waiting on the VT switch...

Looks like it's trying to restore a 2 pipe config?  Is that correct?
The BIOS re-enabled VGA across suspend/resume too, I guess that would
cause trouble...  but the check code says both CRTCs are disabled at
resume.

So first a DP train appears to fail, then we fail waiting for a pipe to
disable because we try another, single pipe mode set.

Which is the proper config?  One pipe or two?

-- 
Jesse Barnes, Intel Open Source Technology Center