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?
>
> Signed-off-by: zhaojohn <john.zhao@xxxxxxxxx>
> Signed-off-by: Arindam Roy <arindam.roy@xxxxxxxxx>
> Tested-by: Freddy Paul <freddy.paul@xxxxxxxxx>
> Reviewed-by: Icarus W Sparry <icarus.w.sparry@xxxxxxxxx>
> Reviewed-by: Marc Herbert <marc.herbert@xxxxxxxxx>
> Reviewed-by: Eric Caruso <ejcaruso@xxxxxxxxxxxx>
> Signed-off-by: Brian Norris <briannorris@xxxxxxxxxxxx>
> Signed-off-by: Thierry Escande <thierry.escande@xxxxxxxxxxxxx>
> ---
> drivers/mmc/card/block.c | 8 ++++++++
> drivers/mmc/core/mmc.c | 8 +++++++-
> include/linux/mmc/card.h | 2 ++
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 2206d44..cbc2d97 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -2572,6 +2572,14 @@ static const struct mmc_fixup blk_fixups[] =
> MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc,
> MMC_QUIRK_TRIM_BROKEN),
>
> + /*
> + * 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.
> + */
> + MMC_FIXUP(CID_NAME_ANY, CID_MANFID_HYNIX, CID_OEMID_ANY, add_quirk_mmc,
> + MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP),
> +
> END_FIXUP
> };
>
> 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.
[...]
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
