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

[Stephane Marchesin]

On Thu, May 27, 2010 at 23:03, Stephane Marchesin <
stephane.marchesin at gmail.com> wrote:

>
>
> 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.
>
>
Blah, of course the *read* has to be atomic, not the write...

Stephane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20100527/4411cb01/attachment.html>