From patchwork Fri Apr 14 07:41:20 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bough Chen X-Patchwork-Id: 9680731 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 BB3B260326 for ; Fri, 14 Apr 2017 07:41:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id ABFE12863E for ; Fri, 14 Apr 2017 07:41:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9E9A42866A; Fri, 14 Apr 2017 07:41:28 +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=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 8E2242863E for ; Fri, 14 Apr 2017 07:41:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751518AbdDNHl0 (ORCPT ); Fri, 14 Apr 2017 03:41:26 -0400 Received: from mail-eopbgr00062.outbound.protection.outlook.com ([40.107.0.62]:52320 "EHLO EUR02-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751492AbdDNHlZ (ORCPT ); Fri, 14 Apr 2017 03:41:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k8a6dj6HG+HURMV3SXZtx0ZpPDBQ+hoLllVssRKZ40M=; b=r/nelA2QypQkcWd4JuVJp2FRah6KTC1LJi/y/RoWgsTGetN8HMLg71D2hJn/ennRSx8HJgbg8zU3JkimCdBR786xBmbZTtwX7prOl2HffNBSV0d9WWiXrQA9NRByErWbS62Cu3O+Bu8CJNxH5FiMeWxQnJ39cvncMEEtAAEWP0I= Received: from VI1PR0401MB2335.eurprd04.prod.outlook.com (10.169.133.150) by VI1PR0401MB2640.eurprd04.prod.outlook.com (10.168.66.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Fri, 14 Apr 2017 07:41:21 +0000 Received: from VI1PR0401MB2335.eurprd04.prod.outlook.com ([10.169.133.150]) by VI1PR0401MB2335.eurprd04.prod.outlook.com ([10.169.133.150]) with mapi id 15.01.1034.012; Fri, 14 Apr 2017 07:41:20 +0000 From: Bough Chen To: Tim Harvey CC: David Haworth , Linux MMC List , Fabio Estevam , "Ulf Hansson" , Weijun Yang , "Adrian Hunter" Subject: RE: IMX6 ESDHC mmc with UHS-I occasional failure with DDR50 cards Thread-Topic: IMX6 ESDHC mmc with UHS-I occasional failure with DDR50 cards Thread-Index: AQHSrYoo/5eqkZZe7EeLU2SO7SNj2qG1wrcAgASUAwCABZJxMIAAWZ6AgAREGZA= Date: Fri, 14 Apr 2017 07:41:20 +0000 Message-ID: References: <20170404220040.GA2997@fen-net.de> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gateworks.com; dkim=none (message not signed) header.d=none; gateworks.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [199.59.231.64] x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2640; 7:moOOYhmr17hMkLMOSuMQ+Ox7iriR2U3/aFtL/i17ukYUQHjC8sVcdwIsA0DBiv/jbcDvK5zsfKtejlWuyKuN7BAqtKIZV2iKVwI+DIqLovYWpzPHGlDaPeXe9JWkXNZg/mP73lVyeAjJB6xg0TEFYoZDOAa5BHidfPhB9jue46oDYq4NmPJsHP+hORBLyyl7jzQoMY0mEUPCzToakn9Pk/kuuPUvYP0bXeoJXjHIgAsU0ajdYeqQ0qc6DYhFSKOh4TtCBExM1FAGkQX/SvBdwdFNSk2/s1lJzFHPgfDdB4yzzu6PR6TTuXeBwnR8QbG4UAtFvshCwnpk/7X6dwI3GA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39450400003)(39400400002)(39410400002)(39850400002)(377454003)(24454002)(51914003)(13464003)(5660300001)(53546009)(8676002)(8936002)(25786009)(3846002)(305945005)(81166006)(122556002)(86362001)(77096006)(6436002)(66066001)(6506006)(110136004)(2906002)(6916009)(3660700001)(93886004)(2950100002)(6246003)(229853002)(99286003)(55016002)(38730400002)(9686003)(6116002)(4326008)(74316002)(102836003)(7736002)(7696004)(53936002)(3280700002)(189998001)(33656002)(50986999)(54356999)(2900100001)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2640; H:VI1PR0401MB2335.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 1705fbb5-cefe-4d07-b50a-08d48309a45f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:VI1PR0401MB2640; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(185117386973197)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:VI1PR0401MB2640; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2640; x-forefront-prvs: 02778BF158 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2017 07:41:20.0501 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2640 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 > -----Original Message----- > From: Tim Harvey [mailto:tharvey@gateworks.com] > Sent: Tuesday, April 11, 2017 10:22 PM > To: Bough Chen > Cc: David Haworth ; Linux MMC List mmc@vger.kernel.org>; Fabio Estevam ; Ulf > Hansson ; Weijun Yang ; Adrian > Hunter > Subject: Re: IMX6 ESDHC mmc with UHS-I occasional failure with DDR50 cards > > On Tue, Apr 11, 2017 at 2:28 AM, Bough Chen wrote: > >> -----Original Message----- > > >> > >> I've moved on to 4.11-rc5 and notice that I'm always seeing that on a > >> failure the imx sdhc not able to determine a min/max tuning delay: > >> > >> 4.11.0-rc5: > >> [ 48.812381] mmc0: card aaaa removed > >> [ 49.793392] mmc0: host does not support reading read-only switch, > >> assuming write-enable > >> [ 49.810294] sdhci_execute_tuning > >> [ 49.813612] esdhc_executing_tuning > >> [ 49.968154] sdhci-esdhc-imx 2198000.usdhc: tuning failed at 0x7f > >> ret -5 (min=127/max=128) > >> ^^^^ added debug shows -EIO returned from mmc_send_tuning although > >> I've also seen -84 get returned > >> [ 49.980540] mmc0: tuning execution failed: -5 > >> [ 49.984974] mmc0: ddr50 tuning failed > >> [ 49.989068] mmc0: new ultra high speed DDR50 SDHC card at address aaaa > >> [ 49.999844] mmcblk0: mmc0:aaaa SL08G 7.40 GiB > >> > >> I've also found that if I revert '9faac7b mmc: sdhci: enable tuning for DDR50' > >> thus skipping the tuning the issue goes away however note that > >> occasionally I do see a transfer error that perhaps is retried [ > >> 361.067763] mmc0: card aaaa removed [ 361.412732] mmc0: host does > >> not support reading read-only switch, assuming write-enable [ > >> 361.429719] mmc0: new ultra high speed DDR50 SDHC card at address > >> aaaa [ 361.443060] mmcblk0: mmc0:aaaa SL08G 7.40 GiB [ 361.465658] > >> mmcblk0: p1 [ 362.422335] mmc0: card aaaa removed [ 362.752719] > >> mmc0: host does not support reading read-only switch, assuming > >> write-enable [ 362.769675] mmc0: new ultra high speed DDR50 SDHC > >> card at address aaaa [ 362.782900] mmcblk0: mmc0:aaaa SL08G 7.40 GiB > >> [ 362.805996] > >> mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response > >> 0x900, card status 0xb00 ^^^^ occasionally see this error but because > >> retries occur at the block level it still works [ 362.931689] > >> mmcblk0: p1 > >> > >> Again with 9faac7b reverted and some extra debugging: > >> [ 33.823170] mmc0: host does not support reading read-only switch, > >> assuming write-enable > >> [ 33.847185] mmc0: new ultra high speed DDR50 SDHC card at address aaaa > >> [ 33.856063] mmcblk0: mmc0:aaaa SL08G 7.40 GiB > >> [ 33.874227] mmcblk0: error -84 transferring data, sector 0, nr 8, > >> cmd response 0x900, card status 0xb00 > >> [ 33.896829] mmcblk0: error -84 transferring data, sector 0, nr 8, > >> cmd response 0x900, card status 0xb00 > >> [ 33.906312] mmcblk0: error -84 transferring data, sector 0, nr 8, > >> cmd response 0x900, card status 0xb00 > >> [ 34.022117] mmcblk0: error 0 transferring data, sector 0, nr 8, cmd > >> response 0x900, card status 0xb00 > >> ^^^^ added debugging shows retries at block level and eventually all is fine > >> [ 34.031500] mmcblk0: p1 > >> > >> So far every DDR50 card I have (several Kingston and Sandisk card > >> models) behaves like this. > >> > >> I tried adding a settling delay when VSELECT was changed in the > >> sdhci-esdhc- imx driver and that didn't help. > >> > > Hi Tim > > > > Which imx6 soc do you use? From your log, I notice you use the MAN tuning > method, so I guess you use imx6qdl. > > > > imx usdhc has an IC bug. For the tuning procedure, the first pass tuning delay > value must bigger than 10. > > Due to DDR50 timing is not that rigorous, so maybe even when we just add 1 > delay cell, tuning can pass, but this trigger the internal IC bug, then you meet > the following issue just as you meet: > > sdhci-esdhc-imx 2198000.usdhc: tuning failed at 0x7f > ( min=127/max=128) > > > > Haibo, > > Thanks for the response. > > Yes, this issue is seen on the IMX6DQ and IMX6SDL. Can you point me to > information on this bug? I don't see it in the latest IMX6DQCE.pdf errata > document. > > > So you can change the ESDHC_TUNE_CTRL_MIN from 0 to 15, then you can > see the DDR50 tuning return to normal. > > > > For the STD tuning method, you can add the property 'fsl,tuning-start-tap = > <20>' in dts. > > > > All this make the first trying tuning delay value larger than 10, to avoid the > internal IMX USDHC IC bug. > > > > SDR104 card do not has this issue, because for SDR104 card, the first pass > tuning value normally larger than 10. > > > > unfortunately, this does not resolve the issue. I tried ESDHC_TUNE_CTRL_MIN > of 15, 20, and 30 and they all produce the same issue around 20% of insertions: > sdhci-esdhc-imx 2198000.usdhc: tunning failed at 0x7f ret -84 > > Here are some min/max tuning values from some various cards I have: > - Samsung SL08G DDR50: min=8 max=37 > - Kingston SD8GB DDR50: min=8 max=36 > - Sandisk SS16G DDR50: min=10 max=37 > - Sandisk SU08G DDR50: min=9 max=36 > - Samsung Pro 00000 SDR104: min=14 max=26 > - Kingston SDR104 SDCIT: min=25 max=36 > > All of the DDR50 cards above fail in the same way appx 20% of insertions. > > Has anyone else been able to confirm they see the same issue on IMX6 boards > with UHS-I support and DDR50? Hi Tim, I debug this issue these days, and find this is the I/O timing issue. Can you try to improve the pad I/O drive strength for DDR50 card? You can apply the following patch: If this patch also test pass on your side, I will upstream it. By the way, I just confirm with our IC guys, the IC bug I mentioned in the before mail do not impact the software tuning method (MAN_TUNING), this IC bug just impact the STD_TUNING, sorry for the mislead. Haibo Chen > > Regards, > > Tim diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c index 6a1328e..4c3aeac 100644 --- a/drivers/mmc/host/sdhci-esdhc-imx.c +++ b/drivers/mmc/host/sdhci-esdhc-imx.c @@ -848,6 +848,7 @@ static int esdhc_change_pinstate(struct sdhci_host *host, switch (uhs) { case MMC_TIMING_UHS_SDR50: + case MMC_TIMING_UHS_DDR50: pinctrl = imx_data->pins_100mhz; break; case MMC_TIMING_UHS_SDR104: