On 07.07.2012 15:55, Eric Ding wrote: > On 07/07/2012 09:11 PM, Oleksij Rempel wrote: >> On 07.07.2012 13:38, Eric Ding wrote: >>> On 07/07/2012 06:09 PM, Oleksij Rempel wrote: >>>> On 07.07.2012 11:20, Eric Ding wrote: >>>>> On 07/06/2012 11:47 PM, Alan Stern wrote: >>>>>> On Fri, 6 Jul 2012, Alan Cox wrote: >>>>>> >>>>>>>> Yes, but we still need to know the reason why. Neither Rafael nor I >>>>>>>> has been able to figure out why that commit messed things up. >>>>>>> >>>>>>> Was the driver doing any dynamic autosuspend at all until that point ? >>>>>> I don't know... but whatever it was doing before the commit, it should >>>>>> be doing the same thing afterward. >>>>> >>>>> I thought that getting some comparative usbmon logs might help, but I'm >>>>> not equipped to parse them. To generate these logs, I ran guvcview once >>>>> after plugging in the webcam, then did the following upon quiting >>>>> guvcview: start listening via usbmon, sleep for four seconds, start >>>>> guvcview again and stop listening via usbmon after four seconds. >>>>> >>>>> I did this both at commit e1620d5 (the commit which triggered this >>>>> issue) and once at commit 9975961 (one commit prior). Going through >>>>> these motions also confirmed that the problem is readily reproducible >>>>> the second time I start guvcview at e1620d5, but not at 9975961. I've >>>>> attached both logs in case they're helpful. >>>> >>>> In both logs you send the cam start to stream video. Major difference is >>>> that, after suspend/resume it need more time (about 10 seconds) to start >>>> stream. Is it correct? >>> >>> My tests didn't continue a full 10 seconds after I restarted the webcam, >>> so I'm not sure I follow your question. In the second case (with >>> e1620d5), the camera never returns a "normal" video image -- instead, it >>> gets a garbled video image of horizontal stripes, which change with what >>> the camera lens is seeing, but are obviously not the correct image. >> >> Ok, i guess i know your problem but i doubt it will be completely fixed >> by changing powermanagement behavior. Two logitech cams i tested is >> really easy to confuse/brake/freeze. Just turn off the stream before it >> will send first frame. It looks like it take longer to boot buildin >> controller or image processor. On second (hot) start it take less time. >> If the cam was suspended it need this boot time again. The problem, even >> if we do hot start and turn of stream before first frame, like some apps >> did, the cam will brake again. By disabling auto suspend, we will reduce >> probability to brake it, but not fix it. >> >> Some times i have the splitimage issue too, but i can't 100% reproduce it. > > So does your description of the problem explain why commit e1620d5 > causes this problem to happen 100% of the time on the second start, even > though I cannot reproduce this problem at all before that commit? Please note, i said "i guess", i'm not sure if it is same issue. With 3.5.0-rc5-00098-g9e85a6f i can't reproduce this issue at least after fresh start. After long work some times i get some thing similar to your description. > Isn't > that the mystery that still remains unsolved? Do the usbmon logs not > answer that question? no. Same configuration sequence, same responses. I see only one difference, on e1620d5 the cam needed longer to start streaming. This is know on other cams, but they work. > Going back also to the patch I submitted, it seems (at least in my > testing) that USB_QUIRK_RESET_RESUME does work around this issue > consistently, at least for my webcam. ok. the problem is, e1620d5 moves existing CONFIG_USB_SUSPEND from one place to another. uvcvideo used autosuspend before. This is why this quirk make no sense. -- Regards, Oleksij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
