diff mbox

sdhci-esdhc-imx : cannot read eMMC

Message ID CAA+hA=TKYdkaVJtNg1457oSCgrtaT3xpg32m7Hn7xJxh8OGk7g@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Dong Aisheng Sept. 4, 2014, 9:37 a.m. UTC 
On Wed, Sep 3, 2014 at 11:11 PM, Jean-Michel Hautbois
<jhautbois@gmail.com> wrote:
> 2014-09-03 10:15 GMT+02:00 Dong Aisheng <dongas86@gmail.com>:
>> Hi JM,
>>
>> On Tue, Sep 2, 2014 at 11:10 PM, Jean-Michel Hautbois
>> <jhautbois@gmail.com> wrote:
>>> 2014-09-02 11:20 GMT+02:00 Jean-Michel Hautbois
>>> <jean-michel.hautbois@vodalys.com>:
>>>> 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

Comments

Arnd Bergmann Sept. 4, 2014, 9:43 a.m. UTC | #1 
On Thursday 04 September 2014 17:37:59 Dong Aisheng wrote:
> 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);
>         do {
> 
> 

mdelay() is a rather nasty function to call because it hogs the CPU.
Better use msleep(), which will allow another process to use the
CPU in the meantime.
It might be worthwhile to check the manufacturer ID field so we
don't delay the boot process for non-sandisk devices.

	Arnd
--
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
Jean-Michel Hautbois Sept. 4, 2014, 9:55 a.m. UTC | #2 
2014-09-04 11:43 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 04 September 2014 17:37:59 Dong Aisheng wrote:
>> 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);
>>         do {
>>
>>
>
> mdelay() is a rather nasty function to call because it hogs the CPU.
> Better use msleep(), which will allow another process to use the
> CPU in the meantime.
> It might be worthwhile to check the manufacturer ID field so we
> don't delay the boot process for non-sandisk devices.

OK, so I will also move MFID defines from drivers/mmc/core/block.c to
include/linux/mmc/card.h which will allow the use of these defines
from mmc_ops.c.

I am testing right now and if it works, I will send a patch.
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
Jean-Michel Hautbois Sept. 4, 2014, 10:06 a.m. UTC | #3 
2014-09-04 11:55 GMT+02:00 Jean-Michel Hautbois <jhautbois@gmail.com>:
> 2014-09-04 11:43 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> On Thursday 04 September 2014 17:37:59 Dong Aisheng wrote:
>>> 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);
>>>         do {
>>>
>>>
>>
>> mdelay() is a rather nasty function to call because it hogs the CPU.
>> Better use msleep(), which will allow another process to use the
>> CPU in the meantime.
>> It might be worthwhile to check the manufacturer ID field so we
>> don't delay the boot process for non-sandisk devices.
>
> OK, so I will also move MFID defines from drivers/mmc/core/block.c to
> include/linux/mmc/card.h which will allow the use of these defines
> from mmc_ops.c.
>
> I am testing right now and if it works, I will send a patch.
> Thanks,
> JM

And that will not work because card->cid.manfid is not yet defined
when __mmc_switch() is called.
The patch works, but now I need to have it SANDISK dependent.

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
Arnd Bergmann Sept. 4, 2014, 10:12 a.m. UTC | #4 
On Thursday 04 September 2014 12:06:41 Jean-Michel Hautbois wrote:
> And that will not work because card->cid.manfid is not yet defined
> when __mmc_switch() is called.
> The patch works, but now I need to have it SANDISK dependent.
> 

Ok, I see. Then just use msleep() here.

	Arnd
--
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
Jean-Michel Hautbois Sept. 4, 2014, 10:19 a.m. UTC | #5 
2014-09-04 12:12 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 04 September 2014 12:06:41 Jean-Michel Hautbois wrote:
>> And that will not work because card->cid.manfid is not yet defined
>> when __mmc_switch() is called.
>> The patch works, but now I need to have it SANDISK dependent.
>>
>
> Ok, I see. Then just use msleep() here.
>
>         Arnd

Well, in fact, in dirvers/mmc/core/mmc.c :
card->cid.manfid    = UNSTUFF_BITS(resp, 120, 8);

It gets 0x45 on my eMMC  but SANDISK datasheet says 0x02.
And in __mmc_switch, it is set, but to 0x45 which is not tested
correctly against CID_MANFID_SANDISK which is set to 0x2.

So maybe some sandisk have MID at 0x2 and some others have something else ?

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 mbox

Patch

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);