forked from luck/tmp_suning_uos_patched
e296de926d
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 |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| clocksource | ||
| crypto | ||
| drm | ||
| dt-bindings | ||
| keys | ||
| kvm | ||
| linux | ||
| math-emu | ||
| media | ||
| memory | ||
| misc | ||
| net | ||
| pcmcia | ||
| ras | ||
| rdma | ||
| scsi | ||
| soc | ||
| sound | ||
| target | ||
| trace | ||
| uapi | ||
| video | ||
| xen | ||