On 10 February 2016 at 17:36, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > ^ >> I think you should try without MMC_CAP_WAIT_WHILE_BUSY, and then check >> that a following CMD13 command always states that the card isn't busy. >> I think the best path to try this is when sending a big write data >> request, as in that case you can be quite certain that the card gets >> busy between the requests. >> >> So somewhere in the mmc block layer add some debug prints, that should do it. > > I'd think the mmc_test driver already helped me with this. I ran tests > like 31 (Consecutive write performance by transfer size) or 36 (Large > sequential write from scattered pages) which both succeeded without any > warnings printed. And the code explicitly sends a CMD13 after transfer, > checks for busy and prints a warning when MMC_CAP_WAIT_WHILE_BUSY is > set and a busy state is detected. Nice test thing this driver is :) That should do it! > > So, it looks to me that patch 9 is fine to go in? > Not yet. :-) I suspect you are using a delayed work in this driver to deal with request timeouts. The value for the delay that is used, needs to be informed towards the mmc core via the "->max_busy_timeout". One more thing, as the documentation of your host controllers lacks some information about the busy mode, perhaps it's worth to add some comments about this in the code and as well in the change-log!? 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
