[...] > > Do you receive any similar issue report on other eMMC vendor? > No. Although, that may be to that people don't report them. [...] > > > This code is active on all Chromebooks with eMMC without an issue, and the > eMMC spec doesn't require a delay here. So I don't think it can be a common > problem. What eMMC model are you using specifically? > > > > Also, this change fixes a problem with audio glitching on systems with > runtime pm or active retuning due to very long read latency caused by 40ms > of mdelay in the kernel read path. Runtime pm sets the eMMC to sleep if it > has not been used in a short time, so intermittent reads always go though > the retuning path. 40 ms is just a terrible latency. I guess I have asked this question before while the tuning was implemented for sdhci; is there no way you can restore earlier tuned values in runtime resume, instead of always doing a new re-tuning? Another option is to use and increased runtime PM autosuspend timeout while tuning is enabled. It won't remove the 40 ms latency, but would make it happen less frequently. Yet another option would be to temporary forbid runtime suspend, which is what device PM QOS is for. The generic PM domain provides this infrastructure via the domain governor. Finally, of course we shouldn't do the delay - unless in those case where it's actually needed. I am wondering if you are using the exact same SDHCI variant/driver? Perhaps it's not a eMMC issue, but a SDHCI controller/driver issue? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
