I should have guessed that the mailing list rejects html attachments. Here's the mail again with the plain text dump only.
On Saturday 15 December 2007, Greg KH wrote: > On Sat, Dec 15, 2007 at 11:56:02AM +0100, Laurent Pinchart wrote: > > On Friday 14 December 2007, Greg KH wrote: > > > On Fri, Dec 14, 2007 at 12:56:41PM -0200, Mauro Carvalho Chehab wrote: > > > > Em Sex, 2007-12-14 ??s 13:41 +0100, Laurent Pinchart escreveu: > > > > > Controls are queried with a single USB > > > > > control request, which is made of several USB transactions, in turn > > > > > made of several USB packets (have a look at the USB spec for > > > > > reference). usb_control_message. The corresponding kernel API is > > > > > usb_control_msg. I call it exactly once in the driver, and the EHCI > > > > > driver splits that into several transactions. Windows schedules the > > > > > transactions with larger time intervals than Linux does, so the > > > > > device sometimes fails with Linux. Timings depend on the EHCI > > > > > driver only (or OHCI or UHCI when using those controllers). The > > > > > device driver (uvcvideo in this case) has no control whatsoever on > > > > > the timings. > > > > > > > > IMO, we need a feature to enable a quirk at EHCI/OHCI/UHCI to slow > > > > down the speed between two consecutive transactions for those bad > > > > chips. > > > > > > > > Maybe Greg or Brandon may give some light about this. > > > > > > > > Greg/Brandon, > > > > > > > > The issue here is that some USB bad UVC chips got garbled when the > > > > intervals between consecutive transactions for the same usb control > > > > message occurs too fast. > > > > > > Heh, that's too funny. I have read a lot of reports of people on the > > > windows driver mailing lists complaining that Vista slowed down their > > > drivers, looks like some companies are relying on that slow speed :) > > > > > > > Is there a way to slow it down, for some specific devices? > > > > > > Just send smaller commands that don't get broken up by the host > > > controller? Then you can control the timing between submissions. > > > > I don't think that would work (I'm not actually sure to understand your > > advice :-)). > > > > The broken devices we are talking about have trouble with USB control > > requests. I'm still not 100% sure about this, but it seems the device > > misses the interrupt associated with the control transfer's status stage. > > Windows seems to schedule the setup and status transactions in different > > frames, while Linux seems to pack them in the same frame. > > Ok, I'm confused, can you please show me the commands that are failing > here? Can you use usbmon and show the dump of when this fails? I attached a dump to this e-mail. It shows the device enumeration process and two control requests initiated by the UVC driver (URBs 43 to 46). I added a 5 seconds delay before each request to make sure the device has time to initialize/recover/whatever. The first request is successful while the second isn't. It should be noted that on other computers both request succeed. From the information Logitech developers have been able to gather, the device receives the second request setup transaction but misses the data stage interrupt. It then just times out. > The linux-usb list should also be involved, please send the information > to them too. Ok done. Best regards, Laurent Pinchart
f6023440 3922419709 S Ii:001:01 -115 4 < e4f12340 3922419744 S Ci:001:00 s a3 00 0000 0001 0004 4 < e4f12340 3922419749 C Ci:001:00 0 4 = 00010000 e4f12340 3922419753 S Ci:001:00 s a3 00 0000 0002 0004 4 < e4f12340 3922419755 C Ci:001:00 0 4 = 01050100 e4f12340 3922419757 S Co:001:00 s 23 01 0010 0002 0000 0 e4f12340 3922419759 C Co:001:00 0 0 e4f12340 3922419761 S Ci:001:00 s a3 00 0000 0002 0004 4 < e4f12340 3922419763 C Ci:001:00 0 4 = 01050000 e4f12340 3922449708 S Ci:001:00 s a3 00 0000 0002 0004 4 < e4f12340 3922449716 C Ci:001:00 0 4 = 01050000 e4f12340 3922479706 S Ci:001:00 s a3 00 0000 0002 0004 4 < e4f12340 3922479713 C Ci:001:00 0 4 = 01050000 e4f12340 3922509708 S Ci:001:00 s a3 00 0000 0002 0004 4 < e4f12340 3922509716 C Ci:001:00 0 4 = 01050000 e4f12340 3922539706 S Ci:001:00 s a3 00 0000 0002 0004 4 < e4f12340 3922539711 C Ci:001:00 0 4 = 01050000 e4f12340 3922539724 S Co:001:00 s 23 03 0004 0002 0000 0 e4f12340 3922539727 C Co:001:00 0 0 e4f12340 3922593043 S Ci:001:00 s a3 00 0000 0002 0004 4 < e4f12340 3922593068 C Ci:001:00 0 4 = 03051000 e4f12340 3922646437 S Co:001:00 s 23 01 0014 0002 0000 0 e4f12340 3922646444 C Co:001:00 0 0 e4f12340 3922646489 S Ci:000:00 s 80 06 0100 0000 0040 64 < e4f12340 3922651162 C Ci:000:00 0 18 = 12010002 00000140 6d04c308 05000000 0001 e4f12340 3922651170 S Co:001:00 s 23 03 0004 0002 0000 0 e4f12340 3922651178 C Co:001:00 0 0 e4f12340 3922703038 S Ci:001:00 s a3 00 0000 0002 0004 4 < e4f12340 3922703081 C Ci:001:00 0 4 = 03051000 e4f12340 3922756378 S Co:001:00 s 23 01 0014 0002 0000 0 e4f12340 3922756386 C Co:001:00 0 0 e4f12340 3922756392 S Co:000:00 s 00 05 0004 0000 0000 0 e4f12340 3922756427 C Co:000:00 0 0 e4f12340 3922773040 S Ci:004:00 s 80 06 0100 0000 0012 18 < e4f12340 3922777805 C Ci:004:00 0 18 = 12010002 00000140 6d04c308 05000000 0001 e4f12340 3922777816 S Ci:004:00 s 80 06 0200 0000 0009 9 < e4f12340 3922789179 C Ci:004:00 0 9 = 09025105 04010080 fa e4f12340 3922789186 S Ci:004:00 s 80 06 0200 0000 0551 1361 < e4f12340 3922957707 C Ci:004:00 0 1361 = 09025105 04010080 fa080b00 02ff0300 00090400 0001ff01 00000d24 0100016a f67f0940 3922957967 S Co:004:00 s 00 09 0001 0000 0000 0 f67f0940 3922958201 C Co:004:00 0 0 e4f12940 3922958504 S Co:004:00 s 01 0b 0000 0001 0000 0 e4f12940 3922958575 C Co:004:00 0 0 e4f126c0 3927959720 S Ci:004:00 s a1 87 0100 0001 001a 26 < e4f126c0 3927965688 C Ci:004:00 0 26 = 00000101 40420f00 00000000 04000000 0000003c 0000c000 0000 e4f12940 3932966385 S Co:004:00 s 21 01 0200 0001 001a 26 = 00000101 40420f00 00000000 04000000 0000003c 0000c000 0000 e4f12940 3933966421 C Co:004:00 -2 0
