Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751679AbZIGTrk (ORCPT ); Mon, 7 Sep 2009 15:47:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751525AbZIGTrj (ORCPT ); Mon, 7 Sep 2009 15:47:39 -0400 Received: from mail-yw0-f141.google.com ([209.85.211.141]:47250 "EHLO mail-yw0-f141.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751517AbZIGTrj convert rfc822-to-8bit (ORCPT ); Mon, 7 Sep 2009 15:47:39 -0400 MIME-Version: 1.0 Date: Mon, 7 Sep 2009 12:47:41 -0700 (PDT) In-Reply-To: X-IP: 82.0.91.38 References: User-Agent: G2/1.0 X-HTTP-Via: 1.1 home (squid/3.0.STABLE8) X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090810 Ubuntu/9.10 (karmic) Firefox/3.5.2,gzip(gfe),gzip(gfe) Message-ID: <10928a87-c449-4401-8765-9e297ca13a0b@y9g2000yqn.googlegroups.com> Subject: Re: sdhci can turn off irq up to 200 ms From: Daniel J Blueman To: Matthieu CASTET Cc: Linux Kernel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1438 Lines: 47 On Jul 9, 11:30?am, Matthieu CASTET wrote: > Matthieu CASTET a ?crit : > > > Hi, > > > sdhci code got tasklets (sdhci_tasklet_card and sdhci_tasklet_finish), > > that does : > > { > > spin_lock_irqsave > > > if (cond) { > > sdhci_reset > > sdhci_reset > > } > > > spin_unlock_irqrestore > > } > > > The problem is that sdhci_reset [1] does busy pooling on a register up > > to a timeout of 100 ms. > > That's not low latency friendly. > > > On our system, we saw that sdhci_reset take 1 ms. That should be because > > we enter in mdelay, even if the hardware clears the bit faster. > > I wonder why there is an mdelay(1). Using cpu_relax and > > time_is_after_jiffies should make sdhci_reset faster. > > In case somebody cares, here a patch that reduce on our hardware > sdhci_reset from 1 ms to 30 us. On my Core2Duo, cpu_relax (implementing rep;nop) takes 3.2ns, but a (synchronous) read over the PCI bus takes 0.5-1us, so it's hard to say how much benefit the cpu_relax call will give, or am I missing something? If the code is reading from a memory location, or perhaps writing to non-writethrough memory, it's a different story. Daniel -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/