Messages in this thread | | | Date | Mon, 7 Sep 2009 12:47:41 -0700 (PDT) | Subject | Re: sdhci can turn off irq up to 200 ms | From | Daniel J Blueman <> |
| |
On Jul 9, 11:30 am, Matthieu CASTET <matthieu.cas...@parrot.com> 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/
| |