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@xxxxxxxxx wrote: > > From: John Harrison <John.C.Harrison@xxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
