> On 26/08/24 10:26, Avri Altman wrote: > >>> + /* > >>> + * 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_ult_capacity(card)) > >>> + mmc_delay(500); > >> > >> To get here, it should have had to go through: > >> > >> /* Try to get back to "tran" state */ > >> if (!mmc_host_is_spi(mq->card->host) && > >> (err || !mmc_ready_for_data(status))) > >> err = mmc_blk_fix_state(mq->card, req); > >> > >> which would mean the card is not indicating "busy". > >> Either that is not working, or it seems like an issue with the card, > >> in which case it could be a card quirk perhaps. > > I was getting here on a setup with micro-to-SD adapter - I guess because of > phy errors on one of the early card versions. > > 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. > > Shawn was interested in this as well - see the discussion in V3. > > The spec reads like the timeout is for card busy. If the card is not indicating > busy when it is busy, then that is an issue with the card. Will remove it. Thanks, Avri
