Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp47626ybv; Wed, 12 Feb 2020 18:54:06 -0800 (PST) X-Google-Smtp-Source: APXvYqwQOta7H3HBeeyegobiz+IwgSWafFmHyixT0RVw0CaPUQUpxYeqfGM93ZyZzt3iqDueoPuo X-Received: by 2002:a05:6830:2015:: with SMTP id e21mr11455779otp.106.1581562446160; Wed, 12 Feb 2020 18:54:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581562446; cv=none; d=google.com; s=arc-20160816; b=m+VW5WJatCQXWDekkaPvrP0H6V365WtbR66I2pzVW7bd3n0cx1hyIGohUtaoyl9tTi khf1E7qPYvOWSHOVDJckl25Ea2RJ3K+twTQuFr/T92X4KIiBoIJs15/tu6EV6Vhlf/R+ DCz3TS81MT/1qfI58NQk1o55eW2Tfokj31e6Xoz+CxFM7+js8y9FY1uo8JNf3QH+Rzee zfIlmciHqOzu1xllFJpGspaKIbafG9ffb3yln+7p6XD/orvR1xlLue0B4CgHE7YCiwZo On09Wp9kRJnvT1l6nYVL+POTKmH+0QmTBHRCcRQLc96K1FaLbB1YUHcfNp70ZgDCjPB5 LNOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=qAAa2KbFfMvP0Xd5tKYvsl66uX6NHBgKUC21HuQOjBU=; b=eAxXj1GerJt2RWBF8wCX78M6dTA7mQ1vB/5/HkH7BT6e0rn/ndzYLV1PZ96MrUeWMP 5tFbrs0srceVL1NINsq/T2g+Z3kJG9aZ61Ww+w9aLV36Ddr0jdgp/TPty0tk0mkkPALF tcF+wFc6D8PvJ5ZKbYTVzblVj85qvW72U+m3FtJOu1lIU4V71akHLT104IYw1EJqOwNE LuCrsc3fzZ4+btFZmEbtRc+FqjYTSGfFw4Ff3bWvP1lj1nWT392sJ6RxzkR5XypxHBOk SV/iKcMQzZd8tbxRlX4OkzwJbKxFAZJec/750nexXlVRWEieSZ3OGckCGLu+7sBF+HQH i4IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=kmqENplD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 8si371300ota.266.2020.02.12.18.53.53; Wed, 12 Feb 2020 18:54:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=kmqENplD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729514AbgBMCxT (ORCPT + 99 others); Wed, 12 Feb 2020 21:53:19 -0500 Received: from mail26.static.mailgun.info ([104.130.122.26]:22854 "EHLO mail26.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729333AbgBMCxT (ORCPT ); Wed, 12 Feb 2020 21:53:19 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1581562398; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=qAAa2KbFfMvP0Xd5tKYvsl66uX6NHBgKUC21HuQOjBU=; b=kmqENplDK8lQ4uYZYf16cgLWKcj7BoXCUYk+1q7hw4xXAQejL/SpUOwv0vz0ArKTGTPlJ59o OkR0gj284F7oSH1jLcYWugfslALn2T6LEsZGcqCcXYw4I/ZU3GMbb2DxN5teDMCXppYbwYTu OB94kmg+FR4MPxktqcs4eisNPHs= 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 mxa.mailgun.org with ESMTP id 5e44ba1c.7fa3b0c77a40-smtp-out-n02; Thu, 13 Feb 2020 02:53:16 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 43D3BC433A2; Thu, 13 Feb 2020 02:53:16 +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 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cang) by smtp.codeaurora.org (Postfix) with ESMTPSA id DDC35C43383; Thu, 13 Feb 2020 02:53:13 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 13 Feb 2020 10:53:13 +0800 From: Can Guo To: Avri Altman Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org, hongwus@codeaurora.org, rnayak@codeaurora.org, linux-scsi@vger.kernel.org, kernel-team@android.com, saravanak@google.com, salyzyn@google.com, Alim Akhtar , "James E.J. Bottomley" , "Martin K. Petersen" , Bean Huo , Stanley Chu , Bart Van Assche , Venkat Gopalakrishnan , Tomas Winkler , open list Subject: Re: [PATCH v1 1/2] scsi: ufs: Use ufshcd_config_pwr_mode() when scale gear In-Reply-To: References: <1581485910-8307-1-git-send-email-cang@codeaurora.org> <1581485910-8307-2-git-send-email-cang@codeaurora.org> Message-ID: <5a54ea8f5c9f24a5c14b022d1d087a6d@codeaurora.org> X-Sender: cang@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-02-12 20:21, Avri Altman wrote: > Hi, > >> >> When scale gear, use ufshcd_config_pwr_mode() instead of >> ufshcd_change_power_mode() so that >> vops_pwr_change_notify(PRE_CHANGE) >> can be utilized to allow vendors use customized settings before change >> the power mode. >> >> Signed-off-by: Can Guo >> --- >> drivers/scsi/ufs/ufshcd.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c >> index adcce41..67bd4f2 100644 >> --- a/drivers/scsi/ufs/ufshcd.c >> +++ b/drivers/scsi/ufs/ufshcd.c >> @@ -1059,8 +1059,7 @@ static int ufshcd_scale_gear(struct ufs_hba >> *hba, >> bool scale_up) >> } >> >> /* check if the power mode needs to be changed or not? */ >> - ret = ufshcd_change_power_mode(hba, &new_pwr_info); >> - >> + ret = ufshcd_config_pwr_mode(hba, &new_pwr_info); > > You might want to inform ufshcd_config_pwr_mode() of the caller, > As now it will be called much more frequently, and you want/don't want > To call your vops on probe but not on scale_gear? > > Also, Alim exported ufshcd_config_pwr_mode a while ago, > In commit 0d846e703dc8 "scsi: ufs: make ufshcd_config_pwr_mode of > non-static func"), > But nobody uses it outside ufshcd - so maybe revert this commit as > part of this series? > > > Hi Avri, Thanks for your review and suggestion. What I get from your suggestion is that add one more parameter to ufshcd_config_pwr_mode(say: bool from_probe), and pass the param to ufshcd_vops_pwr_change_notify() so that vendor drivers know where is the call comes from? If I get it correctly, then yes, we can do that. However, in ufs-qcom.c, ufs_qcom_pwr_change_notify(PRE_CHANGE) is fine being called every time whenever there is a power mode change, we have no problem with that. And as we are the only user of clock scaling in the latest code base, so this change does not impact any other vendors. If later other vendors need to use clock scaling, they can do this change as you suggested above. As for the commit from Alim, I think I should leave it to Alim's call on it, maybe he has changes that use this func outside ufshcd.c but not uploaded yet. Thanks, Can Guo. >> if (ret) >> dev_err(hba->dev, "%s: failed err %d, old gear: (tx %d >> rx %d), new >> gear: (tx %d rx %d)", >> __func__, ret, >> @@ -4126,8 +4125,6 @@ int ufshcd_config_pwr_mode(struct ufs_hba *hba, >> memcpy(&final_params, desired_pwr_mode, >> sizeof(final_params)); >> >> ret = ufshcd_change_power_mode(hba, &final_params); >> - if (!ret) >> - ufshcd_print_pwr_info(hba); >> >> return ret; >> } >> @@ -7157,6 +7154,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba, >> bool async) >> __func__, ret); >> goto out; >> } >> + ufshcd_print_pwr_info(hba); >> } >> >> /* set the state as operational after switching to desired >> gear */ >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >> Forum, >> a Linux Foundation Collaborative Project