full power management for usb touchscreens

Hi,

this patch series implements:

- full support for suspend/resume/reset_resume
- runtime power management

It does so by adding normal methods for suspend/resume, splitting device intialization into a part that needs to be repeated after reset_resume() and a part that does not.
Runtime power management is possible while the device is active if the device supports remote wakeup, otherwise a fallback to a method based on open/close is implemented.

I lack the hardware. Therefore I need testers.

Quoted 14 lines · Oliver Neukum

Hi,

this patch series implements:

- full support for suspend/resume/reset_resume
- runtime power management

It does so by adding normal methods for suspend/resume, splitting device intialization into a part that needs to be repeated after reset_resume() and a part that does not.
Runtime power management is possible while the device is active if the device supports remote wakeup, otherwise a fallback to a method based on open/close is implemented.

Quoted 1 line

I lack the hardware. Therefore I need testers.

Ondrej,

You are the latest person I know who users usbtouchscreen driver, any chance you could lend a hand to Oliver here, please?

Quoted 14 lines · Oliver Neukum

Hi,

this patch series implements:

- full support for suspend/resume/reset_resume
- runtime power management

It does so by adding normal methods for suspend/resume, splitting device intialization into a part that needs to be repeated after reset_resume() and a part that does not.
Runtime power management is possible while the device is active if the device supports remote wakeup, otherwise a fallback to a method based on open/close is implemented.

Quoted 1 line

I lack the hardware. Therefore I need testers.

Ondrej,

You are the latest person I know who users usbtouchscreen driver, any chance you could lend a hand to Oliver here, please?

(quoted diff) +9 -2

-               err = type->init(usbtouch);
+               err = type->alloc(usbtouch);
                if (err) {
-                       dbg("%s - type->init() failed, err: %d", __func__,
 err); +                       dbg("%s - type->alloc() failed, err: %d",
 __func__, err); goto out_free_urb;
                }
        }
