Hi Ulf, thanks again for the heads up. > Let's first take a step back, because I don't know how the HW busy > detection works for your controller. > > I have noticed there is TMIO_STAT_CMD_BUSY bit being set for some > variants, which seems to cause renesas_sdhi_wait_idle() to loop for a > pre-defined number of loops/timeout. This looks scary, but I can't > tell if it's really a problem. That should be okay. The datasheet mentions that some registers can only be accessed when either CBSY or SCLKDIVEN bits signal non-busyness. renesas_sdhi_wait_idle() is for that. > BTW, do you know what TMIO_STAT_CMD_BUSY actually is monitoring? 0: A command sequence has been completed. 1: A command sequence is being executed. > I have also noticed that MMC_CAP_WAIT_WHILE_BUSY isn't set for any of > the renesas/tmio variant hosts. Is that simply because the HW doesn't > support this? Or because implementation is missing? Good thing we use public development. I recalled we discussed this before but I needed a search engine to find it again: https://patchwork.kernel.org/patch/8114821/ Summary: The HW (at least since Gen2) has HW support for busy timeout detection but I never came around to implement it (and even forgot about it :( ). So, we still use a workqueue for it. Kind regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
