Re: [PATCH v2] dma-fence: deliver set_deadline callback even if fence is already signaled

[Jeffrey Boody <jeffrey.boody@oss.qualcomm.com>]

Hi Christian,

I apologize for missing this issue and will follow up if we can find 
another approach.

Thank you for reviewing the change,

Jeff

On 9/23/2026 1:35 AM, Christian König wrote:
> 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>
>>