USB Interrupts
- Dominant language
- No language data
- Stars
- 43.3k
- Forks
- 5.7k
- PR merge metrics
- No merged PRs in 30d
Description
The section titled "Interrupt fires [NOT for USB keyboards]" is incorrect. The USB controller is a either a chip or module in an SOC in any computer, that USB controller does poll over the physical USB lines to handle the different transfer types such as bulk transfer, interrupt transfer, etc, however the CPU itself is not polling. The USB controller has a line to an interrupt pin on the CPU and the USB controller generates a real interrupt when a USB interrupt transfer occurs, such as from a USB keyboard. So on the CPU an interrupt really does fire for USB keyboards
It's actually easy to prove this on a linux computer. Most linux machines have a couple USB controllers, you can see them with lspci:
lspci | grep -i usb
00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10)
3a:00.0 USB controller: Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] (rev 02)
Next attach a USB keyboard to one of the controllers that doesn't have many or any other USB devices on it and watch the interrupts:
watch -n1 "cat /proc/interrupts | grep -i hci"
CPU0 CPU1 CPU2 CPU3
148: 0 174 0 0 IR-PCI-MSI 30408704-edge xhci_hcd
I can see the number 174 tick up twice everytime I tap a key (one interrupt for key down and another for key up).
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.