On Wednesday 20 December 2006 4:40 pm, Vivek Dharmadhikari wrote: > Hello > > I want to understand how the queue heads are linked and unlinked in the > ehci driver. I interpret following after reading the ehci code
After you understand that, what will you do with that knowledge? > 1. The class drivers such usb-stroage submit urb using usb_submit_urb() Yes, but not all USB device drivers are class drivers... > 2. The usb core driver chops the urb into qtds. No, EHCI does that in qh_urb_transaction(). > 3. The qtds are then linked into an existing queue head if any or > otherwise a new queue head is created and then the qtds are linked into > it. Yes, EHCI does this in submit_async() and qh_append_tds(); the last step will be qh_link_async() if the QH is newly created, or is otherwise in the IDLE state (controller doesn't see it). Note that appending to an active queue head is tricky and racey. That's especially true given certain bugs in older EHCI silicon, and the fact that the queue head may be in the middle of fault cleanup (including cleanup from a software-induced "unlink TDs associated with this URB" fault). > 4. The host controller execute the transactions defined by the each qtd > and generate QTD_IOC interrupt. Not every QTD involves an IOC though ... only the last TD associated with an URB needs one. Also, getting a STS_INT completion interrupt just means _some_ qtd (or itd) completed. The driver scans the schedule and collects all the completed transfers. Many of those will imply a completed URB; and taking the completed transfers off the schedules is only slightly racey, that's actually pretty easy. (What's harder is cleanup after faults, which can mean putting a modified QH back on the async ring...) > Is the above interpretation correct ? > > I am not sure how unlinking queue head happens though. I suppose the > queue head is unlinked after queue head scan reveals that there are no > pending qtds. Is that a fair assumption ? See what scan_async() does. It turns out to be a bad idea to unlink a queue head (using the IAA mechanism) immediately after its last QTD gets collected, since it takes time to unlink and it's routine to submit a new URB to an endpoint soon after the last one gets given back to the driver. So instead of immediately unlinking, there's a delay. > I understand that the queue heads are unlinked to reduce memory chatter. > Is there a way whereby the queue heads stays forever and are not > unlinked at all ? Not in this driver. > Is the Asynclistaddr register updated by the host controller after > unlinking a queue head ? No, since it always holds the queue head. What happens instead is that the controler is told to stop scanning the async ring once it becomes empty, and stays empty for a while. - Dave > > Thanks. > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > linux-usb-devel@lists.sourceforge.net > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
