On Tue, 4 Dec 2012, Sarah Sharp wrote: > The USB core hub thread (khubd) is designed with external USB hubs in > mind. It expects that if a port status change bit is set, the hub will > continue to send a notification through the hub status data transfer. > Basically, it expects hub notifications to be level-triggered. > > The xHCI host controller is designed to be edge-triggered. When all > port status change bits are clear, and a new change bit is set, the xHC > will generate a Port Status Change Event. If another change bit is set > in the same port status register before the first bit is cleared, it > will not send another event. This explanation is okay, but in general I often find the terms "edge-triggered" and "level-triggered" to be rather confusing in this sort of context. The real issue here is what input will turn on the IRQ signal (or cause an event to be raised). With xHCI, that input is the "or" of all the status-change bits in a port register -- a new IRQ won't be generated until the "or" changes from 0 to 1. With EHCI, on the other hand, a 0 -> 1 change in any of the bits will cause a new IRQ. Both controllers use edge-triggered IRQs. The difference lies in what edges they are monitoring. > + /* > + * xHCI portsc bits are level-triggered. An event is sent on the first > + * change bit, but won't be sent if another change bit is still set. > + * Poll to avoid losing change bits. > + */ The first two lines of this comment don't express the idea very well. I suggest something more like: /* * xHCI port-status-change events occur when the "or" of all the * status-change bits in the portsc register changes from 0 to 1. * New status changes won't cause an event if any other change * bits are still set. When an event occurs, switch over to * polling to avoid losing status changes. */ Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
