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.
I do not have this issue with xhci. He is using ehci.
The USB endpoint specifies a transfer interval of 10. The rts5139
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.
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.
regards
Marcus
==============
Proposed "fix" (workaround)
diff --git a/drivers/staging/rts5139/
rts51x_transport.c
b/drivers/staging/rts5139/rts51x_transport.c
index c172f4a..c4ede32 100644
--- a/drivers/staging/rts5139/rts51x_transport.c
+++ b/drivers/staging/rts5139/rts51x_transport.c
@@ -640,7 +640,7 @@ int rts51x_get_epc_status(struct rts51x_chip
*chip, u16 *status)
usb_fill_int_urb(chip->usb->intr_urb, chip->usb->pusb_dev, pipe,
status, 2, urb_done_completion, &urb_done, 10);
- result = rts51x_msg_common(chip, chip->usb->intr_urb, 100);
+ result = rts51x_msg_common(chip, chip->usb->intr_urb, 500);
return interpret_urb_result(chip, pipe, 2, result,
chip->usb->intr_urb->actual_length);
==============
===============
Patch that went into kernel 3.11
Using correct transfer interval as specified by the USB endpoint
when doing the interrupt transfer fixes the warning printed by
xhci USB core on every transfer that resulted in spamming
"xhci_queue_intr_tx: 74 callbacks suppressed" to syslog
every 5 seconds.
Signed-off-by: Marcus Overhagen <marcus.overha...@gmail.com>
---
drivers/staging/rts5139/
rts51x_transport.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_transport.c
b/drivers/staging/rts5139/rts51x_transport.c
index c573618..c172f4a 100644
--- a/drivers/staging/rts5139/rts51x_transport.c
+++ b/drivers/staging/rts5139/rts51x_transport.c
@@ -635,10 +635,10 @@ int rts51x_get_epc_status(struct rts51x_chip
*chip, u16 *status)
ep = chip->usb->pusb_dev->ep_in[usb_pipeendpoint(pipe)];
/* fill and submit the URB */
- /* We set interval to 1 here, so the polling interval is controlled
- * by our polling thread */
+ /* Set interval to 10 here to match the endpoint descriptor,
+ * the polling interval is controlled by the polling thread */
usb_fill_int_urb(chip->usb->intr_urb, chip->usb->pusb_dev, pipe,
- status, 2, urb_done_completion, &urb_done, 1);
+ status, 2, urb_done_completion, &urb_done, 10);
result = rts51x_msg_common(chip, chip->usb->intr_urb, 100);
===============
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
