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
