[Intel-gfx] [PATCH 5/7] drm/i915: Interrupt driven fences

[Chris Wilson]

On Fri, Jan 08, 2016 at 10:14:16PM +0000, Chris Wilson wrote:
> On Fri, Jan 08, 2016 at 06:47:26PM +0000, John.C.Harrison at Intel.com wrote:
> > From: John Harrison <John.C.Harrison at Intel.com>
> > 
> > The intended usage model for struct fence is that the signalled status
> > should be set on demand rather than polled. That is, there should not
> > be a need for a 'signaled' function to be called everytime the status
> > is queried. Instead, 'something' should be done to enable a signal
> > callback from the hardware which will update the state directly. In
> > the case of requests, this is the seqno update interrupt. The idea is
> > that this callback will only be enabled on demand when something
> > actually tries to wait on the fence.
> 
> But struct fence already has support for that model, i.e.
> fence_add_callback(). This looks to duplicate that code.
> 
> What exactly are you trying to improve?

I was being dense and thought you were describing how you intended our
driver to function. (In the driver, the preference is definitely lazily
batched polling.) You could make it clearer that you are describing
how the external interface to struct fence operates.

"When signaling is enabled on a struct fence, the driver is expected to
call fence_signal() as soon as the fence is complete. To do this, we
unmask the user interrupt and then in the interrupt handler we check the
seqno and call fence_signal() on completed requests."

Then you can explain how you replaced the waitqueue_t with a list of all
requests, be they waited upon or not. And how you moved the heavyweight
seqno processing from out of process context into interrupt context.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre