Message ID | CACVXFVOHqze=HRxhwmfDaDEs9bQ7rsAi9P4WFwn1OY3G4x5hTg@mail.gmail.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-path: <linux-media-owner@vger.kernel.org> Envelope-to: mchehab@infradead.org Delivery-date: Thu, 14 Jul 2011 09:16:36 +0000 Received: from casper.infradead.org [85.118.1.10] by localhost.localdomain with IMAP (fetchmail-6.3.17) for <mchehab@localhost> (single-drop); Thu, 14 Jul 2011 07:14:23 -0300 (BRT) Received: from vger.kernel.org ([209.132.180.67]) by casper.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QhI27-0002fm-L8; Thu, 14 Jul 2011 09:16:35 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752606Ab1GNJQc (ORCPT <rfc822; kmpark@infradead.org> + 1 other); Thu, 14 Jul 2011 05:16:32 -0400 Received: from mail-gy0-f174.google.com ([209.85.160.174]:57007 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510Ab1GNJQb convert rfc822-to-8bit (ORCPT <rfc822;linux-media@vger.kernel.org>); Thu, 14 Jul 2011 05:16:31 -0400 Received: by gyh3 with SMTP id 3so23033gyh.19 for <multiple recipients>; Thu, 14 Jul 2011 02:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CYLrlK66Pw5pei9TnG/C9bM5zCiHwEcEniiHdZdq3sQ=; b=OY8prPeR8RGNYtTtK/o2OK+ZKrW5kh4J4chryuDei925UhH8qGX18bDVnGtPN7TuQ/ eRsJCig7QZApJ4ViC/EgaI5zvxSsgEqJSEamFMHvqPaLlC23tgiSvbl+WZ33XwLDuno4 xciNm5shpVMXN0KC4DXMec19r0NyquCrRskGA= MIME-Version: 1.0 Received: by 10.236.176.36 with SMTP id a24mr2693326yhm.284.1310634990647; Thu, 14 Jul 2011 02:16:30 -0700 (PDT) Received: by 10.236.70.101 with HTTP; Thu, 14 Jul 2011 02:16:30 -0700 (PDT) In-Reply-To: <Pine.LNX.4.44L0.1107131154390.2156-100000@iolanthe.rowland.org> References: <CACVXFVPJvuzKZetupzBf+GhwZKV10EHjpNUwTz98sweH3xkd4w@mail.gmail.com> <Pine.LNX.4.44L0.1107131154390.2156-100000@iolanthe.rowland.org> Date: Thu, 14 Jul 2011 17:16:30 +0800 Message-ID: <CACVXFVOHqze=HRxhwmfDaDEs9bQ7rsAi9P4WFwn1OY3G4x5hTg@mail.gmail.com> Subject: Re: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera From: Ming Lei <tom.leiming@gmail.com> To: Alan Stern <stern@rowland.harvard.edu> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Ming Lei <ming.lei@canonical.com>, linux-media@vger.kernel.org, linux-usb@vger.kernel.org, Jeremy Kerr <jeremy.kerr@canonical.com>, Mauro Carvalho Chehab <mchehab@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org |
Commit Message
Ming Lei
July 14, 2011, 9:16 a.m. UTC
Hi, On Wed, Jul 13, 2011 at 11:59 PM, Alan Stern <stern@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. thanks,
Comments
On Thu, 14 Jul 2011, Ming Lei wrote: > Hi, > > On Wed, Jul 13, 2011 at 11:59 PM, Alan Stern <stern@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-usb" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Jul 14, 2011 at 11:03 PM, Alan Stern <stern@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,
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 },