Nhân Linux: udelay() trả về quá sớm?

Question

Tôi có trình điều khiển yêu cầu độ trễ micro giây. Để tạo độ trễ này, trình điều khiển của tôi đang sử dụng chức năng udelay của hạt nhân. Cụ thể, có một cuộc gọi đến 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 

Chúng tôi đã gặp sự cố về độ tin cậy với thiết bị. Sau nhiều lần gỡ lỗi, chúng tôi đã tìm ra vấn đề với trình điều khiển tiếp tục trước khi 90us trôi qua. (Xem "bằng chứng" bên dưới.)

Tôi đang chạy phiên bản hạt nhân 2.6.38-11-chung SMP (Kubuntu 11.04, x86_64) trên Intel Pentium Dual Core (E5700).

Theo như tôi biết, tài liệu tuyên bố rằng udelay sẽ trì hoãn thực hiện cho ít nhất độ trễ được chỉ định và không thể ngắt. Có lỗi nào trong phiên bản này của hạt nhân không, hoặc tôi có hiểu lầm về việc sử dụng udelay không?

---

Để thuyết phục bản thân rằng vấn đề là do udelay trở về quá sớm, chúng tôi ăn một đồng hồ 100kHz với một trong các cổng vào/O và thực hiện chậm trễ của chúng ta như sau:

// 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; 
      } 
     } 
    } 
} 

... và người lái xe bây giờ hoạt động hoàn hảo.

---

Là một lưu ý cuối cùng, tôi thấy a discussion chỉ ra rằng tần số rộng có thể gây ra cho gia đình * delay() chức năng để misbehave, nhưng đây là một danh sách gửi thư ARM - Tôi giả sử các vấn đề như vậy sẽ không tồn tại trên một máy tính dựa trên Linux x86.

Answer 1

E5700 có X86_FEATURE_CONSTANT_TSC nhưng không X86_FEATURE_NONSTOP_TSC. TSC là nguồn đồng hồ có khả năng cho số udelay. Trừ khi bị ràng buộc với một trong các lõi có mặt nạ ái lực, nhiệm vụ của bạn có thể đã được đặt trước và được lên lịch lại cho một CPU khác trong thời gian udelay. Hoặc TSC có thể không ổn định trong các chế độ CPU công suất thấp hơn.

Bạn có thể thử tắt các ngắt hoặc vô hiệu hóa việc sử dụng trong số udelay không? Ngoài ra, hãy thử đọc TSC trước và sau.

Answer 2

Tôi không biết bất kỳ lỗi nào trong phiên bản hạt nhân đó (nhưng điều đó không có nghĩa là không có phiên bản nào).

udelay() không phải là "không gián đoạn" - nó không vô hiệu hóa việc sử dụng trước, do đó nhiệm vụ của bạn có thể được tác vụ RT thực hiện trước trong thời gian trễ. Tuy nhiên, điều tương tự cũng đúng với việc triển khai chậm trễ thay thế của bạn, do đó, điều đó có vẻ không phải là vấn đề.

Sự cố thực tế của bạn có phải là vấn đề liên quan đến bộ nhớ/mạch kết hợp DMA không? Việc triển khai chậm trễ thay thế của bạn truy cập vào bus, vì vậy điều này có thể che giấu vấn đề thực sự như là một tác dụng phụ.