Linux 内核 : udelay() returns too early?

Question

我有一个需要微秒延迟的驱动程序。为了创建这种延迟，我的驱动程序使用了内核的 udelay 函数。具体来说，有一次调用 udelay(90):

iowrite32(data, addr + DATA_OFFSET);
iowrite32(trig, addr + CONTROL_OFFSET);

udelay(30);

trig |= 1;
iowrite32(trig, addr + CONTROL_OFFSET);

udelay(90); // This is the problematic call

我们的设备存在可靠性问题。经过大量调试，我们将问题追踪到驱动程序在 90us 之前恢复。 (参见下面的“证明”。)

我在 Intel Pentium 双核 (E5700) 上运行内核版本 2.6.38-11-generic SMP(Kubuntu 11.04，x86_64)。

据我所知，文档指出 udelay 将延迟执行 至少 指定的延迟，并且是不可中断的。 是不是这个版本的内核有bug，还是我对udelay的使用理解有误？

---

为了说服自己问题是由 udelay 返回得太早引起的，我们将一个 100kHz 的时钟馈送到其中一个 I/O 端口并实现了我们自己的延迟，如下所示:

// Wait until n number of falling edges
// are observed
void clk100_delay(void *addr, u32 n) {
    int i;

    for (i = 0; i < n; i++) {
        u32 prev_clk = ioread32(addr);
        while (1) {
            u32 clk = ioread32(addr);
            if (prev_clk && !clk) {
                break;
            } else {
                prev_clk = clk;
            }
        }
    }
}

...现在驱动程序可以完美运行。

---

最后一点，我找到了 a discussion表明频率缩放可能会导致 *delay() 函数系列出现异常，但这是在 ARM 邮件列表上 - 我假设此类问题在基于 Linux x86 的 PC 上不存在。

Answer 1

我不知道该版本的内核中有任何错误(但这并不意味着没有错误)。

udelay() 不是“不可中断的”——它不会禁用抢占，因此您的任务可以在延迟期间被 RT 任务抢占。但是，您的替代延迟实现也是如此，因此这不太可能成为问题。

您的实际问题可能是 DMA 一致性/内存排序问题吗？您的备用延迟实现访问总线，因此这可能将真正的问题隐藏为副作用。