On Saturday, July 07, 2012, Alan Stern wrote: > On Sat, 7 Jul 2012, Oleksij Rempel wrote: > > > >> 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. > > I don't think that was the problem. As far as I can tell, the problem > with these Logitech webcams is that they often fail to resume correctly > following a suspend. They require a reset before they will start > working again. > > Apparently the behavior before commit e1620d5 was that the webcam > didn't get suspended, and after the commit it did. Unfortunately > the usbmon traces do not explain this difference; all they show is > when/whether a suspend took place. > > For example, the prelog.9975961.out trace shows that the webcam wasn't > suspended before the trace began, and the postlog.e1620d5.out trace > shows that it was (although when the webcam was resumed, it did work > okay -- this was one of the times it didn't crash during the resume). > > > >> 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. > > The quirk tells Linux to reset the webcam whenever it is resumed. > > > 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. > > Well, the quirk does make sense. What doesn't make sense is why moving > the runtime PM operation pointers from usb_bus_type to usb_device_type > should cause any change in the autosuspend behavior. That's what we > would like to know. I think the reason was the way rpm_suspend() worked at the time of that commit (it works a bit differently now, but not as much as to avoid the problem). Namely, before commit e1620d591a75a10b15cf61dbf8243a0b7e6731a2 the device had a device type without runtime PM callbacks. So, rpm_suspend() saw that dev->type was set and dev->type->pm was set, so it assigned NULL to callback. As a result, nothing happened when rpm_callback(callback, dev) was run. After the change, though, the runtime callbacks are present in usb_device_pm_ops, so the same code assigns the address of usb_runtime_suspend() to callback and the device is actually suspended by rpm_callback(callback, dev). Thanks, Rafael -- 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
