Message ID | 20221117104957.254648-2-bmasney@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp331068wrr; Thu, 17 Nov 2022 02:54:18 -0800 (PST) X-Google-Smtp-Source: AA0mqf6PYJMx/p7c7JBzT7s5545/MdtDhkjRX32k8nNo4nMLsmhxPrCE3OCkvzQWViX/6zE4JMJX X-Received: by 2002:a17:902:ce06:b0:186:7070:8ab4 with SMTP id k6-20020a170902ce0600b0018670708ab4mr2229710plg.23.1668682457753; Thu, 17 Nov 2022 02:54:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668682457; cv=none; d=google.com; s=arc-20160816; b=DZTvObkObVQe0/HCCXMljB0WNLA+K/+uSK66m05Fccz6irX9QNHzMG/ZUJQTCVgxp6 p/cmGVebYkeX+ifncO+mSoDky76zTOYDPQanblLhKzRASDgjwyUjtYiaOFJiJrxaw4C1 2nC5ryy+QFfLg0chksndsfwRkkabVQoSgYD4VzH0Yc9iKHXOpwbaQfmLMABLdmy7beWa QfDvWazVNTPxXmYt9VRvNCtx5+afDPU2xiZbQM2XYPxMNAAmeYEimMv1914vuwujOi66 T6fM6iEVucW9NlgP4qfLiEIhTLh7dQ37SabYj3L7dAQNK9cWor0xp2OVLYUOGfuZXBBP zIgA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=x6n9un+DF1STb0f8Wt45FFfORAUWPZZjfWdP+jBOFAw=; b=wVblaDqLRLZFWznWOEpC6S6kQFPW1YScZA/ilywRM6hSVpkPNGRp6Tq/tqMzcOk/HK XhcGtLzqTfCCJMKyvs850E797e4K5UCLgD99ds7q1OZ7czka8YeWP62R+V25boToDJPH 1UpF9ZsATkGx+MPE3lEpYgcfyJ6DTJDDeppWeMkOmOF6f+hZqUn7WP+tQV1ouSKjQRpy +RtnWeqmdxLAklCmjAn7ooIA2LRmK5jLmjbukUwpFz1873w+8yQRtxTUq0ZhxiqehCJj dfkxAeOtHPFNEQwGA7lDaUkPSbCRQSCFxwbQJEzx+U3vVWDnnes4mb0a/K+esuVQcD9y OtFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="IGz8/5Yx"; 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=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g19-20020a635653000000b00476d24ebb04si706393pgm.322.2022.11.17.02.54.04; Thu, 17 Nov 2022 02:54:17 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b="IGz8/5Yx"; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234637AbiKQKvg (ORCPT <rfc822;just.gull.subs@gmail.com> + 99 others); Thu, 17 Nov 2022 05:51:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233502AbiKQKvd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 17 Nov 2022 05:51:33 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 028CF183B5 for <linux-kernel@vger.kernel.org>; Thu, 17 Nov 2022 02:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668682230; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x6n9un+DF1STb0f8Wt45FFfORAUWPZZjfWdP+jBOFAw=; b=IGz8/5Yx70KGnfHXmFSM3h2LAPA9ScSjg9V6BfDkK2CDmGiPRmEb4BDfAAgwehcLYmdil9 VkyJ9Tgil6ARowkDEddwAxTk8CpM67+1sHa9QldpgPue11TAiIlHw6lARG+yY0C/1iuNXI ku4oY1VC/ok8KrhjHZNg1HOCsLSUPP4= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-126-n7e_mWaINmyK4_nliwCNWQ-1; Thu, 17 Nov 2022 05:50:28 -0500 X-MC-Unique: n7e_mWaINmyK4_nliwCNWQ-1 Received: by mail-qt1-f200.google.com with SMTP id ff5-20020a05622a4d8500b003a526107477so1297427qtb.9 for <linux-kernel@vger.kernel.org>; Thu, 17 Nov 2022 02:50:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=x6n9un+DF1STb0f8Wt45FFfORAUWPZZjfWdP+jBOFAw=; b=3nnTUhFHHkhPR8K3GP7j66KKbya1G1eTPnjK8YR8Kteh+709+skWuG6lIc11Wb8DXA rtVRSO9Tpdp+GEio6SfMSwloL4PM9H1w4W3acqrz8LWpsrBWhhk+WKhJQEz2zbqTMBr7 3pUh4y/sJUrtH/++Q+PyFgmdDFev4odlGUnU/Apst6nGbm5VT4YDkbCFe9Q3hhrocnQ4 b+OsFzN2w0rrAPmP7LJJg1+5YLn42as5bK3X/mxH3xFyQhSY9/O7QfF2hhhmA7HQj8fp AIbGW3shCjbK5uL4+S8bqj1m6s5GFDcxuayxB31zPUYrZEeaZxzuaiDFsUlepXq3cM/P Jktg== X-Gm-Message-State: ANoB5pmhfIu+l5awG3W5W3vLcJrOlx18mT7JzcN0D9MMX1yxTZcVSeE4 +yXC5uyOpFRoOEJEP+p0bzKr0N6oB1ZJKJK6u0GwNG1yMc5HYNynVrMjT1D7ysvYEGvGT16cYNU Qs85QetFWybcnCI6vmrqiiE3M X-Received: by 2002:ac8:741a:0:b0:3a5:2932:3a77 with SMTP id p26-20020ac8741a000000b003a529323a77mr1561853qtq.591.1668682228224; Thu, 17 Nov 2022 02:50:28 -0800 (PST) X-Received: by 2002:ac8:741a:0:b0:3a5:2932:3a77 with SMTP id p26-20020ac8741a000000b003a529323a77mr1561843qtq.591.1668682228025; Thu, 17 Nov 2022 02:50:28 -0800 (PST) Received: from x1.redhat.com (c-73-214-169-22.hsd1.pa.comcast.net. [73.214.169.22]) by smtp.gmail.com with ESMTPSA id i15-20020a05620a248f00b006fa9d101775sm236022qkn.33.2022.11.17.02.50.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 02:50:27 -0800 (PST) From: Brian Masney <bmasney@redhat.com> To: andersson@kernel.org Cc: agross@kernel.org, konrad.dybcio@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, jejb@linux.ibm.com, martin.petersen@oracle.com, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Subject: [PATCH 1/2] scsi: ufs: ufs-qcom: add basic interconnect support Date: Thu, 17 Nov 2022 05:49:56 -0500 Message-Id: <20221117104957.254648-2-bmasney@redhat.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221117104957.254648-1-bmasney@redhat.com> References: <20221117104957.254648-1-bmasney@redhat.com> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749740376995597229?= X-GMAIL-MSGID: =?utf-8?q?1749740376995597229?= |
Series |
qcom: add basic interconnect support to UFS
|
|
Commit Message
Brian Masney
Nov. 17, 2022, 10:49 a.m. UTC
The firmware on the Qualcomm platforms expects the interconnect votes to
be present. Let's add very basic support where the maximum throughput is
requested to match what's done in a few other drivers.
This will not break boot on systems where the interconnects and
interconnect-names properties are not specified in device tree for UFS
since the interconnect framework will silently return.
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
drivers/ufs/host/ufs-qcom.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
Comments
On Thu, Nov 17, 2022 at 05:49:56AM -0500, Brian Masney wrote: > The firmware on the Qualcomm platforms expects the interconnect votes to > be present. Let's add very basic support where the maximum throughput is > requested to match what's done in a few other drivers. > > This will not break boot on systems where the interconnects and > interconnect-names properties are not specified in device tree for UFS > since the interconnect framework will silently return. > > Signed-off-by: Brian Masney <bmasney@redhat.com> > --- > drivers/ufs/host/ufs-qcom.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c > index 8ad1415e10b6..55bf8dd88985 100644 > --- a/drivers/ufs/host/ufs-qcom.c > +++ b/drivers/ufs/host/ufs-qcom.c > @@ -7,6 +7,7 @@ > #include <linux/time.h> > #include <linux/clk.h> > #include <linux/delay.h> > +#include <linux/interconnect.h> > #include <linux/module.h> > #include <linux/of.h> > #include <linux/platform_device.h> > @@ -936,6 +937,22 @@ static const struct reset_control_ops ufs_qcom_reset_ops = { > .deassert = ufs_qcom_reset_deassert, > }; > > +static int ufs_qcom_icc_init(struct device *dev, char *pathname) > +{ > + struct icc_path *path; > + int ret; > + > + path = devm_of_icc_get(dev, pathname); > + if (IS_ERR(path)) > + return dev_err_probe(dev, PTR_ERR(path), "failed to acquire interconnect path\n"); > + > + ret = icc_set_bw(path, 0, UINT_MAX); Please use icc macros for setting the bandwidth. Like, GBps_to_icc(), MBps_to_icc() etc... Also, during the init stage you can set a minimum bandwidth that will allow the controller to get probed successfully. Then, you should update the bandwidth based on the gear in pwr_change_notify() callback. > + if (ret < 0) > + return dev_err_probe(dev, ret, "failed to set bandwidth request\n"); > + > + return 0; > +} > + > /** > * ufs_qcom_init - bind phy with controller > * @hba: host controller instance > @@ -991,6 +1008,14 @@ static int ufs_qcom_init(struct ufs_hba *hba) > err = dev_err_probe(dev, PTR_ERR(host->generic_phy), "Failed to get PHY\n"); > goto out_variant_clear; > } > + > + err = ufs_qcom_icc_init(dev, "ufs-ddr"); > + if (err) > + goto out_variant_clear; > + > + err = ufs_qcom_icc_init(dev, "cpu-ufs"); > + if (err) > + goto out_variant_clear; It'd be nice to have a single function that initializes both paths. Thanks, Mani > } > > host->device_reset = devm_gpiod_get_optional(dev, "reset", > -- > 2.38.1 >
On 17/11/2022 12:49, Brian Masney wrote: > The firmware on the Qualcomm platforms expects the interconnect votes to > be present. Let's add very basic support where the maximum throughput is > requested to match what's done in a few other drivers. > > This will not break boot on systems where the interconnects and > interconnect-names properties are not specified in device tree for UFS > since the interconnect framework will silently return. > > Signed-off-by: Brian Masney <bmasney@redhat.com> > --- > drivers/ufs/host/ufs-qcom.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c > index 8ad1415e10b6..55bf8dd88985 100644 > --- a/drivers/ufs/host/ufs-qcom.c > +++ b/drivers/ufs/host/ufs-qcom.c > @@ -7,6 +7,7 @@ > #include <linux/time.h> > #include <linux/clk.h> > #include <linux/delay.h> > +#include <linux/interconnect.h> > #include <linux/module.h> > #include <linux/of.h> > #include <linux/platform_device.h> > @@ -936,6 +937,22 @@ static const struct reset_control_ops ufs_qcom_reset_ops = { > .deassert = ufs_qcom_reset_deassert, > }; > > +static int ufs_qcom_icc_init(struct device *dev, char *pathname) > +{ > + struct icc_path *path; > + int ret; > + > + path = devm_of_icc_get(dev, pathname); > + if (IS_ERR(path)) > + return dev_err_probe(dev, PTR_ERR(path), "failed to acquire interconnect path\n"); > + > + ret = icc_set_bw(path, 0, UINT_MAX); I noticed that this patch bumps peak_bw (and leaves average_bw as 0), while vendor kernels bump average_bw, but ib (peak_bw) is set to 0. > + if (ret < 0) > + return dev_err_probe(dev, ret, "failed to set bandwidth request\n"); > + > + return 0; > +} > + > /** > * ufs_qcom_init - bind phy with controller > * @hba: host controller instance > @@ -991,6 +1008,14 @@ static int ufs_qcom_init(struct ufs_hba *hba) > err = dev_err_probe(dev, PTR_ERR(host->generic_phy), "Failed to get PHY\n"); > goto out_variant_clear; > } > + > + err = ufs_qcom_icc_init(dev, "ufs-ddr"); > + if (err) > + goto out_variant_clear; > + > + err = ufs_qcom_icc_init(dev, "cpu-ufs"); > + if (err) > + goto out_variant_clear; > } > > host->device_reset = devm_gpiod_get_optional(dev, "reset",
On 17.11.2022 11:49, Brian Masney wrote: > The firmware on the Qualcomm platforms expects the interconnect votes to > be present. Let's add very basic support where the maximum throughput is > requested to match what's done in a few other drivers. > > This will not break boot on systems where the interconnects and > interconnect-names properties are not specified in device tree for UFS > since the interconnect framework will silently return. > > Signed-off-by: Brian Masney <bmasney@redhat.com> > --- Hi everyone! This was never merged, but it's actually strictly necessary! For example UFS dies on SM8450 if we add sync_state to its interconnect driver, as there's no votes cast. Can we look into this again? Konrad > drivers/ufs/host/ufs-qcom.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c > index 8ad1415e10b6..55bf8dd88985 100644 > --- a/drivers/ufs/host/ufs-qcom.c > +++ b/drivers/ufs/host/ufs-qcom.c > @@ -7,6 +7,7 @@ > #include <linux/time.h> > #include <linux/clk.h> > #include <linux/delay.h> > +#include <linux/interconnect.h> > #include <linux/module.h> > #include <linux/of.h> > #include <linux/platform_device.h> > @@ -936,6 +937,22 @@ static const struct reset_control_ops ufs_qcom_reset_ops = { > .deassert = ufs_qcom_reset_deassert, > }; > > +static int ufs_qcom_icc_init(struct device *dev, char *pathname) > +{ > + struct icc_path *path; > + int ret; > + > + path = devm_of_icc_get(dev, pathname); > + if (IS_ERR(path)) > + return dev_err_probe(dev, PTR_ERR(path), "failed to acquire interconnect path\n"); > + > + ret = icc_set_bw(path, 0, UINT_MAX); > + if (ret < 0) > + return dev_err_probe(dev, ret, "failed to set bandwidth request\n"); > + > + return 0; > +} > + > /** > * ufs_qcom_init - bind phy with controller > * @hba: host controller instance > @@ -991,6 +1008,14 @@ static int ufs_qcom_init(struct ufs_hba *hba) > err = dev_err_probe(dev, PTR_ERR(host->generic_phy), "Failed to get PHY\n"); > goto out_variant_clear; > } > + > + err = ufs_qcom_icc_init(dev, "ufs-ddr"); > + if (err) > + goto out_variant_clear; > + > + err = ufs_qcom_icc_init(dev, "cpu-ufs"); > + if (err) > + goto out_variant_clear; > } > > host->device_reset = devm_gpiod_get_optional(dev, "reset",
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c index 8ad1415e10b6..55bf8dd88985 100644 --- a/drivers/ufs/host/ufs-qcom.c +++ b/drivers/ufs/host/ufs-qcom.c @@ -7,6 +7,7 @@ #include <linux/time.h> #include <linux/clk.h> #include <linux/delay.h> +#include <linux/interconnect.h> #include <linux/module.h> #include <linux/of.h> #include <linux/platform_device.h> @@ -936,6 +937,22 @@ static const struct reset_control_ops ufs_qcom_reset_ops = { .deassert = ufs_qcom_reset_deassert, }; +static int ufs_qcom_icc_init(struct device *dev, char *pathname) +{ + struct icc_path *path; + int ret; + + path = devm_of_icc_get(dev, pathname); + if (IS_ERR(path)) + return dev_err_probe(dev, PTR_ERR(path), "failed to acquire interconnect path\n"); + + ret = icc_set_bw(path, 0, UINT_MAX); + if (ret < 0) + return dev_err_probe(dev, ret, "failed to set bandwidth request\n"); + + return 0; +} + /** * ufs_qcom_init - bind phy with controller * @hba: host controller instance @@ -991,6 +1008,14 @@ static int ufs_qcom_init(struct ufs_hba *hba) err = dev_err_probe(dev, PTR_ERR(host->generic_phy), "Failed to get PHY\n"); goto out_variant_clear; } + + err = ufs_qcom_icc_init(dev, "ufs-ddr"); + if (err) + goto out_variant_clear; + + err = ufs_qcom_icc_init(dev, "cpu-ufs"); + if (err) + goto out_variant_clear; } host->device_reset = devm_gpiod_get_optional(dev, "reset",