On Wed, May 27, 2020 at 06:46:00PM -0700, Wesley Cheng wrote: > Changes in V3: > - Removed "Reviewed-by" tags > - Renamed series back to RFC > - Modified logic to ensure that fifo_size is reset if we pass the minimum > threshold. Tested with binding multiple FDs requesting 6 FIFOs. > > Changes in V2: > - Modified TXFIFO resizing logic to ensure that each EP is reserved a > FIFO. > - Removed dev_dbg() prints and fixed typos from patches > - Added some more description on the dt-bindings commit message > > Currently, there is no functionality to allow for resizing the TXFIFOs, and > relying on the HW default setting for the TXFIFO depth. In most cases, the > HW default is probably sufficient, but for USB compositions that contain > multiple functions that require EP bursting, the default settings > might not be enough. Also to note, the current SW will assign an EP to a > function driver w/o checking to see if the TXFIFO size for that particular > EP is large enough. (this is a problem if there are multiple HW defined > values for the TXFIFO size) > > It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3 > is required for an EP that supports bursting. Otherwise, there may be > frequent occurences of bursts ending. For high bandwidth functions, > such as data tethering (protocols that support data aggregation), mass > storage, and media transfer protocol (over FFS), the bMaxBurst value can be > large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB > throughput. (which can be associated to system access latency, etc...) It > allows for a more consistent burst of traffic, w/o any interruptions, as > data is readily available in the FIFO. > > With testing done using the mass storage function driver, the results show > that with a larger TXFIFO depth, the bandwidth increased significantly. Why is this still a "RFC" series? That implies you don't want this applied...
