On Tue, May 12, 2015 at 09:18:00AM +0100, Chris Wilson wrote: > On Tue, May 12, 2015 at 08:42:58AM +0200, Daniel Vetter wrote: > > On Mon, May 11, 2015 at 09:26:40PM +0100, Chris Wilson wrote: > > > On Mon, May 11, 2015 at 06:37:14PM +0200, Daniel Vetter wrote: > > > > On Mon, May 11, 2015 at 04:03:27PM +0100, Peter Antoine wrote: > > > > > If an batch ends while the IRQs are not turned on the notification can > > > > > go missing and the GPU can hang. So generate a warning in this case. > > > > > > > > > > Signed-off-by: Peter Antoine <peter.antoine@xxxxxxxxx> > > > > > > > > Queued for -next, thanks for the patch. > > > > > > Please drop this. We already have the test inside the irq handler. The > > > instance where you want the guard is during resume, inside > > > intel_lr_context_render_state_init() where you can even emit an error > > > code! > > > > _unqueue is also called from intel_logical_ring_advance_and_submit and > > should cover us I hope. And I don't think we should add error handling for > > this, that has cost of its own. > > Pardon? Your explanation for adding it to the *interrupt* handler after > an existing check is that it also catches the initial submission? I wanted to add it as low down as possible to increase changes of the check surviving refactoring. This way it's as close to possible to the writes to the submit ports. Yes that means it's also run from interrupt context when requeueing, but I'm fairly meh about that. What's your concern? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
