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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30 September 2014 14:41, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
> On 30/09/14 15:09, Ulf Hansson wrote:
>> On 30 September 2014 13:21, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>>> On 25/09/14 12:20, Ulf Hansson wrote:
>>>> On 23 September 2014 22:00, Adrian Hunter <adrian.hunter@xxxxxxxxx> 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.

I will certainly keep this in mind. Likely a similar situation will
occur when I fixup mmc erase/discard.

In principle host drivers must pay attention to MMC_RSP_R1B and act
accordingly both if set and not set. I suppose you will add some extra
quirks around that in your driver.

Anyway, thanks for the discussion, it was useful!

Kind regards
Uffe
--
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




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux