|
XenevaOS
|
#include <dma-fence.h>
Public Attributes | |
| const char *(* | get_driver_name )(struct dma_fence *fence) |
| const char *(* | get_timeline_name )(struct dma_fence *fence) |
| bool(* | enable_signaling )(struct dma_fence *fence) |
| bool(* | signaled )(struct dma_fence *fence) |
| signed long(* | wait )(struct dma_fence *fence, bool intr, signed long timeout) |
| void(* | release )(struct dma_fence *fence) |
| void(* | set_deadline )(struct dma_fence *fence, ktime_t deadline) |
struct dma_fence_ops - operations implemented for fence
@enable_signaling:
Enable software signaling of fence.
For fence implementations that have the capability for hw->hw signaling, they can implement this op to enable the necessary interrupts, or insert commands into cmdstream, etc, to avoid these costly operations for the common case where only hw->hw synchronization is required. This is called in the first dma_fence_wait() or dma_fence_add_callback() path to let the fence implementation know that there is another driver waiting on the signal (ie. hw->sw case).
This is called with irq's disabled, so only spinlocks which disable IRQ's can be used in the code outside of this callback.
A return value of false indicates the fence already passed, or some failure occurred that made it impossible to enable signaling. True indicates successful enabling.
&dma_fence.error may be set in enable_signaling, but only when false is returned.
Since many implementations can call dma_fence_signal() even when before @enable_signaling has been called there's a race window, where the dma_fence_signal() might result in the final fence reference being released and its memory freed. To avoid this, implementations of this callback should grab their own reference using dma_fence_get(), to be released when the fence is signalled (through e.g. the interrupt handler).
This callback is optional. If this callback is not present, then the driver must always have signaling enabled.
| const char *(* dma_fence_ops::get_driver_name) (struct dma_fence *fence) |
@get_driver_name:
Returns the driver name. This is a callback to allow drivers to compute the name at runtime, without having it to store permanently for each fence, or build a cache of some sort.
This callback is mandatory.
| const char *(* dma_fence_ops::get_timeline_name) (struct dma_fence *fence) |
@get_timeline_name:
Return the name of the context this fence belongs to. This is a callback to allow drivers to compute the name at runtime, without having it to store permanently for each fence, or build a cache of some sort.
This callback is mandatory.
| void(* dma_fence_ops::release) (struct dma_fence *fence) |
@release:
Called on destruction of fence to release additional resources. Can be called from irq context. This callback is optional. If it is NULL, then dma_fence_free() is instead called as the default implementation.
Implementing this callback prevents the fence from detaching after signaling and so it is necessary for the module providing the dma_fence_ops to stay loaded as long as the dma_fence exists.
If the callback is implemented the memory backing the dma_fence object must be freed RCU safe.
@set_deadline:
Callback to allow a fence waiter to inform the fence signaler of an upcoming deadline, such as vblank, by which point the waiter would prefer the fence to be signaled by. This is intended to give feedback to the fence signaler to aid in power management decisions, such as boosting GPU frequency.
This is called without &dma_fence.lock held, it can be called multiple times and from any context. Locking is up to the callee if it has some state to manage. If multiple deadlines are set, the expectation is to track the soonest one. If the deadline is before the current time, it should be interpreted as an immediate deadline.
This callback is optional.
@signaled:
Peek whether the fence is signaled, as a fastpath optimization for e.g. dma_fence_wait() or dma_fence_add_callback(). Note that this callback does not need to make any guarantees beyond that a fence once indicates as signalled must always return true from this callback. This callback may return false even if the fence has completed already, in this case information hasn't propogated throug the system yet. See also dma_fence_is_signaled().
May set &dma_fence.error if returning true.
This callback is optional.
@wait:
Custom wait implementation, defaults to dma_fence_default_wait() if not set.
Deprecated and should not be used by new implementations. Only used by existing implementations which need special handling for their hardware reset procedure.
Must return -ERESTARTSYS if the wait is intr = true and the wait was interrupted, and remaining jiffies if fence has signaled, or 0 if wait timed out. Can also return other error values on custom implementations, which should be treated as if the fence is signaled. For example a hardware lockup could be reported like that.
Implementing this callback prevents the fence from detaching after signaling and so it is necessary for the module providing the dma_fence_ops to stay loaded as long as the dma_fence exists.