From: Stanley Chu <stanley.chu@mediatek.com>
To: Can Guo <cang@codeaurora.org>
Cc: <kuohong.wang@mediatek.com>, <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 <alim.akhtar@samsung.com>,
Avri Altman <avri.altman@wdc.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Bean Huo <beanhuo@micron.com>,
Colin Ian King <colin.king@canonical.com>,
Tomas Winkler <tomas.winkler@intel.com>,
"Bart Van Assche" <bvanassche@acm.org>,
Venkat Gopalakrishnan <venkatg@codeaurora.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 6/8] scsi: ufs: Add dev ref clock gating wait time support
Date: Thu, 6 Feb 2020 08:55:56 +0800 [thread overview]
Message-ID: <1580950556.27391.11.camel@mtksdccf07> (raw)
In-Reply-To: <d37515ab264b0c46848ee2b88ba0a676@codeaurora.org>
Hi Can,
On Wed, 2020-02-05 at 12:52 +0800, Can Guo wrote:
> 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.
Actually I do not have any value in mind because I guess the 50us here
is just a margin time added for safety as your comments: "Give it more
time to be on the safe side".
An example case is that some vendors only specify 1us in
bRefClkGatingWaitTime, so this 50us may be too long compared to device's
requirement. If such device really needs this additional 50us, it shall
be specified in bRefClkGatingWaitTime.
So if this additional delay does not have any special reason or not
mentioned by UFS specification, would you consider move it to vendor
specific implementations. By this way, it would be more flexible to be
controlled by vendors or by platforms.
Thanks,
Stanley
>
> Thanks,
> Can Guo.
>
> >> &dev_info->model, SD_ASCII_STD);
next prev parent reply other threads:[~2020-02-06 0:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1580721472-10784-1-git-send-email-cang@codeaurora.org>
2020-02-03 9:17 ` [PATCH v5 1/8] scsi: ufs: Flush exception event before suspend Can Guo
2020-02-03 21:31 ` [EXT] " Bean Huo (beanhuo)
2020-02-03 9:17 ` [PATCH v5 2/8] scsi: ufs: set load before setting voltage in regulators Can Guo
2020-02-03 21:41 ` [EXT] " Bean Huo (beanhuo)
2020-02-04 6:16 ` Stanley Chu
2020-02-03 9:17 ` [PATCH v5 3/8] scsi: ufs: Remove the check before call setup clock notify vops Can Guo
2020-02-03 22:14 ` [EXT] " Bean Huo (beanhuo)
2020-02-04 6:16 ` Stanley Chu
2020-02-03 9:17 ` [PATCH v5 4/8] scsi: ufs-qcom: Adjust bus bandwidth voting and unvoting Can Guo
2020-02-05 2:17 ` Asutosh Das (asd)
2020-02-03 9:17 ` [PATCH v5 5/8] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic Can Guo
2020-02-03 22:07 ` [EXT] " Bean Huo (beanhuo)
2020-02-04 6:26 ` Stanley Chu
2020-02-03 9:17 ` [PATCH v5 6/8] scsi: ufs: Add dev ref clock gating wait time support Can Guo
2020-02-04 15:26 ` [EXT] " Bean Huo (beanhuo)
2020-02-05 2:50 ` Stanley Chu
2020-02-05 4:52 ` Can Guo
2020-02-06 0:55 ` Stanley Chu [this message]
2020-02-06 2:39 ` Can Guo
2020-02-03 9:17 ` [PATCH v5 7/8] scsi: ufs-qcom: Delay specific time before gate ref clk Can Guo
2020-02-05 7:20 ` hongwus
2020-02-03 9:17 ` [PATCH v5 8/8] scsi: ufs: Select INITIAL adapt for HS Gear4 Can Guo
2020-02-04 15:26 ` [EXT] " Bean Huo (beanhuo)
2020-02-05 7:38 ` hongwus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1580950556.27391.11.camel@mtksdccf07 \
--to=stanley.chu@mediatek.com \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=colin.king@canonical.com \
--cc=hongwus@codeaurora.org \
--cc=jejb@linux.ibm.com \
--cc=kernel-team@android.com \
--cc=kuohong.wang@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=nguyenb@codeaurora.org \
--cc=rnayak@codeaurora.org \
--cc=salyzyn@google.com \
--cc=saravanak@google.com \
--cc=tomas.winkler@intel.com \
--cc=venkatg@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox