On 9/22/26 18:57, Jeffrey Boody wrote:

The set_deadline callback is currently skipped if the fence has already been signaled. This prevents GPU drivers from performing power management adjustments when the deadline hint arrives after fence completion.

In triple-buffered rendering, a staged frame may be completed well ahead of the vblank deadline. When a display driver delivers the deadline hint, the fence has already been signaled and the callback is silently dropped. This leaves the GPU driver unable to evaluate the headroom between the fence signal time and the vblank deadline, and therefore unable to reduce GPU frequency when the target headroom is exceeded.

Remove the dma_fence_is_signaled() guard from dma_fence_set_deadline() so that the callback is invoked unconditionally when ops->set_deadline is present. Implementations of set_deadline must already tolerate concurrent and repeated calls; handling a post-signal invocation requires no additional locking. The fence signaler can compare the fence signal time against the supplied deadline to determine whether frequency scaling is warranted.

Sorry but I have to clearly reject that patch.

No callback whatsoever is allowed to be used after the fence has signaled or otherwise we break module unloading for the originator of the fence.

So that approach you want to have here simply doesn't work at all.

Regards, Christian.

Signed-off-by: Jeffrey Boody jeffrey.boody@oss.qualcomm.com

Signed-off-by: Jeff Boody jeffrey.boody@oss.qualcomm.com

drivers/dma-buf/dma-fence.c | 22 ++++++++++++++++++++-- drivers/gpu/drm/msm/msm_fence.c | 3 +++ include/linux/dma-fence.h | 11 ++++++++++- 3 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index bd58688b81a7..ebc7c5ca6f69 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -999,8 +999,19 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout);

• Multiple deadlines may be set on a given fence, even in parallel. See the
• documentation for &dma_fence_ops.set_deadline.

• • The deadline hint may also be delivered *after* the fence has already been
• • signaled. This is intentional and supports the case where a fence signaler
• • aware of a periodic deadline (e.g. vblank) and the fence's signal time can
• • evaluate the headroom between the two. In triple-buffered rendering, for
• • example, a staged frame that is completed well ahead of the vblank deadline
• • represents excess headroom; delivering the deadline hint post-signal allows
• • the fence signaler to consider reducing frequency for subsequent workloads,
• • rather than holding an unnecessarily high frequency. Implementations
• • of &dma_fence_ops.set_deadline must therefore tolerate invocation on
• • already-signaled fences.
• • The deadline hint is just that, a hint. The driver that created the fence

• • may react by increasing frequency, making different scheduling choices, etc.

• • may react by changing frequency, making different scheduling choices, etc.
  • Or doing nothing at all.
  */

@@ -1016,6 +1027,13 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout);

• to aid in power management decisions, such as boosting GPU frequency
• if a periodic vblank deadline is approaching but the fence is not
• yet signaled..

• • This function may also be called after the fence has already been
• • signaled. In that case the fence signaler can compare the fence's signal
• • time against the deadline to determine the available headroom. If the
• • fence was signaled significantly ahead of the deadline, the fence
• • signaler may choose to reduce frequency for subsequent workloads to
• • avoid unnecessarily high power consumption.
  */

void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) { @@ -1023,7 +1041,7 @@ void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)

    rcu_read_lock();
    ops = rcu_dereference(fence->ops);

•   if (ops && ops->set_deadline && !dma_fence_is_signaled(fence))
  

•   if (ops && ops->set_deadline)
            ops->set_deadline(fence, deadline);
    rcu_read_unlock();
  

} diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c index 3dca8e09c192..3c5de96d4092 100644 --- a/drivers/gpu/drm/msm/msm_fence.c +++ b/drivers/gpu/drm/msm/msm_fence.c @@ -136,6 +136,9 @@ static void msm_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) unsigned long flags; ktime_t now;

•   if (dma_fence_is_signaled(fence))
  

•           return;
  

•   spin_lock_irqsave(&fctx->spinlock, flags);
    now = ktime_get();
  
  

diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index ffa99b930843..839ef2e5dad9 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -264,7 +264,16 @@ struct dma_fence_ops { * 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.
  

•    * decisions, such as boosting GPU frequency if the deadline has
  

•    * not yet been met, or reducing GPU frequency if the fence was
  

•    * signaled significantly ahead of the deadline.
  

•    *
  

•    * This callback may be invoked even after the fence has been
  

•    * signaled.  In this case, the signaler may use the deadline and
  

•    * the fence's signal time to evaluate whether the GPU frequency
  

•    * should be adjusted for future workloads.  Implementations must
  

•    * therefore be prepared to handle calls on already-signaled fences
  

•    * without error.
     *
     * This is called without &dma_fence.lock held, it can be called
     * multiple times and from any context.  Locking is up to the callee
  
  

---

base-commit: f0100363d8c374bd8e9ea7c9ba02744f0b802ca4 change-id: 20260917-dma-fence-set-deadline-a778746e9abd

Best regards,

Jeff Boody jeffrey.boody@oss.qualcomm.com