On Wed, 3 Mar 2021 at 10:22, Kiwoong Kim <kwmad.kim@xxxxxxxxxxx> wrote: > > Dear all > > I hope opinions from you guys. > > For many users of mobile device, there is a possibility that issuing no IO request to > a SD card is rare during much of the device's lifetime. If you want to put the card into a low power state after a period of idle, you can set MMC_CAP_AGGRESSIVE_PM for the corresponding mmc host. Be careful though, as you will prevent the card from doing internal garbage collection if you power it off. It may be a good idea to extend the idle period for this, which can be done from userspace via sysfs. > Obviously the symptom would happen frequently among system suspend times, too. > In this situation, doing SD initialization at every system resume leads to long latency > and can make the users feel it, even when there is no IO request during the period, > when a hardware architecture requires re-initialization at resume time. No matter if you have MMC_CAP_AGGRESSIVE_PM or not, system resume time should not be affected. Re-initialization of the SD/eMMC cards are deferred to be managed through runtime PM, which means that the card will be resumed the next time there is a command/request to be sent to the card. Assuming there is no I/O request after the system has resumed, then a non-removable card (host has MMC_CAP_NONREMOVABLE set), typically an eMMC, will thus remain in low power state even after the system has resumed. For a removable card (typically SD cards), there is a limitation that we need to check if the card remains inserted after the system has resumed. Although, note that this is done in a workqueue, thus not affecting the overall system resume time. Still, we do end up re-initializing of removable cards, just to check that they are still inserted, which certainly is not always a good thing to do. > This is what had actually happened and was fixed with some code in commercial products. The above code in the mmc core was introduced around kernel v3.11, even if it has been fine tuned since then. Maybe you have been using even older kernels? > > Is there any way to avoid that symptom w/o any code change? > With no way, I hope to make soemthing to improve it. Improvements can certainly be done and would be greatly appreciated. If you want to look at optimizing the behaviour, I suggest trying to avoid the re-initialization of removable cards during system resume. It's not possible for all cases, but certainly for some. If you care about system resume time of SDIO cards, there are even more improvements that can be made. > > Thanks. > Kiwoong Kim > Kind regards Uffe
