Hi Alan, > > > > In ALL of the control transfers that I looked at, the time difference > > > > between the SETUP packet and the first IN or OUT packet was never > > > > more than 5 or 6 microseconds. The time difference between the ACK > > > > of the SETUP and the first IN/OUT is around 2 or 3 microseconds. > > > > That's true for the Windows trace as well. > > > > > > I was talking about transactions, not packets. > > > > That's not a good way to talk. Transactions are made up of up to 3 > > packets, so they don't have definite times. Or at least, not as > > definite. > > > > > Let me give you a quick > > > example to make sure we're talking about the same thing: > > > > > > luvcview-error-32-on-set-cur: > > > > Right. > > > > > The failed SetCur at 7.126 > > > > I don't know what's going on, but your timestamps don't agree with the > > ones I see. On my system, that file begins at time 3.314 with normal > > device initialization, proceeding through SetConfig at 4.069 and SetCur, > > GetDef, SetCur, and IN ending at 4.158. There there is a whole bunch of > > appended data which starts at 7.270. The failed SetCur is near the end > > at 10.804. > > > > > has 479 microseconds between the SETUP > > > transaction and the OUT transaction (with plenty of PINGs in between). > > > > Um, no. There is 479 us between the SETUP and the final failed OUT. But > > here's what actually happens: > > > > SETUP 10.804 455 550 > > DATA0 455 983 > > ACK 456 467 > > > > OUT 10.804 459 400 > > DATA1 459 833 > > NAK 460 800 > > > > ... Lots of PINGs. Some get NAK. Some get ACK, after which > > the host sends OUT, DATA1, and the device replies NAK... > > Eventually the transfer fails with this transaction: > > > > OUT 10.804 934 500 > > DATA1 934 917 > > STALL 935 883 > > > > As you can see, there is a gap of only 3.85 us between the SETUP packet > > and the first OUT packet (only 2.933 us between the ACK and the first > > OUT). > > > > > The > > > successful SetCur right before it, at 7.104, has 866 microseconds > > > between the same transactions (with more PINGs in between). > > > > On my system there is a successful SetCur 22 ms before the failed one. > > Presumably that's the one you're talking about. The timing between the > > SETUP transaction and the first OUT transaction is similar to the timing > > above. The interval between the SETUP and the _last_ OUT is 866 us. > > > > > What controls this difference in timing? From my understanding of the > > > earlier messages in this thread, this is the EHCI controller and cannot > > > directly be influenced by the kernel, right? > > > > No. The timing you're worried about, i.e., the time between the SETUP > > transaction and the failed OUT transaction, is determined by when the > > STALL is received. And it's the device that sends the STALL. > > > > In short, the timing is controller by the device, not the EHCI > > controller, and it cannot directly be influenced by the kernel. > > Did anything ever come out of all this? Was the problem located and was > the firmware fixed?
As far as I know, no :-( Martin has finished his thesis and doesn't work at Logitech anymore. He told me before leaving that the firmware developers will definitely implement a workaround for the hardware bug. New cameras won't suffer from the problem, but we have a bunch of old cameras in the field that work fine under Windows and fail miserably under Linux. I'd really like to solve the problem on the software side. There is very little the driver can do, as the issue lies at the USB level. The device is at fault, but Windows doesn't trigger the bug. I'm pretty sure Windows and Linux handle control transfers differently. Can you see another explanation ? I'm not familiar with the USB stack internals, but I wouldn't mind getting my hands dirty. Could you tell me where I should look at ? Anything that comes to your mind ? Laurent Pinchart ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
