| Message ID | 1527229110-217188-1-git-send-email-shawn.lin@rock-chips.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 25 May 2018 at 08:18, Shawn Lin <shawn.lin@rock-chips.com> 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@rock-chips.com> > --- > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2018/5/25 17:02, Ulf Hansson wrote: > On 25 May 2018 at 08:18, Shawn Lin <shawn.lin@rock-chips.com> 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@rock-chips.com> >> --- >> >> 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(). > Kind regards > Uffe > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 25 May 2018 at 11:12, Shawn Lin <shawn.lin@rock-chips.com> wrote: > On 2018/5/25 17:02, Ulf Hansson wrote: >> >> On 25 May 2018 at 08:18, Shawn Lin <shawn.lin@rock-chips.com> 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@rock-chips.com> >>> --- >>> >>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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); } }
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@rock-chips.com> --- drivers/mmc/core/mmc_ops.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)