Re: uhci question
Alan Stern <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 10 Oct 2007, jidong xiao wrote: > I am seeing in struct uhci_hcd,there is a struct uhci_td *term_td, and > hence in uhci_start, there are such lines: > > 638 /* This dummy TD is to work around a bug in Intel PIIX > controllers */ > 639 uhci_fill_td(uhci->term_td, 0, uhci_explen(0) | > 640 (0x7f << TD_TOKEN_DEVADDR_SHIFT) | > USB_PID_IN, 0); > 641 uhci->term_td->link = UHCI_PTR_TERM; > 642 uhci->skel_async_qh->element = uhci->skel_term_qh->element = > 643 LINK_TO_TD(uhci->term_td); > > I wonder what bug it is?Where can I find any description about this > bug.And how term_td can be a work around for that bug? The bug is described on Intel's developer web site; it is listed in the errata document for their early motherboards. I don't have a URL available for it. IIRC, the bug was that if FSBR was turned on and none of the full-speed control or bulk QHs had a valid TD pointer, the controller would hang or malfunction in some other way. It didn't matter whether the TD was active or not; as long as it was there the controller would be okay. That's what term_td is for. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel