Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp200284ybt; Tue, 23 Jun 2020 19:30:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwJoKkB5FSgMOr/1tBKyEa3n8KShxmmkKqtjWfBFwv5H/varbG4lvJSyHQvNZHwpe9T4TqC X-Received: by 2002:a17:907:7245:: with SMTP id ds5mr15631401ejc.67.1592965808618; Tue, 23 Jun 2020 19:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592965808; cv=none; d=google.com; s=arc-20160816; b=0bOoDvK9mQd7TuM+R41iLR8d4O+8pv2JVxFswYgRNCWV4v4PxtB0uCYi2Cx0/vnCDs ExjZcjB4P0m3SWQMQ6x9HOEAlmi5EPS40PdF3xuM7i4HTjKbuAjISOL4VSH77/nMtJyX PHmq+L6ombrS3i+BN/gIi+K7oD1wA72etN453AI0oK/VlIX0fbSXxjcCzRv+6rNmu8Lj uSja0F7o/Ks7BKpURYQmIJvlq+qmCsYbkjHcsN2NQtwqONBscx5CJthoYkUnHIIRZ5x6 RWatzOE476vHH6TR9HFhm/WGoskz4qwdDaWOuy8XGhib0VJutQKDiPvD69hWzGQO6r27 3x2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dmarc-filter:dkim-signature; bh=UFyHj+W9ynWlJQRUY/i2VctFzcjjSc1Tu2WiBup8M1o=; b=U73wcP6vYfJkZwzu6Sm2KXCf2NirhRK343RqkifLtKodT6/MkE60geT2Xq29gUUWEn uC2uHyoNUmjRoCirn4V12fITCIT4rFHIjTZ1ntnsysjnk1Ob5rHAafsA4q50PFoYvCaC Sl6nJBaD/4nuxkB49qR5jOyCDZ0wqKqaLStpXBtg/sIWRJyc/v486S3j06M1XpOPTZZJ sy93ejp1jnMtib5uUR/TosJJx49NTT5koU67MOJadaI+n4xdCePgVeXHmFsFSDASHXB5 XbBxLqkZGVM7bAFijymghAMUOkPAy0WCtNOpipJNtSngMkopRtANIuldIgSTG6Wkb9Uk xxZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=Ipo+lNK5; 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 y5si12399836eju.687.2020.06.23.19.29.45; Tue, 23 Jun 2020 19:30:08 -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=Ipo+lNK5; 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 S2388470AbgFXC3I (ORCPT + 99 others); Tue, 23 Jun 2020 22:29:08 -0400 Received: from m43-7.mailgun.net ([69.72.43.7]:28414 "EHLO m43-7.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388147AbgFXC3G (ORCPT ); Tue, 23 Jun 2020 22:29:06 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1592965746; h=Content-Transfer-Encoding: MIME-Version: Message-Id: Date: Subject: Cc: To: From: Sender; bh=UFyHj+W9ynWlJQRUY/i2VctFzcjjSc1Tu2WiBup8M1o=; b=Ipo+lNK5dvb4aSotrczIq8yZWRect5vZ6MD+cvEt6QhZ2M/ZDqAYGSaB5Umxnr9K8ccbCev4 lJ7lnpoCfGiLu8HStWisjYqyDoZy8nZltzJGFxxUZ56+XkNheE+C4utvj+Op58sogCWudcwR NSmeaaz75SUysfzCbOYD5SLR9hM= X-Mailgun-Sending-Ip: 69.72.43.7 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 smtp-out-n11.prod.us-west-2.postgun.com with SMTP id 5ef2ba686f2ee827daeecfeb (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Wed, 24 Jun 2020 02:28:56 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id B1E55C43395; Wed, 24 Jun 2020 02:28:56 +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 7CE4BC43391; Wed, 24 Jun 2020 02:28:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 7CE4BC43391 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, balbi@kernel.org, gregkh@linuxfoundation.org, robh+dt@kernel.org Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, jackp@codeaurora.org, Wesley Cheng Subject: [RFC v4 0/3] Re-introduce TX FIFO resize for larger EP bursting Date: Tue, 23 Jun 2020 19:28:45 -0700 Message-Id: <20200624022848.7765-1-wcheng@codeaurora.org> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Changes in V4: - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos() - Removed WARN_ON(1) in case we run out of fifo space 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. 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 .../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 | 8 ++ drivers/usb/dwc3/ep0.c | 37 +++++- drivers/usb/dwc3/gadget.c | 115 ++++++++++++++++++ 6 files changed, 163 insertions(+), 2 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project