Messages in this thread Patch in this message | | | Subject | Re: [RFC PATCH 0/4] mmc: core: Provide CMD5 awake and partial_init support | From | Ritesh Harjani <> | Date | Mon, 20 Feb 2017 18:34:25 +0530 |
| |
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
| |