On 13 October 2017 at 12:00, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > + Ulf > > On 2017/10/12 20:27, Goldschmidt Simon wrote: >>> >>> On 2017/9/22 17:40, Shawn Lin wrote: >>> Still think that should be part of mmc core's behaviour. I try to make >>> sure the following ugly patch could work for you? And we could move >>> forward later to see how to do it more gracefully. >> >> >> Thanks for your response and sorry my answer comes with three weeks delay. >> Unfortunately, I had other problems with the board in question up to now. >> >> I can confirm the patch works for me. On the oscilloscope shots, I can >> clearly >> see that the next request gets delayed when R1b tells the host the "card" >> is busy. >> > > Thanks for testing. > >> How can we move forward to a clean fix here? > > > I think mmc core haven't considered this case that we issue a R1b > command from usersapce and check the busy(or poll the CMD13 to get it > right). I was thinking of adding some check for that case but I'm aslo > now thinking could we reuse the functions from mmc_ops.c instead of > directly sending this command to the host drivers. That we better reuse > the checking logic of the existing code, for instance, mmc_switch. > > Ulf, do you have some comment here? Well, only that I fully agree with you! Not that long time ago we also did some re-factoring of that busy detection code for mmc switch, so I definitely think that it should possible to re-use that code (perhaps after yet some more re-factoring). [...] 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
