From: "DooHyun Hwang(황두현/Device S/W Solution Lab.(MX)/삼성전자)" <dh0421.hwang@samsung.com>
To: "'Bart Van Assche'" <bvanassche@acm.org>,
<linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<alim.akhtar@samsung.com>, <avri.altman@wdc.com>,
<James.Bottomley@HansenPartnership.com>,
<martin.petersen@oracle.com>, <peter.wang@mediatek.com>,
<manivannan.sadhasivam@linaro.org>, <quic_mnaresh@quicinc.com>
Cc: <grant.jung@samsung.com>, <jt77.jang@samsung.com>,
<junwoo80.lee@samsung.com>, <jangsub.yi@samsung.com>,
<sh043.lee@samsung.com>, <cw9316.lee@samsung.com>,
<sh8267.baek@samsung.com>, <wkon.kim@samsung.com>
Subject: RE: [PATCH] scsi: ufs: core: increase the NOP_OUT command timeout
Date: Thu, 16 Jan 2025 11:02:35 +0900 [thread overview]
Message-ID: <351601db67ba$b67a54d0$236efe70$@samsung.com> (raw)
In-Reply-To: <44520a93-a52e-4f88-8ca5-5f0fb38df607@acm.org>
> On 1/14/25 6:23 PM, DooHyun Hwang wrote:
> > It is found that is UFS device may take longer than 500ms(50ms *
> > 10times) to respond to NOP_OUT command.
> >
> > The NOP_OUT command timeout was total 500ms that is from a timeout
> > value of 50ms(defined by NOP_OUT_TIMEOUT) with 10 retries(defined by
> > NOP_OUT_RETRIES)
> >
> > This change increase the NOP_OUT command timeout to total 1000ms by
> > changing timeout value to 100ms(NOP_OUT_TIMEOUT)
> >
> > Signed-off-by: DooHyun Hwang <dh0421.hwang@samsung.com>
> > ---
> > drivers/ufs/core/ufshcd.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> > index cd404ade48dc..bf5c4620ef6b 100644
> > --- a/drivers/ufs/core/ufshcd.c
> > +++ b/drivers/ufs/core/ufshcd.c
> > @@ -57,8 +57,8 @@ enum {
> > };
> > /* NOP OUT retries waiting for NOP IN response */
> > #define NOP_OUT_RETRIES 10
> > -/* Timeout after 50 msecs if NOP OUT hangs without response */
> > -#define NOP_OUT_TIMEOUT 50 /* msecs */
> > +/* Timeout after 100 msecs if NOP OUT hangs without response */
> > +#define NOP_OUT_TIMEOUT 100 /* msecs */
> >
> > /* Query request retries */
> > #define QUERY_REQ_RETRIES 3
>
> The above change relies on all device management commands being issued
> with the same tag. If a single NOP OUT command may take longer than
> 500 ms, shouldn't NOP_OUT_TIMEOUT be increased to 1000 ms instead of
> 100 ms? The number of NOP OUT retries seems high to me and probably can be
> reduced?
>
> Thanks,
>
> Bart.
I want to keep sending NOP_OUT commands repeatedly to get a response
from the UFS device, as per the existing method. To accommodate this method,
I propose increasing the total timeout duration by increasing the single timeout
value(defined by NOP_OUT_TIMEOUT) from 50ms to 100ms rather than
increasing the timeout value(defined by NOP_OUT_TIMEOUT) from 50ms to 1000ms
or increasing the retry count value(defined by NOP_OUT_RETRIES).
This is time measurement log confirmed on a real device with NOP_OUT_TIMEOUT is 100ms
1. normal operation
[ 2.010156] [6: kworker/u18:0: 76] ufshcd-qcom 1d84000.ufshc: [TEST] ufshcd_verify_dev_init: takes 1271 us, retries = 1 * 100ms.
2. issued log : exceeds 500ms
[ 2.524525] [6: kworker/u17:2: 141] ufshcd-qcom 1d84000.ufshc: [TEST] ufshcd_verify_dev_init: takes 533000 us, retries = 6 * 100ms.
And a certain UFS vendor has confirmed that the response to NOP_OUT command
can be delayed by up to 540ms in certain circumstances on a specific model.
BR,
Thank you.
DooHyun Hwang.
next prev parent reply other threads:[~2025-01-16 2:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250115022348epcas1p29705c109f51c01e1e91ef227233c7119@epcas1p2.samsung.com>
2025-01-15 2:23 ` [PATCH] scsi: ufs: core: increase the NOP_OUT command timeout DooHyun Hwang
2025-01-15 18:12 ` Bart Van Assche
2025-01-16 2:02 ` DooHyun Hwang(황두현/Device S/W Solution Lab.(MX)/삼성전자) [this message]
2025-01-16 14:58 ` Bart Van Assche
2025-01-16 8:38 ` Avri Altman
2025-01-16 9:59 ` DooHyun Hwang
2025-01-16 16:30 ` Bao D. Nguyen
2025-01-24 6:16 ` DooHyun Hwang
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='351601db67ba$b67a54d0$236efe70$@samsung.com' \
--to=dh0421.hwang@samsung.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=bvanassche@acm.org \
--cc=cw9316.lee@samsung.com \
--cc=grant.jung@samsung.com \
--cc=jangsub.yi@samsung.com \
--cc=jt77.jang@samsung.com \
--cc=junwoo80.lee@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=martin.petersen@oracle.com \
--cc=peter.wang@mediatek.com \
--cc=quic_mnaresh@quicinc.com \
--cc=sh043.lee@samsung.com \
--cc=sh8267.baek@samsung.com \
--cc=wkon.kim@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.