Messages in this thread | | | Date | Thu, 14 Nov 2019 21:15:14 +0100 | From | Wolfram Sang <> | Subject | Re: [PATCH] mmc: renesas_sdhi_internal_dmac: Add MMC_CAP_ERASE to Gen3 SoCs |
| |
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
[unhandled content-type:application/pgp-signature] | |