Re: [PATCH 0/3] mmc: also abort tuning with CMD12 for SD

[Wolfram Sang <wsa+renesas@sang-engineering.com>]

[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]

Hi Avri,

first of all, thank you very much for asking your SD experts and
providing this valuable information! This is much appreciated. Sadly, I
have only indirect access to the SD specs and more advanced measurement
techniques.

> "We are ok with host sending CMD12 to abort data transfer when they
> discover failure with response / incoming data. In both SD/eMMC spec,
> stop transmission command is allowed during data transfer phase
> ('data' state).

Yes. The spec is clear about the data state.

> Sometimes, the CMD12 would have been received by card while in 'tran'
> state. As long host is able to handle the 'illegal command' error
> indication for this situation, we don't see any other problem. 

Confirmed. The call to mmc_send_abort_tuning() returns -EILSEQ. But it
still makes the card work. Leaving out the call to
mmc_send_abort_tuning() gives:

	mmc1: error -5 whilst initialising SD card

> Per SD Spec, CMD12 is allowed in 'tran' state only for SDUC card. In
> non SDUC cards, CMD12 received while in 'tran' state will be treated
> as illegal command.

I didn't know about SDUC. The advantage of the approach Ulf suggested is
that we can distinguish the type of cards in the SD callback if needed.

> However we could not understand how aborting the data transfer is
> helping host to complete the tuning scheme and have successful read /
> write operations."

I also didn't know why. But read on, there is a pointer now.

> They also think that :
> " we believe this hack was added to avoid the data transfer after response crc error...
> Receiving CRC error with the tuning pattern would be normal as long as the tuning was not complete."

Yes, I get CRC and CMD_IDX errors for CMD19.

> My 5 cents are, maybe you should try retries > 0 in sd_send_abort_tuning,
> If indeed it's a crc while tuning is not complete.

Interesting. If I do this, I get a timeout error from
mmc_send_abort_tuning(). And bingo! If I replace mmc_send_abort_tuning()
with mdelay(100) the card also probes fine. Also, if I skip this patch
series (so abort_tuning is only for MMC) and add the delay in my host
driver, then the card also comes up. I don't think, though, I should fix
it in the host driver.

Is there a delay defined somewhere which ones need to wait after a CRC
error in tuning? I couldn't find it in the simplified spec.

Thanks for the help again,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]