On Tuesday 10 October 2006 9:35 pm, Rupesh Kumar wrote: > > This is the first time I've heard of that kind of hardware bug. > > > > If it's always doing 8 transfers, despite being told to do only > > one, that's pretty significant ... > > > > Have you verified with the silicon vendor that this is what's > > happening? And that they won't fix it? > > I have verified with the silicon vendor and they are claiming that > > "Section 4.3.1.1 of OHCI specifications, says that "The Host > Controller Driver should not modify any portion of the TD while it is > accessible to the HC". So after processing the ISOCH TD the OHCI > controller updates completed TD with the necessary changes in the TD > fields." > > "But here we identified that the driver is using the some of TD fields > to manipulate the TDs while that TD is processing by the HC" And > driver is not supposed to use those fields.
What fields in the TD is it manipulating? The TD only describes a handful of frames ... FC+1 to be specific. Are you saying that this silicon is updating (non-existent) PSW entries for other frames ... FC+2, FC+3, FC+4, maybe all the way to FC+7 (the max)? If so, how is it updating them? If it's just writing out eight PSW entries -- but only changing the one that's actually used!! -- then the simplest fix would be move that field down (e.g. move the two dma_addr_t fields up) so that memory can safely be rewritten. (I can see that clobbering td_hash would make a lot of trouble.) If on the other hand it's changing those (non-existent) PSW entries, like maybe zeroing them, then things get awkward. > > The downside of adding more PSWs is memory wastage, but most > > systems don't use all the TDs pre-allocated in their pool. > > So it should be fine if i provide 6 more PSWs can i conclude on this. If possible, I'd rather just see the next three 32-bit fields after the PSW become write-once (hence safe to rewrite) since I don't like to waste memory. (And if that works, yes put a comment there about the isue: some rare hardware reads, then rewrites, PSW entries it was told not to use; so there must be 8*16 bytes of data the HCD doesn't change after queueing the TD, beginning at hwPSW[0].) But yes, if there's no other way around this, then that would be the only option. - Dave ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
