Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp253949ybv; Tue, 4 Feb 2020 20:53:46 -0800 (PST) X-Google-Smtp-Source: APXvYqwbZE4MfMMndlVPb6M+9BjF0FWN0tT2kiksbviSL3XcpObj3MFZ570b01moVKZ6k/4IdfKr X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr23958874otr.82.1580878426745; Tue, 04 Feb 2020 20:53:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580878426; cv=none; d=google.com; s=arc-20160816; b=d4Aclf8P466YItWOG/3+JVXw3szY/fkQjLJmHMmZojuyUSt4VniuhArOARiKldSAZx ExXE7e1A9SP1FPpUkpKrL6nol35Qgyr4iSi0L19LzvIB0syxM7sfkiAM7H9wva7jyf3i WVweUKU0P/h+1+UunPskF4/siPdjGlckqn2VKoOx7cZuptAX82DjBygaahpIgAZPPhxe JN3KVZpmvG3wjnX1ojY6ObCmzlsV6R9KovQc6gmHTt1JN3MYoHuWTVerPLREk4OTAvi9 pVgtQ2RfuSCUsMD2YoQYrGsHX0GR7Oo85bq+cK9blVj6w6eB0WrjttvxcMO19cybJxoI gaYg== 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=qIsXFy+HHp7SSvQVHd8PMPwqr2p1gsi3igCBMs8ZZZg=; b=LE30RgNQF2C6csLbedZEJACJZZWDTuQQUObb1wl/bJU5y5JjLQWyv9PGRNePIttCTA DxyYndfGDJhltbA+7sIJoT8ipPTNMG1XVws+N66ah6WL9eL4Ph6ZTYa8lvYFhjjaANnR UsyUuyweMN/k9Vz3jc9/wFH4Q0+x2C7sHVRsT6Qt/qtV0DLb/iy2vtrEiopSPuejfSud KIYf1Q6u8YHM6VI5r8oJbQ4LcIEC2jIjySpvBli9ciMV8wst5WpHyd9UjJDCf8bmZxbP 2azC6JA2U4KZUi7yuN3WcdvqBeIUi48dQqCU6QvuOGAj7+uh35a0R1Dem13pr7g8P2hj 19vA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=Fn6D3ZXp; 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 a13si13550562otq.201.2020.02.04.20.53.33; Tue, 04 Feb 2020 20:53:46 -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=Fn6D3ZXp; 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 S1727949AbgBEEwX (ORCPT + 99 others); Tue, 4 Feb 2020 23:52:23 -0500 Received: from mail25.static.mailgun.info ([104.130.122.25]:16304 "EHLO mail25.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727884AbgBEEwX (ORCPT ); Tue, 4 Feb 2020 23:52:23 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1580878342; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=qIsXFy+HHp7SSvQVHd8PMPwqr2p1gsi3igCBMs8ZZZg=; b=Fn6D3ZXpLZ2TWZJwBWgH/4at5SbRXr+OE3kDCFhccorB+1UAtJiki4e9bjc58uS8U7uP7z6s eYUhw72nP1H18P7vBktZ4hI4A1EtnQ6mTMN0AogV7cGk/SFJlaxlsh9UpRQ6RP+oTW10te1t 3Aou52xq7KQRNqJOJx+etgx+AEc= X-Mailgun-Sending-Ip: 104.130.122.25 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 5e3a49fb.7f46fdfc9dc0-smtp-out-n03; Wed, 05 Feb 2020 04:52:11 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id B9D1BC447A6; Wed, 5 Feb 2020 04:52:11 +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,URIBL_BLOCKED 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 85B99C43383; Wed, 5 Feb 2020 04:52:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 05 Feb 2020 12:52:10 +0800 From: Can Guo To: Stanley Chu 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 , Avri Altman , "James E.J. Bottomley" , "Martin K. Petersen" , Bean Huo , Colin Ian King , Tomas Winkler , Bart Van Assche , Venkat Gopalakrishnan , open list Subject: Re: [PATCH v5 6/8] scsi: ufs: Add dev ref clock gating wait time support In-Reply-To: <1580871040.21785.7.camel@mtksdccf07> References: <1580721472-10784-1-git-send-email-cang@codeaurora.org> <1580721472-10784-7-git-send-email-cang@codeaurora.org> <1580871040.21785.7.camel@mtksdccf07> Message-ID: 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-05 10:50, Stanley Chu wrote: > Hi Can, > > On Mon, 2020-02-03 at 01:17 -0800, Can Guo wrote: >> In UFS version 3.0, a newly added attribute bRefClkGatingWaitTime >> defines >> the minimum time for which the reference clock is required by device >> during >> transition to LS-MODE or HIBERN8 state. Make this change to reflect >> the new >> requirement by adding delays before turning off the clock. >> >> Signed-off-by: Can Guo >> Reviewed-by: Asutosh Das >> --- >> drivers/scsi/ufs/ufs.h | 3 +++ >> drivers/scsi/ufs/ufshcd.c | 40 >> ++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 43 insertions(+) >> >> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h >> index cfe3803..304076e 100644 >> --- a/drivers/scsi/ufs/ufs.h >> +++ b/drivers/scsi/ufs/ufs.h >> @@ -167,6 +167,7 @@ enum attr_idn { >> QUERY_ATTR_IDN_FFU_STATUS = 0x14, >> QUERY_ATTR_IDN_PSA_STATE = 0x15, >> QUERY_ATTR_IDN_PSA_DATA_SIZE = 0x16, >> + QUERY_ATTR_IDN_REF_CLK_GATING_WAIT_TIME = 0x17, >> }; >> >> /* Descriptor idn for Query requests */ >> @@ -534,6 +535,8 @@ struct ufs_dev_info { >> u16 wmanufacturerid; >> /*UFS device Product Name */ >> u8 *model; >> + u16 spec_version; >> + u32 clk_gating_wait_us; >> }; >> >> /** >> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c >> index e8f7f9d..d5c547b 100644 >> --- a/drivers/scsi/ufs/ufshcd.c >> +++ b/drivers/scsi/ufs/ufshcd.c >> @@ -91,6 +91,9 @@ >> /* default delay of autosuspend: 2000 ms */ >> #define RPM_AUTOSUSPEND_DELAY_MS 2000 >> >> +/* Default value of wait time before gating device ref clock */ >> +#define UFSHCD_REF_CLK_GATING_WAIT_US 0xFF /* microsecs */ >> + >> #define ufshcd_toggle_vreg(_dev, _vreg, _on) \ >> ({ \ >> int _ret; \ >> @@ -3281,6 +3284,37 @@ static inline int >> ufshcd_read_unit_desc_param(struct ufs_hba *hba, >> param_offset, param_read_buf, param_size); >> } >> >> +static int ufshcd_get_ref_clk_gating_wait(struct ufs_hba *hba) >> +{ >> + int err = 0; >> + u32 gating_wait = UFSHCD_REF_CLK_GATING_WAIT_US; >> + >> + if (hba->dev_info.spec_version >= 0x300) { >> + err = ufshcd_query_attr_retry(hba, UPIU_QUERY_OPCODE_READ_ATTR, >> + QUERY_ATTR_IDN_REF_CLK_GATING_WAIT_TIME, 0, 0, >> + &gating_wait); >> + if (err) >> + dev_err(hba->dev, "Failed reading bRefClkGatingWait. err = %d, use >> default %uus\n", >> + err, gating_wait); >> + >> + if (gating_wait == 0) { >> + gating_wait = UFSHCD_REF_CLK_GATING_WAIT_US; >> + dev_err(hba->dev, "Undefined ref clk gating wait time, use default >> %uus\n", >> + gating_wait); >> + } >> + >> + /* >> + * bRefClkGatingWaitTime defines the minimum time for which the >> + * reference clock is required by device during transition from >> + * HS-MODE to LS-MODE or HIBERN8 state. Give it more time to be >> + * on the safe side. >> + */ >> + hba->dev_info.clk_gating_wait_us = gating_wait + 50; > > > Not sure if the additional 50us wait time here is too large. > > Is there any special reason to fix it as "50"? > > > Thanks, > Stanley > Hi Stanley, We used to ask vendors about it, 50 is somehow agreed by them. Do you have a better value in mind? For me, I just wanted to give it 10, so that we can directly use usleep_range with it, no need to decide whether to use udelay or usleep_range. Thanks, Can Guo. >> &dev_info->model, SD_ASCII_STD); >> @@ -7003,6 +7041,8 @@ static int ufshcd_device_params_init(struct >> ufs_hba *hba) >> goto out; >> } >> >> + ufshcd_get_ref_clk_gating_wait(hba); >> + >> ufs_fixup_device_setup(hba); >> >> if (!ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_READ_FLAG,