Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1226748ybk; Thu, 21 May 2020 01:38:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyj/31x843gbuy+IpsQtNDWU6EIVg+S8FZC+d1eu1zqOY5uHWtpESVGVinbYJwcNK2jege X-Received: by 2002:a17:906:c108:: with SMTP id do8mr2671767ejc.134.1590050296332; Thu, 21 May 2020 01:38:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590050296; cv=none; d=google.com; s=arc-20160816; b=0k+uEviyY/M1hJK6kI1AajASO+xTtJxO3ibBlpdQ73SCzbklBaogbZLAK7jT0a4CBh Xmg8kzJUijZNAymT1FlDHhdwI4EZiOyloZh8j+I9CtbQGGyrU6XbBRaKtPXVPWpkiLuq bmqmVOrDIm0ZnfDdks4O2wTfykHM5PJFZAWouYfyvDI8suppCvOQTVBr4+N+AmqW02Hr tuj7Mg7NexCcu87xTmP/a8B8PPdOPfTmUy94tGtR5+hrhLZbTNbRHoeNPlPJjVOyO6ew fkf4zjhj9iA3UrUI7Qpkc5MO6OOODv6Yh3d4YBHKDYCPP4c625YdvwSbwdaqfoYWSQO4 MIOw== 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=OldWI3GbYyFeEDn6EU3YMjMalIM9qrgjySI6Ez3VZXg=; b=mkVaHhPGr91Fzn1patq9Cr+mkJ/dWwCP2kha7oZUNLvOvg1+1wyzWAWVdUB1OYCzC4 8iN6YcFeLrWf80R4ADOKeCUQ7CJbttit15RPirxWUdMr8QsqePho9sa6zxU+tGunRfnZ lG9+aduNNItUWfnePgeGU5Z3bPqqOacdNssfKKJmaBgBWl9YOwaEqpItOvr3MQ2X/rJf nnMjTO2NAYGamtCtNQn1lDIQFZl7mORZGOc+84QDu1PdlaHIA+7PXpu+hHnDgbERluc8 OFjq1R338Cc3+ia/I6PeXr3dmr4LcQ2jsQeyra/kmHy3b8hzQ6ouB0TtHAf6V5J5INXg h0QA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=UOcbLWBI; 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 dd22si2777426edb.557.2020.05.21.01.37.49; Thu, 21 May 2020 01:38:16 -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=UOcbLWBI; 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 S1728718AbgEUIgU (ORCPT + 99 others); Thu, 21 May 2020 04:36:20 -0400 Received: from mail26.static.mailgun.info ([104.130.122.26]:49273 "EHLO mail26.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728708AbgEUIgT (ORCPT ); Thu, 21 May 2020 04:36:19 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1590050179; h=Message-Id: Date: Subject: Cc: To: From: Sender; bh=OldWI3GbYyFeEDn6EU3YMjMalIM9qrgjySI6Ez3VZXg=; b=UOcbLWBIfiZ0Lct8kDJnYs0Sls1gerG4f5Rw3Xrl4Yd3Y9Hhj50l3zHJyJT/LkMH4hP96OBY /6ZFdyJ4DGu6DoZctAqhI3stJQ58HKVC1yeSqmXdUk/7cK+zYNinisZ0na3bvn/BrBeB97ki IFhkaGfYNg6QPgjOIGxhFy6QMEs= X-Mailgun-Sending-Ip: 104.130.122.26 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-n01.prod.us-east-1.postgun.com with SMTP id 5ec63d7fe79e24225da452c9 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 21 May 2020 08:36:15 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id DC74BC433C8; Thu, 21 May 2020 08:36:14 +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 CD47BC433C8; Thu, 21 May 2020 08:36:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org CD47BC433C8 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: [PATCH v2 0/3] Re-introduce TX FIFO resize for larger EP bursting Date: Thu, 21 May 2020 01:36:06 -0700 Message-Id: <1590050169-30747-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 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 Reviewed-by: Felipe Balbi Reviewed-by: Rob Herring 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 | 8 ++ drivers/usb/dwc3/ep0.c | 37 ++++++++- drivers/usb/dwc3/gadget.c | 111 +++++++++++++++++++++++++ 6 files changed, 159 insertions(+), 2 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project