[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