From patchwork Tue Mar 27 09:29:53 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Masahiro Yamada X-Patchwork-Id: 10309671 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 37AD460212 for ; Tue, 27 Mar 2018 09:30:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2BCA229C33 for ; Tue, 27 Mar 2018 09:30:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2051E29C37; Tue, 27 Mar 2018 09:30:40 +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 9E10A29C33 for ; Tue, 27 Mar 2018 09:30:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751398AbeC0Jae (ORCPT ); Tue, 27 Mar 2018 05:30:34 -0400 Received: from conuserg-09.nifty.com ([210.131.2.76]:44377 "EHLO conuserg-09.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbeC0Jad (ORCPT ); Tue, 27 Mar 2018 05:30:33 -0400 Received: from pug.e01.socionext.com (p14092-ipngnfx01kyoto.kyoto.ocn.ne.jp [153.142.97.92]) (authenticated) by conuserg-09.nifty.com with ESMTP id w2R9U31D007315; Tue, 27 Mar 2018 18:30:03 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conuserg-09.nifty.com w2R9U31D007315 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1522143004; bh=as5UkoHC+7NGqSvWVG1LQaG3OmXp8gHY9r7meAoNFEo=; h=From:To:Cc:Subject:Date:From; b=UJHgECkCc1krbm/eeQyyIPQHrzmIWgpfAPIJHZKd9+HY1QsWa5aqzuHiVhG2zpItj 66w5roypXqpJUSFLVhbnUdRiEsKxsEWCcYVk9UmV3T2v1jXy5+WtzivAeRRKweb773 9M7/ScFWHTTmL4uM9bPMl3Amj6zSQEMyprAhDnooZPTq+OJeqKG/1Mpv4ha4hfAQ1K 8DBcarLdq1gcs5dIUSBF6O4xc7grHS0WwBC6OajTR4aAii3UA4ulnArPOFL8KYOIha 0F7/LNrrxEcIQ5z5RmkYAj6MFSdYTwtEQVfIEQSpvdgqqYzU/Iip85x0kI+pGQAKwC TOmwIdxwUtgNQ== X-Nifty-SrcIP: [153.142.97.92] From: Masahiro Yamada To: linux-mmc@vger.kernel.org Cc: Piotr Sroka , Masahiro Yamada , linux-kernel@vger.kernel.org, Adrian Hunter , Ulf Hansson Subject: [PATCH] mmc: sdhci-cadence: send tune request twice to work around errata Date: Tue, 27 Mar 2018 18:29:53 +0900 Message-Id: <1522142993-25654-1-git-send-email-yamada.masahiro@socionext.com> X-Mailer: git-send-email 2.7.4 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 Cadence sent out an errata report to their customers of this IP. This errata is not so severe, but the tune request should be sent twice to avoid the potential issue. Quote from the report: Problem Summary --------------- The IP6116 SD/eMMC PHY design has a timing issue on receive data path. This issue may lead to an incorrect values of read/write pointers of the synchronization FIFO. Such a situation can happen at the SDR104 and HS200 tuning procedure when the PHY is requested to change a phase of sampling clock when moving to the next tuning iteration. Workarounds ----------- The following are valid workarounds to resolve the issue: 1. In eMMC mode, software sends tune request twice instead of once at each iteration. This means that the clock phase is not changed on the second request so there is no potential for clock instability. 2. In SD mode, software must not use the hardware tuning and instead perform an almost identical procedure to eMMC, using the HRS34 Tune Force register. Signed-off-by: Masahiro Yamada --- drivers/mmc/host/sdhci-cadence.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c index 0f589e2..bc30d16 100644 --- a/drivers/mmc/host/sdhci-cadence.c +++ b/drivers/mmc/host/sdhci-cadence.c @@ -253,6 +253,7 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val) struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host); void __iomem *reg = priv->hrs_addr + SDHCI_CDNS_HRS06; u32 tmp; + int i, ret; if (WARN_ON(!FIELD_FIT(SDHCI_CDNS_HRS06_TUNE, val))) return -EINVAL; @@ -260,11 +261,24 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val) tmp = readl(reg); tmp &= ~SDHCI_CDNS_HRS06_TUNE; tmp |= FIELD_PREP(SDHCI_CDNS_HRS06_TUNE, val); - tmp |= SDHCI_CDNS_HRS06_TUNE_UP; - writel(tmp, reg); - return readl_poll_timeout(reg, tmp, !(tmp & SDHCI_CDNS_HRS06_TUNE_UP), - 0, 1); + /* + * Workaround for IP errata: + * The IP6116 SD/eMMC PHY design has a timing issue on receive data + * path. Send tune request twice. + */ + for (i = 0; i < 2; i++) { + tmp |= SDHCI_CDNS_HRS06_TUNE_UP; + writel(tmp, reg); + + ret = readl_poll_timeout(reg, tmp, + !(tmp & SDHCI_CDNS_HRS06_TUNE_UP), + 0, 1); + + return ret; + } + + return 0; } static int sdhci_cdns_execute_tuning(struct mmc_host *mmc, u32 opcode)