On 11/05/2014 01:23 PM, Chris Wilson wrote:
On Wed, Nov 05, 2014 at 01:03:00PM +0200, Ander Conselvan de Oliveira wrote:
This simplifies the code quite a bit compared to iterating over all
rings during the ring interrupt.
Also, it allows us to drop the mmio_flip spinlock, since the mmio_flip
struct is only accessed in two places. The first is when the flip is
queued and the other when the mmio writes are done. Since a flip cannot
be queued while there is a pending flip, the two paths shouldn't ever
run in parallel. We might need to revisit that if support for replacing
flips is implemented though.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx>
---
I'm not sure if locking dev->struct_mutex in the work function might
have any ill effects, so I'd appreciate if someone could enlighten me.
Good news is you can wait on the seqno without holding any locks. You
need to use the lower level entry point __wait_seqno() though.
I considered the fact that __wait_seqno() is static as a warning that I
shouldn't use it directly. Should I just change that so I can use it
intel_display.c?
The other reason I avoided it is because I didn't really understand how
the barrier for reading the reset_counter should work. Is it sufficient
that I do
atomic_read(&dev_priv->gpu_error.reset_counter))
before calling __wait_seqno() or is there something more to it?
Thanks,
ander
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
