[U-Boot] [PATCH 2/2] usb: gadget: fotg210: EP0 fifo empty indication is non-reliable

[Marek Vasut]

On Thursday, December 19, 2013 at 08:07:00 AM, Kuo-Jung Su wrote:
> 2013/12/19 Marek Vasut <marex at denx.de>:
> > On Thursday, December 19, 2013 at 01:50:55 AM, Kuo-Jung Su wrote:
> >> 2013/12/18 Marek Vasut <marex at denx.de>:
> >> > On Wednesday, December 18, 2013 at 08:24:49 AM, Kuo-Jung Su wrote:
> >> >> From: Kuo-Jung Su <dantesu at faraday-tech.com>
> >> >> 
> >> >> Because the EP0 fifo empty indication is non-reliable,
> >> >> an extra delay is necessary to avoid data corruption while
> >> >> handling packets with size greater than 64 bytes.
> >> >> 
> >> >> This workaround should be applied to all hardware revisions.
> >> >> 
> >> >> Signed-off-by: Kuo-Jung Su <dantesu at faraday-tech.com>
> >> >> CC: Marek Vasut <marex at denx.de>
> >> >> ---
> >> >> 
> >> >>  drivers/usb/gadget/fotg210.c |    1 +
> >> >>  1 file changed, 1 insertion(+)
> >> >> 
> >> >> diff --git a/drivers/usb/gadget/fotg210.c
> >> >> b/drivers/usb/gadget/fotg210.c index e3a61cc..14bfec6 100644
> >> >> --- a/drivers/usb/gadget/fotg210.c
> >> >> +++ b/drivers/usb/gadget/fotg210.c
> >> >> @@ -245,6 +245,7 @@ static int fotg210_dma(struct fotg210_ep *ep,
> >> >> struct fotg210_request *req) if (ep->id == 0) {
> >> >> 
> >> >>                       /* Wait until cx/ep0 fifo empty */
> >> >>                       fotg210_cxwait(chip, CXFIFO_CXFIFOE);
> >> >> 
> >> >> +                     udelay_masked(1);
> >> > 
> >> > Why don't you use regular udelay() here please ? Also, how exactly
> >> > does the delay help solving the unreliability problem please?
> >> 
> >> 1. No specific reason at all, I'll use regular udelay() in next version.
> >> :)
> >> 
> >> 2. The fifo size of ep0 is 64 bytes, and my driver is supposed to make
> >> sure the fifo empty
> >> 
> >>     before filling up the fifo. However there is a hardware bug that
> >> 
> >> the fifo empty indication is somehow
> >> 
> >>     a bit earlier than fifo reset. So if I don't add an extra delay
> >> 
> >> here, the data might be corrupted (i.e., 1 byte missing.)
> >> 
> >>     And after a couple of tests, it looks like that 1 usec is good
> >> 
> >> enough for this.
> > 
> > Ick, but I guess you guys know the IP blocks' sourcecode.
> 
> Yes, but I don't have the access permission , and I'm not a member of
> the IP verification team......
> 
> Anyway I'll try to call the IP owner see if he's willing to do FPGA
> verification.

Would be nice, but I dont mind picking it even without such confirmation. 
Thanks!

Best regards,
Marek Vasut