From patchwork Mon Feb 20 13:04:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ritesh Harjani X-Patchwork-Id: 9582725 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id DD9BE6042F for ; Mon, 20 Feb 2017 13:04:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CB9A4286A0 for ; Mon, 20 Feb 2017 13:04:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BE62C28871; Mon, 20 Feb 2017 13:04:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D422E286A0 for ; Mon, 20 Feb 2017 13:04:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752383AbdBTNEg (ORCPT ); Mon, 20 Feb 2017 08:04:36 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:38338 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752118AbdBTNEf (ORCPT ); Mon, 20 Feb 2017 08:04:35 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 7716760A51; Mon, 20 Feb 2017 13:04:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1487595874; bh=tBFAxIsaAFOAb9rOkPOToN0T0mQD6ojNuMdBmvtFjuQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=FnMpKXuFPeewGlAuwgMfO5uZz7yziZd2FswfyfLyyuaCnAQg+HeE+4hiuTxT2qs1K 62x29Rg0piOKtGxienYKzYpesCcFfEkTEIZaE2sgrLE9x5c4mJcZLPLgV2J+1Avufl K9/niBSDmEFVr/+otHAmUPOi2XMnpwcXcZCVN6kk= Received: from [10.44.22.83] (unknown [202.46.23.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: riteshh@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 58FB360C52; Mon, 20 Feb 2017 13:04:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1487595873; bh=tBFAxIsaAFOAb9rOkPOToN0T0mQD6ojNuMdBmvtFjuQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Tqa8SEejCWk4QwCAQUcvgqFmDPltzLFy/5cB0UmyITxmnNv/iGxM4zBHeqlHyIroN 30jzZ7d6Tq0MD9Fi5VqNCuogGypNT/8mk+IMOTZjQf3KUfZk8SGWbAc8HmWa3K7QmM HWF42iikc+0Ti5lCaEGd6MzVXl5xPrnvMN+1Jvh4= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 58FB360C52 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=riteshh@codeaurora.org Subject: Re: [RFC PATCH 0/4] mmc: core: Provide CMD5 awake and partial_init support To: Ulf Hansson References: <1487577792-12510-1-git-send-email-riteshh@codeaurora.org> Cc: "linux-mmc@vger.kernel.org" , Adrian Hunter , Shawn Lin , "devicetree@vger.kernel.org" , Andy Gross , "linux-arm-msm@vger.kernel.org" , Georgi Djakov , Alex Lemberg , Mateusz Nowak , Yuliy Izrailov , Asutosh Das , David Griego , Sahitya Tummala , Venkat Gopalakrishnan , Pramod Gurav , jeremymc@redhat.com, "linux-kernel@vger.kernel.org" From: Ritesh Harjani Message-ID: Date: Mon, 20 Feb 2017 18:34:25 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Ulf, On 2/20/2017 5:09 PM, Ulf Hansson wrote: > On 20 February 2017 at 09:03, Ritesh Harjani 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. 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% 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. 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 > 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)