David Brownell wrote:
+static void musb_h_ep0_flush_fifo(struct musb_hw_ep *ep) +{ + void __iomem *epio = ep->regs; + u16 csr; + int retries = 5; + + /* scrub any data left in the fifo */ + do { + csr = musb_readw(epio, MUSB_TXCSR); + if (!(csr & (MUSB_CSR0_TXPKTRDY | MUSB_CSR0_RXPKTRDY))) + break;Note that the same rule applies ot other endpoints, i.e. you shouldn't flush FIFO if these bits are not set
Right ... but, this patch is just for ep0.
No arguing here. Just an idea for another patch to which I haven't gotten as yet.
and even if you do, you need to force TXPktRdy set. This needs to be fixed too...
TXCSR section says that Flush FIFO "may be set simultaneously with TxPktRdy to abort the packet that is currently being loaded into the FIFO", at least...
... except that setting those bits, at least in this case, was taking priority over flushing the fifo, causing the "flush" to return with a packet left in the fifo. Kind of a "non-flush".
Hm...
(You had asked about CamelCase? TXPktRdy, vs TXPKTRDY as used in the driver, is one example.)
That's how the bit is called in the MUSB documentation. I didn't feel obliged to avoid CamelCase in the comments -- where it's not even a real CamelCase. You're clearly over-strict here. :-)
WBR, Sergei -- 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
