From patchwork Tue Nov 3 20:37:25 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 316940 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFFCCC388F7 for ; Tue, 3 Nov 2020 21:27:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6011C20757 for ; Tue, 3 Nov 2020 21:27:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604438834; bh=HhNDJzeC3EK4hMXYyYjZ2WxRqOgNM2/3kDgCDmDW1oI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=CwyLwvJ4c1VKmg4e+x0KsGqy8dezwJ4MrGg/Gfcj5W/3VPI+uM95J9ildNeUzEi4+ 17wEJlE+gb8U3p+dAoXwdGTlgIh8TKY0paDb6VEcyAwPAlsspA95Jg3X/26mB//qA+ 78jTHMdTWEY8eVzG1Lg/4hLgNOI6slSkf6ryFI9U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733292AbgKCVBE (ORCPT ); Tue, 3 Nov 2020 16:01:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:37260 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733038AbgKCVBC (ORCPT ); Tue, 3 Nov 2020 16:01:02 -0500 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2A9A722226; Tue, 3 Nov 2020 21:01:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604437261; bh=HhNDJzeC3EK4hMXYyYjZ2WxRqOgNM2/3kDgCDmDW1oI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zB7nMNh6UoncVa6XlcFhy3JSvcslctFBpxFwT8KdMziDJ+WLga+vQDd/3fdAhHsmQ /VCgbMAenkcmrDaiCSjbOD9AOpDW6KEMUBS0Ik1ZB3HPi0LEYCLMlj34FrOWzinQYK o1h4WHvyUZW6jKtwSJHyZYGW0gMoaMyxzPQG+Vmc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Walle , Adrian Hunter , Ulf Hansson Subject: [PATCH 5.4 197/214] mmc: sdhci-of-esdhc: set timeout to max before tuning Date: Tue, 3 Nov 2020 21:37:25 +0100 Message-Id: <20201103203309.110202991@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201103203249.448706377@linuxfoundation.org> References: <20201103203249.448706377@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Michael Walle commit 0add6e9b88d0632a25323aaf4987dbacb0e4ae64 upstream. 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 Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201022222337.19857-1-michael@walle.cc Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman --- drivers/mmc/host/sdhci-of-esdhc.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -1004,6 +1004,17 @@ static int esdhc_execute_tuning(struct m 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 {