Message ID | 20230720054100.9940-1-manivannan.sadhasivam@linaro.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp2915218vqt; Wed, 19 Jul 2023 23:17:09 -0700 (PDT) X-Google-Smtp-Source: APBJJlHOBr9JEhy4Sld4w+rV8h6Fi+VKCiCbnITOnJyTzkz2Fk10lWR1yPodkwnLCxOXjtOhyQGo X-Received: by 2002:a05:6808:218e:b0:3a3:6f96:f15f with SMTP id be14-20020a056808218e00b003a36f96f15fmr990874oib.15.1689833829603; Wed, 19 Jul 2023 23:17:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689833829; cv=none; d=google.com; s=arc-20160816; b=SlkAkoEDS25vqj+jcxIIpFdhnRloac+WZrTOyO9J+Uw44E2xSTCiYIES4dEv8DkWBS WkqMtjzxUXfrXzMbLSle7LIhETTxNTnxpD7Q6vOT1De7zpzaRSgLoq7g/lbvpJlqrG38 UyU5wbMFUBSYDnIpoRD/dk0hZdQFQ7BzLf/gtC4l7aReDmOF+jtoi2w+hFag5GvgSzA3 fKUemBlkwsQn8G29e8CYaTY8AshCT6G0cSyOe3KdtwS1eAkGmi9pzJkUBPaZ3uKivqQP C8n+u8Hcq4fT2utnIpcW5atjiUcsOq4Taju/OBbS3V+zBsC5c+Ip3p9nwBKH67Nzhn94 2jEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=WN6RnkgIzdaal19YY8XLdqCtBwmPCaI6lFevgwA6NkQ=; fh=3109qC6i7dREPMf79CsN/jl+9zRd4/rV6IOQmZMqsxU=; b=tUS1/tqjF7E0cQFyA68SwrxTM4tpNxhPc9hdRsKRDFwg1g2MiyG40KPluouUuMeBS9 qMS/fR3BP2fCofee7cjDM1Bef5+zNhWQfS8c5sk72oH9qTHewhCBAhzce82ZGuBHtW8N 4hQcQf4jgbD9UZtts6VoVe5zmaI3+QnNsbctAFm+84WynPrcwJ+8fwLdsWy6Todq/F8Z kXPpNTvCkMqJkhKlJSZmPY6kiEFxj7DX8olkyGgp0XIKrQnU2ECKqPEpOswTvokBsboy c0AfsvHC+9bDWaUXn4FuS/NaXYlcwD+SCm7XfT3TmeagSFqCxK5S2vFjtfZQwMgLMIN6 HOXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QcYN2iEF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b26-20020a6567da000000b0056337aa2f03si173404pgs.234.2023.07.19.23.16.55; Wed, 19 Jul 2023 23:17:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QcYN2iEF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229571AbjGTFlf (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Thu, 20 Jul 2023 01:41:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229517AbjGTFlb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 20 Jul 2023 01:41:31 -0400 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56C0A172D for <linux-kernel@vger.kernel.org>; Wed, 19 Jul 2023 22:41:29 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1b8b2886364so2278405ad.0 for <linux-kernel@vger.kernel.org>; Wed, 19 Jul 2023 22:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689831689; x=1690436489; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=WN6RnkgIzdaal19YY8XLdqCtBwmPCaI6lFevgwA6NkQ=; b=QcYN2iEFkUyQ9vHTSJINfTdF7Du3vqHm7+OJIxMyIcPuF8wdIC66YH1vt5jWCRjYlh JmwoX5r4Ob1wCA6nTd5XkFYt85qKAzVnQj7l9EuEgtjPUAtwq+glNlKsOdi0NcrE8EMc bWw1W7Chzo8CtMEmzQTqJzOctMJj7KnlCXZK3l4/zZlJfaj5v2XQa0OOdjZA5QD4OhaN NtOmAPtb9Evw/eRaNG1HSbHPnl2xxUJj5l657HC355NXs7jc5i8/9W/edxqDiY97snMv udRbCcszreDVjxnanciO2otrhctaRybcyMfqRSHbc4TAg0mFufQ/FYJL5qvGOVh4TPS8 jVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689831689; x=1690436489; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WN6RnkgIzdaal19YY8XLdqCtBwmPCaI6lFevgwA6NkQ=; b=I6uxC55pH6bPJ+dakpznKMRPcZBaPGCnMPcL4NGKX1cWjqBbSrkbm7Hl8SF7+MXgQW 6FgwTREGjzlQP/jnYEWtxTM4+4cy3ghGr7jqOmvVJ39C+t78Hk4XVyBmySY5aZaERQzW T3NcNSQCiJKwbk+OlqDiXnQ/s3F51ArluAFiFwfgoi3bIStwAtNwMXC1ZeWctNP4j9nb /TVqb5huRFrRP3lVSdRa1Ap2fsYwP/p4cTzdcSrC8UEUOE0UdusTp1Onk50QcrC2KhF0 M+l1NR72fk6Km86oVFEhIky8XH+SKePgB9rJokmQ63c5V/tsL3R2dFL4A9gWRazjhDzj PATQ== X-Gm-Message-State: ABy/qLbpuaisHXL2LYyMEfmmiiMKuRfgtEN+r63zAjDyCPlj9RTc1fpn rsbb3PZ/9QJzYjBcao5abUtG X-Received: by 2002:a17:903:26c5:b0:1b8:5735:2850 with SMTP id jg5-20020a17090326c500b001b857352850mr3799158plb.32.1689831688756; Wed, 19 Jul 2023 22:41:28 -0700 (PDT) Received: from localhost.localdomain ([117.206.119.70]) by smtp.gmail.com with ESMTPSA id r2-20020a170902be0200b001b85bb5fd77sm263367pls.119.2023.07.19.22.41.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 22:41:28 -0700 (PDT) From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> To: vireshk@kernel.org, nm@ti.com, sboyd@kernel.org, myungjoo.ham@samsung.com, kyungmin.park@samsung.com, cw00.choi@samsung.com, andersson@kernel.org, konrad.dybcio@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, jejb@linux.ibm.com, martin.petersen@oracle.com Cc: alim.akhtar@samsung.com, avri.altman@wdc.com, bvanassche@acm.org, linux-scsi@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, quic_asutoshd@quicinc.com, quic_cang@quicinc.com, quic_nitirawa@quicinc.com, quic_narepall@quicinc.com, quic_bhaskarv@quicinc.com, quic_richardp@quicinc.com, quic_nguyenb@quicinc.com, quic_ziqichen@quicinc.com, bmasney@redhat.com, krzysztof.kozlowski@linaro.org, linux-kernel@vger.kernel.org, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Subject: [PATCH v2 00/15] UFS: Add OPP and interconnect support Date: Thu, 20 Jul 2023 11:10:45 +0530 Message-Id: <20230720054100.9940-1-manivannan.sadhasivam@linaro.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771919197584343312 X-GMAIL-MSGID: 1771919197584343312 |
Series |
UFS: Add OPP and interconnect support
|
|
Message
Manivannan Sadhasivam
July 20, 2023, 5:40 a.m. UTC
Hi, This series adds OPP (Operating Points) support to UFSHCD driver and interconnect support to Qcom UFS driver. Motivation behind adding OPP support is to scale both clocks as well as regulators/performance state dynamically. Currently, UFSHCD just scales clock frequency during runtime with the help of "freq-table-hz" property defined in devicetree. With the addition of OPP tables in devicetree (as done for Qcom SDM845 and SM8250 SoCs in this series) UFSHCD can now scale both clocks and performance state of power domain which helps in power saving. For the addition of OPP support to UFSHCD, there are changes required to the OPP framework and devfreq drivers which are also added in this series. Finally, interconnect support is added to Qcom UFS driver for scaling the interconnect path dynamically. This is required to avoid boot crash in recent SoCs and also to save power during runtime. More information is available in patch 13/13. Credits ======= This series is a continuation of previous work by Krzysztof Kozlowski [1] and Brian Masney [2]. Ideally, this could've split into two series (OPP and interconnect) but since there will be a dependency in the devicetree, I decided to keep them in a single series. Testing ======= This series is tested on 96Boards RB3 (SDM845 SoC) and RB5 (SM8250 SoC) development boards. Merging Strategy ================ An immutable branch might be required between OPP and SCSI trees because of the API dependency (devfreq too). And I leave it up to the maintainers to decide. Thanks, Mani [1] https://lore.kernel.org/all/20220513061347.46480-1-krzysztof.kozlowski@linaro.org/ [2] https://lore.kernel.org/all/20221117104957.254648-1-bmasney@redhat.com/ Changes in v2: * Added more description to the bindings patch 2/15 * Fixed dev_pm_opp_put() usage in patch 10/15 * Added a new patch for adding enums for UFS lanes 14/15 * Changed the icc variables to mem_bw and cfg_bw and used the enums for gears and lanes in bw_table * Collected review tags * Added SCSI list and folks * Removed duplicate patches Krzysztof Kozlowski (2): dt-bindings: ufs: common: add OPP table arm64: dts: qcom: sdm845: Add OPP table support to UFSHC Manivannan Sadhasivam (13): dt-bindings: opp: Increase maxItems for opp-hz property arm64: dts: qcom: sdm845: Add missing RPMh power domain to GCC arm64: dts: qcom: sdm845: Fix the min frequency of "ice_core_clk" arm64: dts: qcom: sm8250: Add OPP table support to UFSHC OPP: Introduce dev_pm_opp_find_freq_{ceil/floor}_indexed() APIs OPP: Introduce dev_pm_opp_get_freq_indexed() API PM / devfreq: Switch to dev_pm_opp_find_freq_{ceil/floor}_indexed() APIs scsi: ufs: core: Add OPP support for scaling clocks and regulators scsi: ufs: host: Add support for parsing OPP arm64: dts: qcom: sdm845: Add interconnect paths to UFSHC arm64: dts: qcom: sm8250: Add interconnect paths to UFSHC scsi: ufs: core: Add enums for UFS lanes scsi: ufs: qcom: Add support for scaling interconnects .../devicetree/bindings/opp/opp-v2-base.yaml | 2 +- .../devicetree/bindings/ufs/ufs-common.yaml | 34 +++- arch/arm64/boot/dts/qcom/sdm845.dtsi | 47 ++++-- arch/arm64/boot/dts/qcom/sm8250.dtsi | 43 +++-- drivers/devfreq/devfreq.c | 14 +- drivers/opp/core.c | 76 +++++++++ drivers/ufs/core/ufshcd.c | 148 +++++++++++++----- drivers/ufs/host/ufs-qcom.c | 131 +++++++++++++++- drivers/ufs/host/ufs-qcom.h | 3 + drivers/ufs/host/ufshcd-pltfrm.c | 120 +++++++++++++- include/linux/pm_opp.h | 26 +++ include/ufs/ufshcd.h | 4 + include/ufs/unipro.h | 6 + 13 files changed, 586 insertions(+), 68 deletions(-)
Comments
On 7/19/23 22:40, Manivannan Sadhasivam wrote: > This series adds OPP (Operating Points) support to UFSHCD driver and > interconnect support to Qcom UFS driver. > > Motivation behind adding OPP support is to scale both clocks as well as > regulators/performance state dynamically. Currently, UFSHCD just scales > clock frequency during runtime with the help of "freq-table-hz" property > defined in devicetree. With the addition of OPP tables in devicetree (as > done for Qcom SDM845 and SM8250 SoCs in this series) UFSHCD can now scale > both clocks and performance state of power domain which helps in power > saving. > > For the addition of OPP support to UFSHCD, there are changes required to > the OPP framework and devfreq drivers which are also added in this series. > > Finally, interconnect support is added to Qcom UFS driver for scaling the > interconnect path dynamically. This is required to avoid boot crash in > recent SoCs and also to save power during runtime. More information is > available in patch 13/13. How much power can OPP save? I'm asking this since I'm wondering whether the power saved by OPP outweighs the complexity added by this patch series. Thanks, Bart.
On Thu, Jul 20, 2023 at 09:44:38AM -0700, Bart Van Assche wrote: > On 7/19/23 22:40, Manivannan Sadhasivam wrote: > > This series adds OPP (Operating Points) support to UFSHCD driver and > > interconnect support to Qcom UFS driver. > > > > Motivation behind adding OPP support is to scale both clocks as well as > > regulators/performance state dynamically. Currently, UFSHCD just scales > > clock frequency during runtime with the help of "freq-table-hz" property > > defined in devicetree. With the addition of OPP tables in devicetree (as > > done for Qcom SDM845 and SM8250 SoCs in this series) UFSHCD can now scale > > both clocks and performance state of power domain which helps in power > > saving. > > > > For the addition of OPP support to UFSHCD, there are changes required to > > the OPP framework and devfreq drivers which are also added in this series. > > > > Finally, interconnect support is added to Qcom UFS driver for scaling the > > interconnect path dynamically. This is required to avoid boot crash in > > recent SoCs and also to save power during runtime. More information is > > available in patch 13/13. > > How much power can OPP save? I'm asking this since I'm wondering whether > the power saved by OPP outweighs the complexity added by this patch series. > I haven't had a chance to do proper power measurements with this series due to lack of access to tools. But it won't be optimal to run the clocks at high/low frequencies without changing the associated regulator/power domain state. Atleast on Qcom platforms, the clock frequencies are tied to RPMh (power management entity) performance states for the peripherals. So both have to go hand in hand. Till now, only UFS among the other peripherals is not doing it right and hence this series. - Mani > Thanks, > > Bart.
On 20-07-23, 11:10, Manivannan Sadhasivam wrote: > Hi, > > This series adds OPP (Operating Points) support to UFSHCD driver and > interconnect support to Qcom UFS driver. > > Motivation behind adding OPP support is to scale both clocks as well as > regulators/performance state dynamically. Currently, UFSHCD just scales > clock frequency during runtime with the help of "freq-table-hz" property > defined in devicetree. With the addition of OPP tables in devicetree (as > done for Qcom SDM845 and SM8250 SoCs in this series) UFSHCD can now scale > both clocks and performance state of power domain which helps in power > saving. > > For the addition of OPP support to UFSHCD, there are changes required to > the OPP framework and devfreq drivers which are also added in this series. > > Finally, interconnect support is added to Qcom UFS driver for scaling the > interconnect path dynamically. This is required to avoid boot crash in > recent SoCs and also to save power during runtime. More information is > available in patch 13/13. Hi Mani, I have picked the OPP related patches from here (apart from DT one) and sent them separately in a series, along with few changes from me. Also pushed them in my linux-next branch. Thanks.
On Fri, Jul 21, 2023 at 03:12:06PM +0530, Viresh Kumar wrote: > On 20-07-23, 11:10, Manivannan Sadhasivam wrote: > > Hi, > > > > This series adds OPP (Operating Points) support to UFSHCD driver and > > interconnect support to Qcom UFS driver. > > > > Motivation behind adding OPP support is to scale both clocks as well as > > regulators/performance state dynamically. Currently, UFSHCD just scales > > clock frequency during runtime with the help of "freq-table-hz" property > > defined in devicetree. With the addition of OPP tables in devicetree (as > > done for Qcom SDM845 and SM8250 SoCs in this series) UFSHCD can now scale > > both clocks and performance state of power domain which helps in power > > saving. > > > > For the addition of OPP support to UFSHCD, there are changes required to > > the OPP framework and devfreq drivers which are also added in this series. > > > > Finally, interconnect support is added to Qcom UFS driver for scaling the > > interconnect path dynamically. This is required to avoid boot crash in > > recent SoCs and also to save power during runtime. More information is > > available in patch 13/13. > > Hi Mani, > > I have picked the OPP related patches from here (apart from DT one) > and sent them separately in a series, along with few changes from me. > Also pushed them in my linux-next branch. > Thanks Viresh! For patch 8/15, Kbuild bot has identified one potential null ptr dereference issue. Could you please fix that in your branch? You just need to remove the opp dereference in dev_pm_opp_get_freq_indexed() before the IS_ERR_OR_NULL() check as below: ``` diff --git a/drivers/opp/core.c b/drivers/opp/core.c index 66dc0d0cfaed..683e6e61f80b 100644 --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -208,9 +208,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq); */ unsigned long dev_pm_opp_get_freq_indexed(struct dev_pm_opp *opp, u32 index) { - struct opp_table *opp_table = opp->opp_table; - - if (IS_ERR_OR_NULL(opp) || index >= opp_table->clk_count) { + if (IS_ERR_OR_NULL(opp) || index >= opp->opp_table->clk_count) { pr_err("%s: Invalid parameters\n", __func__); return 0; } ``` - Mani > Thanks. > > -- > viresh
On Thu, 20 Jul 2023 11:10:45 +0530, Manivannan Sadhasivam wrote: > This series adds OPP (Operating Points) support to UFSHCD driver and > interconnect support to Qcom UFS driver. > > Motivation behind adding OPP support is to scale both clocks as well as > regulators/performance state dynamically. Currently, UFSHCD just scales > clock frequency during runtime with the help of "freq-table-hz" property > defined in devicetree. With the addition of OPP tables in devicetree (as > done for Qcom SDM845 and SM8250 SoCs in this series) UFSHCD can now scale > both clocks and performance state of power domain which helps in power > saving. > > [...] Applied, thanks! [03/15] arm64: dts: qcom: sdm845: Add missing RPMh power domain to GCC commit: 4b6ea15c0a1122422b44bf6c47a3c22fc8d46777 [04/15] arm64: dts: qcom: sdm845: Fix the min frequency of "ice_core_clk" commit: bbbef6e24bc4493602df68b052f6f48d48e3184a [12/15] arm64: dts: qcom: sdm845: Add interconnect paths to UFSHC commit: 84e2e371f4f911337604e8ba9281e950230d1189 [13/15] arm64: dts: qcom: sm8250: Add interconnect paths to UFSHC commit: aeea56072cc8cb0af2b35798aa7d72047f4c8ffa Best regards,
On 21-07-23, 17:24, Manivannan Sadhasivam wrote: > On Fri, Jul 21, 2023 at 03:12:06PM +0530, Viresh Kumar wrote: > > On 20-07-23, 11:10, Manivannan Sadhasivam wrote: > > > Hi, > > > > > > This series adds OPP (Operating Points) support to UFSHCD driver and > > > interconnect support to Qcom UFS driver. > > > > > > Motivation behind adding OPP support is to scale both clocks as well as > > > regulators/performance state dynamically. Currently, UFSHCD just scales > > > clock frequency during runtime with the help of "freq-table-hz" property > > > defined in devicetree. With the addition of OPP tables in devicetree (as > > > done for Qcom SDM845 and SM8250 SoCs in this series) UFSHCD can now scale > > > both clocks and performance state of power domain which helps in power > > > saving. > > > > > > For the addition of OPP support to UFSHCD, there are changes required to > > > the OPP framework and devfreq drivers which are also added in this series. > > > > > > Finally, interconnect support is added to Qcom UFS driver for scaling the > > > interconnect path dynamically. This is required to avoid boot crash in > > > recent SoCs and also to save power during runtime. More information is > > > available in patch 13/13. > > > > Hi Mani, > > > > I have picked the OPP related patches from here (apart from DT one) > > and sent them separately in a series, along with few changes from me. > > Also pushed them in my linux-next branch. > > > > Thanks Viresh! For patch 8/15, Kbuild bot has identified one potential null ptr > dereference issue. Could you please fix that in your branch? > > You just need to remove the opp dereference in dev_pm_opp_get_freq_indexed() > before the IS_ERR_OR_NULL() check as below: > > ``` > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index 66dc0d0cfaed..683e6e61f80b 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -208,9 +208,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq); > */ > unsigned long dev_pm_opp_get_freq_indexed(struct dev_pm_opp *opp, u32 index) > { > - struct opp_table *opp_table = opp->opp_table; > - > - if (IS_ERR_OR_NULL(opp) || index >= opp_table->clk_count) { > + if (IS_ERR_OR_NULL(opp) || index >= opp->opp_table->clk_count) { > pr_err("%s: Invalid parameters\n", __func__); > return 0; > } Fixed.