> 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?
I only observed it with SDUC, and on a setup with micro-to-SD adapter.
On my other setups, the recovery flow wasn't triggered.
What was happening is:
mmc_blk_mq_req_done
mmc_blk_mq_complete_prev_req
mmc_blk_mq_poll_completion
CMD13: 0: 00080900 00000000 00000000 00000000 = READY_FOR_DATA + ERROR
mmc_blk_mq_rw_recovery
mmc_sd_num_wr_blocks - bytes_xfered = 0
Consulting with our SD system guys, the 500msec must-have write timeout brought up,
And fixed that.
May I ask what exactly your concerns are?
Thanks,
Avri
>
> > Thanks,
> > Avri
> >
