lkml.org 
[lkml]   [2017]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [RFC PATCH 0/4] mmc: core: Provide CMD5 awake and partial_init support
From
Date
Hi Ulf,

On 2/20/2017 5:09 PM, Ulf Hansson wrote:
> On 20 February 2017 at 09:03, Ritesh Harjani <riteshh@codeaurora.org> wrote:
>> As per JEDEC spec - CMD5 can be used to awake from sleep mode for emmc.
>> This patch series provide CMD5(awake) + mmc_partial_init support to resume
>> mmc card device. This is mainly to reduce the resume time.
>
> I assume with "resume time" you don't mean "system PM resume time"?
I meant mmc_runtime_resume time which will be accounted only in MMC card
run-time resume now.


>
> The current approach we have for MMC is to postpone system PM resume
> of the card until it's actually needed, thus via runtime PM instead.
> Then the time it takes to re-initialize the eMMC don't affect the
> system PM resume time at all.
>
> Therefore I am wondering about how big of a problem this really is. Is
> there a specific use case you are optimizing for?
In general MMC card resume time will be optimized.

>
>>
>> This was tested on db410c (emmc with HS200 mode) and MS8996 (emmc with HS400ES)
>> based internal board. This patch reduced the resume time by ~50% on msm8996
>> and ~11% on db410c.
Sorry, I did not enable MMC_CAP_WAIT_WHILE_BUSY on db410c. That's why we
see 11% improvement only. After I enabled this cap, I see ~47%
improvement in mmc_runtime_resume on db410c.


>
> The improved behaviour in percentage is very interesting, but I would
> also like to see real numbers.

<DB410c>
1. ~110ms without the patch on db410c (with MMC_CAP_WAIT_WHILE_BUSY)

2. ~97ms with the patch on db410c (w/o enabling MMC_CAP_WAIT_WHILE_BUSY)

3. ~58ms with the patch (with MMC_CAP_WAIT_WHILE_BUSY capability).= ~47%

<MSM8996>
1. ~142ms without the patch on msm8996 (with MMC_CAP_WAIT_WHILE_BUSY)

2. ~50ms with the patch on msm8996. (with MMC_CAP_WAIT_WHILE_BUSY)= ~60%

>
> Moreover, I would like to know what kind of mechanism the
> corresponding host drivers/controllers are using for card busy
> detection?
These controllers have MMC_CAP_WAIT_WHILE_BUSY capability enabled.

I have tested with below caps.

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 10cdc84..2da9c4e 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1283,6 +1283,9 @@ static int sdhci_msm_probe(struct platform_device
*pdev)
pm_runtime_use_autosuspend(&pdev->dev);

host->mmc_host_ops.execute_tuning = sdhci_msm_execute_tuning;
+ host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
+ host->mmc->caps |= MMC_CAP_AGGRESSIVE_PM;
+ host->mmc->caps2 |= MMC_CAP2_SLEEP_AWAKE;
ret = sdhci_add_host(host);
if (ret)
goto pm_runtime_disable;

>
>>
>> As of now this patch series provides a caps (MMC_CAP2_SLEEP_AWAKE) to enable this feature.
>> Since there is no dependency on host platform for this, we can enable this feature by
>> default as well. Thoughts?
>
> I will look into the series in more detail, however we must not add a
Sure, please let me know your feedback.

> corresponding DT binding for this as this isn't a HW configuration. I
> guess what you need to know is that VCCQ stays powered on when the
> card is a sleep, else waking up with CMD5 won't work
> (MMC_CAP_FULL_PWR_CYCLE).
Ok.

>
> The current main concern I can think of, is whether the added
> complexity to the wakeup path can be justified for the improved
> behaviour.
This may not be very complex actually.


>
>>
>>
>> Ritesh Harjani (4):
>> Documentation: mmc: add mmc-sleep-awake
>> mmc: core: add mmc-sleep-awake caps
>> mmc: mmc: add support for CMD5 awake
>> mmc: core: Implement mmc_partial_init during resume
>>
>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 +
>> drivers/mmc/core/core.c | 13 +++
>> drivers/mmc/core/core.h | 1 +
>> drivers/mmc/core/host.c | 2 +
>> drivers/mmc/core/mmc.c | 160 ++++++++++++++++++++++++--
>> include/linux/mmc/card.h | 3 +
>> include/linux/mmc/host.h | 2 +
>> 7 files changed, 176 insertions(+), 7 deletions(-)
>>
>> --
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project.
>>
>
> Kind regards
> Uffe
>

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

\
 
 \ /
  Last update: 2017-02-20 14:05    [W:0.098 / U:0.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site