On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
From: Rob Clark robdclark@chromium.org
missing some wording here...
v2: rebase
Signed-off-by: Rob Clark robdclark@chromium.org
drivers/gpu/drm/i915/i915_request.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 7503dcb9043b..44491e7e214c 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence *fence) return i915_request_enable_breadcrumb(to_request(fence)); } +static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) +{
- struct i915_request *rq = to_request(fence);
- if (i915_request_completed(rq))
return;- if (i915_request_started(rq))
return;
why do we skip the boost if already started? don't we want to boost the freq anyway?
- /*
* TODO something more clever for deadlines that are in the* future. I think probably track the nearest deadline in* rq->timeline and set timer to trigger boost accordingly?*/
I'm afraid it will be very hard to find some heuristics of what's late enough for the boost no? I mean, how early to boost the freq on an upcoming deadline for the timer?
- intel_rps_boost(rq);
+}
static signed long i915_fence_wait(struct dma_fence *fence, bool interruptible, signed long timeout) @@ -182,6 +201,7 @@ const struct dma_fence_ops i915_fence_ops = { .signaled = i915_fence_signaled, .wait = i915_fence_wait, .release = i915_fence_release,
- .set_deadline = i915_fence_set_deadline,
}; static void irq_execute_cb(struct irq_work *wrk) -- 2.39.1