Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1102067ybj; Thu, 7 May 2020 15:01:44 -0700 (PDT) X-Google-Smtp-Source: APiQypJc/tq6MR9DbAIWiWPoFhXGcffdDWYQVVHkzJ+YyA1UD9CwCRMDXCsk62VVyHpqfTOH6N9f X-Received: by 2002:a05:6402:154e:: with SMTP id p14mr11759433edx.326.1588888904770; Thu, 07 May 2020 15:01:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588888904; cv=none; d=google.com; s=arc-20160816; b=c9G1zwfds887gT6JLuKIhMKXJwcTE/Grz6GTaYWOqwFdsoX541diFJGZRnVjkn+gaO oaEIdssOUFhO+Fp8pE3EMDTGoOF5jU4lNyy9+7Y0fDTY1iQQfty+uv1rJDRxc0/Wgifd YHVTWpe+4lvP8GtdE07Am48kVzss5a1bikkLkg0JZu422a5nklI9itNL31RrW+fWpKBc bodSx3+RN3Iy6jYzNpdmA8Gpq77yoOVhUBaOTeAAp5CSMCVWyIKaoQ9LN9pXJarQV+xK 4k7bGrqyutmXPoJyLQ/PC/vdVgV4oOPV5pAQT77mHlJekRxlfZ0ZnRJ8n5LXAXiOOuRP K6wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dmarc-filter:dkim-signature; bh=2JzIuaOGhuGmjvd/Q8TuZu3HdVzNfJc54yOI38k0duI=; b=jnJMapPJFvCxAIJeM4EKfrDBJGVa4WMskdfGAvusGDtrni6fd7npLnyjiCDT3mNqYv 3PeQSM1ZoNLP18xDI/lIA88BWn4ebpRnfk6koYFXNvRl5dxEev+Kx6nD1WiCwoENdH5G fWvJJaQUcdqyeZWao1fXZMXCTvMUrlRa+6MkQagHJdZNa4Qf8h8Awffvnly5mLxNpvTL qrPL+/d3M/+YIaXT/3Xk/gJ3VtJ4zO9kiXInjJV9FKwqFm1tIHTHMxMM1Ukma4Yo57ew Dy4cwiIwoGZdzFjPruadYfXJB16jGSMTRcEopCXiyXEmNewA7XySxkppYnB/Al5cQCMK zdAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=njSqFtJV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e16si1807878ejx.37.2020.05.07.15.01.21; Thu, 07 May 2020 15:01:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=njSqFtJV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727111AbgEGV7k (ORCPT + 99 others); Thu, 7 May 2020 17:59:40 -0400 Received: from mail27.static.mailgun.info ([104.130.122.27]:36708 "EHLO mail27.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727097AbgEGV7i (ORCPT ); Thu, 7 May 2020 17:59:38 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1588888778; h=Message-Id: Date: Subject: Cc: To: From: Sender; bh=2JzIuaOGhuGmjvd/Q8TuZu3HdVzNfJc54yOI38k0duI=; b=njSqFtJVAb1wlTMLtG2EkMVmNUL6FaNrmPQq3un0INYkA9xe0Mtuck1QLEAkEXjbzEw8LLjv S66/ArYBkmkqSHuw0Xsif/gG2uhhyhPWqINPAjyBt3w4fHFNQnGdF/7SvSf/+rl7Y9512Qok XFLjywkZkl4XW4REkkL/NFtDb6k= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5eb484c5.7f707f34a688-smtp-out-n01; Thu, 07 May 2020 21:59:33 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 19D15C43637; Thu, 7 May 2020 21:59:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.0 Received: from wcheng-linux.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: wcheng) by smtp.codeaurora.org (Postfix) with ESMTPSA id 10DA3C433D2; Thu, 7 May 2020 21:59:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 10DA3C433D2 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=wcheng@codeaurora.org From: Wesley Cheng To: agross@kernel.org, bjorn.andersson@linaro.org, robh+dt@kernel.org, balbi@kernel.org, gregkh@linuxfoundation.org Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, jackp@codeaurora.org, Wesley Cheng Subject: [RFC 0/3] Re-introduce TX FIFO resize for larger EP bursting Date: Thu, 7 May 2020 14:59:25 -0700 Message-Id: <1588888768-25315-1-git-send-email-wcheng@codeaurora.org> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Test Parameters: - Platform: Qualcomm SM8150 - bMaxBurst = 6 - USB req size = 256kB - Num of USB reqs = 16 - USB Speed = Super-Speed - Function Driver: Mass Storage (w/ ramdisk) - Test Application: CrystalDiskMark Results: TXFIFO Depth = 3 max packets Test Case | Data Size | AVG tput (in MB/s) ------------------------------------------- Sequential|1 GB x | Read |9 loops | 193.60 | | 195.86 | | 184.77 | | 193.60 ------------------------------------------- TXFIFO Depth = 6 max packets Test Case | Data Size | AVG tput (in MB/s) ------------------------------------------- Sequential|1 GB x | Read |9 loops | 287.35 | | 304.94 | | 289.64 | | 293.61 ------------------------------------------- Wesley Cheng (3): usb: dwc3: Resize TX FIFOs to meet EP bursting requirements arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic dt-bindings: usb: dwc3: Add entry for tx-fifo-resize Documentation/devicetree/bindings/usb/dwc3.txt | 2 +- arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 + drivers/usb/dwc3/core.c | 2 + drivers/usb/dwc3/core.h | 6 ++ drivers/usb/dwc3/ep0.c | 40 ++++++++++- drivers/usb/dwc3/gadget.c | 95 ++++++++++++++++++++++++++ 6 files changed, 144 insertions(+), 2 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project