02 Jun, 2016

1 commit

  • Fence contexts are created on the fly (for example) by the GPU scheduler used
    in the amdgpu driver as a result of an userspace request. Because of this
    userspace could in theory force a wrap around of the 32bit context number
    if it doesn't behave well.

    Avoid this by increasing the context number to 64bits. This way even when
    userspace manages to allocate a billion contexts per second it takes more
    than 500 years for the context number to wrap around.

    v2: fix printf formats as well.

    Signed-off-by: Christian König
    Reviewed-by: Gustavo Padovan
    Acked-by: Sumit Semwal
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/1464786612-5010-2-git-send-email-deathsimple@vodafone.de

    Christian König
     

30 Oct, 2015

1 commit

  • Waiting for the first fence in an array of fences to signal.

    This is useful for device driver specific resource managers
    and also Vulkan needs something similar.

    v2: more parameter checks, handling for timeout==0,
    remove NULL entry support, better callback removal.

    Signed-off-by: Christian König
    Reviewed-by: Alex Deucher
    Reviewed-by: Maarten Lankhorst

    Christian König
     

22 Jan, 2015

1 commit


04 Nov, 2014

1 commit


28 Aug, 2014

1 commit


09 Jul, 2014

2 commits

  • This adds some extra functions to deal with rcu.

    reservation_object_get_fences_rcu() will obtain the list of shared
    and exclusive fences without obtaining the ww_mutex.

    reservation_object_wait_timeout_rcu() will wait on all fences of the
    reservation_object, without obtaining the ww_mutex.

    reservation_object_test_signaled_rcu() will test if all fences of the
    reservation_object are signaled without using the ww_mutex.

    reservation_object_get_excl and reservation_object_get_list require
    the reservation object to be held, updating requires
    write_seqcount_begin/end. If only the exclusive fence is needed,
    rcu_dereference followed by fence_get_rcu can be used, if the shared
    fences are needed it's recommended to use the supplied functions.

    Signed-off-by: Maarten Lankhorst
    Acked-by: Sumit Semwal
    Acked-by: Daniel Vetter
    Reviewed-By: Thomas Hellstrom
    Signed-off-by: Greg Kroah-Hartman

    Maarten Lankhorst
     
  • A fence can be attached to a buffer which is being filled or consumed
    by hw, to allow userspace to pass the buffer without waiting to another
    device. For example, userspace can call page_flip ioctl to display the
    next frame of graphics after kicking the GPU but while the GPU is still
    rendering. The display device sharing the buffer with the GPU would
    attach a callback to get notified when the GPU's rendering-complete IRQ
    fires, to update the scan-out address of the display, without having to
    wake up userspace.

    A driver must allocate a fence context for each execution ring that can
    run in parallel. The function for this takes an argument with how many
    contexts to allocate:
    + fence_context_alloc()

    A fence is transient, one-shot deal. It is allocated and attached
    to one or more dma-buf's. When the one that attached it is done, with
    the pending operation, it can signal the fence:
    + fence_signal()

    To have a rough approximation whether a fence is fired, call:
    + fence_is_signaled()

    The dma-buf-mgr handles tracking, and waiting on, the fences associated
    with a dma-buf.

    The one pending on the fence can add an async callback:
    + fence_add_callback()

    The callback can optionally be cancelled with:
    + fence_remove_callback()

    To wait synchronously, optionally with a timeout:
    + fence_wait()
    + fence_wait_timeout()

    When emitting a fence, call:
    + trace_fence_emit()

    To annotate that a fence is blocking on another fence, call:
    + trace_fence_annotate_wait_on(fence, on_fence)

    A default software-only implementation is provided, which can be used
    by drivers attaching a fence to a buffer when they have no other means
    for hw sync. But a memory backed fence is also envisioned, because it
    is common that GPU's can write to, or poll on some memory location for
    synchronization. For example:

    fence = custom_get_fence(...);
    if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
    dma_buf *fence_buf = seqno_fence->sync_buf;
    get_dma_buf(fence_buf);

    ... tell the hw the memory location to wait ...
    custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
    } else {
    /* fall-back to sw sync * /
    fence_add_callback(fence, my_cb);
    }

    On SoC platforms, if some other hw mechanism is provided for synchronizing
    between IP blocks, it could be supported as an alternate implementation
    with it's own fence ops in a similar way.

    enable_signaling callback is used to provide sw signaling in case a cpu
    waiter is requested or no compatible hardware signaling could be used.

    The intention is to provide a userspace interface (presumably via eventfd)
    later, to be used in conjunction with dma-buf's mmap support for sw access
    to buffers (or for userspace apps that would prefer to do their own
    synchronization).

    v1: Original
    v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
    that dma-fence didn't need to care about the sw->hw signaling path
    (it can be handled same as sw->sw case), and therefore the fence->ops
    can be simplified and more handled in the core. So remove the signal,
    add_callback, cancel_callback, and wait ops, and replace with a simple
    enable_signaling() op which can be used to inform a fence supporting
    hw->hw signaling that one or more devices which do not support hw
    signaling are waiting (and therefore it should enable an irq or do
    whatever is necessary in order that the CPU is notified when the
    fence is passed).
    v3: Fix locking fail in attach_fence() and get_fence()
    v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
    we decided that we need to be able to attach one fence to N dma-buf's,
    so using the list_head in dma-fence struct would be problematic.
    v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
    v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
    about checking if fence fired or not. This is broken by design.
    waitqueue_active during destruction is now fatal, since the signaller
    should be holding a reference in enable_signalling until it signalled
    the fence. Pass the original dma_fence_cb along, and call __remove_wait
    in the dma_fence_callback handler, so that no cleanup needs to be
    performed.
    v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
    fence wasn't signaled yet, for example for hardware fences that may
    choose to signal blindly.
    v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
    header and fixed include mess. dma-fence.h now includes dma-buf.h
    All members are now initialized, so kmalloc can be used for
    allocating a dma-fence. More documentation added.
    v9: Change compiler bitfields to flags, change return type of
    enable_signaling to bool. Rework dma_fence_wait. Added
    dma_fence_is_signaled and dma_fence_wait_timeout.
    s/dma// and change exports to non GPL. Added fence_is_signaled and
    fence_enable_sw_signaling calls, add ability to override default
    wait operation.
    v10: remove event_queue, use a custom list, export try_to_wake_up from
    scheduler. Remove fence lock and use a global spinlock instead,
    this should hopefully remove all the locking headaches I was having
    on trying to implement this. enable_signaling is called with this
    lock held.
    v11:
    Use atomic ops for flags, lifting the need for some spin_lock_irqsaves.
    However I kept the guarantee that after fence_signal returns, it is
    guaranteed that enable_signaling has either been called to completion,
    or will not be called any more.

    Add contexts and seqno to base fence implementation. This allows you
    to wait for less fences, by testing for seqno + signaled, and then only
    wait on the later fence.

    Add FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
    An CONFIG_DEBUG_FENCE will be added to turn off the FENCE_TRACE
    spam, and another runtime option can turn it off at runtime.
    v12:
    Add CONFIG_FENCE_TRACE. Add missing documentation for the fence->context
    and fence->seqno members.
    v13:
    Fixup CONFIG_FENCE_TRACE kconfig description.
    Move fence_context_alloc to fence.
    Simplify fence_later.
    Kill priv member to fence_cb.
    v14:
    Remove priv argument from fence_add_callback, oops!
    v15:
    Remove priv from documentation.
    Explicitly include linux/atomic.h.
    v16:
    Add trace events.
    Import changes required by android syncpoints.
    v17:
    Use wake_up_state instead of try_to_wake_up. (Colin Cross)
    Fix up commit description for seqno_fence. (Rob Clark)
    v18:
    Rename release_fence to fence_release.
    Move to drivers/dma-buf/.
    Rename __fence_is_signaled and __fence_signal to *_locked.
    Rename __fence_init to fence_init.
    Make fence_default_wait return a signed long, and fix wait ops too.

    Signed-off-by: Maarten Lankhorst
    Signed-off-by: Thierry Reding #use smp_mb__before_atomic()
    Acked-by: Sumit Semwal
    Acked-by: Daniel Vetter
    Reviewed-by: Rob Clark
    Signed-off-by: Greg Kroah-Hartman

    Maarten Lankhorst