Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1856843imu; Tue, 6 Nov 2018 05:31:23 -0800 (PST) X-Google-Smtp-Source: AJdET5fEjOmWBvYSYrLy7dR/sIyYx7ym96bq2Y1uVmGoF9CCbmAcyZWMIYxwhwCf7u6f+rVV2Tm6 X-Received: by 2002:a63:e40c:: with SMTP id a12mr16009527pgi.28.1541511083879; Tue, 06 Nov 2018 05:31:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541511083; cv=none; d=google.com; s=arc-20160816; b=sr0/u1nHzDxhEYOff+SjJQhAY0FMdl8WM2hfHu04eiZNhDNfXzqlDMypDoTrMR+m/+ 98Vd/kDG5ar7wHqncpbrkdNXrio98GOfKjxk3zBGopLIsGnTDqMKZTwIPrcfjnAKDoQT 75sEGnmA3Sfgi7+9PA43+rn6Y+lBXjvfVdoLLJlfQvs443xImTs6xF5h2X1WLJlCB91p BSFoWBidhA+pu5O8NCB/xgEvzKSiT4qZRL7/EnODVfhy/61OvF6BPCRfi/uLWzWBls1K AswM3bItVIlaA2EJUcQfurA8io96TH3iNt9lg9BZNHn3Am99wCVTC0NtXnNkDD4AJuvc Hz9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=6ZD8yrw20MFD1Qbv8TYYdV1vvV9H3I2R8DOdIjUlBUk=; b=KsVFrjojRPqMIyZgpnGInS/Q+3Us6nL5S/2RZLxL7k4lkjxvFESrSFFnBmJmVlEOB0 JfFQeH9emXyYDW/D3c40/bazyDBAlJTKZ0GO5s/Vx4Eo/nBAmB+VGI3JWa4wcB8KpVfD 1IVEhbBqvukjIm0wuEwWsiIz5rL9riepp97sGi3Z2EAwKZ7+H6zIg+SAjBae9UwdoYqa FmFWnD7J918dHQBg7QlUVr9fES1/QDYpMJyKxRDz7TwmlkHUyFzTIjT9a656g+UcXs8E ElVK4gG7cKDE39CQ2k5p6lV+Epp8jyCzBWt5l271QTBnf0tyqThPBMpvFNlH81dAVi/x MMvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u8-v6si39776733plh.188.2018.11.06.05.31.07; Tue, 06 Nov 2018 05:31:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730606AbeKFWzZ (ORCPT + 99 others); Tue, 6 Nov 2018 17:55:25 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:53740 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730421AbeKFWzZ (ORCPT ); Tue, 6 Nov 2018 17:55:25 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: sjoerd) with ESMTPSA id 68D8F27DDD7 Received: by beast.luon.net (Postfix, from userid 1000) id EA1283E238B; Tue, 6 Nov 2018 14:30:07 +0100 (CET) From: Sjoerd Simons To: linux-mmc@vger.kernel.org Cc: kernel@collabora.com, linux-kernel@vger.kernel.org, Hongjie Fang , Bastian Stender , Kyle Roeschley , Wolfram Sang , Shawn Lin , Ulf Hansson , Harish Jenny K N , Simon Horman Subject: [PATCH] mmc: core: Remove timeout when enabling cache Date: Tue, 6 Nov 2018 14:30:07 +0100 Message-Id: <20181106133007.12318-1-sjoerd.simons@collabora.co.uk> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On some of our boards containing Micron eMMC chips compatible with the eMMC 5.0 specification we starting seeing boot failures due to timeouts: mmc1: error -110 whilst initialising MMC card It turns out that switching the cache on after a power loss event can take quite long. In some simple testing thusfar we've seen values up to 700ms, which is far longer then the GENERIC_CMD6_TIME of the chip (250ms). Looking at both the eMMC 4.51 and 5.0 specification there doesn't seem to be a defined upper bound for the CACHE_CTRL ON command. For both CACHE_CTRL OFF and FLUSH_CACHE it is documented that they can take essentially unbounded time, but CACHE_CTRL ON i get the impression that it's assumed to be "fast". Unfortunately this is not true in reality. To resolve this, simply drop the timeout from CACHE_CTRL ON and assume it might take an unbounded time similar to the FLUSH_CACHE command. Signed-off-by: Sjoerd Simons --- drivers/mmc/core/mmc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index bc1bd2c25613..ac70b508a939 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -1794,8 +1794,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, if (!mmc_card_broken_hpi(card) && card->ext_csd.cache_size > 0) { err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, - EXT_CSD_CACHE_CTRL, 1, - card->ext_csd.generic_cmd6_time); + EXT_CSD_CACHE_CTRL, 1, 0); if (err && err != -EBADMSG) goto free_card; -- 2.19.1