On 2002.06.15 18:25 Leif Delgass wrote: > On Sat, 15 Jun 2002, Keith Whitwell wrote: > > > ... > > > > Is this necessary if the toggle is really just a write? Jose, you're > not > > doing a read-modify-write operation on that flag are you? > > Actually, with the current implementation it is a read-modify-write. > Jose, we could avoid that by caching the ring offset and data for > BM_COMMAND from the (previous) tail as my original patch did. >
As Leif said, I'm doing a read-modify-write. But there is no need to keep track of the previous written value to void the read since (as I said in a previous post) the linux kernel function clear_bit does the necessary job atomically (with no read too). Nevertheless I still fail to understand why the engine would fail here. If he got either the previous value, or the new one it shouldn't fail as both situations are accounted for. My concern is if it can gets values different than these two due to a simultaneous read/write, but I'm not sure if this is even possible as the modify consists of a single bit! > > I suppose to some extent we're relying on the atomicity of the mach64's > use of > > that flag as well -- I don't know if there are any obvious ways they > could get > > it wrong (I assume they just fetch it once...) -- so that's probably > not a > > huge problem. > > There is the possibility of I'm missing something... well, I have no other choice than keep trying and eliminating hypothesis. José Fonseca _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
