On 25 May 2018 at 11:12, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > On 2018/5/25 17:02, Ulf Hansson wrote: >> >> 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!? >> > > > Hmm... that's why I was not changing card_busy_detect(). It means we > need a new parameter for what busy indication the callers want, as well > as a output status. Well, I will rework it next week along with reusing > it for card_busy_detect(). Yes, that sound like a good idea! 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
