Hi, By the eMMC5.0 spec, before sending Sleep command (CMD5), hosts may set the POWER_OFF_NOTIFICATION byte to SLEEP_NOTIFICATION (0x04). Isn’t this a case in this patch? If yes, why not sending SLEEP_NOTIFICATION instead of POWER_OFF_SHORT? In the past we had a discussion on this topic, but the solution became more complicated because of possibly long timeout (max 83 seconds) on SLEEP_NOTIFICATION. https://marc.info/?t=143374696600002&r=1&w=1 But still, in case we want to support POWER_OFF_NOTIFICATION before Sleep command, and in case we want to be eMMC spec aligned, I believe the right thing to do is to support SLEEP_NOTIFICATION… Thanks, Alex On 10/27/16, 10:49 PM, "linux-mmc-owner@xxxxxxxxxxxxxxx on behalf of Ulf Hansson" <linux-mmc-owner@xxxxxxxxxxxxxxx on behalf of ulf.hansson@xxxxxxxxxx> wrote: >On 27 October 2016 at 17:06, Thierry Escande ><thierry.escande@xxxxxxxxxxxxx> wrote: >> Hi Ulf, >> >> On 25/10/2016 12:03, Ulf Hansson wrote: >>> >>> On 3 October 2016 at 16:19, Thierry Escande >>> <thierry.escande@xxxxxxxxxxxxx> wrote: >>>> >>>> From: zhaojohn <john.zhao@xxxxxxxxx> >>>> >>>> Hynix eMMC devices sometimes take 50% longer to resume from sleep. >>>> Based on a recommendation from Hynix, send a Power-Off Notification >>>> before going to S3 to restore a resume time consistently within spec. >>> >>> >>> Could you also share what mmc controller and SoC you get this results >>> from? >>> >>> More precisely, are you using MMC_CAP_WAIT_WHILE_BUSY? >> >> This occurs on a braswell based chromebook, using the acpi sdhci controller. >> So yes, using MMC_CAP_WAIT_WHILE_BUSY. >> >> [...] >>>> >>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c >>>> index f2d185c..46a4562 100644 >>>> --- a/drivers/mmc/core/mmc.c >>>> +++ b/drivers/mmc/core/mmc.c >>>> @@ -1925,8 +1925,14 @@ static int _mmc_suspend(struct mmc_host *host, >>>> bool is_suspend) >>>> if (mmc_can_poweroff_notify(host->card) && >>>> ((host->caps2 & MMC_CAP2_FULL_PWR_CYCLE) || !is_suspend)) >>>> err = mmc_poweroff_notify(host->card, notify_type); >>>> - else if (mmc_can_sleep(host->card)) >>>> + else if (mmc_can_sleep(host->card)) { >>>> + if (host->card->quirks & >>>> MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP) { >>>> + err = mmc_poweroff_notify(host->card, >>>> notify_type); >>>> + if (err) >>>> + goto out; >>>> + } >>> >>> >>> So, I am curious to know from a power management point of view; how >>> does the card behave comparing the sleep and power off notification >>> command? >>> >>> Is the card in a low power state after the power off notification has >>> been received? If so, did you manage to do some measurement for that >>> or perhaps the data-sheet tells about this? It would be interesting to >>> know if there were any differences between sleep and power off >>> notification in this regards. >> >> I do not have any clue about that. It appears only with Hynix emmc and the >> fix has been approved by Hynix engineers... It seems that if not powered >> off, the firmware does some garbage collection when resuming and it takes >> more time... > >Okay, I see. So before I continue reviewing, can you please also tell >what regulators to the card that is being cut while powering off in >this path. > >VMMC, VQMMC? > >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 ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
