Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp455643pxu; Fri, 23 Oct 2020 05:31:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfu1dG0Za/yBOgU8f26I7vhRKiFK6sfFe0evzYpa6woRFOjT8H6dZS6k/opNo/Ql/d+ZY6 X-Received: by 2002:a17:907:382:: with SMTP id ss2mr1804111ejb.544.1603456275097; Fri, 23 Oct 2020 05:31:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603456275; cv=none; d=google.com; s=arc-20160816; b=mDgUHcACIylo8+Mnnk3nXQjzLda2U/hvwFB9flCql6pJCMt7qg/SONrl4eB+MhiBYW 9j4qi0d36R+rWXgDQX9XgAkDSCk36wHcIzgArg3It63fvR+b/tsIVTdtNMAifdSZb7X8 anetHB4fdP2K18f6wghSG/MDZz04SEr4gbxtiKsIbuJBF5qA4RBy9WAop5g283t8Jwzy yZz2ewLwh35FFC+uWiJ6PSqvi1YWxj5Wnau/UUFdH6sdxIFHrhYEDZ2GkQxHWSzQdTIp CATkU1j03H7Rya2/TtpAS3t8jjF+8JtLamTbIvhqseg3wV570VjoqtXqPd8kz/p/zBTU R9fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=cdCHaJkQW9rShLRXxj7ElU/lrunlyUEAtdDvcabUG2w=; b=Yo3MbI1ItFoNzULgyccWXfRyzzC9Rsmy1RCqEwrMjYSd++rR18sosvLyrgQ8z1id1o DrVxVIRS6CyNkrZQz9mpoMMX36Zwj+Ju44yGY/jHeDqDIqJuiIj2t1REt4nDvx1DeCSZ F3MShyrHtwIIDCyyZJIO43aLosjHxmhwveVEvuS8wvqwarbyFEcn04ulfLK9YtHdNlJL Jj8znzkksXtJI3f4UKQgGOtka66tQN2O8l0dye/7sQcis8AeXIun+v5BlB8SMNsbMpf3 fsFGRNdW8jT0LgjRvKasCs9NOIJEVxLzjCg8KF/9RExmfLSAUMv+Q3S2VN99VhF3wRYb A8mw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=XOi0x38w; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp1si809397ejc.167.2020.10.23.05.30.52; Fri, 23 Oct 2020 05:31:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=XOi0x38w; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S369714AbgJVWYL (ORCPT + 99 others); Thu, 22 Oct 2020 18:24:11 -0400 Received: from ssl.serverraum.org ([176.9.125.105]:47693 "EHLO ssl.serverraum.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S369632AbgJVWYK (ORCPT ); Thu, 22 Oct 2020 18:24:10 -0400 Received: from apollo.fritz.box (unknown [IPv6:2a02:810c:c200:2e91:6257:18ff:fec4:ca34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id E189322F00; Fri, 23 Oct 2020 00:24:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1603405448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=cdCHaJkQW9rShLRXxj7ElU/lrunlyUEAtdDvcabUG2w=; b=XOi0x38w8s2x0F5DnnWfqaJ7NvNOk3w5LH4ZGac8IQsDEGRT3Vz9UJUTOK6O+38DAdlw1G SlEb6ObsC6stYC64Duv7YwDpUURY96cQ1SBqm09hjM5bil2iC2bBdjpyx77r9v67Jo3rqI 2PwZhur5vZ8t31c8iGMjGPUguYBC2AM= From: Michael Walle To: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Yangbo Lu , Adrian Hunter , Ulf Hansson , Michael Walle Subject: [PATCH v2] mmc: sdhci-of-esdhc: set timeout to max before tuning Date: Fri, 23 Oct 2020 00:23:37 +0200 Message-Id: <20201022222337.19857-1-michael@walle.cc> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On rare occations there is the following error: mmc0: Tuning timeout, falling back to fixed sampling clock There are SD cards which takes a significant longer time to reply to the first CMD19 command. The eSDHC takes the data timeout value into account during the tuning period. The SDHCI core doesn't explicitly set this timeout for the tuning procedure. Thus on the slow cards, there might be a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong sequence of events. In the end this will lead to an unsuccessful tuning procedure and to the above error. To workaround this, set the timeout to the maximum value (which is the best we can do) and the SDHCI core will take care of the proper timeout handling. Fixes: ba49cbd0936e ("mmc: sdhci-of-esdhc: add tuning support") Signed-off-by: Michael Walle Acked-by: Adrian Hunter --- Changes since v1: - Added fixes tag. Suggested by Ulf Hansson. drivers/mmc/host/sdhci-of-esdhc.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c index 0b45eff6fed4..baf7801a1804 100644 --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -1052,6 +1052,17 @@ static int esdhc_execute_tuning(struct mmc_host *mmc, u32 opcode) esdhc_tuning_block_enable(host, true); + /* + * The eSDHC controller takes the data timeout value into account + * during tuning. If the SD card is too slow sending the response, the + * timer will expire and a "Buffer Read Ready" interrupt without data + * is triggered. This leads to tuning errors. + * + * Just set the timeout to the maximum value because the core will + * already take care of it in sdhci_send_tuning(). + */ + sdhci_writeb(host, 0xe, SDHCI_TIMEOUT_CONTROL); + hs400_tuning = host->flags & SDHCI_HS400_TUNING; do { -- 2.20.1