From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH] mmc: sdhci: use udelay instead of mdelay Date: Mon, 30 May 2016 10:00:42 +0200 Message-ID: <6616684.XTKejIxGbJ@wuerfel> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: Received: from mout.kundenserver.de ([212.227.17.13]:54010 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161091AbcE3IAY (ORCPT ); Mon, 30 May 2016 04:00:24 -0400 In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: "Baranowska, BeataX" Cc: "Hunter, Adrian" , Ulf Hansson , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Dong, Chuanxiao" , "Jarosz, SebastianX" On Monday, May 30, 2016 7:55:55 AM CEST Baranowska, BeataX wrote: > From: Chuanxiao Dong > > This patch will use udelay instead of mdelay when waiting for > SDHCI hardware to be stable. udelay can help to reduce the waiting > time when is in critical region which is protected by spinlock. > > With this patch, __sdhci_set_ios only take a few microseconds to be > done. > > Signed-off-by: Chuanxiao Dong > --- > drivers/mmc/host/sdhci.c | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index e010ea4eb6f5..56d2c7567d97 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -173,8 +173,8 @@ void sdhci_reset(struct sdhci_host *host, u8 mask) > sdhci_runtime_pm_bus_off(host); > } > > - /* Wait max 100 ms */ > - timeout = 100; > + /* Wait max 10000 ms */ > + timeout = 10000; > > /* hw clears the bit when it's done */ > while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) { > @@ -185,7 +185,7 @@ void sdhci_reset(struct sdhci_host *host, u8 mask) > return; > } > timeout--; > - mdelay(1); > + udelay(10); > } > } > EXPORT_SYMBOL_GPL(sdhci_reset); This can significantly increase the timeout length. I think you should instead use time_before() to see how many jiffies have passed since the start. However, the real question is why the reset function gets called under a spinlock in the first place. Can you try to rearrange the code so it doesn't need the lock at all and you can just use msleep() instead? Arnd