>> Hi all, >> >> Sorry for bothering you. : ) >> >> The problem is that I don't understand why swapping dummy qtd is >> needed in queue requests. After tracing the code, I know that dummy >> qtd is already in the qtd list of qh, and the host controller must see >> dummy qtd before the new qtd list is added to queue head. > > That last part isn't true. The new qtd list may be added before the > host controller sees the dummy qtd. > >> But what is >> the difference if dummy qtd is not used to swap the first qtd entry ?? > > What do you mean? If the swap didn't take place then the new qtd would > be queued _after_ the dummy, and so the host controller would never see > it -- it would stop when it reached the dummy in the qtd list. > >> and the source code's comment say that the method can "avoid racing >> the HC". I can't figure out why swap dummy qtd is related to "avoid >> racing the HC" ?? > > Suppose the controller has already reached the old dummy qtd, so that > the dummy qtd's address was stored in the Next qTD Pointer field of the > QH's overlay. How do you get the controller to execute the new qtd? > And how do you get the controller to execute the new qtd if it _hasn't_ > reached the old dummy qtd yet? That's what "racing the HC" refers to. so the dummy qtd is the empty qtd which cause the host controller to go over to next qh to process the next qtd_list ?? and this cause me to think another question that why empty queue head detection(H=1,reclamation=0) is needed in queue traversal ?? why hc need to stop traversing the asynchronous list when these criteria are met? Can hc still continue schedule traversal?? >> Could someone please help me to figure this out ?? > > Does this help? Do you have more specific questions? Sorry about that I have a lot of questions to ask. Because usb subsystem is not easy to understand. As a new-comer here I have a lot to learn from you. Your advice and comments are appreciated. :) > 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
