EHCI 驅動程式

2002 年 12 月 27 日

EHCI 驅動程式用於透過 USB 2.0 功能的主機控制器硬體與高速 USB 2.0 裝置通訊。 USB 2.0 標準與 USB 1.1 標準相容。 它定義了三個傳輸速度

  • “高速” 480 Mbit/秒 (60 MByte/秒)

  • “全速” 12 Mbit/秒 (1.5 MByte/秒)

  • “低速” 1.5 Mbit/秒

USB 1.1 僅處理全速和低速。 高速裝置可以在 USB 1.1 系統上使用，但它們會降低到 USB 1.1 速度。

USB 1.1 裝置也可以在 USB 2.0 系統上使用。 當插入 EHCI 控制器時，它們會被交給 USB 1.1 “伴侶”控制器，該控制器是通常與此類裝置一起使用的 OHCI 或 UHCI 控制器。 當 USB 1.1 裝置插入 USB 2.0 集線器時，它們透過集線器中的“事務轉換器”(TT) 與 EHCI 控制器互動，該轉換器將低速或全速事務轉換為高速“拆分事務”，不會浪費傳輸頻寬。

在撰寫本文時，已發現該驅動程式可與（按字母順序排列）Intel、NEC、Philips 和 VIA 的 EHCI 實現一起使用。 其他供應商也開始提供其他 EHCI 實現； 您應該期望此驅動程式也能與它們一起使用。

雖然 usb-storage 裝置自 2001 年年中開始可用（在此驅動程式的 2.4 版本上執行速度很快），但集線器自 2001 年底才可用，並且其他型別的高速裝置似乎處於暫停狀態，直到更多系統內建 USB 2.0。 自 2002 年初以來，此類新系統已經上市，並在 2002 年下半年變得更加普遍。

請注意，USB 2.0 支援不僅僅涉及 EHCI。 它需要對 Linux-USB 核心 API 進行其他更改，包括集線器驅動程式，但這些更改無需真正更改暴露給 USB 裝置驅動程式的基本“usbcore” API。

功能

該驅動程式在 x86 硬體上定期進行測試，並且也已在 PPC 硬體上使用，因此大小端問題應該已經消失。 據信它可以完成所有正確的 PCI 魔術，因此即使在具有有趣 DMA 對映問題的系統上，I/O 也能正常工作。

傳輸型別

在撰寫本文時，該驅動程式應該可以輕鬆處理所有控制、批次和中斷傳輸，包括透過 USB 2.0 集線器中的事務轉換器 (TT) 向 USB 1.1 裝置發出的請求。 但您可能會發現錯誤。

高速同步 (ISO) 傳輸支援也已啟用，但在撰寫本文時，沒有 Linux 驅動程式使用該支援。

透過事務轉換器的全速同步傳輸支援尚不可用。 請注意，ISO 傳輸的拆分事務支援無法與高速 ISO 傳輸的程式碼共享太多程式碼，因為 EHCI 使用不同的資料結構來表示這些傳輸。 因此，目前，大多數 USB 音訊和影片裝置無法連線到高速匯流排。

驅動程式行為

所有型別的傳輸都可以排隊。 這意味著來自一個介面上的驅動程式（或透過 usbfs）的控制傳輸不會干擾來自另一個驅動程式的傳輸，並且中斷傳輸可以使用一幀的時間間隔，而不會因中斷處理成本而導致資料丟失。

EHCI 根集線器程式碼將 USB 1.1 裝置交給其伴侶控制器。 此驅動程式無需瞭解有關這些驅動程式的任何資訊； 已經可以工作的 OHCI 或 UHCI 驅動程式無需因 EHCI 驅動程式也存在而進行更改。

電源管理存在一些問題； 目前暫停/恢復行為不太正確。

此外，在安排定期事務（中斷和同步傳輸）時，也採取了一些捷徑。 這些對可以安排的定期事務的數量施加了一些限制，並阻止使用小於一幀的輪詢間隔。

使用

假設您有一個 EHCI 控制器（在 PCI 卡或主機板上）並將此驅動程式編譯為模組，請像這樣載入它

# modprobe ehci-hcd

並透過以下方式刪除它

# rmmod ehci-hcd

您還應該有一個“伴侶控制器”的驅動程式，例如“ohci-hcd”或“uhci-hcd”。 如果 EHCI 驅動程式出現任何問題，請刪除其模組，然後該伴侶控制器的驅動程式將接管（以較低速度）先前由 EHCI 驅動程式處理的所有裝置。

模組引數（傳遞給“modprobe”）包括

log2_irq_thresh (預設 0)

預設中斷延遲的 Log2，以微幀為單位。 預設值為 0，表示 1 個微幀（125 微秒）。 最大值為 6，表示 2^6 = 64 個微幀。 這控制 EHCI 控制器發出中斷的頻率。

如果您在 2.5 核心上使用此驅動程式，並且啟用了 USB 除錯支援，您將在任何 EHCI 控制器的“sysfs”目錄中看到三個檔案

“async”

