If DCD supports queuing of stall requests then USB MSC delay work-around is not necessary

This commit is contained in:
Gregory Nutt 2014-03-20 15:20:24 -06:00
parent f139391f8a
commit c6127ad09d
4 changed files with 30 additions and 0 deletions

View File

@ -7014,4 +7014,8 @@
* include/nuttx/i2c.h: More typo fixes from Vijay Kumar (2014-3-19).
* arch/Kconfig and *_assert.h: Add a configuration option to enable
dumping of the USB trace buffer on assertion (2014-3-19).
* drivers/usbdev/Kconfig, arch/arm/src/sam34/Kconfig, and
drivers/usbdev/usbmsc_scsi.c: If DCD can support queuing of stall
requests, then the USB MSC stall work around delays are not necessary
(2014-3-20).

9
TODO
View File

@ -947,6 +947,15 @@ o USB (drivers/usbdev, drivers/usbhost)
Description: There is a workaround for a bug in drivers/usbdev/usbdev_storage.c.
that involves delays. This needs to be redesigned to eliminate these
delays. See logic conditioned on CONFIG_USBMSC_RACEWAR.
If queuing of stall requests is supported by DCD then this workaround
is not required. In this case, (1) the stall is not sent until all
write requests preceding the stall request are sent, (2) the stall is
sent, and then after the stall is cleared, (3) all write requests
queued after the stall are sent.
See, for example, the queuing of pending stall requests in the SAM3/4
UDP driver at arch/arm/src/sam34/sam_udp.c.
Status: Open
Priority: Medium

View File

@ -561,6 +561,7 @@ config SAM34_UDP
bool "USB Device Full Speed (UDP)"
default n
depends on ARCH_CHIP_SAM4S || ARCH_CHIP_SAM4E
select ARCH_USBDEV_STALLQUEUE
config SAM34_UDPHS
bool "USB Device High Speed (UDPHS)"

View File

@ -72,6 +72,22 @@ bool "Board DMA Allocation Hooks"
memory of the specified size; usbdev_dma_free() is the corresponding
function that will be called to free the DMA-capable memory.
config ARCH_USBDEV_STALLQUEUE
bool
default n
---help---
This option is set by the USB device controller driver (DCD)
selection. These selection means that the DCD can support
queuing of stall requests. By this, it is meant that, (1) the
stall is not sent until all write requests preceding the stall
request are sent, (2) the stall is sent, and then after the
stall is cleared, (3) all write requests queued after the stall
are sent.
If the driver does not support this feature, that the class drivers
will enable some hokey and inefficient delay logic to workaround
the lack of queuing.
config USBDEV_TRACE
bool "Enable USB tracing for debug"
default n