On 25 May 2018 at 08:18, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > Per JESD85-B51, section 6.6.8.1, it says "Some Devices may require > long and unpredictable times to write a block of data. After receiving > a block of data and completing the CRC check, the Device will begin > writing and hold the DAT0 line low. The host may poll the status of > the Device with a SEND_STATUS command(CMD13) at any time, and the > Device will respond with its status (except in Sleep state). The status > bit READY_FOR_DATA indicates whether the Device can accept new data or > not." That describes the busy condition for data write that we should > consider R1_READY_FOR_DATA as a busy indication. And R1_READY_FOR_DATA > shouldn't happen as well when doing switch and erase stuff, > > Signed-off-by: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> > --- > > drivers/mmc/core/mmc_ops.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c > index 959b8cd..1288802 100644 > --- a/drivers/mmc/core/mmc_ops.c > +++ b/drivers/mmc/core/mmc_ops.c > @@ -507,7 +507,8 @@ static int mmc_poll_for_busy(struct mmc_card *card, unsigned int timeout_ms, > err = mmc_send_status_error(host, status, true); > if (err) > return err; > - busy = R1_CURRENT_STATE(status) == R1_STATE_PRG; > + busy = R1_CURRENT_STATE(status) == R1_STATE_PRG > + || !(status & R1_READY_FOR_DATA); This makes sense, only that it may have a little impact on performance. Thinking if R1_READY_FOR_DATA takes a little longer to be raised rather than only de-asserting R1_STATE_PRG bit. On this other hand, so far I don't think there are any real performance critical callers of mmc_poll_for_busy(). That may change if you intend to switch card_busy_detect() in block.c to use this polling as well!? 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
