On Thu, 14 Nov 2019 at 21:15, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > > 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. Alright, thanks for clarifying! > > > 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. I had a vague memory about this discussion as well, thanks for giving the pointers to it. I think using a workqueue for scheduling a reset work with a timeout of 5 s, as in your case. However, as a heads up, if/when implementing support for busy detection and adding MMC_CAP_WAIT_WHILE_BUSY, needs to update that timeout according to cmd->busy_timeout, which is provided by the core. Kind regards Uffe
