From patchwork Thu Oct 12 20:11:17 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Douglas Anderson X-Patchwork-Id: 10002751 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 D5A4D60216 for ; Thu, 12 Oct 2017 20:12:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C8B7D28E98 for ; Thu, 12 Oct 2017 20:12:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BD87828EA0; Thu, 12 Oct 2017 20:12:05 +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 7509228E98 for ; Thu, 12 Oct 2017 20:12:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753371AbdJLULt (ORCPT ); Thu, 12 Oct 2017 16:11:49 -0400 Received: from mail-pf0-f171.google.com ([209.85.192.171]:49294 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755723AbdJLULo (ORCPT ); Thu, 12 Oct 2017 16:11:44 -0400 Received: by mail-pf0-f171.google.com with SMTP id l188so6449272pfc.6 for ; Thu, 12 Oct 2017 13:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Qeg51n6Gh5d7nfY8t1fonGhg9mpMzomzAbxYqeraFRU=; b=IX//MgS+1Y+geebDWGm4FOPXoFy1VhCgg16DGkgdlbKUmnGqK6FIRrfZkx4VD401a6 qCSfILap+Ks+cCsCDaGQY6BP0lrA0qHmJGPZVu4WYFXk4DMca3wjpXjPS/812JLDuZah vJghmb+UuosdUDt6Z4MT/phDoVW/XcvTWdU08= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=Qeg51n6Gh5d7nfY8t1fonGhg9mpMzomzAbxYqeraFRU=; b=dTGOcdmyUAyaakDG76zdOA1NCNZbp5pz6BGMJF1JO6kJjdPoQcsGv827jfEZZqEANd uNRS9B17vxYP4d3zFSz6sJE4Swl6a4mv9Xq0ocs4/h3kk0rrfjky2SPuSXu4CwW5c9fx nd2ViDogBCFtQsf1ioSIzuiiwNaxYBPSQU4jLj6tjJBejoGo58deGbRUdy206MT1lPXp 4amMD7MzIixRyMQh/vMsrvZFcX5iLMpdAdvj+s2KdBdF1EmemC//C7ez4yf0n+clQxlD VGUTJHZkJmDj24sOVN5J2TSqDUdvQxCjTmb/lCqmDmFhDl4vJIbPXX8pUj6/+w6NHueM OKTg== X-Gm-Message-State: AMCzsaXqRFFVRB0MKrvdU1Js+bPoTdYXxQPD/4IEU0WTsroLAjG7zGmY duEYAdI+z/+EmCZVlrmy6zZ0GQ== X-Google-Smtp-Source: AOwi7QDVV84EFfD7Erqnw4car3s6ZUmpDS83vBc2/4Roq2MJ7ei75i8DbddPfnU4jcq+sqfpizAd0A== X-Received: by 10.98.72.198 with SMTP id q67mr3152038pfi.110.1507839104159; Thu, 12 Oct 2017 13:11:44 -0700 (PDT) Received: from tictac.mtv.corp.google.com ([172.22.112.154]) by smtp.gmail.com with ESMTPSA id l3sm29749635pgn.36.2017.10.12.13.11.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Oct 2017 13:11:43 -0700 (PDT) From: Douglas Anderson To: jh80.chung@samsung.com, ulf.hansson@linaro.org, shawn.lin@rock-chips.com Cc: xzy.xu@rock-chips.com, amstan@chromium.org, linux-rockchip@lists.infradead.org, briannorris@chromium.org, linux-samsung-soc@vger.kernel.org, kernel@esmil.dk, Douglas Anderson , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 4/5] mmc: dw_mmc: Fix the DTO timeout calculation Date: Thu, 12 Oct 2017 13:11:17 -0700 Message-Id: <20171012201118.23570-5-dianders@chromium.org> X-Mailer: git-send-email 2.15.0.rc0.271.g36b669edcc-goog In-Reply-To: <20171012201118.23570-1-dianders@chromium.org> References: <20171012201118.23570-1-dianders@chromium.org> Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Just like the CTO timeout calculation introduced recently, the DTO timeout calculation was incorrect. It used "bus_hz" but, as far as I can tell, it's supposed to use the card clock. Let's account for the div value, which is documented as 2x the value stored in the register, or 1 if the register is 0. NOTE: This was likely not terribly important until commit 16a34574c6ca ("mmc: dw_mmc: remove the quirks flags") landed because "DIV" is documented on Rockchip SoCs (the ones that used to define the quirk) to always be 0 or 1. ...and, in fact, it's documented to only be 1 with EMMC in 8-bit DDR52 mode. Thus before the quirk was applied to everyone it was mostly OK to ignore the DIV value. I haven't personally observed any problems that are fixed by this patch but I also haven't tested this anywhere with a DIV other an 0. AKA: this problem was found simply by code inspection and I have no failing test cases that are fixed by it. Presumably this could fix real bugs for someone out there, though. Fixes: 16a34574c6ca ("mmc: dw_mmc: remove the quirks flags") Signed-off-by: Douglas Anderson Reviewed-by: Shawn Lin --- Changes in v2: - Fix the DTO timeout calculation new for v2 drivers/mmc/host/dw_mmc.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 50148991f30e..6bc87b1385a9 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -1936,10 +1936,16 @@ static int dw_mci_data_complete(struct dw_mci *host, struct mmc_data *data) static void dw_mci_set_drto(struct dw_mci *host) { unsigned int drto_clks; + unsigned int drto_div; unsigned int drto_ms; + unsigned long irqflags; drto_clks = mci_readl(host, TMOUT) >> 8; - drto_ms = DIV_ROUND_UP(drto_clks, host->bus_hz / 1000); + drto_div = (mci_readl(host, CLKDIV) & 0xff) * 2; + if (drto_div == 0) + drto_div = 1; + drto_ms = DIV_ROUND_UP(MSEC_PER_SEC * drto_clks * drto_div, + host->bus_hz); /* add a bit spare time */ drto_ms += 10;