From patchwork Thu Nov 24 00:31:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: subhashj@codeaurora.org X-Patchwork-Id: 9444549 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EA1746075F for ; Thu, 24 Nov 2016 00:33:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E7BA127E5A for ; Thu, 24 Nov 2016 00:33:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DC9C127F2B; Thu, 24 Nov 2016 00:33:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5F80727E5A for ; Thu, 24 Nov 2016 00:33:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935846AbcKXAcJ (ORCPT ); Wed, 23 Nov 2016 19:32:09 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:51232 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935681AbcKXAcA (ORCPT ); Wed, 23 Nov 2016 19:32:00 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 634FE6151E; Thu, 24 Nov 2016 00:31:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1479947519; bh=Wv6EgFSE/YHzAWuIFg9qk3VvPPin3eoOaHAkcL4y0jw=; h=From:To:Cc:Subject:Date:From; b=GYfoZJ8e2+EdKfptw5AqXn3d20sGmOsvgf9HtNZVSz4SHyLqdx06QLhRa9+w9FtJY 2Fy1KKn983nntKXQDDZAKtgoi5TJixYZeh9d7aest5bFriHiNLNvDDzDTmQcXqsfTW sigDKCUfVJKGzHf/bWPixoua0n41mIeltNzHxFDQ= Received: from subhashj-linux1.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: subhashj@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 84004614A1; Thu, 24 Nov 2016 00:31:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1479947518; bh=Wv6EgFSE/YHzAWuIFg9qk3VvPPin3eoOaHAkcL4y0jw=; h=From:To:Cc:Subject:Date:From; b=AxrdPC5ql9tJhMF0r6D2ATUYCoOK7+6Sshg7QFDVLJCNq9ELw29ryqI87yUvp+t1/ IiplYu65ulrrkuZwgidStBnxYnxd9/Axi3rYMTfQcr8DsYhFPXIXThyXx3TZcR+Hyc tw1y81/X2usYPt7eSTazVEW5Il71S4mLd3VhmZM8= DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 84004614A1 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=subhashj@codeaurora.org From: Subhash Jadavani To: vinholikatti@gmail.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com Cc: Subhash Jadavani , linux-scsi@vger.kernel.org (open list:UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER), linux-kernel@vger.kernel.org (open list) Subject: [PATCH v1 05/11] scsi: ufs: increase the scsi query response timeout Date: Wed, 23 Nov 2016 16:31:52 -0800 Message-Id: <1479947512-7096-1-git-send-email-subhashj@codeaurora.org> X-Mailer: git-send-email 1.9.1 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP It is found thats UFS device may take longer than 30ms to respond to query requests and in this case we might run into following scenario: 1. UFS host SW sends a query request to UFS device to read an attribute value. SW uses tag #31 for this purpose. 2. UFS host SW waits for 30ms to get the query response (and doorbell to be cleared by UFS host HW). 3. UFS device doesn't respond back within 30ms hence UFS host SW times out waiting for the query response. 4. UFS host SW clears the tag#31 from UTRLCLR register. 5. UFS host SW waits until UFS host HW to clear tag#31 from the doorbell register. 6. UFS host SW retries the same query request on same tag#31 (sends a query request to device to read an attribute value). 7. UFS host HW gets the query response from the device but this was intended as a query response for the 1st query request sent (step-1). 8. Now UFS device sends another query response to host (for query request sent @step-6). Now there are 2 issues that could happen with above scenario: 1. UFS device should have actually responded back with only one query response but it is found that device may respond back with 2 query responses. 2. If UFS device responds back with 2 resposes on same tag, host HW/SW behaviour isn't predictable. To avoid running into above scenario, we would basically allow device to take longer (upto 1.5 seconds) for query response. Reviewed-by: Gilad Broner Signed-off-by: Subhash Jadavani --- drivers/scsi/ufs/ufshcd.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index d6e87dc..393f6d5 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -59,15 +59,9 @@ #define NOP_OUT_TIMEOUT 30 /* msecs */ /* Query request retries */ -#define QUERY_REQ_RETRIES 10 +#define QUERY_REQ_RETRIES 3 /* Query request timeout */ -#define QUERY_REQ_TIMEOUT 30 /* msec */ -/* - * Query request timeout for fDeviceInit flag - * fDeviceInit query response time for some devices is too large that default - * QUERY_REQ_TIMEOUT may not be enough for such devices. - */ -#define QUERY_FDEVICEINIT_REQ_TIMEOUT 600 /* msec */ +#define QUERY_REQ_TIMEOUT 1500 /* 1.5 seconds */ /* Task management command timeout */ #define TM_CMD_TIMEOUT 100 /* msecs */ @@ -1842,9 +1836,6 @@ int ufshcd_query_flag(struct ufs_hba *hba, enum query_opcode opcode, goto out_unlock; } - if (idn == QUERY_FLAG_IDN_FDEVICEINIT) - timeout = QUERY_FDEVICEINIT_REQ_TIMEOUT; - err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, timeout); if (err) {