On 25/02/2020 14:26, Ulf Hansson wrote: ... > However, from the core point of view, the response is still requested, > only that we don't want the driver to wait for the card to stop > signaling busy. Instead we want to deal with that via "polling" from > the core. > > This is a rather worrying behaviour, as it seems like the host driver > doesn't really follow this expectations from the core point of view. > And mmc_flush_cache() is not the only case, as we have erase, bkops, > sanitize, etc. Are all these working or not really well tested? I don't believe that they are well tested. We have a simple test to mount an eMMC partition, create a file, check the contents, remove the file and unmount. The timeouts always occur during unmounting. > Earlier, before my three patches, if the provided timeout_ms parameter > to __mmc_switch() was zero, which was the case for > mmc_mmc_flush_cache() - this lead to that __mmc_switch() simply > ignored validating host->max_busy_timeout, which was wrong. In any > case, this also meant that an R1B response was always used for > mmc_flush_cache(), as you also indicated above. Perhaps this is the > critical part where things can go wrong. > > BTW, have you tried erase commands for sdhci tegra driver? If those > are working fine, do you have any special treatments for these? That I am not sure, but I will check. Cheers Jon -- nvpublic
