Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
> We have two trace messages that rely on the function name for
> distinction. However, if gcc inlines the function, the two traces end up
> with the same function name and are indistinguishable. Add a different
> message to each to clarify which one we hit, i.e. which phase of engine
> parking we are processing.
>
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index ea90ab3e396e..b6cf284e3a2d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -112,7 +112,7 @@ __queue_and_release_pm(struct i915_request *rq,
> {
> struct intel_gt_timelines *timelines = &engine->gt->timelines;
>
> - ENGINE_TRACE(engine, "\n");
> + ENGINE_TRACE(engine, "parking\n");
>
> /*
> * We have to serialise all potential retirement paths with our
> @@ -249,7 +249,7 @@ static int __engine_park(struct intel_wakeref *wf)
> if (!switch_to_kernel_context(engine))
> return -EBUSY;
>
> - ENGINE_TRACE(engine, "\n");
> + ENGINE_TRACE(engine, "parked\n");
Reading the functions, the exact spots are a mystery for me still
as of why in these exact lines. Like the 'parked' would mean it
is parked already, which it seems not to.
However, what comes to the commit message and to
immediate problem and fixing it,
Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
>
> call_idle_barriers(engine); /* cleanup after wedging */
>
> --
> 2.25.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
