On 26/11/2014 12:49, Daniel Vetter wrote:
On Wed, Nov 26, 2014 at 1:12 PM, John Harrison
<John.C.Harrison@xxxxxxxxx> wrote:
The unref_irq is needed for the flip_queued_req as that is still
dereferenced from interrupt time. Possibly this one could now be downgraded
to a mutex lock but before the recent rebase, the mmio_flip request was also
being dereferenced at interrupt time so definitely needed the irq friendly
version. Is there a worry that waiting for the mutex lock could stall the
flip handler so long that it misses the next flip?
Yup this is only possible very recently. I've simply dropped the _irq
and wrapped with struct_mutex locking, but a lockless unref (which
only grabs the lock on the final kput in the free function) like Chris
suggested would indeed be tidier.
-Daniel
A lockless unref only works if you can guarantee never to call it when
you are holding the last reference. And that is something that is
extremely difficult to prove in advance. Just because the flip code
usually releases its reference before the request has been retired does
not mean that it always will. I have definitely seen it occur the other
way around in my testing.
Having a 'lockless' unref that can acquire the mutex lock internally is
not much use when you are needing to call it from code that cannot lock
(e.g. an interrupt handler). In that context, the free must be deferred
until a later time.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
