Hi Avri,
在 2024/8/15 20:57, Avri Altman 写道:
Hi,
Thanks for having a look.
Hi Avri,
在 2024/8/14 15:29, Avri Altman 写道:
@@ -948,13 +949,20 @@ static int mmc_sd_num_wr_blocks(struct mmc_card
*card, u32 *written_blocks)
int err;
u32 result;
__be32 *blocks;
-
+ u8 resp_sz;
struct mmc_request mrq = {};
struct mmc_command cmd = {};
struct mmc_data data = {};
-
struct scatterlist sg;
+ /*
+ * SD cards, specifically high volume cards, expect to be allowed with the
+ * full 500msec busy period post write. Otherwise, they may not indicate
+ * correctly the number of bytes written.
+ */
+ if (mmc_card_is_sduc(card->host))
+ mmc_delay(500);
Could you kindly point me to the right section of SD spec which states
this 500ms before ACMD22 ? Is it the write busy time?
Yes. I encountered it while testing SDUC:
If there are some phy errors (probably caused because the micro-to-SD adapter I was using),
The first get-status response contains an error bit, and the recovery flow is entered immediately.
Thus, violating the min 500msec allotted to the card write.
I see.
And as you mentioned high volume cards, I am curious if 1TB sandisk
MircoSDXC need 500ms delay as well?
Theoretically should be applied to all cards.
But since this code is there since forever, and no issue observed thus far -
I preferred limiting this to ultra capacity cards only.
So my biggest guess is the cards issue the busy indication after the
first error block and the host drivers implemented either SW or HW wait
busy mechanism, maybe before ACMD22 is issued, so no issue observed?
Thanks,
Avri
