On 30 September 2014 13:21, Adrian Hunter <[email protected]> wrote: > On 25/09/14 12:20, Ulf Hansson wrote: >> On 23 September 2014 22:00, Adrian Hunter <[email protected]> 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. Unless you really are fixing a regression here, I can't see the need for your patch. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
