[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0509c5a9-47ec-4a0f-8251-f1be62e8ca1e@acm.org>
Date: Thu, 16 Jan 2025 06:58:46 -0800
From: Bart Van Assche <bvanassche@....org>
To: DooHyun Hwang(황두현/Device S/W Solution Lab.(MX)/삼성전자) <dh0421.hwang@...sung.com>,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
alim.akhtar@...sung.com, avri.altman@....com,
James.Bottomley@...senPartnership.com, martin.petersen@...cle.com,
peter.wang@...iatek.com, manivannan.sadhasivam@...aro.org,
quic_mnaresh@...cinc.com
Cc: grant.jung@...sung.com, jt77.jang@...sung.com, junwoo80.lee@...sung.com,
jangsub.yi@...sung.com, sh043.lee@...sung.com, cw9316.lee@...sung.com,
sh8267.baek@...sung.com, wkon.kim@...sung.com
Subject: Re: [PATCH] scsi: ufs: core: increase the NOP_OUT command timeout
On 1/15/25 6:02 PM, DooHyun Hwang(황두현/Device S/W Solution Lab.(MX)/삼성전자)
wrote:
> 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.
Thank you for having provided all this additional information. Because
of the above clarification, feel free to add:
Reviewed-by: Bart Van Assche <bvanassche@....org>
Powered by blists - more mailing lists