From patchwork Thu Sep 4 09:37:59 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dong Aisheng X-Patchwork-Id: 4843441 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 054329F314 for ; Thu, 4 Sep 2014 09:38:42 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E2E38201C0 for ; Thu, 4 Sep 2014 09:38:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CCE1F201B9 for ; Thu, 4 Sep 2014 09:38:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750976AbaIDJiC (ORCPT ); Thu, 4 Sep 2014 05:38:02 -0400 Received: from mail-qa0-f48.google.com ([209.85.216.48]:53184 "EHLO mail-qa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbaIDJiA (ORCPT ); Thu, 4 Sep 2014 05:38:00 -0400 Received: by mail-qa0-f48.google.com with SMTP id m5so8977249qaj.7 for ; Thu, 04 Sep 2014 02:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=itnV5hFvke74tz51Bhqa7UixNkqkWXjYMD15CeWI4nU=; b=vc4z46jj72HNN+2IreuPDNulw/idopRKbu2FBzMtR5JRPGgeVhWN4EqlseTNlnyRwF bb+3cVtv2yb4XlaEwC4YbsOhWgkRNaCF6JmDGXbPgrI8L9u8hbB+sG3pkEum01/KtFqf ERIZ7i+nr6tlXmBzbP7HyqDVVUZd4GBsjeEH/z8wexHrFaSeDe12CgekNi99jtLf32Gi lzvjJHj6NFZUbmogA1le2H57hhqXXLsNXqTJtnLnct8Ih8NXeThVsAhYO7Uwqteo9QpU iLjcJROvgacknY7mp+BpDGPHDD1dz0CIXkfV0G139CXIOMA15NzTskxbwsfiHa+b+GVU STzg== MIME-Version: 1.0 X-Received: by 10.229.206.68 with SMTP id ft4mr5208009qcb.28.1409823479636; Thu, 04 Sep 2014 02:37:59 -0700 (PDT) Received: by 10.140.18.238 with HTTP; Thu, 4 Sep 2014 02:37:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Sep 2014 17:37:59 +0800 Message-ID: Subject: Re: sdhci-esdhc-imx : cannot read eMMC From: Dong Aisheng To: Jean-Michel Hautbois Cc: "linux-mmc@vger.kernel.org" Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham 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 On Wed, Sep 3, 2014 at 11:11 PM, Jean-Michel Hautbois wrote: > 2014-09-03 10:15 GMT+02:00 Dong Aisheng : >> Hi JM, >> >> On Tue, Sep 2, 2014 at 11:10 PM, Jean-Michel Hautbois >> wrote: >>> 2014-09-02 11:20 GMT+02:00 Jean-Michel Hautbois >>> : >>>> Hi there, >>>> >>>> I start a new thread, as I have done lots of test and this will be clearer. >>>> I have problems reading and writing eMMC on my i.MX6 board with 3.17-rc3. >>>> Sometimes I don't have read errors explicitly in dmesg, but fdisk has >>>> no effects. >>>> I activated MMC debug in my config file, and here is an extract of >>>> mmc0 register dump and all mmc1 part. >>>> On Freescale kernel, I confirm it works well with the same board and >>>> sample, I can write a partition on mmc1. >>> >> >> My iMX6Q SabreSD board seems ok. >> What board did you use? >> What reading/writing problems did you meet? >> I did not see errors in your log. >> Can you paste the error log? > > When CONFIG_MMC_DEBUG=y there is no error. > When CONFIG_MMC_DEBUG=n then, I get : > > [ 2.036958] SW2: Restricting voltage, 3300000-1950000uV > [ 2.036965] mmc1: Switching to 1.8V signalling voltage failed > [ 2.043714] mmc1: new DDR MMC card at address 0001 > [ 2.044738] mmcblk1: mmc1:0001 SEM02G 1.82 GiB > [ 2.045007] mmcblk1rpmb: mmc1:0001 SEM02G partition 3 128 KiB > [ 2.048345] mmcblk1: error -84 transferring data, sector 0, nr 8, > cmd response 0x900, card status 0xb00 It seems you're using Sandisk eMMC chip, right? We ever got an errata of Sandisk eMMC that it needs certain delay befor sending cmd13 after cmd6. We tried 1ms seems ok for such eMMC chip. You may give a try. e.g. do { BTW, you should also make sure the signal quality is not bad which may also cause such issue. Regards Dong Aisheng > [ 2.048352] mmcblk1: retrying using single block read > [ 2.048858] mmcblk1: error -84 transferring data, sector 0, nr 8, > cmd response 0x900, card status 0x0 > [ 2.048933] end_request: I/O error, dev mmcblk1, sector 0 > [ 2.049449] mmcblk1: error -84 transferring data, sector 1, nr 7, > cmd response 0x900, card status 0x0 > [ 2.049459] end_request: I/O error, dev mmcblk1, sector 1 > [ 2.049969] mmcblk1: error -84 transferring data, sector 2, nr 6, > cmd response 0x900, card status 0x0 > [ 2.049978] end_request: I/O error, dev mmcblk1, sector 2 > [ 2.050484] mmcblk1: error -84 transferring data, sector 3, nr 5, > cmd response 0x900, card status 0x0 > [ 2.050493] end_request: I/O error, dev mmcblk1, sector 3 > [ 2.050998] mmcblk1: error -84 transferring data, sector 4, nr 4, > cmd response 0x900, card status 0x0 > [ 2.051008] end_request: I/O error, dev mmcblk1, sector 4 > [ 2.051512] mmcblk1: error -84 transferring data, sector 5, nr 3, > cmd response 0x900, card status 0x0 > [ 2.051521] end_request: I/O error, dev mmcblk1, sector 5 > [ 2.052028] mmcblk1: error -84 transferring data, sector 6, nr 2, > cmd response 0x900, card status 0x0 > [ 2.052038] end_request: I/O error, dev mmcblk1, sector 6 > [ 2.052542] mmcblk1: error -84 transferring data, sector 7, nr 1, > cmd response 0x900, card status 0x0 > [ 2.052551] end_request: I/O error, dev mmcblk1, sector 7 > [ 2.052620] Buffer I/O error on device mmcblk1, logical block 0 > [ 2.053338] mmcblk1: error -84 transferring data, sector 0, nr 8, > cmd response 0x900, card status 0xb00 > [ 2.053345] mmcblk1: retrying using single block read > [ 2.053849] mmcblk1: error -84 transferring data, sector 0, nr 8, > cmd response 0x900, card status 0x0 > [ 2.053859] end_request: I/O error, dev mmcblk1, sector 0 > [ 2.054378] mmcblk1: error -84 transferring data, sector 1, nr 7, > cmd response 0x900, card status 0x0 > [ 2.054388] end_request: I/O error, dev mmcblk1, sector 1 > [ 2.054892] mmcblk1: error -84 transferring data, sector 2, nr 6, > cmd response 0x900, card status 0x0 > [ 2.055403] mmcblk1: error -84 transferring data, sector 3, nr 5, > cmd response 0x900, card status 0x0 > [ 2.055917] mmcblk1: error -84 transferring data, sector 4, nr 4, > cmd response 0x900, card status 0x0 > [ 2.056428] mmcblk1: error -84 transferring data, sector 5, nr 3, > cmd response 0x900, card status 0x0 > [ 2.056937] mmcblk1: error -84 transferring data, sector 6, nr 2, > cmd response 0x900, card status 0x0 > [ 2.057446] mmcblk1: error -84 transferring data, sector 7, nr 1, > cmd response 0x900, card status 0x0 > [ 2.057460] Buffer I/O error on device mmcblk1, logical block 0 > [ 2.057506] mmcblk1: unable to read partition table > > So, I can't get MMC_DEBUG info when the problem occurs, as it disappears :/. > Thanks, > JM --- 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 diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c index 49f04bc..83d17a9 100644 --- a/drivers/mmc/core/mmc_ops.c +++ b/drivers/mmc/core/mmc_ops.c @@ -440,6 +440,12 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value, if (!use_busy_signal) return 0; + /* + * WORKAROUND: for Sandisk eMMC cards, it might need certain delay + * before sending CMD13 after CMD6 + */ + mdelay(1); + /* Must check status to be sure of no errors */ timeout = jiffies + msecs_to_jiffies(MMC_OPS_TIMEOUT_MS);