Hi,
On Thu, Jul 14, 2011 at 11:03 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
