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" > > 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. -- 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
