Hi, On Thu, Jan 28, 2016 at 10:16 AM, Doug Anderson <dianders at chromium.org> wrote: > Kever, > > > On Wed, Jan 27, 2016 at 10:41 PM, Kever Yang <kever.yang at rock-chips.com> wrote: >> Hi Doug, >> >> We are in HOST mode, we only need to receive data from USB camera >> with RX FIFO, and no need to use TX FIFO for USB webcam, right? :) >> >> Any way, I think we need to NAK this patch after look into the design >> of dwc2 controller. Because all the dwc2 controller inside the Rockchip >> chips don't support the thresholding FIFO mode, in this case, there is >> no more transaction before a whole packet is send out and the dwc2 only >> care if the available FIFO is enough for next packet or not. >> >> So, the addition 48 words won't help to shorten the latency for data prepare >> in this case. > > Ah ha! I see where I messed up. It wasn't lack of FIFO space that I > was running into, it was lack of queue space. :-P I had conflated > the two of them in my mind. We still use the TX queue to transmit > small packets so that we can receive our data... > > OK, so it's pretty sane to assume that exhausting the periodic TX FIFO > isn't terribly common, I think. Audio won't do it by itself and you > probably won't have more than one audio device. I guess if you had a > video _output_ device hooked over USB then it could possible exhaust > things. ...but I think dwc2 still has a ways to do before I'd suggest > anyone hooking that up. :-P At some point in time you could imagine > the driver being more dynamic. > > OK, so the non periodic FIFO it is, then. Actually, in my simple tests adding it to the non periodic FIFO didn't help at all. I'll just drop this patch. -Doug
