// SPDX-License-Identifier: GPL-2.0-only1/*2* Fence mechanism for dma-buf and to allow for asynchronous dma access3*4* Copyright (C) 2012 Canonical Ltd5* Copyright (C) 2012 Texas Instruments6*7* Authors:8* Rob Clark <[email protected]>9* Maarten Lankhorst <[email protected]>10*/1112#include <linux/slab.h>13#include <linux/export.h>14#include <linux/atomic.h>15#include <linux/dma-fence.h>16#include <linux/sched/signal.h>17#include <linux/seq_file.h>1819#define CREATE_TRACE_POINTS20#include <trace/events/dma_fence.h>2122EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);23EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);24EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);2526static DEFINE_SPINLOCK(dma_fence_stub_lock);27static struct dma_fence dma_fence_stub;2829/*30* fence context counter: each execution context should have its own31* fence context, this allows checking if fences belong to the same32* context or not. One device can have multiple separate contexts,33* and they're used if some engine can run independently of another.34*/35static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);3637/**38* DOC: DMA fences overview39*40* DMA fences, represented by &struct dma_fence, are the kernel internal41* synchronization primitive for DMA operations like GPU rendering, video42* encoding/decoding, or displaying buffers on a screen.43*44* A fence is initialized using dma_fence_init() and completed using45* dma_fence_signal(). Fences are associated with a context, allocated through46* dma_fence_context_alloc(), and all fences on the same context are47* fully ordered.48*49* Since the purposes of fences is to facilitate cross-device and50* cross-application synchronization, there's multiple ways to use one:51*52* - Individual fences can be exposed as a &sync_file, accessed as a file53* descriptor from userspace, created by calling sync_file_create(). This is54* called explicit fencing, since userspace passes around explicit55* synchronization points.56*57* - Some subsystems also have their own explicit fencing primitives, like58* &drm_syncobj. Compared to &sync_file, a &drm_syncobj allows the underlying59* fence to be updated.60*61* - Then there's also implicit fencing, where the synchronization points are62* implicitly passed around as part of shared &dma_buf instances. Such63* implicit fences are stored in &struct dma_resv through the64* &dma_buf.resv pointer.65*/6667/**68* DOC: fence cross-driver contract69*70* Since &dma_fence provide a cross driver contract, all drivers must follow the71* same rules:72*73* * Fences must complete in a reasonable time. Fences which represent kernels74* and shaders submitted by userspace, which could run forever, must be backed75* up by timeout and gpu hang recovery code. Minimally that code must prevent76* further command submission and force complete all in-flight fences, e.g.77* when the driver or hardware do not support gpu reset, or if the gpu reset78* failed for some reason. Ideally the driver supports gpu recovery which only79* affects the offending userspace context, and no other userspace80* submissions.81*82* * Drivers may have different ideas of what completion within a reasonable83* time means. Some hang recovery code uses a fixed timeout, others a mix84* between observing forward progress and increasingly strict timeouts.85* Drivers should not try to second guess timeout handling of fences from86* other drivers.87*88* * To ensure there's no deadlocks of dma_fence_wait() against other locks89* drivers should annotate all code required to reach dma_fence_signal(),90* which completes the fences, with dma_fence_begin_signalling() and91* dma_fence_end_signalling().92*93* * Drivers are allowed to call dma_fence_wait() while holding dma_resv_lock().94* This means any code required for fence completion cannot acquire a95* &dma_resv lock. Note that this also pulls in the entire established96* locking hierarchy around dma_resv_lock() and dma_resv_unlock().97*98* * Drivers are allowed to call dma_fence_wait() from their &shrinker99* callbacks. This means any code required for fence completion cannot100* allocate memory with GFP_KERNEL.101*102* * Drivers are allowed to call dma_fence_wait() from their &mmu_notifier103* respectively &mmu_interval_notifier callbacks. This means any code required104* for fence completion cannot allocate memory with GFP_NOFS or GFP_NOIO.105* Only GFP_ATOMIC is permissible, which might fail.106*107* Note that only GPU drivers have a reasonable excuse for both requiring108* &mmu_interval_notifier and &shrinker callbacks at the same time as having to109* track asynchronous compute work using &dma_fence. No driver outside of110* drivers/gpu should ever call dma_fence_wait() in such contexts.111*/112113static const char *dma_fence_stub_get_name(struct dma_fence *fence)114{115return "stub";116}117118static const struct dma_fence_ops dma_fence_stub_ops = {119.get_driver_name = dma_fence_stub_get_name,120.get_timeline_name = dma_fence_stub_get_name,121};122123/**124* dma_fence_get_stub - return a signaled fence125*126* Return a stub fence which is already signaled. The fence's127* timestamp corresponds to the first time after boot this128* function is called.129*/130struct dma_fence *dma_fence_get_stub(void)131{132spin_lock(&dma_fence_stub_lock);133if (!dma_fence_stub.ops) {134dma_fence_init(&dma_fence_stub,135&dma_fence_stub_ops,136&dma_fence_stub_lock,1370, 0);138139set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,140&dma_fence_stub.flags);141142dma_fence_signal_locked(&dma_fence_stub);143}144spin_unlock(&dma_fence_stub_lock);145146return dma_fence_get(&dma_fence_stub);147}148EXPORT_SYMBOL(dma_fence_get_stub);149150/**151* dma_fence_allocate_private_stub - return a private, signaled fence152* @timestamp: timestamp when the fence was signaled153*154* Return a newly allocated and signaled stub fence.155*/156struct dma_fence *dma_fence_allocate_private_stub(ktime_t timestamp)157{158struct dma_fence *fence;159160fence = kzalloc(sizeof(*fence), GFP_KERNEL);161if (fence == NULL)162return NULL;163164dma_fence_init(fence,165&dma_fence_stub_ops,166&dma_fence_stub_lock,1670, 0);168169set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,170&fence->flags);171172dma_fence_signal_timestamp(fence, timestamp);173174return fence;175}176EXPORT_SYMBOL(dma_fence_allocate_private_stub);177178/**179* dma_fence_context_alloc - allocate an array of fence contexts180* @num: amount of contexts to allocate181*182* This function will return the first index of the number of fence contexts183* allocated. The fence context is used for setting &dma_fence.context to a184* unique number by passing the context to dma_fence_init().185*/186u64 dma_fence_context_alloc(unsigned num)187{188WARN_ON(!num);189return atomic64_fetch_add(num, &dma_fence_context_counter);190}191EXPORT_SYMBOL(dma_fence_context_alloc);192193/**194* DOC: fence signalling annotation195*196* Proving correctness of all the kernel code around &dma_fence through code197* review and testing is tricky for a few reasons:198*199* * It is a cross-driver contract, and therefore all drivers must follow the200* same rules for lock nesting order, calling contexts for various functions201* and anything else significant for in-kernel interfaces. But it is also202* impossible to test all drivers in a single machine, hence brute-force N vs.203* N testing of all combinations is impossible. Even just limiting to the204* possible combinations is infeasible.205*206* * There is an enormous amount of driver code involved. For render drivers207* there's the tail of command submission, after fences are published,208* scheduler code, interrupt and workers to process job completion,209* and timeout, gpu reset and gpu hang recovery code. Plus for integration210* with core mm with have &mmu_notifier, respectively &mmu_interval_notifier,211* and &shrinker. For modesetting drivers there's the commit tail functions212* between when fences for an atomic modeset are published, and when the213* corresponding vblank completes, including any interrupt processing and214* related workers. Auditing all that code, across all drivers, is not215* feasible.216*217* * Due to how many other subsystems are involved and the locking hierarchies218* this pulls in there is extremely thin wiggle-room for driver-specific219* differences. &dma_fence interacts with almost all of the core memory220* handling through page fault handlers via &dma_resv, dma_resv_lock() and221* dma_resv_unlock(). On the other side it also interacts through all222* allocation sites through &mmu_notifier and &shrinker.223*224* Furthermore lockdep does not handle cross-release dependencies, which means225* any deadlocks between dma_fence_wait() and dma_fence_signal() can't be caught226* at runtime with some quick testing. The simplest example is one thread227* waiting on a &dma_fence while holding a lock::228*229* lock(A);230* dma_fence_wait(B);231* unlock(A);232*233* while the other thread is stuck trying to acquire the same lock, which234* prevents it from signalling the fence the previous thread is stuck waiting235* on::236*237* lock(A);238* unlock(A);239* dma_fence_signal(B);240*241* By manually annotating all code relevant to signalling a &dma_fence we can242* teach lockdep about these dependencies, which also helps with the validation243* headache since now lockdep can check all the rules for us::244*245* cookie = dma_fence_begin_signalling();246* lock(A);247* unlock(A);248* dma_fence_signal(B);249* dma_fence_end_signalling(cookie);250*251* For using dma_fence_begin_signalling() and dma_fence_end_signalling() to252* annotate critical sections the following rules need to be observed:253*254* * All code necessary to complete a &dma_fence must be annotated, from the255* point where a fence is accessible to other threads, to the point where256* dma_fence_signal() is called. Un-annotated code can contain deadlock issues,257* and due to the very strict rules and many corner cases it is infeasible to258* catch these just with review or normal stress testing.259*260* * &struct dma_resv deserves a special note, since the readers are only261* protected by rcu. This means the signalling critical section starts as soon262* as the new fences are installed, even before dma_resv_unlock() is called.263*264* * The only exception are fast paths and opportunistic signalling code, which265* calls dma_fence_signal() purely as an optimization, but is not required to266* guarantee completion of a &dma_fence. The usual example is a wait IOCTL267* which calls dma_fence_signal(), while the mandatory completion path goes268* through a hardware interrupt and possible job completion worker.269*270* * To aid composability of code, the annotations can be freely nested, as long271* as the overall locking hierarchy is consistent. The annotations also work272* both in interrupt and process context. Due to implementation details this273* requires that callers pass an opaque cookie from274* dma_fence_begin_signalling() to dma_fence_end_signalling().275*276* * Validation against the cross driver contract is implemented by priming277* lockdep with the relevant hierarchy at boot-up. This means even just278* testing with a single device is enough to validate a driver, at least as279* far as deadlocks with dma_fence_wait() against dma_fence_signal() are280* concerned.281*/282#ifdef CONFIG_LOCKDEP283static struct lockdep_map dma_fence_lockdep_map = {284.name = "dma_fence_map"285};286287/**288* dma_fence_begin_signalling - begin a critical DMA fence signalling section289*290* Drivers should use this to annotate the beginning of any code section291* required to eventually complete &dma_fence by calling dma_fence_signal().292*293* The end of these critical sections are annotated with294* dma_fence_end_signalling().295*296* Returns:297*298* Opaque cookie needed by the implementation, which needs to be passed to299* dma_fence_end_signalling().300*/301bool dma_fence_begin_signalling(void)302{303/* explicitly nesting ... */304if (lock_is_held_type(&dma_fence_lockdep_map, 1))305return true;306307/* rely on might_sleep check for soft/hardirq locks */308if (in_atomic())309return true;310311/* ... and non-recursive successful read_trylock */312lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _RET_IP_);313314return false;315}316EXPORT_SYMBOL(dma_fence_begin_signalling);317318/**319* dma_fence_end_signalling - end a critical DMA fence signalling section320* @cookie: opaque cookie from dma_fence_begin_signalling()321*322* Closes a critical section annotation opened by dma_fence_begin_signalling().323*/324void dma_fence_end_signalling(bool cookie)325{326if (cookie)327return;328329lock_release(&dma_fence_lockdep_map, _RET_IP_);330}331EXPORT_SYMBOL(dma_fence_end_signalling);332333void __dma_fence_might_wait(void)334{335bool tmp;336337tmp = lock_is_held_type(&dma_fence_lockdep_map, 1);338if (tmp)339lock_release(&dma_fence_lockdep_map, _THIS_IP_);340lock_map_acquire(&dma_fence_lockdep_map);341lock_map_release(&dma_fence_lockdep_map);342if (tmp)343lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _THIS_IP_);344}345#endif346347348/**349* dma_fence_signal_timestamp_locked - signal completion of a fence350* @fence: the fence to signal351* @timestamp: fence signal timestamp in kernel's CLOCK_MONOTONIC time domain352*353* Signal completion for software callbacks on a fence, this will unblock354* dma_fence_wait() calls and run all the callbacks added with355* dma_fence_add_callback(). Can be called multiple times, but since a fence356* can only go from the unsignaled to the signaled state and not back, it will357* only be effective the first time. Set the timestamp provided as the fence358* signal timestamp.359*360* Unlike dma_fence_signal_timestamp(), this function must be called with361* &dma_fence.lock held.362*363* Returns 0 on success and a negative error value when @fence has been364* signalled already.365*/366int dma_fence_signal_timestamp_locked(struct dma_fence *fence,367ktime_t timestamp)368{369struct dma_fence_cb *cur, *tmp;370struct list_head cb_list;371372lockdep_assert_held(fence->lock);373374if (unlikely(test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT,375&fence->flags)))376return -EINVAL;377378/* Stash the cb_list before replacing it with the timestamp */379list_replace(&fence->cb_list, &cb_list);380381fence->timestamp = timestamp;382set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);383trace_dma_fence_signaled(fence);384385list_for_each_entry_safe(cur, tmp, &cb_list, node) {386INIT_LIST_HEAD(&cur->node);387cur->func(fence, cur);388}389390return 0;391}392EXPORT_SYMBOL(dma_fence_signal_timestamp_locked);393394/**395* dma_fence_signal_timestamp - signal completion of a fence396* @fence: the fence to signal397* @timestamp: fence signal timestamp in kernel's CLOCK_MONOTONIC time domain398*399* Signal completion for software callbacks on a fence, this will unblock400* dma_fence_wait() calls and run all the callbacks added with401* dma_fence_add_callback(). Can be called multiple times, but since a fence402* can only go from the unsignaled to the signaled state and not back, it will403* only be effective the first time. Set the timestamp provided as the fence404* signal timestamp.405*406* Returns 0 on success and a negative error value when @fence has been407* signalled already.408*/409int dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp)410{411unsigned long flags;412int ret;413414if (WARN_ON(!fence))415return -EINVAL;416417spin_lock_irqsave(fence->lock, flags);418ret = dma_fence_signal_timestamp_locked(fence, timestamp);419spin_unlock_irqrestore(fence->lock, flags);420421return ret;422}423EXPORT_SYMBOL(dma_fence_signal_timestamp);424425/**426* dma_fence_signal_locked - signal completion of a fence427* @fence: the fence to signal428*429* Signal completion for software callbacks on a fence, this will unblock430* dma_fence_wait() calls and run all the callbacks added with431* dma_fence_add_callback(). Can be called multiple times, but since a fence432* can only go from the unsignaled to the signaled state and not back, it will433* only be effective the first time.434*435* Unlike dma_fence_signal(), this function must be called with &dma_fence.lock436* held.437*438* Returns 0 on success and a negative error value when @fence has been439* signalled already.440*/441int dma_fence_signal_locked(struct dma_fence *fence)442{443return dma_fence_signal_timestamp_locked(fence, ktime_get());444}445EXPORT_SYMBOL(dma_fence_signal_locked);446447/**448* dma_fence_signal - signal completion of a fence449* @fence: the fence to signal450*451* Signal completion for software callbacks on a fence, this will unblock452* dma_fence_wait() calls and run all the callbacks added with453* dma_fence_add_callback(). Can be called multiple times, but since a fence454* can only go from the unsignaled to the signaled state and not back, it will455* only be effective the first time.456*457* Returns 0 on success and a negative error value when @fence has been458* signalled already.459*/460int dma_fence_signal(struct dma_fence *fence)461{462unsigned long flags;463int ret;464bool tmp;465466if (WARN_ON(!fence))467return -EINVAL;468469tmp = dma_fence_begin_signalling();470471spin_lock_irqsave(fence->lock, flags);472ret = dma_fence_signal_timestamp_locked(fence, ktime_get());473spin_unlock_irqrestore(fence->lock, flags);474475dma_fence_end_signalling(tmp);476477return ret;478}479EXPORT_SYMBOL(dma_fence_signal);480481/**482* dma_fence_wait_timeout - sleep until the fence gets signaled483* or until timeout elapses484* @fence: the fence to wait on485* @intr: if true, do an interruptible wait486* @timeout: timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT487*488* Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or the489* remaining timeout in jiffies on success. Other error values may be490* returned on custom implementations.491*492* Performs a synchronous wait on this fence. It is assumed the caller493* directly or indirectly (buf-mgr between reservation and committing)494* holds a reference to the fence, otherwise the fence might be495* freed before return, resulting in undefined behavior.496*497* See also dma_fence_wait() and dma_fence_wait_any_timeout().498*/499signed long500dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout)501{502signed long ret;503504if (WARN_ON(timeout < 0))505return -EINVAL;506507might_sleep();508509__dma_fence_might_wait();510511dma_fence_enable_sw_signaling(fence);512513if (trace_dma_fence_wait_start_enabled()) {514rcu_read_lock();515trace_dma_fence_wait_start(fence);516rcu_read_unlock();517}518if (fence->ops->wait)519ret = fence->ops->wait(fence, intr, timeout);520else521ret = dma_fence_default_wait(fence, intr, timeout);522if (trace_dma_fence_wait_end_enabled()) {523rcu_read_lock();524trace_dma_fence_wait_end(fence);525rcu_read_unlock();526}527return ret;528}529EXPORT_SYMBOL(dma_fence_wait_timeout);530531/**532* dma_fence_release - default release function for fences533* @kref: &dma_fence.recfount534*535* This is the default release functions for &dma_fence. Drivers shouldn't call536* this directly, but instead call dma_fence_put().537*/538void dma_fence_release(struct kref *kref)539{540struct dma_fence *fence =541container_of(kref, struct dma_fence, refcount);542543rcu_read_lock();544trace_dma_fence_destroy(fence);545546if (!list_empty(&fence->cb_list) &&547!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {548const char __rcu *timeline;549const char __rcu *driver;550unsigned long flags;551552driver = dma_fence_driver_name(fence);553timeline = dma_fence_timeline_name(fence);554555WARN(1,556"Fence %s:%s:%llx:%llx released with pending signals!\n",557rcu_dereference(driver), rcu_dereference(timeline),558fence->context, fence->seqno);559560/*561* Failed to signal before release, likely a refcounting issue.562*563* This should never happen, but if it does make sure that we564* don't leave chains dangling. We set the error flag first565* so that the callbacks know this signal is due to an error.566*/567spin_lock_irqsave(fence->lock, flags);568fence->error = -EDEADLK;569dma_fence_signal_locked(fence);570spin_unlock_irqrestore(fence->lock, flags);571}572573rcu_read_unlock();574575if (fence->ops->release)576fence->ops->release(fence);577else578dma_fence_free(fence);579}580EXPORT_SYMBOL(dma_fence_release);581582/**583* dma_fence_free - default release function for &dma_fence.584* @fence: fence to release585*586* This is the default implementation for &dma_fence_ops.release. It calls587* kfree_rcu() on @fence.588*/589void dma_fence_free(struct dma_fence *fence)590{591kfree_rcu(fence, rcu);592}593EXPORT_SYMBOL(dma_fence_free);594595static bool __dma_fence_enable_signaling(struct dma_fence *fence)596{597bool was_set;598599lockdep_assert_held(fence->lock);600601was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,602&fence->flags);603604if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))605return false;606607if (!was_set && fence->ops->enable_signaling) {608trace_dma_fence_enable_signal(fence);609610if (!fence->ops->enable_signaling(fence)) {611dma_fence_signal_locked(fence);612return false;613}614}615616return true;617}618619/**620* dma_fence_enable_sw_signaling - enable signaling on fence621* @fence: the fence to enable622*623* This will request for sw signaling to be enabled, to make the fence624* complete as soon as possible. This calls &dma_fence_ops.enable_signaling625* internally.626*/627void dma_fence_enable_sw_signaling(struct dma_fence *fence)628{629unsigned long flags;630631spin_lock_irqsave(fence->lock, flags);632__dma_fence_enable_signaling(fence);633spin_unlock_irqrestore(fence->lock, flags);634}635EXPORT_SYMBOL(dma_fence_enable_sw_signaling);636637/**638* dma_fence_add_callback - add a callback to be called when the fence639* is signaled640* @fence: the fence to wait on641* @cb: the callback to register642* @func: the function to call643*644* Add a software callback to the fence. The caller should keep a reference to645* the fence.646*647* @cb will be initialized by dma_fence_add_callback(), no initialization648* by the caller is required. Any number of callbacks can be registered649* to a fence, but a callback can only be registered to one fence at a time.650*651* If fence is already signaled, this function will return -ENOENT (and652* *not* call the callback).653*654* Note that the callback can be called from an atomic context or irq context.655*656* Returns 0 in case of success, -ENOENT if the fence is already signaled657* and -EINVAL in case of error.658*/659int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,660dma_fence_func_t func)661{662unsigned long flags;663int ret = 0;664665if (WARN_ON(!fence || !func))666return -EINVAL;667668if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {669INIT_LIST_HEAD(&cb->node);670return -ENOENT;671}672673spin_lock_irqsave(fence->lock, flags);674675if (__dma_fence_enable_signaling(fence)) {676cb->func = func;677list_add_tail(&cb->node, &fence->cb_list);678} else {679INIT_LIST_HEAD(&cb->node);680ret = -ENOENT;681}682683spin_unlock_irqrestore(fence->lock, flags);684685return ret;686}687EXPORT_SYMBOL(dma_fence_add_callback);688689/**690* dma_fence_get_status - returns the status upon completion691* @fence: the dma_fence to query692*693* This wraps dma_fence_get_status_locked() to return the error status694* condition on a signaled fence. See dma_fence_get_status_locked() for more695* details.696*697* Returns 0 if the fence has not yet been signaled, 1 if the fence has698* been signaled without an error condition, or a negative error code699* if the fence has been completed in err.700*/701int dma_fence_get_status(struct dma_fence *fence)702{703unsigned long flags;704int status;705706spin_lock_irqsave(fence->lock, flags);707status = dma_fence_get_status_locked(fence);708spin_unlock_irqrestore(fence->lock, flags);709710return status;711}712EXPORT_SYMBOL(dma_fence_get_status);713714/**715* dma_fence_remove_callback - remove a callback from the signaling list716* @fence: the fence to wait on717* @cb: the callback to remove718*719* Remove a previously queued callback from the fence. This function returns720* true if the callback is successfully removed, or false if the fence has721* already been signaled.722*723* *WARNING*:724* Cancelling a callback should only be done if you really know what you're725* doing, since deadlocks and race conditions could occur all too easily. For726* this reason, it should only ever be done on hardware lockup recovery,727* with a reference held to the fence.728*729* Behaviour is undefined if @cb has not been added to @fence using730* dma_fence_add_callback() beforehand.731*/732bool733dma_fence_remove_callback(struct dma_fence *fence, struct dma_fence_cb *cb)734{735unsigned long flags;736bool ret;737738spin_lock_irqsave(fence->lock, flags);739740ret = !list_empty(&cb->node);741if (ret)742list_del_init(&cb->node);743744spin_unlock_irqrestore(fence->lock, flags);745746return ret;747}748EXPORT_SYMBOL(dma_fence_remove_callback);749750struct default_wait_cb {751struct dma_fence_cb base;752struct task_struct *task;753};754755static void756dma_fence_default_wait_cb(struct dma_fence *fence, struct dma_fence_cb *cb)757{758struct default_wait_cb *wait =759container_of(cb, struct default_wait_cb, base);760761wake_up_state(wait->task, TASK_NORMAL);762}763764/**765* dma_fence_default_wait - default sleep until the fence gets signaled766* or until timeout elapses767* @fence: the fence to wait on768* @intr: if true, do an interruptible wait769* @timeout: timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT770*771* Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or the772* remaining timeout in jiffies on success. If timeout is zero the value one is773* returned if the fence is already signaled for consistency with other774* functions taking a jiffies timeout.775*/776signed long777dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout)778{779struct default_wait_cb cb;780unsigned long flags;781signed long ret = timeout ? timeout : 1;782783spin_lock_irqsave(fence->lock, flags);784785if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))786goto out;787788if (intr && signal_pending(current)) {789ret = -ERESTARTSYS;790goto out;791}792793if (!timeout) {794ret = 0;795goto out;796}797798cb.base.func = dma_fence_default_wait_cb;799cb.task = current;800list_add(&cb.base.node, &fence->cb_list);801802while (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) && ret > 0) {803if (intr)804__set_current_state(TASK_INTERRUPTIBLE);805else806__set_current_state(TASK_UNINTERRUPTIBLE);807spin_unlock_irqrestore(fence->lock, flags);808809ret = schedule_timeout(ret);810811spin_lock_irqsave(fence->lock, flags);812if (ret > 0 && intr && signal_pending(current))813ret = -ERESTARTSYS;814}815816if (!list_empty(&cb.base.node))817list_del(&cb.base.node);818__set_current_state(TASK_RUNNING);819820out:821spin_unlock_irqrestore(fence->lock, flags);822return ret;823}824EXPORT_SYMBOL(dma_fence_default_wait);825826static bool827dma_fence_test_signaled_any(struct dma_fence **fences, uint32_t count,828uint32_t *idx)829{830int i;831832for (i = 0; i < count; ++i) {833struct dma_fence *fence = fences[i];834if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {835if (idx)836*idx = i;837return true;838}839}840return false;841}842843/**844* dma_fence_wait_any_timeout - sleep until any fence gets signaled845* or until timeout elapses846* @fences: array of fences to wait on847* @count: number of fences to wait on848* @intr: if true, do an interruptible wait849* @timeout: timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT850* @idx: used to store the first signaled fence index, meaningful only on851* positive return852*853* Returns -EINVAL on custom fence wait implementation, -ERESTARTSYS if854* interrupted, 0 if the wait timed out, or the remaining timeout in jiffies855* on success.856*857* Synchronous waits for the first fence in the array to be signaled. The858* caller needs to hold a reference to all fences in the array, otherwise a859* fence might be freed before return, resulting in undefined behavior.860*861* See also dma_fence_wait() and dma_fence_wait_timeout().862*/863signed long864dma_fence_wait_any_timeout(struct dma_fence **fences, uint32_t count,865bool intr, signed long timeout, uint32_t *idx)866{867struct default_wait_cb *cb;868signed long ret = timeout;869unsigned i;870871if (WARN_ON(!fences || !count || timeout < 0))872return -EINVAL;873874if (timeout == 0) {875for (i = 0; i < count; ++i)876if (dma_fence_is_signaled(fences[i])) {877if (idx)878*idx = i;879return 1;880}881882return 0;883}884885cb = kcalloc(count, sizeof(struct default_wait_cb), GFP_KERNEL);886if (cb == NULL) {887ret = -ENOMEM;888goto err_free_cb;889}890891for (i = 0; i < count; ++i) {892struct dma_fence *fence = fences[i];893894cb[i].task = current;895if (dma_fence_add_callback(fence, &cb[i].base,896dma_fence_default_wait_cb)) {897/* This fence is already signaled */898if (idx)899*idx = i;900goto fence_rm_cb;901}902}903904while (ret > 0) {905if (intr)906set_current_state(TASK_INTERRUPTIBLE);907else908set_current_state(TASK_UNINTERRUPTIBLE);909910if (dma_fence_test_signaled_any(fences, count, idx))911break;912913ret = schedule_timeout(ret);914915if (ret > 0 && intr && signal_pending(current))916ret = -ERESTARTSYS;917}918919__set_current_state(TASK_RUNNING);920921fence_rm_cb:922while (i-- > 0)923dma_fence_remove_callback(fences[i], &cb[i].base);924925err_free_cb:926kfree(cb);927928return ret;929}930EXPORT_SYMBOL(dma_fence_wait_any_timeout);931932/**933* DOC: deadline hints934*935* In an ideal world, it would be possible to pipeline a workload sufficiently936* that a utilization based device frequency governor could arrive at a minimum937* frequency that meets the requirements of the use-case, in order to minimize938* power consumption. But in the real world there are many workloads which939* defy this ideal. For example, but not limited to:940*941* * Workloads that ping-pong between device and CPU, with alternating periods942* of CPU waiting for device, and device waiting on CPU. This can result in943* devfreq and cpufreq seeing idle time in their respective domains and in944* result reduce frequency.945*946* * Workloads that interact with a periodic time based deadline, such as double947* buffered GPU rendering vs vblank sync'd page flipping. In this scenario,948* missing a vblank deadline results in an *increase* in idle time on the GPU949* (since it has to wait an additional vblank period), sending a signal to950* the GPU's devfreq to reduce frequency, when in fact the opposite is what is951* needed.952*953* To this end, deadline hint(s) can be set on a &dma_fence via &dma_fence_set_deadline954* (or indirectly via userspace facing ioctls like &sync_set_deadline).955* The deadline hint provides a way for the waiting driver, or userspace, to956* convey an appropriate sense of urgency to the signaling driver.957*958* A deadline hint is given in absolute ktime (CLOCK_MONOTONIC for userspace959* facing APIs). The time could either be some point in the future (such as960* the vblank based deadline for page-flipping, or the start of a compositor's961* composition cycle), or the current time to indicate an immediate deadline962* hint (Ie. forward progress cannot be made until this fence is signaled).963*964* Multiple deadlines may be set on a given fence, even in parallel. See the965* documentation for &dma_fence_ops.set_deadline.966*967* The deadline hint is just that, a hint. The driver that created the fence968* may react by increasing frequency, making different scheduling choices, etc.969* Or doing nothing at all.970*/971972/**973* dma_fence_set_deadline - set desired fence-wait deadline hint974* @fence: the fence that is to be waited on975* @deadline: the time by which the waiter hopes for the fence to be976* signaled977*978* Give the fence signaler a hint about an upcoming deadline, such as979* vblank, by which point the waiter would prefer the fence to be980* signaled by. This is intended to give feedback to the fence signaler981* to aid in power management decisions, such as boosting GPU frequency982* if a periodic vblank deadline is approaching but the fence is not983* yet signaled..984*/985void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)986{987if (fence->ops->set_deadline && !dma_fence_is_signaled(fence))988fence->ops->set_deadline(fence, deadline);989}990EXPORT_SYMBOL(dma_fence_set_deadline);991992/**993* dma_fence_describe - Dump fence description into seq_file994* @fence: the fence to describe995* @seq: the seq_file to put the textual description into996*997* Dump a textual description of the fence and it's state into the seq_file.998*/999void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq)1000{1001const char __rcu *timeline;1002const char __rcu *driver;10031004rcu_read_lock();10051006timeline = dma_fence_timeline_name(fence);1007driver = dma_fence_driver_name(fence);10081009seq_printf(seq, "%s %s seq %llu %ssignalled\n",1010rcu_dereference(driver),1011rcu_dereference(timeline),1012fence->seqno,1013dma_fence_is_signaled(fence) ? "" : "un");10141015rcu_read_unlock();1016}1017EXPORT_SYMBOL(dma_fence_describe);10181019static void1020__dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,1021spinlock_t *lock, u64 context, u64 seqno, unsigned long flags)1022{1023BUG_ON(!lock);1024BUG_ON(!ops || !ops->get_driver_name || !ops->get_timeline_name);10251026kref_init(&fence->refcount);1027fence->ops = ops;1028INIT_LIST_HEAD(&fence->cb_list);1029fence->lock = lock;1030fence->context = context;1031fence->seqno = seqno;1032fence->flags = flags;1033fence->error = 0;10341035trace_dma_fence_init(fence);1036}10371038/**1039* dma_fence_init - Initialize a custom fence.1040* @fence: the fence to initialize1041* @ops: the dma_fence_ops for operations on this fence1042* @lock: the irqsafe spinlock to use for locking this fence1043* @context: the execution context this fence is run on1044* @seqno: a linear increasing sequence number for this context1045*1046* Initializes an allocated fence, the caller doesn't have to keep its1047* refcount after committing with this fence, but it will need to hold a1048* refcount again if &dma_fence_ops.enable_signaling gets called.1049*1050* context and seqno are used for easy comparison between fences, allowing1051* to check which fence is later by simply using dma_fence_later().1052*/1053void1054dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,1055spinlock_t *lock, u64 context, u64 seqno)1056{1057__dma_fence_init(fence, ops, lock, context, seqno, 0UL);1058}1059EXPORT_SYMBOL(dma_fence_init);10601061/**1062* dma_fence_init64 - Initialize a custom fence with 64-bit seqno support.1063* @fence: the fence to initialize1064* @ops: the dma_fence_ops for operations on this fence1065* @lock: the irqsafe spinlock to use for locking this fence1066* @context: the execution context this fence is run on1067* @seqno: a linear increasing sequence number for this context1068*1069* Initializes an allocated fence, the caller doesn't have to keep its1070* refcount after committing with this fence, but it will need to hold a1071* refcount again if &dma_fence_ops.enable_signaling gets called.1072*1073* Context and seqno are used for easy comparison between fences, allowing1074* to check which fence is later by simply using dma_fence_later().1075*/1076void1077dma_fence_init64(struct dma_fence *fence, const struct dma_fence_ops *ops,1078spinlock_t *lock, u64 context, u64 seqno)1079{1080__dma_fence_init(fence, ops, lock, context, seqno,1081BIT(DMA_FENCE_FLAG_SEQNO64_BIT));1082}1083EXPORT_SYMBOL(dma_fence_init64);10841085/**1086* dma_fence_driver_name - Access the driver name1087* @fence: the fence to query1088*1089* Returns a driver name backing the dma-fence implementation.1090*1091* IMPORTANT CONSIDERATION:1092* Dma-fence contract stipulates that access to driver provided data (data not1093* directly embedded into the object itself), such as the &dma_fence.lock and1094* memory potentially accessed by the &dma_fence.ops functions, is forbidden1095* after the fence has been signalled. Drivers are allowed to free that data,1096* and some do.1097*1098* To allow safe access drivers are mandated to guarantee a RCU grace period1099* between signalling the fence and freeing said data.1100*1101* As such access to the driver name is only valid inside a RCU locked section.1102* The pointer MUST be both queried and USED ONLY WITHIN a SINGLE block guarded1103* by the &rcu_read_lock and &rcu_read_unlock pair.1104*/1105const char __rcu *dma_fence_driver_name(struct dma_fence *fence)1106{1107RCU_LOCKDEP_WARN(!rcu_read_lock_held(),1108"RCU protection is required for safe access to returned string");11091110if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))1111return fence->ops->get_driver_name(fence);1112else1113return "detached-driver";1114}1115EXPORT_SYMBOL(dma_fence_driver_name);11161117/**1118* dma_fence_timeline_name - Access the timeline name1119* @fence: the fence to query1120*1121* Returns a timeline name provided by the dma-fence implementation.1122*1123* IMPORTANT CONSIDERATION:1124* Dma-fence contract stipulates that access to driver provided data (data not1125* directly embedded into the object itself), such as the &dma_fence.lock and1126* memory potentially accessed by the &dma_fence.ops functions, is forbidden1127* after the fence has been signalled. Drivers are allowed to free that data,1128* and some do.1129*1130* To allow safe access drivers are mandated to guarantee a RCU grace period1131* between signalling the fence and freeing said data.1132*1133* As such access to the driver name is only valid inside a RCU locked section.1134* The pointer MUST be both queried and USED ONLY WITHIN a SINGLE block guarded1135* by the &rcu_read_lock and &rcu_read_unlock pair.1136*/1137const char __rcu *dma_fence_timeline_name(struct dma_fence *fence)1138{1139RCU_LOCKDEP_WARN(!rcu_read_lock_held(),1140"RCU protection is required for safe access to returned string");11411142if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))1143return fence->ops->get_driver_name(fence);1144else1145return "signaled-timeline";1146}1147EXPORT_SYMBOL(dma_fence_timeline_name);114811491150