From: Yauheni Kaliuta <yauheni.kaliuta@xxxxxxxxx>
It fixes MUSB's hardware feature, that it doesn't actually flush FIFOs,
when TXPKTRDY flag was set before and we are flushing setting both
FLUSHFIFO and TXPKTRDY.
The specification says about FLUSHFIFO, that it "May be set simultaneously
with TxPktRdy to abort the packet that is currently being loaded into the
FIFO". This is a situation, where TXPKTRDY hasn't been set yet, but some
data already loaded into the fifo. It looks, that if TXPKTRDY has been
set before and there is no loading in progress but we set FLUSHFIFO with
the TXPKTRDY, controller tries to use the same logic to abort loading
and as the result just does nothing (because there is no loading in progress)
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@xxxxxxxxx>
---
drivers/usb/musb/musb_gadget.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 0a50a35..36160a2 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1524,6 +1524,12 @@ static void musb_gadget_fifo_flush(struct usb_ep *ep)
csr = musb_readw(epio, MUSB_TXCSR);
if (csr & MUSB_TXCSR_FIFONOTEMPTY) {
csr |= MUSB_TXCSR_FLUSHFIFO | MUSB_TXCSR_P_WZC_BITS;
+ /*
+ * Setting both TXPKTRDY and FLUSHFIFO makes controller
+ * to interrupt current FIFO loading, but not flushing
+ * the already loaded ones.
+ */
+ csr &= ~MUSB_TXCSR_TXPKTRDY;
musb_writew(epio, MUSB_TXCSR, csr);
/* REVISIT may be inappropriate w/o FIFONOTEMPTY ... */
musb_writew(epio, MUSB_TXCSR, csr);
--
1.7.5.3
--
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
