On Sat, 15 Dec 2007, Laurent Pinchart wrote:

quoted text
> 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.

As far as I know, neither EHCI nor OHCI hardware offers any reasonable 
way to schedule transactions in separate frames, unless the device runs 
at low speed (in which case it wouldn't be handled by EHCI anyway).

It does seem odd that a device with an interface designed to run at 
high speed would be crippled so that it couldn't take advantage of that 
speed.

quoted text
> > > 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.

Above you said the device misses the status-stage interrupt.  Do you 
know which one actually causes the problem?

It's worth mentioning that the device doesn't have any trouble handling
the control transfers during enumeration.  But that may be
understandable, because they are probably handled by very different
code in the firmware.

I'd have to go back and check to be certain, but I don't recall the bus 
traces I've seen of Windows high-speed transfers showing that the 
transactions making up a control message are scheduled in different 
frames (or micro-frames).

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