Hi Do not hit the following bug? Often, This bug fails setting of CMD6. -------- Original Message -------- Subject: Re: [PATCH v2] mmc:sdhci: handle busy-end interrupt during command Date: Tue, 2 Sep 2014 11:27:51 +0200 From: Ulf Hansson <ulf.hansson@xxxxxxxxxx> To: Chanho Min <chanho.min@xxxxxxx> On 30 August 2014 05:40, Chanho Min <chanho.min@xxxxxxx> wrote: > It is fully legal for a controller to start handling busy-end interrupt > before it has signaled that the command has completed. So make sure > we do things in the proper order, Or it results that command interrupt > is ignored so it can cause unexpected operations. This is founded at some > toshiba emmc with the bellow warning. > > "mmc0: Got command interrupt 0x00000001 even though > no command operation was in progress." > > This issue has been also reported by Youssef TRIKI: > It is not specific to Toshiba devices, and happens with eMMC devices > as well as SD card which support Auto-CMD12 rather than CMD23. > > Also, similar patch is submitted by: > Gwendal Grignou <gwendal@xxxxxxxxxxxx> > > Changes since v1: > Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git > and Tested if issue is fixed again. > > Signed-off-by: Hankyung Yu <hankyung.yu@xxxxxxx> > Signed-off-by: Chanho Min <chanho.min@xxxxxxx> > Tested-by: Youssef TRIKI <youssef.triki@xxxxxx> Best Regards, ======================================================= Hisanao Kinkawa [hisanao.kinkawa@xxxxxxxxxxxxx <mailto:hisanao.kinkawa@xxxxxxxxxxxxx>] ======================================================= (2014/09/15 20:29), Jean-Michel Hautbois wrote: > 2014-09-15 12:53 GMT+02:00 Jean-Michel Hautbois > <jean-michel.hautbois@xxxxxxxxxxx>: >> 2014-09-15 12:44 GMT+02:00 Jaehoon Chung <jh80.chung@xxxxxxxxxxx>: >>> On 09/15/2014 07:08 PM, Jean-Michel Hautbois wrote: >>>> Hi Jaehoon, >>>> >>>>> On 09/09/2014 09:26 PM, Jean-Michel Hautbois wrote: >>>>>> Tested on a i.MX6 board, with Sandisk SDIN5D1-2G. >>>>>> Without this patch, I/O errors occur. >>>>>> This eMMC seems to have a different Manufacturer ID as it reads 0x45 >>>>>> and not 0x2 as specified in datasheet. >>>>> I think this patch don't merge into mainline. >>>>> This is not solution for problem. >>>>> you mentioned the below comment, this is workaround. >>>> Yes >>>> >>>>>> Signed-off-by: Jean-Michel Hautbois <jean-michel.hautbois@xxxxxxxxxxx> >>>>>> --- >>>>>> drivers/mmc/core/mmc_ops.c | 9 +++++++++ >>>>>> 1 file changed, 9 insertions(+) >>>>>> >>>>>> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c >>>>>> index f51b5ba..91babaa 100644 >>>>>> --- a/drivers/mmc/core/mmc_ops.c >>>>>> +++ b/drivers/mmc/core/mmc_ops.c >>>>>> @@ -458,6 +458,15 @@ 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 >>>>>> + * On SDIN5D1-2G MANFID is 0x45 and not 0x2 as specified in datasheet >>>>>> + */ >>>>>> + if (card->cid.manfid == CID_MANFID_SANDISK || >>>>>> + card->cid.manfid == 0x45) { >>>>>> + msleep(1); >>>>>> + } >>>>> If it's a general problem of Sandisk SDIN5D1-2G, >>>>> I think you need to verify this problem. And can you use the MMC_FIXUP() and QUIRK? >>>> Well, this is difficult to verify, I know that on all my SDIN5D1-2G I >>>> have this MANFID different from what is defined by CID_MANFID_SANDISK. >>>> How should I use MMC_FIXUP ? Like this ? >>> I think you need to explain why delay is need. >>> i didn't have same card, but it might be your host controller or other problem. >> Well, I don't know why it is needed, this is undocumented, nothing in >> datasheet explains anything about this. > It seems to be uSDHC / DDR mode related. I don't even know if this is > limited to Sandisk ! > And I don't have another board with another manufacturer eMMC to test. > Maybe some guys from Freescale could help with this ? > > Thanks, > JM > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > . > ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
