Hi Alex,
On 2017/2/6 20:20, Alex Lemberg wrote:
On Feb 6, 2017, at 8:46 AM, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote:
Hi Alex,
On 2017/2/5 23:13, Alex Lemberg wrote:
Hi Shawn,
On 2/5/17, 3:43 AM, "Shawn Lin" <shawn.lin@xxxxxxxxxxxxxx> 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?
yes.
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?
right, it was invented with the cap of MMC_CAP_AGGRESSIVE_PM, so some platforms ask for the aggressive power policy will send sleep command
to the cards in rpm context. So I assume they care power-saving more
than others.
OK, I see the MMC_CAP_AGGRESSIVE_PM is already checked in the
mmc_runtime_suspend() function, so your approach, do not send
Sleep command on Runtime Suspend, is already supported.
In case the MMC_CAP_AGGRESSIVE_PM is not set, Sleep command
will not be sent, and the device will be able to perform its
AUTO_BKOPS (if needed).
However, as far as I see in modern mobile hosts,
the Sleep is sent on every Suspend, so I assume the
MMC_CAP_AGGRESSIVE_PM is enabled in most of the cases?
Only Intel platforms add this caps on upstreamed kernel tree and
no, AOSP kernel tree didn't change that much either. But I guess
some vendors want aggressive pm policy for their production?
IMHO, the basic concept of mmc stack is that we could provide
the solutions to support different perf & pm policy for folks but
it's their call to decide it by adding these caps there.
--
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
--
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
