On Fre, 2002-09-27 at 18:11, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote: > > > >>Michel Dänzer wrote: > >> > >>>On Don, 2002-09-26 at 18:17, Keith Whitwell wrote: > >>> > >>> > >>>>Michel Dänzer wrote: > >>>> > >>>> > >>>>>Something else I've been thinking about is that relying on the > >>>>>swi_emitted and swi_received counters being in sync is pretty fragile. > >>>>>It might be better to use a scratch register instead. > >>>>> > >>>>> > >>>>Yes, it could be made more robust. > >>>> > >>>> > >>>Do you think the approach with a scratch register is good? > >>> > >>Yep, but I guess you have to worry about then going to sleep *after* the > >>interrupt has arrived, if there is a delay in getting the scratch write across > >>the bus, compared to the irq, which should be instantaneous. > >> > > > > Is that really an issue? The scratch register is written to before the > > interrupt is triggered, so I'd expect a register read to yield the > > correct value when the interrupt has arrived. > > I was under the understanding that the scratch registers were actually > 'shadows' in main memory, updated by the card across the agp bus. If so, I > don't think there's any guarantee of synchronization with the irq delivery. > Maybe it's not a real risk, but certainly worthwhile to keep it in mind.
That's one reason why I don't use writeback for this one. It should normally only be read once or twice per interrupt anyway. > >>>>We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out > >>>>what has happened -- particularly have the interrupts been disabled? > >>>> > >>>> > >>>Turns out they haven't. GEN_INT_CNTL looks exactly like it should. > >>>Interestingly, the GEN_INT_STATUS bits are set as well, and > >>>acknowledging them helps. So it seems that somehow, the service routine > >>>didn't get called for an interrupt, or the acknowledgement got lost. > >>> > >>>If the updated patch works for you as well, I'll commit it. > >>> > >>The patch doesn't seem to do anything about this case, just print something out... > >> > > > > Are we talking about the same patch, > > http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff with md5sum > > 6abf27a2a1d6a4e57a8c36b19ef0e17b? It worked fine for nicod yesterday... > > (BTW it would have been a pain in the neck for him to debug this without > > reinit) > > OK, I see it now. > > It's a big hack to be doing this. I'd really like to know why this happens, So would I. I suspect it's a workaround for some problem, it worked fine here without. (as I said on IRC yesterday: but then I have sane hardware :) > but in the mean time I'm ok to see it go in. Okay, I'll commit it later tonight. > Maybe I should be more pedantic about things... Well, I'd rather you wouldn't be speaking in riddles. ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
