Re: [PATCH] usb: musb: gadget: clear PKTRDY flags when set FLUSHFIFO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux