I believe this patch is on the wrong series, right? I'm afraid I don't know what was this race neither the two-step reset to be able to review this comment remove. Please give me some pointers to check that. On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > With the two-step reset counter increments which braket the actual > reset code and the subsequent wake-up we're guaranteeing that all the > lockless waiters _will_ be woken up. And since we unconditionally bail > out of waits with -EAGAIN (or -EIO) in that case there is not risk of > lost interrupt enabling bits when the lockless wait code races against > a gpu reset. > > Let's remove this FIXME as resolved then. > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > --- > drivers/gpu/drm/i915/i915_drv.c | 6 ------ > 1 file changed, 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index cc6c51107047..89741e6e2d08 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -878,12 +878,6 @@ int i915_reset(struct drm_device *dev) > } > > /* > - * FIXME: This races pretty badly against concurrent holders of > - * ring interrupts. This is possible since we've started to drop > - * dev->struct_mutex in select places when waiting for the gpu. > - */ > - > - /* > * rps/rc6 re-init is necessary to restore state lost after the > * reset and the re-install of gt irqs. Skip for ironlake per > * previous concerns that it doesn't respond well to some forms > -- > 2.1.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
