Re: [PATCH 5/6] mmc: block: Fix SD card stop cmd response type

[Adrian Hunter <adrian.hunter@intel.com>]

On 30/09/14 15:09, Ulf Hansson wrote:
> On 30 September 2014 13:21, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 25/09/14 12:20, Ulf Hansson wrote:
>>> On 23 September 2014 22:00, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>> Nowhere in the SD Association Specifications does
>>>> it state that the stop command has an R1 response
>>>> type.  It is always R1B.  Change accordingly.
>>>
>>> It depends on how detailed you read the spec. :-)
>>>
>>> First, R1B is the same as R1, but with optional busy signalling on DAT0.
>>
>> Not exactly:
>>
>> "R1b is identical to R1 with an optional busy signal
>> transmitted on the data line. The card may become
>> busy after receiving these commands based on its
>> state prior to the command reception. The Host shall
>> check for busy at the response. Refer to Section 4.12.3
>> for a detailed description and timing diagrams."
>>
>> Note it says "The Host shall check for busy at the response."
>> It does not say "The Host is not affected"
> 
> Sorry, I was a bit unclear. I was referring to the format of the response.
> 
>>
>>>
>>> Just reading the table listing CMDS their related response types,
>>> confirms what you are saying. CMD12 has an R1B.
>>
>> Which is explicit and definitive.
>>
>>> Though, going into the details of the "Timing" section where this is
>>> clearly visualized in diagrams, you realize there are no busy
>>> signalling associated with a DATA READ, only for DATA WRITE. It is
>>> also indicated in earlier sections of the spec when "DATA READ/WRITE
>>> sequences are described", but I think the "Timing" section describes
>>> this the best.
>>
>> You are looking at it only from the point of view of the card. The host
>> controller can expect that CMD12/R1b is the only valid combination
>> because that is what the specification defines.  You can't know what
>> the host controller will do if you tell it to do CMD12/R1 because that
>> is outside the spec.
>>
> 
> It doesn't matter from what point of view we look at it. It's all
> about the details of the spec, which tells us there are no busy
> signalling involved with a READ. HW designers of MMC controllers
> should know this as well.

HW designers may well choose to follow the spec.

> 
> Unless you really are fixing a regression here, I can't see the need
> for your patch.

No, I have a host controller that wants to give a TC interrupt on CMD12
which is correct if the response type is R1b but incorrect if the
response type is R1.  However I am anyway fixing that with a quirk because
theoretically MMC is affected too - although not in practice because it uses
CMD23 instead of CMD12.

That got me thinking that we really ought to follow the spec and use R1b.