On Fri, Aug 23, 2013 at 09:27:42AM +0200, Daniel Vetter wrote: > On Fri, Aug 23, 2013 at 3:05 AM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > > Rather than continue to fix up the timeouts to work around the interface > > impedence in wait_event_*(), open code the combination of > > wait_event[_interruptible][_timeout]. And note the code size reduction, > > and dare say readability?, in doing so.. > > > > v2: In order to satisfy the debug requirement of logging missed > > interrupts with the real world requirments of making machines work even > > if interrupts are hosed, we revert to polling after detecting a missed > > interrupt. > > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > > Yeah, I think this approach should work. A few comments: > - I think we need a debugfs file to shut the safety quirk off - when > testing on a machine where we actually miss interrupts it might be > usful to get the warning output every time.
I did consider a modparam. Exposing it would indeed necessitate some protection against concurrent modificatin. > - I'd go for a new bool dev_priv->unreliable_seqno_signalling or so to > avoid any races due to the rmw cycle you now do on dev_priv->quirks. There isn't a race during writing, as hangcheck should never be run concurrently (or at least any concurrent calls filtered out at the start of the function). The read side is inherently racey. > - I'd have opted for a faster timeout of the fake irq, but one that rearms. Whoops, that was a mistake. The intention was to run at 100Hz, do you want even faster? We could switch to a hrtimer and kill two birds with one stone (as timer is singleshot only). > Also I'd love to be able to test all this (both the missed irq > detection stuff and the fake irq) but I don't have a good idea right > now ... So I guess we need to again hope that it won't break too > quickly (since it eventually will break again). Disable the call to ring->get_irq. Perhaps the high word of dev_priv->stop_rings? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
