Thanks for the reply, Greg, If the update of qh->hw_next is atomic, why need the udelay? Because if the operation is atomic, then HC sees either the previous value or the new value. If it is the previous value, continue on with the operation; if it is the new value, then do nothing, because it is inactive. Is the danger really at the changing of qh->qh_state? I see qh_update() code check the state to be QH_STATE_IDLE before it updates. And the comments in qh_update() says "writes to an active overlay are unsafe". Can you explain why is so? Again if we assume that update is atomic? Thanks, Julie. -----Original Message----- From: Greg KH [mailto:greg@xxxxxxxxx] Sent: Friday, January 09, 2009 4:54 PM To: Julie Zhu Cc: USB list Subject: Re: udelay in intr_deschedule() in ehci-sched.c 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 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
