[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-mmc
Subject:    Re: [PATCH] mmc: Hynix: add QUIRK_NOTIFY_POWEROFF_ON_SLEEP
From:       Alex Lemberg <Alex.Lemberg () sandisk ! com>
Date:       2016-10-31 10:14:22
Message-ID: A6F6C92B-1E3A-4326-88B7-E3E9100E2DD8 () sandisk ! com
[Download RAW message or body]

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@vger.kernel.org on behalf of Ulf Hansson" \
<linux-mmc-owner@vger.kernel.org on behalf of ulf.hansson@linaro.org> wrote:

> On 27 October 2016 at 17:06, Thierry Escande
> <thierry.escande@collabora.com> wrote:
> > Hi Ulf,
> > 
> > On 25/10/2016 12:03, Ulf Hansson wrote:
> > > 
> > > On 3 October 2016 at 16:19, Thierry Escande
> > > <thierry.escande@collabora.com> wrote:
> > > > 
> > > > From: zhaojohn <john.zhao@intel.com>
> > > > 
> > > > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]