hid-multitouch: eGalax Touchscreen not resuming after suspend

Commit Message

Rafael Wysocki Nov. 29, 2012, 12:20 a.m. UTC

On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> On Sun, 25 Nov 2012, Jan-Matthias Braun wrote:
> 
> > Hi all,
> > 
> > sorry for the e-mail address hopping. Answers to both addresses are okay.
> > 
> > I have now done a git bisection from 3.0 to 3.1 and have found commit
> > 1e2ef05bb8cf851a694d38e9170c89e7ff052741 PM: Limit race conditions between runtime PM and system sleep (v2)
> > to be the first one to introduce the necessity of a module reload after resume.

So with that commit your device doesn't work after resume from system suspend
unless you reload the driver?

> > I hope that this helps in finding a solution. As I (again) don't immediatly
> > know how to go on, I kindly ask you to give me some hints for testing/patching
> > or even a possible solution. :-)

Can you apply the patch below to the current mainline kernel and see if it makes any
difference, please?

Rafael


---
 drivers/base/power/main.c |    4 ----
 1 file changed, 4 deletions(-)

Comments

Jan-Matthias Braun Nov. 29, 2012, 2:03 p.m. UTC | #1

Hi Rafael,

thanks for looking into this.

Am Donnerstag, 29. November 2012, 01:20:04 schrieb Rafael J. Wysocki:
> On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> > On Sun, 25 Nov 2012, Jan-Matthias Braun wrote:
> > > I have now done a git bisection from 3.0 to 3.1 and have found commit
> > > 1e2ef05bb8cf851a694d38e9170c89e7ff052741 PM: Limit race conditions between runtime PM and system sleep (v2)
> > > to be the first one to introduce the necessity of a module reload after resume.
> 
> So with that commit your device doesn't work after resume from system suspend
> unless you reload the driver?

Yes. Additionally, with later kernel revisions even this won't help, but I could imagine this to be a consequence of the same problem.

> > > I hope that this helps in finding a solution. As I (again) don't immediatly
> > > know how to go on, I kindly ask you to give me some hints for testing/patching
> > > or even a possible solution. :-)
> 
> Can you apply the patch below to the current mainline kernel and see if it makes any
> difference, please?

It does: Current mainline kernel (version >3.7.0-rc7 from git) is not showing the problem, if the patch is applied.

Cheers,

Jan

> ---
>  drivers/base/power/main.c |    4 ----
>  1 file changed, 4 deletions(-)
> 
> Index: linux/drivers/base/power/main.c
> ===================================================================
> --- linux.orig/drivers/base/power/main.c
> +++ linux/drivers/base/power/main.c
> @@ -589,8 +589,6 @@ static int device_resume(struct device *
>  	if (!dev->power.is_suspended)
>  		goto Unlock;
>  
> -	pm_runtime_enable(dev);
> -
>  	if (dev->pm_domain) {
>  		info = "power domain ";
>  		callback = pm_op(&dev->pm_domain->ops, state);
> @@ -1136,8 +1134,6 @@ static int __device_suspend(struct devic
>  
>  	if (error)
>  		async_error = error;
> -	else if (dev->power.is_suspended)
> -		__pm_runtime_disable(dev, false);
>  
>  	return error;
>  }
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

Index: linux/drivers/base/power/main.c
===================================================================
--- linux.orig/drivers/base/power/main.c
+++ linux/drivers/base/power/main.c
@@ -589,8 +589,6 @@  static int device_resume(struct device *
 	if (!dev->power.is_suspended)
 		goto Unlock;
 
-	pm_runtime_enable(dev);
-
 	if (dev->pm_domain) {
 		info = "power domain ";
 		callback = pm_op(&dev->pm_domain->ops, state);
@@ -1136,8 +1134,6 @@  static int __device_suspend(struct devic
 
 	if (error)
 		async_error = error;
-	else if (dev->power.is_suspended)
-		__pm_runtime_disable(dev, false);
 
 	return error;
 }