Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi,
On Thu, Jul 14, 2011 at 11:03 PM, Alan Stern st...@rowland.harvard.edu wrote:
More likely, the reset erases some device setting that uvcvideo
installed while binding. Evidently uvcvideo does not re-install the
setting during reset-resume; this is probably a bug in the driver.
Alan, you are right.
I think I have found the root cause. Given many devices can't
handle set_interface(0) if the interfaces were already in altsetting 0,
usb_reset_and_verify_device does not run set_interface(0). So we
need to do it in .reset_resume handler of uvc driver and it is always
safe for uvc devices.
I have tested the below patch, and it can make the uvc device work
well after rpm resume and system resume(reset resume), both in
streaming on and off case.
Alan, Laurent, if you have no objections, I will submit a formal one.
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index b6eae48..4055dfc 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -1959,8 +1959,12 @@ static int __uvc_resume(struct usb_interface
*intf, int reset)
}
list_for_each_entry(stream, dev-streams, list) {
- if (stream-intf == intf)
+ if (stream-intf == intf) {
+ if (reset)
+ usb_set_interface(stream-dev-udev,
+ stream-intfnum, 0);
return uvc_video_resume(stream);
+ }
}
uvc_trace(UVC_TRACE_SUSPEND, Resume: video streaming USB interface
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Fri, 15 Jul 2011, Ming Lei wrote:
Hi,
On Thu, Jul 14, 2011 at 11:03 PM, Alan Stern st...@rowland.harvard.edu
wrote:
More likely, the reset erases some device setting that uvcvideo
installed while binding. �Evidently uvcvideo does not re-install the
setting during reset-resume; this is probably a bug in the driver.
Alan, you are right.
I think I have found the root cause. Given many devices can't
handle set_interface(0) if the interfaces were already in altsetting 0,
usb_reset_and_verify_device does not run set_interface(0). So we
need to do it in .reset_resume handler of uvc driver and it is always
safe for uvc devices.
I have tested the below patch, and it can make the uvc device work
well after rpm resume and system resume(reset resume), both in
streaming on and off case.
Alan, Laurent, if you have no objections, I will submit a formal one.
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index b6eae48..4055dfc 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -1959,8 +1959,12 @@ static int __uvc_resume(struct usb_interface
*intf, int reset)
}
list_for_each_entry(stream, dev-streams, list) {
- if (stream-intf == intf)
+ if (stream-intf == intf) {
+ if (reset)
+ usb_set_interface(stream-dev-udev,
+ stream-intfnum, 0);
return uvc_video_resume(stream);
+ }
}
uvc_trace(UVC_TRACE_SUSPEND, Resume: video streaming USB interface
This is fine with me. However, it is strange that the Set-Interface
request is necessary. After being reset, the device should
automatically be in altsetting 0 for all interfaces.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Fri, Jul 15, 2011 at 10:27 PM, Alan Stern st...@rowland.harvard.edu wrote: This is fine with me. However, it is strange that the Set-Interface request is necessary. After being reset, the device should automatically be in altsetting 0 for all interfaces. For uvc devices, seems it is not strange, see uvc_video_init(), which is called in .probe path and executes Set-Interface 0 first, then starts to get/set video control. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Fri, 15 Jul 2011, Ming Lei wrote: Hi, On Fri, Jul 15, 2011 at 10:27 PM, Alan Stern st...@rowland.harvard.edu wrote: This is fine with me. �However, it is strange that the Set-Interface request is necessary. �After being reset, the device should automatically be in altsetting 0 for all interfaces. For uvc devices, seems it is not strange, see uvc_video_init(), which is called in .probe path and executes Set-Interface 0 first, then starts to get/set video control. I see what you mean. Apparently other UVC devices also need to receive a Set-Interface(0) request before they will work right. (It's still strange, though...) Anyway, since the driver does this during probe, it makes sense to do it during reset-resume as well. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi,
On Wed, Jul 13, 2011 at 11:59 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 13 Jul 2011, Ming Lei wrote:
Almost same.
Come on. Almost same means they are different. That difference is
clearly the important thing you need to track down.
I didn't say entirely same because we can't trace the packets via usbmon
during system resume, but we can do it during runtime resume.
In fact, except for above, the packets captured from interrupt ep and control ep
are completely same. Also all functions in uvc (rpm, system)resume path return
successfully.
If I add USB_QUIRK_RESET_RESUME quirk for the device,
the stream data will not be received from the device in runtime pm case,
same with that in system suspend.
uvcvideo should be able to reinitialize the device so that it works
correctly following a reset. If the device doesn't work then uvcvideo
has a bug in its reset_resume handler.
This also indicates the usb reset during resume does make the uvc device
broken.
Maybe buggy BIOS makes root hub send reset signal to the device during
system suspend time, not sure...
That's entirely possible.
The below quirk fixes the issue now.
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 81ce6a8..93c6fa2 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -82,6 +82,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Broadcom BCM92035DGROM BT dongle */
{ USB_DEVICE(0x0a5c, 0x2021), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Microdia uvc camera */
+ { USB_DEVICE(0x0c45, 0x6437), .driver_info = USB_QUIRK_RESET_MORPHS },
+
/* Action Semiconductor flash disk */
{ USB_DEVICE(0x10d6, 0x2200), .driver_info =
USB_QUIRK_STRING_FETCH_255 },
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Thu, 14 Jul 2011, Ming Lei wrote:
Hi,
On Wed, Jul 13, 2011 at 11:59 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Wed, 13 Jul 2011, Ming Lei wrote:
Almost same.
Come on. �Almost same means they are different. �That difference is
clearly the important thing you need to track down.
I didn't say entirely same because we can't trace the packets via usbmon
during system resume, but we can do it during runtime resume.
In fact, except for above, the packets captured from interrupt ep and control
ep
are completely same. Also all functions in uvc (rpm, system)resume path
return
successfully.
All right; this tends to confirm your guess that the BIOS messes up the
device by resetting it during system resume.
�If I add USB_QUIRK_RESET_RESUME quirk for the device,
the stream data will not be received from the device in runtime pm case,
same with that in system suspend.
uvcvideo should be able to reinitialize the device so that it works
correctly following a reset. �If the device doesn't work then uvcvideo
has a bug in its reset_resume handler.
This also indicates the usb reset during resume does make the uvc device
broken.
Resetting the device doesn't actually _break_ it -- if it did then the
device would _never_ work because the first thing that usbcore does to
initialize a new device is reset it!
More likely, the reset erases some device setting that uvcvideo
installed while binding. Evidently uvcvideo does not re-install the
setting during reset-resume; this is probably a bug in the driver.
The below quirk fixes the issue now.
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 81ce6a8..93c6fa2 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -82,6 +82,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Broadcom BCM92035DGROM BT dongle */
{ USB_DEVICE(0x0a5c, 0x2021), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Microdia uvc camera */
+ { USB_DEVICE(0x0c45, 0x6437), .driver_info = USB_QUIRK_RESET_MORPHS },
+
/* Action Semiconductor flash disk */
{ USB_DEVICE(0x10d6, 0x2200), .driver_info =
USB_QUIRK_STRING_FETCH_255 },
It would be better to fix uvcvideo, if you could figure out what it
needs to do differently. This quirk is only a workaround, because the
device doesn't really morph.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi,
On Thu, Jul 14, 2011 at 11:03 PM, Alan Stern st...@rowland.harvard.edu wrote:
All right; this tends to confirm your guess that the BIOS messes up the
device by resetting it during system resume.
Yes. BIOS messes the device first, then usbcore has to reset the device
at the end of resume, so the device behaves badly: ISO transfer oddly
This also indicates the usb reset during resume does make the uvc device
broken.
Resetting the device doesn't actually _break_ it -- if it did then the
device would _never_ work because the first thing that usbcore does to
initialize a new device is reset it!
I means the reset in resume breaks the device, not the reset in enumeration, :-)
(the only extra reset in rpm resume will make the device not work)
More likely, the reset erases some device setting that uvcvideo
installed while binding. Evidently uvcvideo does not re-install the
setting during reset-resume; this is probably a bug in the driver.
Yes, maybe some settings inside device have changed after the
reset signal, I don't know if it is a normal behaviour.
I have tried to add some code in .probe path to .resume path,
but still not make it work. Anyway, it is not easy thing, because we
have not the internal knowledge of uvc device implementation, and
have to try it by guess.
The below quirk fixes the issue now.
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 81ce6a8..93c6fa2 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -82,6 +82,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Broadcom BCM92035DGROM BT dongle */
{ USB_DEVICE(0x0a5c, 0x2021), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Microdia uvc camera */
+ { USB_DEVICE(0x0c45, 0x6437), .driver_info = USB_QUIRK_RESET_MORPHS },
+
/* Action Semiconductor flash disk */
{ USB_DEVICE(0x10d6, 0x2200), .driver_info =
USB_QUIRK_STRING_FETCH_255 },
It would be better to fix uvcvideo, if you could figure out what it
needs to do differently. This quirk is only a workaround, because the
device doesn't really morph.
In fact we can understand the quirk is used to avoid reset in system resume,
which is one of its original purpose too.
I will do some tests to figure out solution in uvc driver, but I am
not sure I can
find it quickly because I debug it remotely and network is very
slowly. If I can't
find out the solution in uvc driver, could you accept the workaround of
USB_QUIRK_RESET_MORPHS first?
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Tue, Jul 12, 2011 at 11:44 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 12 Jul 2011, Ming Lei wrote: Hi Laurent, After resume from sleep, all the ISO packets from camera are like below: 880122d9f400 3527230728 S Zi:1:004:1 -115:1:2568 32 -18:0:1600 -18:1600:1600 -18:3200:1600 -18:4800:1600 -18:6400:1600 51200 880122d9d400 3527234708 C Zi:1:004:1 0:1:2600:0 32 0:0:12 0:1600:12 0:3200:12 0:4800:12 0:6400:12 51200 = 0c8c fa7e 012f1b05 All are headed with 0c8c, see attached usbmon captures. Maybe this device needs a USB_QUIRK_RESET_RESUME entry in quirks.c. I will try it, but seems unbindbind driver don't produce extra usb reset signal to the device. Also, the problem didn't happen in runtime pm case, just happen in wakeup from system suspend case. uvcvideo has enabled auto suspend already at default. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Tue, Jul 12, 2011 at 11:44 PM, Alan Stern st...@rowland.harvard.edu wrote: Maybe this device needs a USB_QUIRK_RESET_RESUME entry in quirks.c. RESET_RESUME quirk makes things worse, now stream data is not received from the camera at all even in resume from runtime suspend case. So the quirk can make the device totally useless, :-) thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Tuesday 12 July 2011 03:21:05 Ming Lei wrote: On Mon, Jul 11, 2011 at 6:44 PM, Laurent Pinchart wrote: That's unfortunately not acceptable as-is. If two cameras are connected to the system, and only one of them doesn't support suspend/resume, the other will be affected by your patch. Yes, other cameras may be affected, but they still can work well, so the patch still makes sense. They can still work, but not optimally, as they will be reset instead of suspended/resumed. That's not acceptable. Have you tried to investigate why suspend/resume fails for the above-mentioned camera, instead of working around the problem ? I have investigated the problem, and not found failures in the suspend/resume path, either .suspend or .resume callback return successful, but no stream packets are received from camera any longer after resume from sleep. Once doing a unbind bind will make the camera work again. Could you give any suggestions to help to find the root cause of the problem? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Wed, Jul 13, 2011 at 4:38 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: They can still work, but not optimally, as they will be reset instead of suspended/resumed. That's not acceptable. If the reset you mentioned is usb bus reset signal, I think unbindbind will not produce the reset signal. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Am Mittwoch, 13. Juli 2011, 10:51:11 schrieb Ming Lei: Hi, On Wed, Jul 13, 2011 at 4:38 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: They can still work, but not optimally, as they will be reset instead of suspended/resumed. That's not acceptable. If the reset you mentioned is usb bus reset signal, I think unbindbind will not produce the reset signal. You are correct. It will not. Regards Oliver -- - - - SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany - - - -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Wednesday 13 July 2011 10:51:11 Ming Lei wrote: On Wed, Jul 13, 2011 at 4:38 PM, Laurent Pinchart wrote: They can still work, but not optimally, as they will be reset instead of suspended/resumed. That's not acceptable. If the reset you mentioned is usb bus reset signal, I think unbindbind will not produce the reset signal. Sorry, I haven't been clear. If you remove the suspend/resume handlers from the driver, the USB core will unbind and rebind the driver instead of suspending/resuming the device properly. As this will affect other UVC devices as well, that's not a good solution. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Wed, Jul 13, 2011 at 4:59 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Sorry, I haven't been clear. If you remove the suspend/resume handlers from the driver, the USB core will unbind and rebind the driver instead of suspending/resuming the device properly. As this will affect other UVC devices as well, that's not a good solution. I agree with you this is not a good solution, but seems there are no other solutions for the buggy device. You are uvc expert, could you give some suggestion about accepted solutions? thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Wed, 13 Jul 2011, Ming Lei wrote: Hi, On Tue, Jul 12, 2011 at 11:44 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 12 Jul 2011, Ming Lei wrote: Hi Laurent, After resume from sleep, �all the ISO packets from camera are like below: 880122d9f400 3527230728 S Zi:1:004:1 -115:1:2568 32 -18:0:1600 -18:1600:1600 -18:3200:1600 -18:4800:1600 -18:6400:1600 51200 880122d9d400 3527234708 C Zi:1:004:1 0:1:2600:0 32 0:0:12 0:1600:12 0:3200:12 0:4800:12 0:6400:12 51200 = 0c8c fa7e 012f1b05 All are headed with 0c8c, see attached usbmon captures. Maybe this device needs a USB_QUIRK_RESET_RESUME entry in quirks.c. I will try it, but seems unbindbind driver don't produce extra usb reset signal to the device. Also, the problem didn't happen in runtime pm case, just happen in wakeup from system suspend case. uvcvideo has enabled auto suspend already at default. Why should system suspend be different from runtime suspend? Have you compared usbmon traces for the two types of suspend? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Wed, Jul 13, 2011 at 11:20 PM, Alan Stern st...@rowland.harvard.edu wrote: Why should system suspend be different from runtime suspend? Have you This is also my puzzle, :-) compared usbmon traces for the two types of suspend? Almost same. If I add USB_QUIRK_RESET_RESUME quirk for the device, the stream data will not be received from the device in runtime pm case, same with that in system suspend. Maybe buggy BIOS makes root hub send reset signal to the device during system suspend time, not sure... thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Wed, 13 Jul 2011, Ming Lei wrote: Hi, On Wed, Jul 13, 2011 at 11:20 PM, Alan Stern st...@rowland.harvard.edu wrote: Why should system suspend be different from runtime suspend? �Have you This is also my puzzle, :-) compared usbmon traces for the two types of suspend? Almost same. Come on. Almost same means they are different. That difference is clearly the important thing you need to track down. If I add USB_QUIRK_RESET_RESUME quirk for the device, the stream data will not be received from the device in runtime pm case, same with that in system suspend. uvcvideo should be able to reinitialize the device so that it works correctly following a reset. If the device doesn't work then uvcvideo has a bug in its reset_resume handler. Maybe buggy BIOS makes root hub send reset signal to the device during system suspend time, not sure... That's entirely possible. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi Laurent, After resume from sleep, all the ISO packets from camera are like below: 880122d9f400 3527230728 S Zi:1:004:1 -115:1:2568 32 -18:0:1600 -18:1600:1600 -18:3200:1600 -18:4800:1600 -18:6400:1600 51200 880122d9d400 3527234708 C Zi:1:004:1 0:1:2600:0 32 0:0:12 0:1600:12 0:3200:12 0:4800:12 0:6400:12 51200 = 0c8c fa7e 012f1b05 All are headed with 0c8c, see attached usbmon captures. thanks, -- Ming Lei usb.tar.gz Description: GNU Zip compressed data
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Tue, 12 Jul 2011, Ming Lei wrote: Hi Laurent, After resume from sleep, all the ISO packets from camera are like below: 880122d9f400 3527230728 S Zi:1:004:1 -115:1:2568 32 -18:0:1600 -18:1600:1600 -18:3200:1600 -18:4800:1600 -18:6400:1600 51200 880122d9d400 3527234708 C Zi:1:004:1 0:1:2600:0 32 0:0:12 0:1600:12 0:3200:12 0:4800:12 0:6400:12 51200 = 0c8c fa7e 012f1b05 All are headed with 0c8c, see attached usbmon captures. Maybe this device needs a USB_QUIRK_RESET_RESUME entry in quirks.c. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi,
On Monday 11 July 2011 11:48:11 Ming Lei wrote:
From 989d894a2af7ceadf2574f455d9e68779f4ae674 Mon Sep 17 00:00:00 2001
From: Ming Lei ming@canonical.com
Date: Mon, 11 Jul 2011 17:04:31 +0800
Subject: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
We found this type(0c45:6437) of Microdia camera does not
work(no stream packets sent out from camera any longer) after
resume from sleep, but unbind/bind driver will work again.
So introduce the quirk of UVC_QUIRK_FIX_SUSPEND_RESUME to
fix the problem for this type of Microdia camera.
Thank you for the patch.
[snip]
+ /* For some buggy cameras, they will not work after wakeup, so
+ * do unbind in .usb_suspend and do rebind in .usb_resume to
+ * make it work again.
+ * */
+ if (dev-quirks UVC_QUIRK_FIX_SUSPEND_RESUME) {
+ uvc_driver.driver.suspend = NULL;
+ uvc_driver.driver.resume = NULL;
+ } else {
+ uvc_driver.driver.suspend = uvc_suspend;
+ uvc_driver.driver.resume = uvc_resume;
+ }
+
That's unfortunately not acceptable as-is. If two cameras are connected to the
system, and only one of them doesn't support suspend/resume, the other will be
affected by your patch.
Have you tried to investigate why suspend/resume fails for the above-mentioned
camera, instead of working around the problem ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hello. On 11-07-2011 13:48, Ming Lei wrote: From 989d894a2af7ceadf2574f455d9e68779f4ae674 Mon Sep 17 00:00:00 2001 From: Ming Leiming@canonical.com Date: Mon, 11 Jul 2011 17:04:31 +0800 Subject: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera Please omit this header when sending patches. We found this type(0c45:6437) of Microdia camera does not work(no stream packets sent out from camera any longer) after resume from sleep, but unbind/bind driver will work again. So introduce the quirk of UVC_QUIRK_FIX_SUSPEND_RESUME to fix the problem for this type of Microdia camera. You didn't sign off. --- drivers/media/video/uvc/uvc_driver.c | 146 +++--- drivers/media/video/uvc/uvcvideo.h |1 + 2 files changed, 84 insertions(+), 63 deletions(-) diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c index b6eae48..2b356c3 100644 --- a/drivers/media/video/uvc/uvc_driver.c +++ b/drivers/media/video/uvc/uvc_driver.c @@ -1787,6 +1787,68 @@ static int uvc_register_chains(struct uvc_device *dev) [...] @@ -1888,6 +1950,18 @@ static int uvc_probe(struct usb_interface *intf, supported.\n, ret); } + /* For some buggy cameras, they will not work after wakeup, so +* do unbind in .usb_suspend and do rebind in .usb_resume to +* make it work again. +* */ The preferred style is: /* * bla * bla */ WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, Thanks for your reply. On Mon, Jul 11, 2011 at 6:44 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: That's unfortunately not acceptable as-is. If two cameras are connected to the system, and only one of them doesn't support suspend/resume, the other will be affected by your patch. Yes, other cameras may be affected, but they still can work well, so the patch still makes sense. Have you tried to investigate why suspend/resume fails for the above-mentioned camera, instead of working around the problem ? I have investigated the problem, and not found failures in the suspend/resume path, either .suspend or .resume callback return successful, but no stream packets are received from camera any longer after resume from sleep. Once doing a unbind bind will make the camera work again. Could you give any suggestions to help to find the root cause of the problem? thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
