> On Feb 6, 2017, at 8:46 AM, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > > Hi Alex, > > On 2017/2/5 23:13, Alex Lemberg wrote: >> Hi Shawn, >> >> On 2/5/17, 3:43 AM, "Shawn Lin" <shawn.lin@xxxxxxxxxxxxxx> wrote: >> >> >> > >> > Hmm. >> > >> > Shouldn't we abort (return -EBUSY) also in the system PM suspend case >> > and not only for runtime PM suspend? >> >> I would rather we don't abort runtime PM, but do it for system PM >> instead. What we do for runtime PM is just for saving power for >> our hosts including manipulating clock and genpd etc.. Thus we don't >> touch any power-supply for eMMC. If so, it could still be possible >> for eMMC firmware to work on doing bkops in rpm context. >> >> If I understand correctly, you are suggesting do not send SLEEP command >> on Runtime Suspend? > > yes. > >> If so, and if mmc host does not touch any power supply for eMMC, >> the device can continue doing Auto BKOPS during Runtime Suspend. >> The question is why the Sleep command is sent now, >> in the original implementation? >> I assume it is sent for saving a power from the device side as well? > > right, it was invented with the cap of MMC_CAP_AGGRESSIVE_PM, so some platforms ask for the aggressive power policy will send sleep command > to the cards in rpm context. So I assume they care power-saving more > than others. > 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? -- 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
