linux-kernel - Re: [PATCH v5 04/21] usb: dwc2: host: Set host_perio_tx_fifo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=Xtbmf2yOQx=cNTnrsV_35jTUhJCKbBNuHCRpr-qXrW0A@mail.gmail.com>
Date:	Thu, 28 Jan 2016 10:16:22 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Kever Yang <kever.yang@...k-chips.com>
Cc:	John Youn <John.Youn@...opsys.com>, Felipe Balbi <balbi@...com>,
	Tao Huang <huangtao@...k-chips.com>,
	"Herrero, Gregory" <gregory.herrero@...el.com>,
	Heiko Stübner <heiko@...ech.de>,
	John Youn <johnyoun@...opsys.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ming Lei <ming.lei@...onical.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	"Kaukab, Yousaf" <yousaf.kaukab@...el.com>,
	Alan Stern <stern@...land.harvard.edu>,
	吴良峰 <william.wu@...k-chips.com>,
	Julius Werner <jwerner@...omium.org>,
	Dinh Nguyen <dinguyen@...nsource.altera.com>
Subject: Re: [PATCH v5 04/21] usb: dwc2: host: Set host_perio_tx_fifo_size to
 304 for rk3066

Kever,

On Wed, Jan 27, 2016 at 10:41 PM, Kever Yang <kever.yang@...k-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.

-Doug