[...] >> >> OK, I see the MMC_CAP_AGGRESSIVE_PM is already checked in the >> mmc_runtime_suspend() function, so your approach, do not send >> Sleep command on Runtime Suspend, is already supported. >> In case the MMC_CAP_AGGRESSIVE_PM is not set, Sleep command >> will not be sent, and the device will be able to perform its >> AUTO_BKOPS (if needed). >> >> However, as far as I see in modern mobile hosts, >> the Sleep is sent on every Suspend, so I assume the >> MMC_CAP_AGGRESSIVE_PM is enabled in most of the cases? > > > Only Intel platforms add this caps on upstreamed kernel tree and > no, AOSP kernel tree didn't change that much either. But I guess > some vendors want aggressive pm policy for their production? > > IMHO, the basic concept of mmc stack is that we could provide > the solutions to support different perf & pm policy for folks but > it's their call to decide it by adding these caps there. > I assume you know the consequences of using MMC_CAP_AGGRESSIVE_PM, still allow me to elaborate a bit on my view. So, MMC_CAP_AGGRESSIVE_PM tells runtime PM suspend of the card to put it into sleep/power off, meaning saving power! However, it also means preventing the eMMC from performing any background operations. The similar applies to the system PM suspend case, no matter if you are using MMC_CAP_AGGRESSIVE_PM or not. To me it seems like we somehow need to start to consider the eMMC'ss BKOPS status in these paths. Depending on the BKOPS state, we may abort the sleep/power off things via returning -EBUSY etc, as otherwise we could end up with poor performing eMMCs, couldn't we!? 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
