From patchwork Tue May 10 18:16:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 9060721 Return-Path: X-Original-To: patchwork-linux-rockchip@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 25086BF29F for ; Tue, 10 May 2016 18:17:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2B2A620173 for ; Tue, 10 May 2016 18:17:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2EB3920172 for ; Tue, 10 May 2016 18:17:34 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1b0CDr-0006Gt-Vn; Tue, 10 May 2016 18:17:31 +0000 Received: from mail-pf0-x230.google.com ([2607:f8b0:400e:c00::230]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1b0CDp-0006EK-87 for linux-rockchip@lists.infradead.org; Tue, 10 May 2016 18:17:30 +0000 Received: by mail-pf0-x230.google.com with SMTP id c189so8803567pfb.3 for ; Tue, 10 May 2016 11:17:08 -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; bh=E3m4XDGk2YCMeLOReLRtLZaDItytQcPY0zF5O20sFhQ=; b=NYzv0ApVDr4NX48CMUeTi+XxI8e2z7uf+oNV27tC0QkIhnt+rGIqdRMDX2YFcRE9WF SWy3lRte50EAGTSy79/9tqlcTbk8gkMCPsQBNDtWrSZMUJF/8uzPvBub2gKDQ/lO5T2W 8Pqj/E8dkVaHZV+We4o0H6iKgesrhhAOju5FE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=E3m4XDGk2YCMeLOReLRtLZaDItytQcPY0zF5O20sFhQ=; b=H7h3V6TRYTCy2PY2Pm6RyA3hTiCp3mn/+BO0tOdl7JVCJFcj4x/vZf/5RuEFYYi6ER tVsFHN+O24W6GTpJDe/acrSwZojs7wzWbTCo4WD1iwHTbUM8iqx543rIjknAkGoP7aI2 B6dDI+hhZ7FRBgxWpSpScYWNtWIvlUS9fy3RyTsCN0aRqdFSf36YtDYkCGxNC+alU1Ax TPEy0y7Q/i92NxkroKXazK1l7WZbWBFejJZic3pOH/flIE5wuy9vUz5tUbqtZC3gYdz8 EJNIyHTqAhMmR4RiN17yy6brXvaUFuAmmHYfP93q9iJcVzFZWwC17jmVtTI/OpM/F0tZ Hokw== X-Gm-Message-State: AOPr4FVLtGaS5xWsiDAx7YmnvRpnU7I1p+qLbhQbP6Tti/GqufLVsqtge76G0rrHrnfocQ== X-Received: by 10.98.91.198 with SMTP id p189mr27328766pfb.146.1462904228244; Tue, 10 May 2016 11:17:08 -0700 (PDT) Received: from tictac.mtv.corp.google.com ([172.22.65.76]) by smtp.gmail.com with ESMTPSA id 7sm6075279pfe.88.2016.05.10.11.17.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 May 2016 11:17:07 -0700 (PDT) From: Douglas Anderson To: jh80.chung@samsung.com, Ulf Hansson , Heiko Stuebner , shawn.lin@rock-chips.com Subject: [PATCH] mmc: dw_mmc: rockchip: Set the drive phase to 180 degrees Date: Tue, 10 May 2016 11:16:35 -0700 Message-Id: <1462904195-18229-1-git-send-email-dianders@chromium.org> X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160510_111729_366068_8AC8DE60 X-CRM114-Status: GOOD ( 16.97 ) X-Spam-Score: -2.7 (--) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: briannorris@chromium.org, linux-mmc@vger.kernel.org, Douglas Anderson , linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance where the power on default is wrong or where the firmware didn't configure this properly then we'll get a mysterious failure. Let's explicitly set this phase in the kernel. You might notice that this patch is currently very dumb and just always sets this phase to 180 degrees. As far as I can tell this is actually a sane thing to do. From reading through the Designware Databook it appears that there are instances where you could still meet hold time requirements and set this phase to 90 degrees, but nothing I've read indicates that 180 degrees is not OK also. As indicated above, adding a delay to the drive is used to achieve proper hold times. For a given speed mode hold times are listed in the spec in terms of nanoseconds. The hold times are different for different speed modes. The actual hold time achieved is actually a function of Delay_O (an internal delay in dw_mmc, which could vary from SoC model to SoC model), pad delays, and the drive delay (which we're setting here). Note also that by setting the drive delay as a phase we will get a different number of nanoseconds of delay depending on the input clock. Note that, as far as I can tell, this _does_ change the behavior of rk3288 devices. On devices I tested, which use coreboot/depthcharge as BIOS, the SDMMC/SDIO0/SDIO1 drive phase used to be 90 degrees. Now it will be 180 degrees. With my understanding from the Designware Databook the 180 degrees ought to be more correct and should increase compatibility. I have tested this by inserting my collection of uSD cards (mostly UHS, though a few not) into a veyron_minnie and confirmed that they still seem to enumerate properly. For a subset of them I tried putting a filesystem on them and also tried running mmc_test. Signed-off-by: Douglas Anderson --- drivers/mmc/host/dw_mmc-rockchip.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c index 8c20b81cafd8..62cbd33a07cd 100644 --- a/drivers/mmc/host/dw_mmc-rockchip.c +++ b/drivers/mmc/host/dw_mmc-rockchip.c @@ -66,6 +66,27 @@ static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios) /* Make sure we use phases which we can enumerate with */ if (!IS_ERR(priv->sample_clk)) clk_set_phase(priv->sample_clk, priv->default_sample_phase); + + /* + * Set the drive phase to 180 degrees. This helps us achieve proper + * hold times. + * + * Note that this is _not_ a value that is tuned and is also _not_ a + * value that will vary from board to board. It is a value that + * _could_ vary between different SoC models (could be different on + * rk3066 vs. rk3288 for instance). It is also a value that _could_ + * need to be adjusted based on our clock frequency and speed mode + * since different speed modes have different hold time requirements + * and hold time requirements are in "ns" (a phase offset adds a + * different "ns" delay for different input clocks). + * + * Despite these theoretical needs, it has been observed that 180 + * degrees gives us good signaling across all tested SoCs and all + * tested speed modes. If when we find someone that needs 90 degrees + * here we can add a table based on speed mode / SoC compatible ID. + */ + if (!IS_ERR(priv->drv_clk)) + clk_set_phase(priv->drv_clk, 180); } #define NUM_PHASES 360