From patchwork Fri Jan 12 00:03:01 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Beno=C3=AEt_Th=C3=A9baudeau?= X-Patchwork-Id: 10158867 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 456E8602A7 for ; Fri, 12 Jan 2018 00:03:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3A5E928877 for ; Fri, 12 Jan 2018 00:03:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2EC43288A8; Fri, 12 Jan 2018 00:03:25 +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_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham 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 7ED7F28877 for ; Fri, 12 Jan 2018 00:03:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753998AbeALADX (ORCPT ); Thu, 11 Jan 2018 19:03:23 -0500 Received: from mail-ua0-f173.google.com ([209.85.217.173]:36314 "EHLO mail-ua0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753517AbeALADW (ORCPT ); Thu, 11 Jan 2018 19:03:22 -0500 Received: by mail-ua0-f173.google.com with SMTP id a25so2923441uak.3 for ; Thu, 11 Jan 2018 16:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wQVR/vkpw3rfmV2mymSvRamNmv1BHcMD0yya6P0e70I=; b=OLk8+0+yLMuCCX1Wz/W0wWU6JKs27WyGS1VC5+ClitVQpGP+i4vGee+e7GUK8W/psE vuKJqMgdHXjEf7TebtBbzo8F7DMH8Y+J0P3LB2wpz/SDaDm1yhwlJl3jdgMWsWwQzmij r5h6abPPSpqBgNV1+StEAlYGUwWFznO8IIOkYf80yMm9/ijIB8aTOnvmBpYISjuTZ6tq rSWSnsBdZiUEtxxVDavjK/rht3Y2elXUHhpFT8WOFe5MTLwhjmSct3d2yrbEP9PNn5G0 q9YqjfZpIkxxpRNgciXOlPI/2M6JJvWEsCieE1PcOTg0HSqL1n6Gtwh6wdZrF8NMSvxo MKBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wQVR/vkpw3rfmV2mymSvRamNmv1BHcMD0yya6P0e70I=; b=N4MZ432wY8sxayXbgRyip54oKt8qTkpFzl1xFxpG5RLDix+/sLNQ6AJPgJJbJIdfar 0UJGZOURG8K0McOy6dCDGwt1RUFANXcPFLib5oWjRi5gP4FIA8+UHda9tTYz8ePpB/Li yscVQA8GEtLp4GjJpdqWDulvoJmrqWlbx1v4gqq5R+ouFnEFx95Qzrud7bH1IjbvSy1L cxE3OVsdPG5XImeOM6JCA7x2vBCo1h9doU1Mx4bFqrYmza7IywVfBjNkcnKm+LZT+VTQ 6InNxt5z5swThXSQSZFWs0677vINGs7mcDi2CsZimSPEW3TQWko59kw0wP5CKf2bcEmj ORwA== X-Gm-Message-State: AKwxytcGwaFS3QjhxjA/AVDJhIQaYh4ocoz7LZ+5gl0JMORFqeHHsYPS dSz3K4IFKPIThUn8sRuumXxQmVy8A3fkKCHAxnI= X-Google-Smtp-Source: ACJfBotNCeln2cjenxZgdhFQxDKejDE+nS0q0EwN15mmlA6Rl5OpD8CsDz0EvQIZZbnsG+Wwzioq64zpDMDYK9/RViQ= X-Received: by 10.159.49.14 with SMTP id m14mr24044094uab.92.1515715402037; Thu, 11 Jan 2018 16:03:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.13.137 with HTTP; Thu, 11 Jan 2018 16:03:01 -0800 (PST) In-Reply-To: References: <20180111171538.GA32086@amethyst.visucore.com> From: =?UTF-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= Date: Fri, 12 Jan 2018 01:03:01 +0100 Message-ID: Subject: Re: 4.15.0-rc5 fails boot on MX53 LOCO board due to MMC (clock?) issue To: "Wladimir J. van der Laan" Cc: linux-mmc@vger.kernel.org, =?UTF-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= , Fabio Estevam , Ulf Hansson , Chris Healy 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 On Thu, Jan 11, 2018 at 11:11 PM, Benoît Thébaudeau wrote: > Dear Wladimir J. van der Laan, > > On Thu, Jan 11, 2018 at 6:15 PM, Wladimir J. van der Laan > wrote: >> Hello, >> >> I'm experiencing issues with kernel 4.15.0-rc5 on a MX53 LOCO board. >> >> Setup is two 32GB Samsung microSD SDHC cards plugged in >> >> mmc0 plugged indirectly: contains boot and auxiliary data >> mmc1 through SD->microSD adapter that came with the card: contains root fs >> >> Initial error is "mmcblk1: error -84 transferring data, sector 2048, nr 8, cmd >> response 0x900, card status 0xc00". Then various SDHCI REGISTER DUMP follow >> after timeouts and CRC errors. It looks like the filesystem is corrupting, >> resulting in a failed boot. >> >> Bisection gives me: >> >> 5143c953a7864c7abacf1c167c4350d641626949 is the first bad commit >> commit 5143c953a7864c7abacf1c167c4350d641626949 >> Author: Benoît Thébaudeau >> Date: Tue May 30 11:14:10 2017 +0200 >> >> mmc: sdhci-esdhc-imx: Allow all supported prescaler values >> >> On i.MX, SYSCTL.SDCLKFS may always be set to 0 in order to make the SD >> clock frequency prescaler divide by 1 in SDR mode, even with the eSDHC. >> The previous minimum prescaler value of 2 in SDR mode with the eSDHC was >> a code remnant from PowerPC, which actually has this limitation on >> earlier revisions. >> >> In DDR mode, the prescaler can divide by up to 512. >> >> The maximum SD clock frequency in High Speed mode is 50 MHz. On i.MX25, >> this change makes it possible to get 48 MHz from the USB PLL >> (240 MHz / 5 / 1) instead of only 40 MHz from the USB PLL >> (240 MHz / 3 / 2) or 33.25 MHz from the AHB clock (133 MHz / 2 / 2). >> >> Signed-off-by: Benoît Thébaudeau >> Acked-by: Adrian Hunter >> Reviewed-by: Fabio Estevam >> Signed-off-by: Ulf Hansson >> >> And indeed, after reverting this particular commit on top of 4.15.0-rc5, the problem goes away. >> >> This could be a clock rate tolerance issue with the particular brand/type of >> SD card, however I've not experienced any issues with them before. > > [...] > > In a few words, looking at the reference manual of the i.MX53, there > is an exception with its eSDHCv3: it does not allow SYSCTL.SDCLKFS = > 0. It seems to be fine for the eSDHCv2 instances of the i.MX53 and for > all the other i.MXs. So your issue can be fixed by changing the > minimum legal prescaler value if eSDHCv3 is detected on i.MX53. I will > send something for that. This should also be fixed in U-Boot. Can you please try the change below? If it works and everyone is fine with it, I will send a proper patch. Best regards, Benoît Tested-by: Wladimir J. van der Laan --- | ESDHC_CLOCK_MASK); -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/drivers/mmc/host/sdhci-esdhc-imx.c +++ b/drivers/mmc/host/sdhci-esdhc-imx.c @@ -687,6 +687,20 @@ static inline void esdhc_pltfm_set_clock(struct sdhci_host *host, return; } + /* For i.MX53 eSDHCv3, SYSCTL.SDCLKFS may not be set to 0. */ + if (is_imx53_esdhc(imx_data)) { + /* + * According to the i.MX53 reference manual, if DLLCTRL[10] can + * be set, then the controller is eSDHCv3, else it is eSDHCv2. + */ + val = readl(host->ioaddr + ESDHC_DLL_CTRL); + writel(val | BIT(10), host->ioaddr + ESDHC_DLL_CTRL); + temp = readl(host->ioaddr + ESDHC_DLL_CTRL); + writel(val, host->ioaddr + ESDHC_DLL_CTRL); + if (temp & BIT(10)) + pre_div = 2; + } + temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); temp &= ~(ESDHC_CLOCK_IPGEN | ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN