From patchwork Mon Aug 18 06:19:12 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Chuanxiao.Dong" X-Patchwork-Id: 4732501 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9A875C0338 for ; Mon, 18 Aug 2014 06:19:19 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 96A0320123 for ; Mon, 18 Aug 2014 06:19:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5A3B620114 for ; Mon, 18 Aug 2014 06:19:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751036AbaHRGTQ (ORCPT ); Mon, 18 Aug 2014 02:19:16 -0400 Received: from mga02.intel.com ([134.134.136.20]:1104 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750894AbaHRGTQ convert rfc822-to-8bit (ORCPT ); Mon, 18 Aug 2014 02:19:16 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 17 Aug 2014 23:19:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,884,1400050800"; d="scan'208";a="559881553" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga001.jf.intel.com with ESMTP; 17 Aug 2014 23:19:14 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 17 Aug 2014 23:19:14 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 17 Aug 2014 23:19:14 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.246]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.198]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 14:19:12 +0800 From: "Dong, Chuanxiao" To: "Gao, Yunpeng" , "linux-mmc@vger.kernel.org" Subject: RE: [PATCH] mmc: core: optimize mmc device power up ramp up time Thread-Topic: [PATCH] mmc: core: optimize mmc device power up ramp up time Thread-Index: AQHPuqvTF6PGJPPCeEWySgrFso3xUpvV4nTQ Date: Mon, 18 Aug 2014 06:19:12 +0000 Message-ID: <17296D9F8FF2234F831FC3DF505A87A911B2268E@shsmsx102.ccr.corp.intel.com> References: <1408342625-23720-1-git-send-email-yunpeng.gao@intel.com> In-Reply-To: <1408342625-23720-1-git-send-email-yunpeng.gao@intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > -----Original Message----- > From: Gao, Yunpeng > Sent: Monday, August 18, 2014 2:17 PM > To: linux-mmc@vger.kernel.org > Cc: Gao, Yunpeng; Dong, Chuanxiao > Subject: [PATCH] mmc: core: optimize mmc device power up ramp up time > > In current kernel mmc driver, it uses two 'msleep(10)' > for eMMC/SD card power up ramp up time delay. > > According to Spec, the ramp up time should be max of 74 eMMC/SD bus clock > or 1ms. > Take the worst eMMC/SD card I can image as the example - assume it has to > work on 32KHz or 16KHz during the card initialzation, then 74 clock should be > 2.312ms or 4.625ms. > So, 5ms delay should be enough. > > Also, msleep(10) will invlove sechdule and may consume more time than what > we expected. > Measured on Merrifield platform showed it consumed almost > 2*20 = 40ms. This is much more than what we expected. > > Submit this patch to reduce the time of mmc boot up and the time of mmc D3 > resume. > > Signed-off-by: Yunpeng Gao > Signed-off-by: Chuanxiao Dong > --- > drivers/mmc/core/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index > 7dc0c85..7bcb797 100644 > --- a/drivers/mmc/core/core.c > +++ b/drivers/mmc/core/core.c > @@ -1556,7 +1556,7 @@ void mmc_power_up(struct mmc_host *host, u32 > ocr) > * This delay should be sufficient to allow the power supply > * to reach the minimum voltage. > */ > - mmc_delay(10); > + usleep_range(10000, 12000); Instead of directly change the mmc_delay to usleep_range, I prefer to do it in changing the drivers/mmc/core/core.h: Chuanxiao > > host->ios.clock = host->f_init; > > @@ -1567,7 +1567,7 @@ void mmc_power_up(struct mmc_host *host, u32 > ocr) > * This delay must be at least 74 clock sizes, or 1 ms, or the > * time required to reach a stable voltage. > */ > - mmc_delay(10); > + usleep_range(5000, 6000); > > mmc_host_clk_release(host); > } > -- > 1.7.9.5 --- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h index 443a584..b7584d8 100644 --- a/drivers/mmc/core/core.h +++ b/drivers/mmc/core/core.h @@ -55,9 +55,10 @@ static inline void mmc_delay(unsigned int ms) if (ms < 1000 / HZ) { cond_resched(); mdelay(ms); - } else { + } else if (ms < 20) + usleep_range(ms * 1000, (ms + 1) * 1000); + else msleep(ms); - } } Thanks