[Nouveau] Why do we disable local IRQ around nouveau_fence_update?

[Stephane Marchesin]

On Thu, May 27, 2010 at 22:47, Ben Skeggs <skeggsb at gmail.com> wrote:

> On Thu, 2010-05-27 at 17:55 +0300, Pekka Paalanen wrote:
> > On Wed, 26 May 2010 23:24:57 +0200
> > Maarten Maathuis <madman2003 at gmail.com> 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.

Stephane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20100527/53ef90ed/attachment.htm>