On Thu, 14 Nov 2019 at 23:07, Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote: > > Hi Ulf, > > On Thu, Nov 14, 2019 at 01:48:41PM +0100, Ulf Hansson wrote: > > [..] > > > > 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. > > > > BTW, do you know what TMIO_STAT_CMD_BUSY actually is monitoring? > > > > 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? > > Hopefully Wolfram just addressed that? > > > If you want to run a test that stretches the behaviour on the timeout > > path, I would rather use an SD-card (the older the better). For eMMCs > > the erase likely translates to a trim/discard, which is far more > > quicker than a real erase - as is what happens on an old SD card. > > Running 'blkdiscard' with different SD cards on H3ULCB, I don't see any > signs of misbehavior: > > root@rcar-gen3:~# blkdiscard -V > blkdiscard from util-linux 2.32.1 > > root@rcar-gen3:~# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > mmcblk0 179:0 0 59.2G 0 disk > mmcblk0boot0 179:8 0 4M 1 disk > mmcblk0boot1 179:16 0 4M 1 disk > mmcblk1 179:24 0 30G 0 disk > > # Erasing 32 GiB uSD Card > root@rcar-gen3:~# time blkdiscard -v /dev/mmcblk1 > /dev/mmcblk1: Discarded 32227983360 bytes from the offset 0 > > real 0m1.198s > user 0m0.001s > sys 0m0.122s > > # Erasing 64 GiB eMMC > root@rcar-gen3:~# time blkdiscard -v /dev/mmcblk0 > /dev/mmcblk0: Discarded 63585648640 bytes from the offset 0 > > real 0m8.703s > user 0m0.002s > sys 0m1.909s > > I guess that by decreasing below erase sizes, I could further increase > the execution time, but these sysfs properties are read-only: > > cat /sys/devices/platform/soc/ee100000.sd/mmc_host/mmc1/mmc1:59b4/preferred_erase_size > 4194304 > cat /sys/devices/platform/soc/ee100000.sd/mmc_host/mmc1/mmc1:59b4/erase_size > 512 > This test and due to the discussions with Wolfram and you in this thread, I would actually suggest that you enable MMC_CAP_ERASE for all tmio variants, rather than just for this particular one. In other words, set the cap in tmio_mmc_host_probe() should be fine, as it seems none of the tmio variants supports HW busy detection at this point. Kind regards Uffe