On Fri, Jan 09, 2009 at 11:17:17AM -0700, Julie Zhu wrote: > 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? The comment isn't descriptive enough? > Is the updating of qh->hw_next atomic? In what way? It should be a pointer store, which on almost all processors, is atomic. > Is there a way to avoid the udelay() by checking the hardware through > EHCI interface? Do you know of one? thanks, greg k-h -- 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
