From patchwork Tue Nov 6 13:30:07 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sjoerd Simons X-Patchwork-Id: 150271 Delivered-To: patch@linaro.org Received: by 2002:a2e:299d:0:0:0:0:0 with SMTP id p29-v6csp3890222ljp; Tue, 6 Nov 2018 05:30:13 -0800 (PST) X-Google-Smtp-Source: AJdET5fLpMXxsS/x/ERFRHLK3mQ9LPME93ZTQhQENSW9S0g8r+uK5Dxj+oMA/bZWmkbCdAMBiuMl X-Received: by 2002:a17:902:8a8e:: with SMTP id p14-v6mr10334708plo.133.1541511012968; Tue, 06 Nov 2018 05:30:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541511012; cv=none; d=google.com; s=arc-20160816; b=i7tSePIwmm71ruQy6C3DnG9jrE+0Gwtu05Im1q1r/8OC8cQTBlGFw8gDSM6h8q7seB PlwcYcVgZssLYZLpOlp7eY17a0lfz/PLAxDQwu8pVwCeD61tjutXECYED9Kdjn48kMXv HEeGJ2ajC5z8/Zd2AoqqYz9cL0BXKP/6fnN5o1XDt9im0GOz/TMBCNtJ1iSBfAJQdla0 iJsFigsbWfXjFp5TuSUEP883P215qcvJpA6Di3OQQ+p8mbWqntg0e8dOw/hGqVHRT7+4 2IXhf3TTE75p0AKi2JHK1pnRy2CGikmoXR2AwLUvsexdYnnUagd9EvRxCR24Y4Q9TbDB GX0A== 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=AIWPa7EOFDQ+JQyNCOV/bY+KQEB6/Ii512AqR6v/yGpjxw7laqGiRq4OSBa2EV533K KJ+BqpnA+YrFgPpuIeg1omi8xzmomvOMkxJxferLMCYXr+H6w/iPbSJzxnPDITSdWbYQ wEbNkxTwdX2Ply2Wfq3vzZea8+xiHsB+lVASGNDpuCaH3EzrWcG5dXo8ujG0og0j/7AX u1D9IQvn55qxzi9rul0Z9hvd0iOphTOvILL4TZuva/YNXP34EQ0kcTsd4XLSA49cNBwR VDAXkxT3vFQ+tjb5L0/K6jNfS05t8pk+oJcJaiTAxZX6H+6j1fVNDB4hKgdZdeOLflYm MMPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-mmc-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 p62-v6si48403349pfb.77.2018.11.06.05.30.12; Tue, 06 Nov 2018 05:30:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-mmc-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-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-mmc-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 S1730470AbeKFWzZ (ORCPT + 5 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 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@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(-) -- 2.19.1 Reported-by: Andreas Dannenberg Signed-off-by: Faiz Abbas Signed-off-by: Sekhar Nori 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;