From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756960AbcEaJQh (ORCPT ); Tue, 31 May 2016 05:16:37 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:56596 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756598AbcEaJQc (ORCPT ); Tue, 31 May 2016 05:16:32 -0400 From: Arnd Bergmann To: "Baranowska, BeataX" Cc: "Hunter, Adrian" , Ulf Hansson , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Dong, Chuanxiao" , "Jarosz, SebastianX" Subject: Re: [PATCH] mmc: sdhci: use udelay instead of mdelay Date: Tue, 31 May 2016 11:16:56 +0200 Message-ID: <5535547.CKl9RgC1aK@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <6616684.XTKejIxGbJ@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:BU71wyZcnus0fwK1FuReimCrOVdSz+28S9IgUt3ETPKzOjvxOW7 GSg3FvPPq/2P6vFSPCDwKzQ0IUGcEO7EGBfZIB5+yaqkG8PXegTg6+cbtKsA9GJqYk1vbUZ oUYKN4ncWBye7uzDPlC4W1q+d92Ohk2XpWC1Plns7hAQZF0n0tRy3hQIue8H8iOIDRP0bib 5wuCDBmxh0Sln+6OtumPQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ipsTgQLorow=:JDabTiu8lTWd2DMXoiFwTI uUdYJPfVwymaaGkKiJmY8LaGbru9dcO8aBpOyTiuuc3k9EU56ht6JqRZzhE8zW3HyCr8OC65o Cc2xSDdEFtIpMgGP7pPHVVaZMWc5aAITEQsZ8WZtdA/GLwOQyKDw/zIjjItT/tsfJX48HqOrk Y/y9Da/2xWVlf06S122bXALJdrVfgraucCUwFv3lgyXr6G4LuBijuNRsa5z2Cij+lyh7jxByR 5fmiUi9m+YA6VgiMxpYlqvPISc8NRV0q98bsJ9mf3cRQv2Ps3A84cemOR15eweF0SllYo6Yv5 13KRn2dwSK2vxS2pD2SKmPpcJK5rReGx28LVIpkfUn7GKR8v37wx3w+h/Quc615eIgJCkgK00 MyXLWafMjdurF3mnqi8h7fF6u92yYHFzFLJUxsDOt7ifRp9vvtKKcoItjsEdKQVQ8FTqWte4R vmi1CsO84p3gV8ZElDPDjU3wtlTlY8w6dH2Itsco2jV2WiHInhVhukFP6Ige0QFCv154Cof3P ur9Zvm9S0EZLxTW5ZnYl1XPU0ebzABC5ZoWDtWXqfLWMJnLmdmNmhlraUKOIyF8y+skvIb/B9 YBYJ3U1MmMz4gGnospDAq6zZg2j8UrgBQ+BXfGEHyJBScIm9tfcRLjNEjtP7NGzrrAVAD8RTe ZdV53fvwC9MPb3dChQ1+5k5Xk6EJS35w8o4ioNclg6W2DT7HY64RVKBplNfhJheH8mBwzjOCv pqIkKFS5HCx3MFkt Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, May 31, 2016 8:53:18 AM CEST Baranowska, BeataX wrote: > > > > 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 > > Thank you for your quick reply. > Could you please clarify what do you mean is called under a spinlock? > Any is not used here? You write that the function is called in a critical region protected by the spinlock, so I was wondering if that is actually necessary. Usually a device reset should be done in normal process context without any spinlocks so you can call normal sleeping functions. Arnd