aboutsummaryrefslogtreecommitdiffstats
path: root/lib/test_overflow.c
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2018-08-22 11:29:05 +0200
committerDaniel Vetter <daniel.vetter@ffwll.ch>2018-08-22 20:49:33 +0200
commite296de926dfd39cf1ff9e5a41b56d4b3258a5a07 (patch)
tree7badc085328e8441821b9a89c906cbc8c6024f05 /lib/test_overflow.c
parentRevert "drm: crc: Wait for a frame before returning from open()" (diff)
downloadlinux-dev-e296de926dfd39cf1ff9e5a41b56d4b3258a5a07.tar.xz
linux-dev-e296de926dfd39cf1ff9e5a41b56d4b3258a5a07.zip
drm/syncobj: Drop add/remove_callback from driver interface
This is used for handling future fences. Currently no driver use these, and I think given the new timeline fence proposed by KHR it would be better to have a more abstract interface for future fences. Could be something simple like a struct dma_future_fence plus a function to add a callback or wait for the fence to materialize. Then syncobj (and anything else really) could grow new functions to expose these two drivers. Normal dma_fence would then keep the nice guarantee that they will always signal (and through ordering, be deadlock free). dma_future_fence would then be the tricky one. This also fixes sphinx complaining about the kerneldoc. Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822092905.19884-1-daniel.vetter@ffwll.ch
Diffstat (limited to 'lib/test_overflow.c')
0 files changed, 0 insertions, 0 deletions