From: Alex Lemberg <Alex.Lemberg@sandisk.com>
To: Shawn Lin <shawn.lin@rock-chips.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Uri Yanai <Uri.Yanai@sandisk.com>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Jaehoon Chung <jh80.chung@samsung.com>,
Harjani Ritesh <riteshh@codeaurora.org>
Subject: Re: [PATCH v2 2/2] mmc: Checking BKOPS status prior to Suspend
Date: Sun, 5 Feb 2017 15:13:41 +0000 [thread overview]
Message-ID: <695B0367-2BA5-4B95-AF75-6BD43FE17528@sandisk.com> (raw)
In-Reply-To: <935e77c5-7e6a-00e0-9064-ea9dbcb4fef5@rock-chips.com>
Hi Shawn,
On 2/5/17, 3:43 AM, "Shawn Lin" <shawn.lin@rock-chips.com> 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?
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?
next prev parent reply other threads:[~2017-02-05 15:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-22 9:15 [PATCH v2 0/2] Auto BKOPS PM suspend Uri Yanai
2017-01-22 9:15 ` [PATCH v2 1/2] mmc: Adding AUTO_BKOPS_EN bit set for Auto BKOPS support Uri Yanai
2017-02-02 11:50 ` Ulf Hansson
2017-01-22 9:15 ` [PATCH v2 2/2] mmc: Checking BKOPS status prior to Suspend Uri Yanai
2017-02-02 12:49 ` Ulf Hansson
2017-02-03 9:33 ` Ritesh Harjani
2017-02-03 11:46 ` Ulf Hansson
2017-02-03 16:57 ` Ritesh Harjani
2017-02-06 11:07 ` Ulf Hansson
2017-02-05 1:43 ` Shawn Lin
2017-02-05 15:13 ` Alex Lemberg [this message]
2017-02-06 6:46 ` Shawn Lin
2017-02-06 12:20 ` Alex Lemberg
2017-02-07 1:14 ` Shawn Lin
2017-02-07 7:54 ` Ulf Hansson
2017-02-07 8:24 ` Shawn Lin
2017-02-07 14:32 ` Alex Lemberg
2017-02-02 11:38 ` [PATCH v2 0/2] Auto BKOPS PM suspend Ulf Hansson
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=695B0367-2BA5-4B95-AF75-6BD43FE17528@sandisk.com \
--to=alex.lemberg@sandisk.com \
--cc=Uri.Yanai@sandisk.com \
--cc=adrian.hunter@intel.com \
--cc=jh80.chung@samsung.com \
--cc=linux-mmc@vger.kernel.org \
--cc=riteshh@codeaurora.org \
--cc=shawn.lin@rock-chips.com \
--cc=ulf.hansson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox