lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A4B6184.7000903@parrot.com>
Date:	Wed, 1 Jul 2009 15:15:48 +0200
From:	Matthieu CASTET <matthieu.castet@...rot.com>
To:	<sdhci-devel@...ts.ossman.eu>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	<pierre@...man.eu>
Subject: sdhci can turn off irq up to 200 ms

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.


Matthieu

[1]
static void sdhci_reset(struct sdhci_host *host, u8 mask)
{
    unsigned long timeout;
    u32 uninitialized_var(ier);
[...]
    sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);

    if (mask & SDHCI_RESET_ALL)
        host->clock = 0;

    /* Wait max 100 ms */
    timeout = 100;

    /* hw clears the bit when it's done */
    while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) {
        if (timeout == 0) {
            printk(KERN_ERR "%s: Reset 0x%x never completed.\n",
                mmc_hostname(host->mmc), (int)mask);
            sdhci_dumpregs(host);
            return;
        }
        timeout--;
        mdelay(1);
    }
[...]
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