+
+       /* device specific init*/
+       if (type->init) {
+               err = type->alloc(usbtouch);
+               if (err) {
+                       dbg("%s - type->init() failed, err: %d", __func__,
 err); +                       goto out_do_exit;
+               }
+       }
 
        err = input_register_device(usbtouch->input);
        if (err) {

Looking at the patches from archive:

If I understand it correctly, usbtouch_resume submits the irq URB only if the input device is open. That will fail with Nexio as it has an internal watchdog which needs URBs or the device will reconnect - see irq_always (Zytronic seems to need it too).

From 3fe66013333931b4b0cb7361fbe60d502d306eb4 Mon Sep 17 00:00:00 2001

Am Mittwoch, 9. Juni 2010 15:40:04 schrieb Ondrej Zary:

Quoted 6 lines

Looking at the patches from archive:

If I understand it correctly, usbtouch_resume submits the irq URB only if the input device is open. That will fail with Nexio as it has an internal watchdog which needs URBs or the device will reconnect - see irq_always (Zytronic seems to need it too).

Thank you for the review. Does this patch fix the issues?

Regards
Oliver

From 3fe66013333931b4b0cb7361fbe60d502d306eb4 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <[email protected]>
Date: Wed, 9 Jun 2010 18:32:58 +0200
Subject: [PATCH] usbtouchscreen: fix typo and touchpads which require constant polling

1. fix typo
2. start polling on closed devices if they require it

Signed-off-by Oliver Neukum <[email protected]>

---
 drivers/input/touchscreen/usbtouchscreen.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

(quoted diff) +0 -0

b/drivers/input/touchscreen/usbtouchscreen.c index 421f168..d13517a 100644

drivers/input/touchscreen/usbtouchscreen.c +2 -2

@@ -1333,7 +1333,7 @@ static int usbtouch_resume(struct usb_interface
 *intf) int result = 0;
 
 	mutex_lock(&input->mutex);
-	if (input->users)
+	if (input->users || usbtouch->type->irq_always)
 		result = usb_submit_urb(usbtouch->irq, GFP_NOIO);
 	mutex_unlock(&input->mutex);
 	return result;

@@ -1484,7 +1484,7 @@ static int usbtouch_probe(struct usb_interface *intf,
 	usbtouch->irq->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
 
 	/* device specific allocations */
-	if (type->init) {
+	if (type->alloc) {
 		err = type->alloc(usbtouch);
 		if (err) {
 			dbg("%s - type->alloc() failed, err: %d", __func__, err);

Quoted 8 lines

Am Mittwoch, 9. Juni 2010 15:40:04 schrieb Ondrej Zary:

Quoted 6 lines

Looking at the patches from archive:

If I understand it correctly, usbtouch_resume submits the irq URB only if the input device is open. That will fail with Nexio as it has an internal watchdog which needs URBs or the device will reconnect - see irq_always (Zytronic seems to need it too).

Quoted 1 line

Thank you for the review. Does this patch fix the issues?

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

Am Donnerstag, 10. Juni 2010 13:33:57 schrieb Ondrej Zary:

Quoted 9 lines · Oliver Neukum

Quoted 8 lines

Am Mittwoch, 9. Juni 2010 15:40:04 schrieb Ondrej Zary:

Quoted 6 lines

Looking at the patches from archive:

If I understand it correctly, usbtouch_resume submits the irq URB only if the input device is open. That will fail with Nexio as it has an internal watchdog which needs URBs or the device will reconnect - see irq_always (Zytronic seems to need it too).

Quoted 6 lines

Quoted 1 line

Thank you for the review. Does this patch fix the issues?

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

I see. Can you compile with CONFIG_USB_DEBUG and send me the log?

Quoted 6 lines

Quoted 4 lines

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

I see. Can you compile with CONFIG_USB_DEBUG and send me the log?

This can't be fixed - no matter what you do, the device reconnects if you stop talking to it.

Quoted 6 lines

Quoted 4 lines

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

I see. Can you compile with CONFIG_USB_DEBUG and send me the log?

This can't be fixed - no matter what you do, the device reconnects if you stop talking to it.

Am Donnerstag, 10. Juni 2010 16:13:51 schrieb Ondrej Zary:

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

Quoted 4 lines

Quoted 1 line

I see. Can you compile with CONFIG_USB_DEBUG and send me the log?

This can't be fixed - no matter what you do, the device reconnects if you stop talking to it.

Have you tried setting it back to config 0?

Quoted 8 lines

Am Donnerstag, 10. Juni 2010 16:13:51 schrieb Ondrej Zary:

Quoted 7 lines

Quoted 6 lines

Quoted 4 lines

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

I see. Can you compile with CONFIG_USB_DEBUG and send me the log?

Quoted 4 lines

Quoted 2 lines

This can't be fixed - no matter what you do, the device reconnects if you stop talking to it.

Have you tried setting it back to config 0?

No, I haven't. It reconnects even if there's no driver loaded (e.g. older kernel). I don't know if kernel sets configuration on all USB devices upon connect (even if there's no driver).

Am Freitag, 18. Juni 2010 20:34:03 schrieb Ondrej Zary:

Quoted 12 lines · On Friday 18 June 2010 20:22:07 Oliver Neukum wrote:

Quoted 11 lines

Am Donnerstag, 10. Juni 2010 16:13:51 schrieb Ondrej Zary:

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

I see. Can you compile with CONFIG_USB_DEBUG and send me the log?

This can't be fixed - no matter what you do, the device reconnects if you stop talking to it.

Quoted 5 lines

Quoted 1 line

Have you tried setting it back to config 0?

No, I haven't. It reconnects even if there's no driver loaded (e.g. older kernel). I don't know if kernel sets configuration on all USB devices upon connect (even if there's no driver).

Yes, the kernel sets a configuration if the power budget allows it. You can set it back to 0 through sysfs and see what happens.

Quoted 15 lines

Am Freitag, 18. Juni 2010 20:34:03 schrieb Ondrej Zary:

Quoted 14 lines · On Friday 18 June 2010 20:22:07 Oliver Neukum wrote:

Quoted 12 lines

Am Donnerstag, 10. Juni 2010 16:13:51 schrieb Ondrej Zary:

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

I see. Can you compile with CONFIG_USB_DEBUG and send me the log?

This can't be fixed - no matter what you do, the device reconnects if you stop talking to it.

Have you tried setting it back to config 0?

Quoted 6 lines

Quoted 3 lines

No, I haven't. It reconnects even if there's no driver loaded (e.g. older kernel). I don't know if kernel sets configuration on all USB devices upon connect (even if there's no driver).

Yes, the kernel sets a configuration if the power budget allows it. You can set it back to 0 through sysfs and see what happens.

It disconnects and reconnects after bConfigurationValue is set to 0.

Am Dienstag, 22. Juni 2010, 13:06:12 schrieb Ondrej Zary:

Quoted 25 lines · Oliver Neukum

Quoted 23 lines

Am Freitag, 18. Juni 2010 20:34:03 schrieb Ondrej Zary:

Quoted 11 lines · On Friday 18 June 2010 20:22:07 Oliver Neukum wrote:

Quoted 10 lines

Am Donnerstag, 10. Juni 2010 16:13:51 schrieb Ondrej Zary:

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

I haven't tested the patches before. Now I tested them and the Nexio touchscreen does not play well with suspend. It always reconnects after resume from STR or hibernation. Autosuspend is probably never activated at the URBs are submitted continuously.

I see. Can you compile with CONFIG_USB_DEBUG and send me the log?

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

This can't be fixed - no matter what you do, the device reconnects if you stop talking to it.

Have you tried setting it back to config 0?

No, I haven't. It reconnects even if there's no driver loaded (e.g. older kernel). I don't know if kernel sets configuration on all USB devices upon connect (even if there's no driver).

Yes, the kernel sets a configuration if the power budget allows it. You can set it back to 0 through sysfs and see what happens.

Quoted 1 line

It disconnects and reconnects after bConfigurationValue is set to 0.

This is a violation of the spec. Can you give me the IDs so that I can put the devices into the quirks file? Or can I take this from the driver? Do all devices that marked as always needing an irq transfer behave this way?

Quoted 5 lines

This is a violation of the spec. Can you give me the IDs so that I can put the devices into the quirks file? Or can I take this from the driver? Do all devices that marked as always needing an irq transfer behave this way?

This is not a bug surprise as this device is broken in many ways. It takes ages to detect and identify and looks like cdc_acm. The pseudo-multitouch capable protocol is pretty bad too. Also there are some reports about devices using the same ID but different protocol.

I have only one - 1870:0001, don't know anything about the other.

Am Dienstag, 22. Juni 2010, 15:43:24 schrieb Ondrej Zary:

Quoted 11 lines · Oliver Neukum

Quoted 4 lines

This is a violation of the spec. Can you give me the IDs so that I can put the devices into the quirks file? Or can I take this from the driver? Do all devices that marked as always needing an irq transfer behave this way?

This is not a bug surprise as this device is broken in many ways. It takes ages to detect and identify and looks like cdc_acm. The pseudo-multitouch capable protocol is pretty bad too. Also there are some reports about devices using the same ID but different protocol.

Quoted 1 line

I have only one - 1870:0001, don't know anything about the other.

OK, it seems like those devices are hopeless. Could you test this series form harmlessness on a broken device and functionality on a non-broken device?