轉儲用於控制和批次傳輸的非同步計劃。 顯示每個活動的 qh 和等待的 qtd，通常每個 urb 一個 qtd。 （使用 usb-storage 進行磁碟 I/O 來檢視它；觀察請求佇列！）

“periodic”

轉儲用於中斷和同步傳輸的定期計劃。 不顯示 qtd。

“registers”

顯示控制器暫存器狀態，以及

這些檔案的內容可以幫助識別驅動程式問題。

裝置驅動程式不應關心它們是否在 EHCI 上執行，但它們可能需要檢查“usb_device->speed == USB_SPEED_HIGH”。 高速裝置可以執行全速（或低速）裝置無法執行的操作，例如“高頻寬”定期（中斷或 ISO）傳輸。 此外，當以高速執行時，裝置描述符中的某些值（例如定期傳輸的輪詢間隔）使用不同的編碼。

但是，請務必透過 USB 2.0 集線器測試裝置驅動程式。 當使用事務轉換器時，這些集線器以不同的方式報告某些故障，例如斷開連線； 已觀察到一些驅動程式在看到與 OHCI 或 UHCI 報告的不同故障時表現不佳。

效能

USB 2.0 吞吐量受兩個主要因素限制：主機控制器處理請求的速度以及裝置響應請求的速度。 所有裝置都遵守 480 Mbit/秒的“原始傳輸速率”，但總吞吐量也受到各個高速資料包之間的延遲、驅動程式智慧以及當然的整體系統負載等問題的影響。 延遲也是一個性能問題。

批次傳輸最常用於吞吐量是一個問題的情況。 重要的是要記住，批次傳輸始終採用 512 位元組的資料包，並且最多有 13 個數據包適合一個 USB 2.0 微幀。 八個 USB 2.0 微幀適合一個 USB 1.1 幀； 一個微幀是 1 毫秒/8 = 125 微秒。

因此，當硬體和裝置驅動程式軟體允許時，批次傳輸的可用頻寬超過 50 MByte/秒。 定期傳輸模式（同步和中斷）允許更大的資料包大小，從而使您接近引用的 480 MBit/秒傳輸速率。

硬體效能

在撰寫本文時，單個 USB 2.0 裝置往往在 20 MByte/秒左右的傳輸速率達到最大值。 當然，這可能會發生變化； 並且一些裝置現在更快，而另一些裝置則更慢。

第一個 NEC EHCI 實現似乎在 28 MByte/秒左右的總傳輸速率處存在硬體瓶頸。 雖然這對於 20 MByte/秒的單個裝置來說顯然足夠，但將三個這樣的裝置放到一個總線上並不能獲得 60 MByte/秒。 問題似乎在於控制器硬體不會同時進行 USB 和 PCI 訪問，因此它每個微幀僅嘗試六個（或可能七個）USB 事務，而不是十三個。 （對於一個比其他所有產品早一年上市的產品來說，這似乎是一個合理的折衷方案！）

預計較新的實現會更好地解決這個問題，投入更多的矽片空間來解決該問題，以便新的主機板晶片組能夠更接近 60 MByte/秒的目標。 這包括 NEC 的更新實現，以及其他供應商的矽片。

主機從 EHCI 控制器接收中斷以指示請求完成的最小延遲為一個微幀（125 微秒）。 該延遲是可調的； 有一個模組選項。 預設情況下，ehci-hcd 驅動程式使用最小延遲，這意味著如果您發出控制或批次請求，您通常可以期望在不到 250 微秒內得知它已完成（具體取決於傳輸大小）。

軟體效能

為了獲得高達 20 MByte/秒的傳輸速率，Linux-USB 裝置驅動程式需要保持 EHCI 佇列滿。 這意味著發出大請求，或者如果需要發出 一系列小請求，則使用批次排隊。 當驅動程式不這樣做時，它們的效能結果將會顯示出來。

在典型情況下，usb_bulk_msg() 迴圈寫入 4 KB 的塊將浪費超過一半的 USB 2.0 頻寬。 I/O 完成與驅動程式發出下一個請求之間的延遲將比 I/O 更長。 如果同一個迴圈使用 16 KB 的塊，情況會更好； 一系列 128 KB 的塊會浪費更少。

但是，與其依賴如此大的 I/O 緩衝區來使同步 I/O 效率更高，不如直接將多個（批次）請求排隊到 HC，然後等待它們全部完成（或因錯誤而被取消）。 這種 URB 排隊也應該適用於所有 USB 1.1 HC 驅動程式。

在 Linux 2.5 核心中，定義了新的 usb_sg_*() api 呼叫； 它們對來自散佈列表的所有緩衝區進行排隊。 它們還使用散佈列表 DMA 對映（這可能會應用 IOMMU）和 IRQ 減少，所有這些都將有助於使高速傳輸儘可能快地執行。

待定

中斷和 ISO 傳輸效能問題。 這些定期傳輸已完全安排，因此主要問題可能是如何觸發“高頻寬”模式。

待定

可以透過 sysfs uframe_periodic_max 引數實現超過標準 80% 定期頻寬分配的分配。 描述一下。