Hello, I have a question about the udelay that is added into intr_deschedule() in ehci-sched.c: /* simple/paranoid: always delay, expecting the HC needs to read * qh->hw_next or finish a writeback after SPLIT/CSPLIT ... and * expect khubd to clean up after any CSPLITs we won't issue. * active high speed queues may need bigger delays... */ if (list_empty (&qh->qtd_list) || (cpu_to_hc32(ehci, QH_CMASK) & qh->hw_info2) != 0) wait = 2; else wait = 55; /* worst case: 3 * 1024 */ udelay (wait); qh->qh_state = QH_STATE_IDLE; qh->hw_next = EHCI_LIST_END(ehci); wmb (); Can someone explain what it tries to avoid? Is the updating of qh->hw_next atomic? Is there a way to avoid the udelay() by checking the hardware through EHCI interface? Thanks, Julie. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- 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
