[Intel-gfx] [PATCH v8 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

Andi Shyti andi.shyti at linux.intel.com
Mon Jul 24 09:16:53 UTC 2023


Hi Nirmoy,

>      static int mtl_dummy_pipe_control(struct i915_request *rq)
>      {
>             /* Wa_14016712196 */
>             if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
>     -           IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
>     -               u32 *cs;
>     -
>     -               /* dummy PIPE_CONTROL + depth flush */
>     -               cs = intel_ring_begin(rq, 6);
>     -               if (IS_ERR(cs))
>     -                       return PTR_ERR(cs);
>     -               cs = gen12_emit_pipe_control(cs,
>     -                                            0,
>     -                                            PIPE_CONTROL_DEPTH_CACHE_FLUSH,
>     -                                            LRC_PPHWSP_SCRATCH_ADDR);
>     -               intel_ring_advance(rq, cs);
>     -       }
>     +           IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0))
>     +               return gen12_emit_pipe_control_cs(rq, 0,
>     +                                       PIPE_CONTROL_DEPTH_CACHE_FLUSH,
>     +                                       LRC_PPHWSP_SCRATCH_ADDR);
> 
> Don't think this will get backported to 5.8+. I think mtl introduced after
> that.
> 
> If that is not an issue for rest of the series and then

to be honest I don't think I fully understood the stable
policies, as in this series only two are the patches that are
really fixing things and the rest are only support.

In this case I think this will produce a conflict that will be
eventually fixed (... I guess!).

> Reviewed-by: Nirmoy Das <nirmoy.das at intel.com>

Thanks,
Andi


More information about the Intel-gfx mailing list