On Tue, 15 Oct 2013, Marcus Overhagen wrote: > Hello, > > I made a change to the rts5139 driver that got included in kernel 3.11 > (see second patch at end of this email), but Lutz Vieweg reported that > the patch causes issues for him, because the driver falsely detects > that the SD card is no longer present after transfer of a few 100 MBs. Why does the driver make this mistake? > I do not have this issue with xhci. He is using ehci. > > The USB endpoint specifies a transfer interval of 10. The rts5139 Does the device connect at high speed (480 Mb/s)? > driver uses the interrupt transfer to infrequently poll for card > presence, but doesn't queue multiple urbs for periodic transfers. > > The issue seems to be a difference in how early the (first) interrupt > transfer is scheduled by xhci and ehci when the interval specified in > the urb is not 1. > > With ehci it seems to be delayed when the interval is not 1. > With xhci you get warning messages in syslog if interval is not 10. > > My USB knowledge is too limited to properly fix this in xhci or ehci hcd. What needs to be fixed? It sounds like xhci-hcd and ehci-hcd are working correctly and the problem is in the rts5139 driver. > Can somebody help me? what is the correct fix for this problem? > > It is possible that the following patch, that increases the timeout > the driver waits for the interrupt transfer, will fix the problem with ehci. > However, I expect that the transfer is slightly slower then with ehci, > compared to kernel 3.10. bInterval = 10 means the polling period is 64 ms (for a high-speed device). So a timeout of 100 ms should be adequate -- provided the device always sends data over the interrupt endpoint without any further delay. Alan Stern -- 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
