Hi! >>>>> ext Sergei Shtylyov writes: > yauheni.kaliuta@xxxxxxxxx wrote: > > From: Yauheni Kaliuta <yauheni.kaliuta@xxxxxxxxx> > > It fixes MUSB's hardware feature, that it doesn't actually flush FIFOs, > > when it has PKTRDY flag set. > Hm, the MUSB programming guide explicitly says: > "Note: FlushFIFO should only be used when TxPktRdy/RxPktRdy is set. At other > times, it may cause data to be corrupted." > > Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@xxxxxxxxx> > > --- > > drivers/usb/musb/musb_gadget.c | 2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c > > index 0a50a35..830768f 100644 > > --- a/drivers/usb/musb/musb_gadget.c > > +++ b/drivers/usb/musb/musb_gadget.c > > @@ -1524,6 +1524,7 @@ 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; > > + csr &= ~MUSB_TXCSR_TXPKTRDY; > CPU can't clear this bit according to the programming guide -- it can only > set the bit. So this should have no effect. Some comments after more deep examination of the guide. It says about FlushFIFO bit: "The CPU writes a 1 to this bit fo flush the latest packet from the endpoint Tx FIFO. The FIFO pointer is reset, the TxPktRdy bit is cleared and an interrupt is generated" Ok, so when TxPktRdy is set (we have a ready packet) if we set the bit (nothing is said about other bits) when -- we flush the packet and reset the fifo pointer to start position. But the next sentence is: "May be set simultaneously with TxPktRdy to abort the packet that is currently being loaded into the FIFO" what is "the packet that is currently being loaded into the FIFO"? It means, that TxPktRdy was not set, so it just resets a pointer of _not yet ready packet_ to start and does nothing else, agree? What's happening if TxPktRdy was set but we set it again? For me it looks like controller switches logic to the latter branch, it tries to reset the pointer of not yet ready packet to start. Since we do not have a such one (TxPktRdy was set), it just does nothing. -- WBR, Yauheni Kaliuta -- 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