Yuri Tikhonov
2007-12-14 12:15:54 UTC
Hello,
I've discovered a problem with the pxa27x_udc.c driver (signed with
DRIVER_VERSION "1.0.0") using it with the file-storage gadget and Windows
USB host: Windows got stuck when I tried to write some file to my PXA270-based
device. If I use Linux as a host, then everything works fine.
Here are some output I got when turned on the DEBUG and VERBOSE options
in file_storage.c:
...
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=4096; Hc=10, Ho=4096
g_file_storage gadget-lun0: file write 3584 @ 139776 -> 3584
g_file_storage gadget-lun0: file write 512 @ 143360 -> 512
g_file_storage gadget: SCSI CDB: 2a 08 00 01 b5 5d 00 00 80 00
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=65536; Hc=10, Ho=65536
g_file_storage gadget-lun0: file write 1536 @ 57326080 -> 1536
g_file_storage gadget: bulk_out_complete --> 0, 0/16384
g_file_storage gadget-lun0: file write 16384 @ 57327616 -> 16384
g_file_storage gadget-lun0: file write 0 @ 57344000 -> 0
g_file_storage gadget: bulk_out_complete --> -104, 320/16384
g_file_storage gadget: bulk_out_complete --> 0, 0/31
g_file_storage gadget: invalid CBW: len 0 sig 0x0
...
I guess that pxa27x_udc loses packets received from host because of flushing
OUT EP FIFO in handle_ep(), when it discoveres that there are no requests for
this ep in fly yet. As a result, a BULK request finally obtained by
file-storage level is corrupted, and this leads to, e.g.,
"bulk_out_complete --> 0, 0/16384", and, finally, to "invalid CBW" (see the log
above).
What follows is a patch which fixed the issue. Using this approach, data is
being kept safe in OUT EP FIFO even if there are no requests discovered in the
interrupt handler. Then the pxa27x_ep_queue() function is responsible for
reading data from this FIFO.
Signed-off-by: Yuri Tikhonov <***@emcraft.com>
--
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 973f34b..e9a237e 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -1943,7 +1943,10 @@ static void handle_ep(struct pxa27x_ep *ep)
completed = read_fifo(ep, req);
} else {
pio_irq_disable(ep->ep_num);
+#if 0
+ /* the request may be submitted soon */
*ep->reg_udccsr = UDCCSR_FEF;
+#endif
dev_dbg(ep->udc->dev, "%s: no req for out data\n", __FUNCTION__);
}
}
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
I've discovered a problem with the pxa27x_udc.c driver (signed with
DRIVER_VERSION "1.0.0") using it with the file-storage gadget and Windows
USB host: Windows got stuck when I tried to write some file to my PXA270-based
device. If I use Linux as a host, then everything works fine.
Here are some output I got when turned on the DEBUG and VERBOSE options
in file_storage.c:
...
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=4096; Hc=10, Ho=4096
g_file_storage gadget-lun0: file write 3584 @ 139776 -> 3584
g_file_storage gadget-lun0: file write 512 @ 143360 -> 512
g_file_storage gadget: SCSI CDB: 2a 08 00 01 b5 5d 00 00 80 00
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=65536; Hc=10, Ho=65536
g_file_storage gadget-lun0: file write 1536 @ 57326080 -> 1536
g_file_storage gadget: bulk_out_complete --> 0, 0/16384
g_file_storage gadget-lun0: file write 16384 @ 57327616 -> 16384
g_file_storage gadget-lun0: file write 0 @ 57344000 -> 0
g_file_storage gadget: bulk_out_complete --> -104, 320/16384
g_file_storage gadget: bulk_out_complete --> 0, 0/31
g_file_storage gadget: invalid CBW: len 0 sig 0x0
...
I guess that pxa27x_udc loses packets received from host because of flushing
OUT EP FIFO in handle_ep(), when it discoveres that there are no requests for
this ep in fly yet. As a result, a BULK request finally obtained by
file-storage level is corrupted, and this leads to, e.g.,
"bulk_out_complete --> 0, 0/16384", and, finally, to "invalid CBW" (see the log
above).
What follows is a patch which fixed the issue. Using this approach, data is
being kept safe in OUT EP FIFO even if there are no requests discovered in the
interrupt handler. Then the pxa27x_ep_queue() function is responsible for
reading data from this FIFO.
Signed-off-by: Yuri Tikhonov <***@emcraft.com>
--
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 973f34b..e9a237e 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -1943,7 +1943,10 @@ static void handle_ep(struct pxa27x_ep *ep)
completed = read_fifo(ep, req);
} else {
pio_irq_disable(ep->ep_num);
+#if 0
+ /* the request may be submitted soon */
*ep->reg_udccsr = UDCCSR_FEF;
+#endif
dev_dbg(ep->udc->dev, "%s: no req for out data\n", __FUNCTION__);
}
}
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel