From patchwork Fri Apr 20 08:03:53 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shawn Lin X-Patchwork-Id: 10352109 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 CB71660231 for ; Fri, 20 Apr 2018 08:12:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BE715285B0 for ; Fri, 20 Apr 2018 08:12:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B2E37286B7; Fri, 20 Apr 2018 08:12:02 +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.4 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_WEB 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 13B2A286A2 for ; Fri, 20 Apr 2018 08:12:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754294AbeDTILj (ORCPT ); Fri, 20 Apr 2018 04:11:39 -0400 Received: from lucky1.263xmail.com ([211.157.147.131]:53029 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754034AbeDTILg (ORCPT ); Fri, 20 Apr 2018 04:11:36 -0400 Received: from shawn.lin?rock-chips.com (unknown [192.168.167.29]) by lucky1.263xmail.com (Postfix) with ESMTP id 64ED896D4A; Fri, 20 Apr 2018 16:11:30 +0800 (CST) X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 Received: from localhost.localdomain (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTPA id 639133AA; Fri, 20 Apr 2018 16:11:29 +0800 (CST) X-IP-DOMAINF: 1 X-RL-SENDER: shawn.lin@rock-chips.com X-FST-TO: ulf.hansson@linaro.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: shawn.lin@rock-chips.com X-UNIQUE-TAG: <00647f24dccb66e8d95b485f31e00c9e> X-ATTACHMENT-NUM: 0 X-SENDER: lintao@rock-chips.com X-DNS-TYPE: 0 Received: from localhost.localdomain (unknown [58.22.7.114]) by smtp.263.net (Postfix) whith ESMTP id 24844M9X80O; Fri, 20 Apr 2018 16:11:30 +0800 (CST) From: Shawn Lin To: Ulf Hansson Cc: Jaehoon Chung , Wolfram Sang , Adrian Hunter , linux-mmc@vger.kernel.org, Shawn Lin Subject: [RFC PATCH] Revert "mmc: increase power up delay" Date: Fri, 20 Apr 2018 16:03:53 +0800 Message-Id: <1524211433-48972-1-git-send-email-shawn.lin@rock-chips.com> X-Mailer: git-send-email 1.9.1 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 This reverts commit 79bccc5aefb4e64e651abe04f78c3e6bf8acd6f0. The intention for this revert is that the it's too engineering solution for a special board but force all platforms to wait for that long time, especially painful for mmc_power_up for eMMC when booting. In practise, the modern hardware should have a stable power supply with 1ms after setting it for no matter PMIC or discrete power. But more importnatly, most regulators implement the callback of ->set_voltage_time_sel() for regulator core to wait for specific period of time for the power supply to be stable, which means once regulator_set_voltage_* return, the power should reach the the minimum voltage that works for initialization. It has been long time proved 2ms is enough when testing variety of boards. If it finally turned out some boards need more than 2ms here, the best we should do is to ask folks to get that period of time from firmware node, for instance DT, and implement ->set_voltage_time_sel() for the regulaor used, but not bother mmc core again. Just revert it now and see if it could smokes out something interesting. Signed-off-by: Shawn Lin --- Not sure if Toshiba Tecra M5 is still supported for upstream kernel or if there are real users now. 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 121ce50..b154518 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1658,7 +1658,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); + mmc_delay(2); mmc_pwrseq_post_power_on(host); @@ -1671,7 +1671,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); + mmc_delay(2); } void mmc_power_off(struct mmc_host *host)