David > Right, so what's the confusion, and why did you ask the first > question?
Well, you wrote that "NO, it always hold the queue head" which I interpreted to mean the register contents are static. Anyway I am clear about it now. Thanks for your explanation. > The HCD doesn't touch that register after initialization, and > the only thing that's always _known_ to be in the async ring > is a QH that never holds transactions and is marked as the > queue head. Even an "empty" ring will hold that QH. Is this always_present QH also labeled as dummy QH ? What is purpose of using this QH which never holds transactions ? Similarly the code also has comments about dummy qtd. What is their purpose as well ? > -----Original Message----- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 03, 2007 9:02 PM > To: linux-usb-devel@lists.sourceforge.net > Cc: Vivek Dharmadhikari > Subject: Re: [linux-usb-devel] Linking and unlinking queue head > > On Thursday 28 December 2006 4:41 pm, Vivek Dharmadhikari wrote: > > Hello David > > > > > > 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. > > > > I am confused. Section 4.8 of echi specs says that " When the host > > controller completes processing of asynchronous schedule,it retains > > the value of last accessed queue head's horizontal pointer in the > > ASYNCLISTADDR register. Next time the asynchronous schedule is > > accessed, this is the first data structure that will be serviced" > > > > I interpret the above to mean that ASYNCLISTADDR is updated by the > > hardware. In other words, ASYNCLISTADDR may not always hold > ehci->async. > > Is it correct ? > > Right, so what's the confusion, and why did you ask the first > question? > > The HCD doesn't touch that register after initialization, and > the only thing that's always _known_ to be in the async ring > is a QH that never holds transactions and is marked as the > queue head. Even an "empty" ring will hold that QH. > > - Dave > > > > > > Regards > > Vivek > > > > > -----Original Message----- > > > From: David Brownell [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, December 20, 2006 6:41 PM > > > To: linux-usb-devel@lists.sourceforge.net > > > Cc: Vivek Dharmadhikari > > > Subject: Re: [linux-usb-devel] Linking and unlinking queue head > > > > > > 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=D > > > EV > > > > DEV _______________________________________________ > > > > 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=DEV > > DEV _______________________________________________ > > 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
