Hello David The Synopsys USB core that we are using the SOC has following bug which might cause the issue(host controller not issuing ping) that I have been dealing with. The workaround for the bug is also provided and I wanted to implement that in the driver. I guess the second workaround is easier to implement. Can you please provide comments on which workaround is easier to implement and most importantly how to implement it.
When software uses the Doorbell mechanism to remove queue heads, the host controller still has references to the removed queue head even after indicating an Interrupt on Async Advance. This happens if the last executed queue head's Next Link queue head is removed. Consequences of the defect: The Host controller fetches the removed queue head, using memory that would otherwise be deallocated.This results in incorrect transactions on both the USB and system memory. This may result in undefined behavior. Workarounds: 1) If no queue head is active (no Status field's Active bit is set) after removing the queue heads, the software can write one of the valid queue head addresses to the ASYNCLISTADDR register and deallocate the removed queue head's memory after 2 microframes. If one or more of the queue heads is active (the Active bit is set in the Status field) after removing the queue heads, the software can delay memory deallocation after time X, where X is the time required for the Host Controller to go through all the queue heads once. X varies with the number of queue heads and the time required to process periodic transactions: if more periodic transactions must be performed, the Host Controller has less time to process asynchronous transaction processing. 2) Do not use the Doorbell mechanism to remove the queue heads. Disable the Asynchronous Schedule Enable bit instead. Regards Vivek > -----Original Message----- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 12, 2006 9:25 PM > To: Vivek Dharmadhikari > Cc: linux-usb-devel@lists.sourceforge.net > Subject: Re: [linux-usb-devel] decoding qh and qtds > > On Tuesday 11 July 2006 12:37 pm, Vivek Dharmadhikari wrote: > > Hello David > > > > > You should have tried 76 _columns_ or _characters_ instead; that > > > didn't improve anything. > > > > I meant 76 characters. Anyway, I suspect my mail server is > overriding > > the mail client options. I have switched to new mailer which I hope > > will do line wrap correctly. Do let me know if you can read > my response. > > It worked this time, thanks. > > > > After dumping the ring head(given below), I can confirm > that the H bit > > in dword1 is indeed 1. The ring head output is followed by output > > from > > show_async() > > Good ... > > > > ring head begin > > vox160-ehci-hcd vox160-ehci-hcd.0: rh qh a1614000 n01614102 > info 8000 > > 0 cq 0 nq 1 aq 160f000 t 40 > > I don't know what those mean... > > > ring head end > > > > qh/a1614100 dev2 hs ep1 02002102 40000000 (80008c01 data1 nak0) > > a160f120 out len=512 02008c80 urb 8147e6e0 > > > > dword1 is ring head is 0x8000 indicating H bit is set but all the > > other fields like endpoint number,device address are zeroed > out. Is that ok ? > > It's also not enabled, so none of the values will be used. Yes, OK. > > > > The current qtd pointer is null. The alternate qtd pointer > is filled > > up owing to OUT 31 bytes short packet which was NYETed and > i hope that > > the physical address 0x160f000 would correspond to virtual address > > 0xa160f120 of qtd. The token field is 0x40 indicating that > the halted > > bit is set. Apparently the host controller is halted for > some reason. > > is that fair to assume ? > > No, go back and read the source code for where it sets up the > ring head. > > That QTD is used for specific purposes ... see what they are, > and what the EHCI spec says would happen when the controller > tried to fetch such a QTD as part of advancing a QH. (Also > see what I said about chip errata, that applied specifically > in this area.) > > > > On the other hand, the contents of status and command > register given > > below indicates that the HC is not halted. > > > > status 8008 Async FLR > > command 010029 (park)=0 ithresh=1 Async period=256 RUN > > > > The status and command register do not agree with data from > queue head. > > Obviously there is a disconnect or may be I did not > correlate the data > > correctly. What is your comment ? > > You didn't understand the data you're seeing. All that data > looks fine to me. > > - Dave > ------------------------------------------------------------------------- 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
