From: "Kiwoong Kim" <kwmad.kim@samsung.com>
To: "'Avri Altman'" <Avri.Altman@wdc.com>,
<linux-scsi@vger.kernel.org>, <alim.akhtar@samsung.com>,
<jejb@linux.ibm.com>, <martin.petersen@oracle.com>,
<beanhuo@micron.com>, <asutoshd@codeaurora.org>,
<cang@codeaurora.org>, <bvanassche@acm.org>,
<grant.jung@samsung.com>, <sc.suh@samsung.com>,
<hy50.seo@samsung.com>, <sh425.lee@samsung.com>
Subject: RE: [RFC PATCH v3 2/2] ufs: change the way to complete fDeviceInit
Date: Wed, 15 Jul 2020 17:09:56 +0900 [thread overview]
Message-ID: <01f501d65a7f$53aab090$fb0011b0$@samsung.com> (raw)
In-Reply-To: <SN6PR04MB46407E21E411B7E785C3B3C1FC680@SN6PR04MB4640.namprd04.prod.outlook.com>
> > Currently, UFS driver checks if fDeviceInit is cleared at several
> > times, not period. This patch is to wait its completion with the
> > period, not retrying.
> > Many device vendors usually provides the specification on it with just
> > period, not a combination of a number of retrying and period. So it
> > could be proper to regard to the information coming from device
> > vendors.
> >
> > I first added one device specific value regarding the information.
> >
> > Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
> I still think that this patch alone is fine, and you don't need its
> predecessor.
> The spec requires polling, so this is a form of a more-effective-polling:
> so be it.
If what you're mentioning 'effective' means being able to just wait for
some long time upon completion of being cleared, it's not proper in real
products because fDeviceInit latency usually has the biggest overhead of
steps run during boot and some companies often try to manage its latency
as KPI. The method like a combination of retrying and small delay make them
harder to make it.
Or if I understand what you meant, please let me know.
>
>
> > ---
> > drivers/scsi/ufs/ufshcd.c | 36 ++++++++++++++++++++++++------------
> > 1 file changed, 24 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index b26f182..6c08ed2 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -208,6 +208,7 @@ static struct ufs_dev_fix ufs_fixups[] = { };
> >
> > static const struct ufs_dev_value ufs_dev_values[] = {
> > + {UFS_VENDOR_TOSHIBA, UFS_ANY_MODEL, DEV_VAL_FDEVICEINIT, 2000,
> > false},
> > {0, 0, 0, 0, false},
> > };
> >
> > @@ -4162,9 +4163,12 @@ EXPORT_SYMBOL_GPL(ufshcd_config_pwr_mode);
> > */
> > static int ufshcd_complete_dev_init(struct ufs_hba *hba) {
> > - int i;
> > + u32 dev_init_compl_in_ms = 1000;
> > + unsigned long timeout;
> > int err;
> > bool flag_res = true;
> > + bool is_dev_val;
> > + u32 val;
> >
> > err = ufshcd_query_flag_retry(hba, UPIU_QUERY_OPCODE_SET_FLAG,
> > QUERY_FLAG_IDN_FDEVICEINIT, 0, NULL); @@ -4175,20
> > +4179,28 @@ static int ufshcd_complete_dev_init(struct ufs_hba *hba)
> > goto out;
> > }
> >
> > - /* poll for max. 1000 iterations for fDeviceInit flag to clear */
> > - for (i = 0; i < 1000 && !err && flag_res; i++)
> > - err = ufshcd_query_flag_retry(hba,
> > UPIU_QUERY_OPCODE_READ_FLAG,
> > - QUERY_FLAG_IDN_FDEVICEINIT, 0, &flag_res);
> > + /* Poll fDeviceInit flag to be cleared */
> > + is_dev_val = ufs_get_dev_specific_value(hba,
> > + DEV_VAL_FDEVICEINIT,
> > &val);
> > + dev_init_compl_in_ms = (is_dev_val) ? val : 500;
> If you want dev_init_compl_in_ms to take its default 1,000, you should:
> dev_init_compl_in_ms = (!is_dev_val) ? : val;
Got it.
>
> > + timeout = jiffies + msecs_to_jiffies(dev_init_compl_in_ms);
> > + do {
> > + err = ufshcd_query_flag(hba, UPIU_QUERY_OPCODE_READ_FLAG,
> > + QUERY_FLAG_IDN_FDEVICEINIT, 0, &flag_res);
> > + if (!flag_res)
> > + break;
> > + usleep_range(5, 10);
> Per Grant's comment:
> usleep_range(5000, 10000);
Got it.
Thanks.
Kiwoong Kim
next prev parent reply other threads:[~2020-07-15 8:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200703053755epcas2p23adbc614d9a72cf3335ed1e6223709f3@epcas2p2.samsung.com>
2020-07-03 5:30 ` [RFC PATCH v3 0/2] ufs: support various values per device Kiwoong Kim
2020-07-03 5:30 ` [RFC PATCH v3 1/2] " Kiwoong Kim
2020-07-05 11:14 ` Avri Altman
2020-07-06 11:35 ` Grant Jung
2020-07-15 8:03 ` Kiwoong Kim
2020-07-05 15:07 ` Bart Van Assche
2020-07-06 6:43 ` Kiwoong Kim
2020-07-06 17:52 ` Bart Van Assche
2020-07-03 5:30 ` [RFC PATCH v3 2/2] ufs: change the way to complete fDeviceInit Kiwoong Kim
2020-07-05 10:53 ` Avri Altman
2020-07-15 8:09 ` Kiwoong Kim [this message]
2020-07-19 6:46 ` Avri Altman
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='01f501d65a7f$53aab090$fb0011b0$@samsung.com' \
--to=kwmad.kim@samsung.com \
--cc=Avri.Altman@wdc.com \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=grant.jung@samsung.com \
--cc=hy50.seo@samsung.com \
--cc=jejb@linux.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sc.suh@samsung.com \
--cc=sh425.lee@samsung.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.