summaryrefslogtreecommitdiff
path: root/common
diff options
context:
space:
mode:
authorMarek Vasut <marek.vasut+renesas@gmail.com>2019-10-06 17:13:38 +0300
committerMarek Vasut <marek.vasut+renesas@gmail.com>2019-10-31 14:13:40 +0300
commit02b0e1a36c5bc20174299312556ec4e266872bd6 (patch)
tree1359cb9206d81f27232903d1c9513d6d3ae2f97b /common
parentda3d1c499fbb7cfe1c1dc1bc47699a2f30df4384 (diff)
downloadu-boot-02b0e1a36c5bc20174299312556ec4e266872bd6.tar.xz
usb: ehci-hcd: Keep async schedule running
Profiling the EHCI driver shows a significant performance problem in ehci_submit_async(). Specifically, this function keeps enabling and disabling async schedule back and forth for every single transaction. However, enabling/disabling the async schedule does not take effect immediatelly, but instead may take up to 1 mS (8 uFrames) to complete. This impacts USB storage significantly, esp. since the recent reduction of maximum transfer size to support more USB storage devices. This in turn results in sharp increase in the number of ehci_submit_async() calls. Since one USB storage BBB transfer does three such calls and the maximum transfer size is 120 kiB, the overhead is 6 mS per 120 kiB, which is unacceptable. However, this overhead can be removed simply by keeping the async schedule running. Specifically, the first transfer starts the async schedule and then each and every subsequent transfer only adds a new QH into that schedule, waits until the QH is completed and does NOT disable the async schedule. The async schedule is stopped only by shutting down the controller, which must happen before moving out of U-Boot, otherwise the controller will corrupt memory. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'common')
0 files changed, 0 insertions, 0 deletions