On Thu, May 27, 2010 at 23:03, Stephane Marchesin < [email protected]> wrote:
> > > On Thu, May 27, 2010 at 22:47, Ben Skeggs <[email protected]> wrote: > >> On Thu, 2010-05-27 at 17:55 +0300, Pekka Paalanen wrote: >> > On Wed, 26 May 2010 23:24:57 +0200 >> > Maarten Maathuis <[email protected]> wrote: >> > >> > > For NV04 i can understand, since it's irq driven fences, so let's >> > > split the question. >> > > >> > > NV10+: can we reduce it to just spin_lock? >> > >> > I don't know the answer, but I know the theory: if there is >> > any path, that can take the spinlock from an interrupt >> > service path, then you must use the irq-safe version everywhere. >> We could, the interrupt-based path is currently only used on really old >> chips that don't have REF_CNT. >> >> > >> > > NV04: can't we rely on a normal spin lock and add it as well in >> > > nv04_graph_mthd_set_ref? >> > >> > So if NV04 fences are driven by irqs, and the ISR needs to >> > take the lock, then no, you cannot revert to irq-unsafe spinlocks. >> > I'm not sure how it relates to ISR bottom halves, though. >> > >> > Note, that also irq-unsafe spinlocks disable preemption, which >> > might be enough to disturb audio. >> The spinlock was actually only ever meant to protect the list itself and >> not the sequence counters. >> >> I've attached a patch removing the spinlock use everywhere except when >> we're actually going to touch the pending list, I think >> last_sequence_irq is still safe as the NV04 fence IRQ handler is the >> only writer. >> > > That would mean the write has to be atomic everywhere though. > > Blah, of course the *read* has to be atomic, not the write... Stephane
_______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
