All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Ulf Hansson <ulf.hansson@stericsson.com>
Cc: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Maya Erez <merez@codeaurora.org>,
	Subhash Jadavani <subhashj@codeaurora.org>,
	Arnd Bergmann <arnd@arndb.de>, Kevin Liu <kliu5@marvell.com>,
	Daniel Drake <dsd@laptop.org>, Ohad Ben-Cohen <ohad@wizery.com>
Subject: Re: [PATCH V3 4/4] mmc: core: Support aggressive power management for (e)MMC/SD
Date: Thu, 02 May 2013 13:38:36 +0300	[thread overview]
Message-ID: <5182422C.6000902@intel.com> (raw)
In-Reply-To: <1366106437-18004-5-git-send-email-ulf.hansson@stericsson.com>

On 16/04/13 13:00, Ulf Hansson wrote:
> Aggressive power management is suitable when saving power is
> essential. At request inactivity timeout, aka pm runtime
> autosuspend timeout, the card will be suspended.
> 
> Once a new request arrives, the card will be re-initalized and
> thus the first request will suffer from a latency. This latency
> is card-specific, experiments has shown in general that SD-cards
> has quite poor initialization time, around 300ms-1100ms. eMMC is
> not surprisingly far better but still a couple of hundreds of ms
> has been observed.
> 
> Except for the request latency, it is important to know that
> suspending the card will also prevent the card from executing
> internal house-keeping operations in idle mode. This could mean
> degradation in performance.
> 
> To use this feature make sure the request inactivity timeout is
> chosen carefully. This has not been done as a part of this patch.
> 
> Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and
> by setting CONFIG_MMC_UNSAFE_RESUME.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Maya Erez <merez@codeaurora.org>
> Cc: Subhash Jadavani <subhashj@codeaurora.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Kevin Liu <kliu5@marvell.com>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Daniel Drake <dsd@laptop.org>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> ---
>  drivers/mmc/core/mmc.c   |   43 +++++++++++++++++++++++++++++++++++++++++++
>  drivers/mmc/core/sd.c    |   42 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/mmc/host.h |    2 +-
>  3 files changed, 86 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index bf19058..8dfbc84 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1454,6 +1454,47 @@ static int mmc_resume(struct mmc_host *host)
>  	return err;
>  }
>  
> +
> +/*
> + * Callback for runtime_suspend.
> + */
> +static int mmc_runtime_suspend(struct mmc_host *host)
> +{
> +	int err;
> +
> +	if (!(host->caps & MMC_CAP_AGGRESSIVE_PM))
> +		return 0;
> +

mmc_power_off() needs to be within mmc_claim_host() / mmc_release_host().

Claiming is nested, so you can out put mmc_claim_host() here:

	mmc_claim_host(host);


> +	err = mmc_suspend(host);
> +	if (err) {
> +		pr_err("%s: error %d doing aggessive suspend\n",
> +			mmc_hostname(host), err);
> +		return err;

		goto out;

> +	}
> +
> +	mmc_power_off(host);

out:
	mmc_release_host(host);

> +	return err;
> +}
> +
> +/*
> + * Callback for runtime_resume.
> + */
> +static int mmc_runtime_resume(struct mmc_host *host)
> +{
> +	int err;
> +
> +	if (!(host->caps & MMC_CAP_AGGRESSIVE_PM))
> +		return 0;
> +
> +	mmc_power_up(host);

As above

> +	err = mmc_resume(host);
> +	if (err)
> +		pr_err("%s: error %d doing aggessive resume\n",
> +			mmc_hostname(host), err);
> +
> +	return err;

The power is on - leaving the device in a RPM_SUSPENDED state does not seem
useful so better to return zero here.

> +}
> +
>  static int mmc_power_restore(struct mmc_host *host)
>  {
>  	int ret;
> @@ -1514,6 +1555,8 @@ static const struct mmc_bus_ops mmc_ops_unsafe = {
>  	.detect = mmc_detect,
>  	.suspend = mmc_suspend,
>  	.resume = mmc_resume,
> +	.runtime_suspend = mmc_runtime_suspend,
> +	.runtime_resume = mmc_runtime_resume,
>  	.power_restore = mmc_power_restore,
>  	.alive = mmc_alive,
>  };
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
> index 30387d6..e0458f9 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -1095,6 +1095,46 @@ static int mmc_sd_resume(struct mmc_host *host)
>  	return err;
>  }
>  
> +/*
> + * Callback for runtime_suspend.
> + */
> +static int mmc_sd_runtime_suspend(struct mmc_host *host)
> +{
> +	int err;
> +
> +	if (!(host->caps & MMC_CAP_AGGRESSIVE_PM))
> +		return 0;
> +
> +	err = mmc_sd_suspend(host);
> +	if (err) {
> +		pr_err("%s: error %d doing aggessive suspend\n",
> +			mmc_hostname(host), err);
> +		return err;
> +	}
> +
> +	mmc_power_off(host);

As above

> +	return err;
> +}
> +
> +/*
> + * Callback for runtime_resume.
> + */
> +static int mmc_sd_runtime_resume(struct mmc_host *host)
> +{
> +	int err;
> +
> +	if (!(host->caps & MMC_CAP_AGGRESSIVE_PM))
> +		return 0;
> +
> +	mmc_power_up(host);

As above

> +	err = mmc_sd_resume(host);
> +	if (err)
> +		pr_err("%s: error %d doing aggessive resume\n",
> +			mmc_hostname(host), err);
> +
> +	return err;

As above

	return 0

> +}
> +
>  static int mmc_sd_power_restore(struct mmc_host *host)
>  {
>  	int ret;
> @@ -1119,6 +1159,8 @@ static const struct mmc_bus_ops mmc_sd_ops = {
>  static const struct mmc_bus_ops mmc_sd_ops_unsafe = {
>  	.remove = mmc_sd_remove,
>  	.detect = mmc_sd_detect,
> +	.runtime_suspend = mmc_sd_runtime_suspend,
> +	.runtime_resume = mmc_sd_runtime_resume,
>  	.suspend = mmc_sd_suspend,
>  	.resume = mmc_sd_resume,
>  	.power_restore = mmc_sd_power_restore,
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 17d7148..cec6684 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -239,7 +239,7 @@ struct mmc_host {
>  #define MMC_CAP_SPI		(1 << 4)	/* Talks only SPI protocols */
>  #define MMC_CAP_NEEDS_POLL	(1 << 5)	/* Needs polling for card-detection */
>  #define MMC_CAP_8_BIT_DATA	(1 << 6)	/* Can the host do 8 bit transfers */
> -
> +#define MMC_CAP_AGGRESSIVE_PM	(1 << 7)	/* Suspend (e)MMC/SD at idle  */

Using a "cap" is not ideal here - it should really be under the control of
user space.

>  #define MMC_CAP_NONREMOVABLE	(1 << 8)	/* Nonremovable e.g. eMMC */
>  #define MMC_CAP_WAIT_WHILE_BUSY	(1 << 9)	/* Waits while card is busy */
>  #define MMC_CAP_ERASE		(1 << 10)	/* Allow erase/trim commands */
> 


  reply	other threads:[~2013-05-02 10:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16 10:00 [PATCH V3 0/4] mmc: Use runtime pm for blkdevice Ulf Hansson
2013-04-16 10:00 ` [PATCH V3 1/4] mmc: core: Stop bkops for eMMC only from mmc suspend Ulf Hansson
2013-04-18  7:17   ` Jaehoon Chung
2013-04-16 10:00 ` [PATCH V3 2/4] mmc: core: Add bus_ops for runtime pm callbacks Ulf Hansson
2013-04-26 13:11   ` Adrian Hunter
2013-04-29  7:54     ` Adrian Hunter
2013-04-29 13:42       ` Ulf Hansson
2013-04-16 10:00 ` [PATCH V3 3/4] mmc: block: Enable runtime pm for mmc blkdevice Ulf Hansson
2013-05-02  8:58   ` Adrian Hunter
2013-05-02  9:52     ` Ulf Hansson
2013-05-02  9:57       ` Asutosh Das
2013-05-02 11:09         ` Ulf Hansson
2013-05-02 12:22           ` Adrian Hunter
     [not found]   ` <CAMj5BkiOmh8sz-=b0z1VF9owGPX0KpbZeNfPzETemCb=C2odGQ@mail.gmail.com>
2013-05-24  8:27     ` Ulf Hansson
     [not found]       ` <CAMj5Bki+1=DSzQWYyEC1L=Pa6LpSFQKF3YvoUkkuq62wHuMWow@mail.gmail.com>
2013-05-27  7:51         ` Ulf Hansson
2013-05-27  7:52           ` Ulf Hansson
2013-05-28  6:49             ` zhangfei gao
2013-04-16 10:00 ` [PATCH V3 4/4] mmc: core: Support aggressive power management for (e)MMC/SD Ulf Hansson
2013-05-02 10:38   ` Adrian Hunter [this message]
2013-05-02 11:35     ` Ulf Hansson
2013-05-02 12:24       ` Adrian Hunter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5182422C.6000902@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=arnd@arndb.de \
    --cc=cjb@laptop.org \
    --cc=dsd@laptop.org \
    --cc=kliu5@marvell.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=merez@codeaurora.org \
    --cc=ohad@wizery.com \
    --cc=subhashj@codeaurora.org \
    --cc=ulf.hansson@linaro.org \
    --cc=ulf.hansson@stericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.