[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Add workaround 14016712196
== Series Details == Series: drm/i915/gt: Add workaround 14016712196 URL : https://patchwork.freedesktop.org/series/117661/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M] drivers/gpu/drm/i915/gt/gen8_engine_cs.o drivers/gpu/drm/i915/gt/gen8_engine_cs.c:180:5: error: no previous prototype for ‘mtl_dummy_pipe_control’ [-Werror=missing-prototypes] 180 | int mtl_dummy_pipe_control(struct i915_request *rq, u32 *cs) | ^~ cc1: all warnings being treated as errors make[5]: *** [scripts/Makefile.build:252: drivers/gpu/drm/i915/gt/gen8_engine_cs.o] Error 1 make[4]: *** [scripts/Makefile.build:494: drivers/gpu/drm/i915] Error 2 make[3]: *** [scripts/Makefile.build:494: drivers/gpu/drm] Error 2 make[2]: *** [scripts/Makefile.build:494: drivers/gpu] Error 2 make[1]: *** [scripts/Makefile.build:494: drivers] Error 2 make: *** [Makefile:2026: .] Error 2 Build failed, no error log produced
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pxp: Add MTL PXP Support (rev12)
== Series Details ==
Series: drm/i915/pxp: Add MTL PXP Support (rev12)
URL : https://patchwork.freedesktop.org/series/112647/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13139_full -> Patchwork_112647v12_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_112647v12_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_112647v12_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 8)
--
Additional (1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112647v12_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-apl: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13139/shard-apl6/igt@gem_ctx_isolation@preservation...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-apl1/igt@gem_ctx_isolation@preservation...@vcs0.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@flip-vs-panning-vs-hang@a-hdmi-a4:
- {shard-dg1}:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13139/shard-dg1-17/igt@kms_flip@flip-vs-panning-vs-h...@a-hdmi-a4.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-dg1-13/igt@kms_flip@flip-vs-panning-vs-h...@a-hdmi-a4.html
Known issues
Here are the changes found in Patchwork_112647v12_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@smem-oom:
- shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-apl7/igt@gem_lmem_swapp...@smem-oom.html
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-glk3/igt@gem_lmem_swapp...@smem-oom.html
* igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271]) +93 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-apl7/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html
* igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-apl: NOTRUN -> [FAIL][8] ([i915#7036])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-apl7/igt@i915_pipe_str...@stress-xrgb-untiled.html
* igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886]) +4
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-apl7/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3886]) +1
similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-glk3/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_content_protection@uevent@pipe-a-dp-1:
- shard-apl: NOTRUN -> [FAIL][11] ([i915#1339])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-apl6/igt@kms_content_protection@uev...@pipe-a-dp-1.html
*
igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-upscaling@pipe-a-valid-mode:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4579]) +6
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-apl6/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-upscal...@pipe-a-valid-mode.html
*
igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-upscaling@pipe-a-valid-mode:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4579]) +3
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-glk3/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-upscal...@pipe-a-valid-mode.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-mmap-wc:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271]) +38 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/shard-glk3/igt@kms_frontbuffer_track...@psr-2p-primscrn-pri-shrfb-draw-mmap-wc.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#658])
[15]:
[Intel-gfx] [PATCH] drm/i915/gt: Add workaround 14016712196
Wa_14016712196 implementation for mtl
Bspec: 72197
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 38
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index e1c76e5bfa82..2b9691ef1a4a 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -177,14 +177,40 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32
*cs, const i915_reg_t inv
return cs;
}
+int mtl_dummy_pipe_control(struct i915_request *rq, u32 *cs)
+{
+ struct intel_engine_cs *engine = rq->engine;
+
+ if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+ IS_MTL_GRAPHICS_STEP(engine->i915, P, STEP_A0, STEP_B0)) {
+ /* 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);
+ }
+
+ return 0;
+}
+
int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
{
struct intel_engine_cs *engine = rq->engine;
+ int err;
if (mode & EMIT_FLUSH) {
u32 flags = 0;
u32 *cs;
+ /* Wa_14016712196 */
+ err = mtl_dummy_pipe_control(rq, cs);
+ if (err)
+ return err;
+
flags |= PIPE_CONTROL_TILE_CACHE_FLUSH;
flags |= PIPE_CONTROL_FLUSH_L3;
flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
@@ -218,6 +244,11 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
u32 flags = 0;
u32 *cs, count;
+ /* Wa_14016712196 */
+ err = mtl_dummy_pipe_control(rq, cs);
+ if (err)
+ return err;
+
flags |= PIPE_CONTROL_COMMAND_CACHE_INVALIDATE;
flags |= PIPE_CONTROL_TLB_INVALIDATE;
flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
@@ -733,6 +764,13 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request
*rq, u32 *cs)
PIPE_CONTROL_DC_FLUSH_ENABLE |
PIPE_CONTROL_FLUSH_ENABLE);
+ /* Wa_14016712196 */
+ if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
+ IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+ /* dummy PIPE_CONTROL + depth flush */
+ cs = gen12_emit_pipe_control(cs, 0,
+PIPE_CONTROL_DEPTH_CACHE_FLUSH, 0);
+
if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12,
50))
/* Wa_1409600907 */
flags |= PIPE_CONTROL_DEPTH_STALL;
--
2.25.1
Re: [Intel-gfx] [PATCH v2 25/27] KVM: x86/mmu: Drop @slot param from exported/external page-track APIs
> > Hi Sean,
> > After more thoughts, do you think checking KVM internal memslot is
> > necessary?
>
> I don't think it's necessary per se, but I also can't think of any reason to
> allow
> it.
>
> > slot = gfn_to_memslot(kvm, gfn);
> > if (!slot || slot->id >= KVM_USER_MEM_SLOTS) {
> > srcu_read_unlock(>srcu, idx);
> > return -EINVAL;
> > }
> >
> > Do we allow write tracking to APIC access page when APIC-write VM exit
> > is not desired?
>
> Allow? Yes.
>
> But KVM doesn't use write-tracking for anything APICv related, e.g. to disable
> APICv, KVM instead zaps the SPTEs for the APIC access page and on page fault
> goes
> straight to MMIO emulation.
>
> Theoretically, the guest could create an intermediate PTE in the APIC access
> page
> and AFAICT KVM would shadow the access and write-protect the APIC access page.
> But that's benign as the resulting emulation would be handled just like
> emulated
> APIC MMIO.
>
> FWIW, the other internal memslots, TSS and idenity mapped page tables, are
> used
> if and only if paging is disabled in the guest, i.e. there are no guest PTEs
> for
> KVM to shadow (and paging must be enabled to enable VMX, so nested EPT is also
> ruled out). So this is theoretically possible only for the APIC access page.
> That changes with KVMGT, but that again should not be problematic. KVM will
> emulate in response to the write-protected page and things go on. E.g. it's
> arguably much weirder that the guest can read/write the identity mapped page
> tables that are used for EPT without unrestricted guest.
>
> There's no sane reason to allow creating PTEs in the APIC page, but I'm also
> not
> all that motivated to "fix" things. account_shadowed() isn't expected to
> fail,
> so KVM would need to check further up the stack, e.g. in walk_addr_generic()
> by
> open coding a form of kvm_vcpu_gfn_to_hva_prot().
>
> I _think_ that's the only place KVM would need to add a check, as KVM already
> checks that the root, i.e. CR3, is in a "visible" memslot. I suppose KVM
> could
> just synthesize triple fault, like it does for the root/CR3 case, but I don't
> like making up behavior.
>
> In other words, I'm not opposed to disallowing write-tracking internal
> memslots,
> but I can't think of anything that will break, and so for me personally at
> least,
> the ROI isn't sufficient to justify writing tests and dealing with any
> fallout.
It makes sense. Thanks for the explanation.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: drop dependency on VLV_DISPLAY_BASE (rev2)
== Series Details ==
Series: drm/i915/gt: drop dependency on VLV_DISPLAY_BASE (rev2)
URL : https://patchwork.freedesktop.org/series/117620/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13138_full -> Patchwork_117620v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_117620v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][1] -> [ABORT][2] ([i915#5566])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-apl4/igt@gen9_exec_pa...@allowed-single.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-apl1/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2346])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-rkl-7/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-rkl-7/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][7] ([i915#7461] / [i915#8234]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-dg1-18/igt@gem_barrier_race@remote-requ...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-close-race:
- {shard-dg1}:[DMESG-WARN][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-dg1-16/igt@gem_ctx_e...@basic-close-race.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-dg1-14/igt@gem_ctx_e...@basic-close-race.html
* igt@gem_eio@unwedge-stress:
- {shard-tglu}: [TIMEOUT][11] ([i915#3063] / [i915#7941]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-tglu-4/igt@gem_...@unwedge-stress.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-tglu-8/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][13] ([i915#2842]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- {shard-rkl}:[FAIL][15] ([i915#2842]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-rkl-7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-rkl-1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- {shard-tglu}: [FAIL][17] ([i915#2842]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-tglu-9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-tglu-10/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@smem-oom@lmem0:
- {shard-dg1}:[TIMEOUT][19] ([i915#5493]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-dg1-15/igt@gem_lmem_swapping@smem-...@lmem0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-dg1-14/igt@gem_lmem_swapping@smem-...@lmem0.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip:
- {shard-rkl}:[FAIL][21] ([i915#3743]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-rkl-7/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/shard-rkl-7/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: [FAIL][23] ([i915#2346]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Turn off the timer to sample frequencies when GT is parked
== Series Details ==
Series: drm/i915/pmu: Turn off the timer to sample frequencies when GT is parked
URL : https://patchwork.freedesktop.org/series/117658/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13140 -> Patchwork_117658v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/index.html
Participating hosts (41 -> 39)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117658v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [PASS][3] -> [ABORT][4] ([i915#4983] / [i915#7461] /
[i915#7913] / [i915#7981] / [i915#8347])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-rpls-2/igt@i915_selftest@l...@reset.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- bat-atsm-1: [PASS][5] -> [INCOMPLETE][6] ([i915#7913])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-atsm-1/igt@i915_selftest@l...@slpc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-atsm-1/igt@i915_selftest@l...@slpc.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][7] ([i915#3546]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [ABORT][8] ([i915#4579] / [i915#8260])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@i915_selftest@live@gt_engines:
- bat-atsm-1: [FAIL][9] ([i915#6268]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-atsm-1/igt@i915_selftest@live@gt_engines.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-atsm-1/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][11] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-mtlp-6/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@slpc:
- {bat-mtlp-8}: [DMESG-WARN][13] ([i915#6367] / [i915#7953]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-mtlp-8/igt@i915_selftest@l...@slpc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-mtlp-8/igt@i915_selftest@l...@slpc.html
- bat-rpls-1: [DMESG-WARN][15] ([i915#6367] / [i915#7953]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [FAIL][17] ([i915#7932]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
Warnings
* igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: [ABORT][19] -> [SKIP][20] ([i915#1072])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117658v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Fix confused register capture list creation
== Series Details ==
Series: drm/i915/guc: Fix confused register capture list creation
URL : https://patchwork.freedesktop.org/series/117655/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13140 -> Patchwork_117655v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/index.html
Participating hosts (41 -> 29)
--
Missing(12): fi-kbl-soraka fi-kbl-7567u bat-kbl-2 fi-cfl-guc fi-ilk-650
fi-snb-2520m fi-hsw-4770 fi-kbl-x1275 fi-cfl-8109u fi-blb-e6850 bat-jsl-1
fi-skl-6600u
Known issues
Here are the changes found in Patchwork_117655v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][1] ([i915#7077])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html
* igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][2] -> [DMESG-WARN][3] ([i915#7699] /
[i915#7953])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- bat-rpls-2: [PASS][4] -> [DMESG-WARN][5] ([i915#6367])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-rpls-2/igt@i915_selftest@l...@slpc.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [SKIP][6] ([i915#3555] / [i915#4579])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@i915_selftest@live@gt_engines:
- bat-atsm-1: [FAIL][7] ([i915#6268]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-atsm-1/igt@i915_selftest@live@gt_engines.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/bat-atsm-1/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][9] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/bat-mtlp-6/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: [DMESG-WARN][11] ([i915#6367] / [i915#7953]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
Warnings
* igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: [ABORT][13] -> [SKIP][14] ([i915#1072])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13140/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117655v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6268]: https://gitlab.freedesktop.org/drm/intel/issues/6268
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7953]: https://gitlab.freedesktop.org/drm/intel/issues/7953
Build changes
-
* Linux: CI_DRM_13140 -> Patchwork_117655v1
CI-20190529: 20190529
CI_DRM_13140: 42375f267a2451a1b2a1d5dc753785d7f1b7d9b3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7285: d1cbf2bad9c2664ab8bd3bd0946510a52800912f @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_117655v1: 42375f267a2451a1b2a1d5dc753785d7f1b7d9b3 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
54787746dca8 drm/i915/guc: Fix confused register capture
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Fix confused register capture list creation
== Series Details == Series: drm/i915/guc: Fix confused register capture list creation URL : https://patchwork.freedesktop.org/series/117655/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix confused register capture list creation
On Thu, 2023-05-11 at 18:35 -0700, john.c.harri...@intel.com wrote: > From: John Harrison > > The GuC has a completely separate engine class enum when referring to > register capture lists, which combines render and compute. The driver > was using the 'normal' GuC specific engine class enum instead. That > meant that it thought it was defining a capture list for compute > engines, the list was actually being applied to the GSC engine. And if > a platform didn't have a render engine, then it would get no compute > register captures at all. > > Fix that. > > Signed-off-by: John Harrison alan:snip. LGTM, simple and straight-forward patch - although i can only imagine the pain of debugging this one. So for the benefit of others on the mailing list, because the COMPUTE and RENDER enum of the i915 (not-GuC-ABI) was different, but the GuC-ABI one was using the its own Render for both, (coincidentially '0' == render for both GUC-ABI and i915), it means that ADS popultion of capture-register list would only cause problems for devices that had no render or has a GSC (all have VD/VE/Blt). So MTL is not yet fully POR and none of the existing upstream supported devices had no render engine so therefore the "Fixes" tag isn't needed IIUC. That said, pending CI results, Reviewed-by: Alan Previn
[Intel-gfx] [PATCH] drm/i915/pmu: Turn off the timer to sample frequencies when GT is parked
pmu_needs_timer() keeps the timer running even when GT is parked,
ostensibly to sample requested/actual frequencies. However
frequency_sample() has the following:
/* Report 0/0 (actual/requested) frequency while parked. */
if (!intel_gt_pm_get_if_awake(gt))
return;
The above code prevents frequencies to be sampled while the GT is
parked. So we might as well turn off the sampling timer itself in this
case and save CPU cycles/power.
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_pmu.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 7ece883a7d956..8db1d681cf4ab 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -124,11 +124,14 @@ static bool pmu_needs_timer(struct i915_pmu *pmu, bool
gpu_active)
ENGINE_SAMPLE_MASK;
/*
-* When the GPU is idle per-engine counters do not need to be
-* running so clear those bits out.
+* When GPU is idle, frequency or per-engine counters do not need
+* to be running so clear those bits out.
*/
- if (!gpu_active)
- enable &= ~ENGINE_SAMPLE_MASK;
+ if (!gpu_active) {
+ enable &= ~(config_mask(I915_PMU_ACTUAL_FREQUENCY) |
+ config_mask(I915_PMU_REQUESTED_FREQUENCY) |
+ ENGINE_SAMPLE_MASK);
+ }
/*
* Also there is software busyness tracking available we do not
* need the timer for I915_SAMPLE_BUSY counter.
--
2.38.0
[Intel-gfx] [PATCH] drm/i915/guc: Fix confused register capture list creation
From: John Harrison
The GuC has a completely separate engine class enum when referring to
register capture lists, which combines render and compute. The driver
was using the 'normal' GuC specific engine class enum instead. That
meant that it thought it was defining a capture list for compute
engines, the list was actually being applied to the GSC engine. And if
a platform didn't have a render engine, then it would get no compute
register captures at all.
Fix that.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 36 ++-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 61 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 9 +++
3 files changed, 72 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 69ce06faf8cda..63724e17829a7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -643,6 +643,39 @@ static void guc_init_golden_context(struct intel_guc *guc)
GEM_BUG_ON(guc->ads_golden_ctxt_size != total_size);
}
+static u32 guc_get_capture_engine_mask(struct iosys_map *info_map, u32
capture_class)
+{
+ u32 mask;
+
+ switch (capture_class) {
+ case GUC_CAPTURE_LIST_CLASS_RENDER_COMPUTE:
+ mask = info_map_read(info_map,
engine_enabled_masks[GUC_RENDER_CLASS]);
+ mask |= info_map_read(info_map,
engine_enabled_masks[GUC_COMPUTE_CLASS]);
+ break;
+
+ case GUC_CAPTURE_LIST_CLASS_VIDEO:
+ mask = info_map_read(info_map,
engine_enabled_masks[GUC_VIDEO_CLASS]);
+ break;
+
+ case GUC_CAPTURE_LIST_CLASS_VIDEOENHANCE:
+ mask = info_map_read(info_map,
engine_enabled_masks[GUC_VIDEOENHANCE_CLASS]);
+ break;
+
+ case GUC_CAPTURE_LIST_CLASS_BLITTER:
+ mask = info_map_read(info_map,
engine_enabled_masks[GUC_BLITTER_CLASS]);
+ break;
+
+ case GUC_CAPTURE_LIST_CLASS_GSC_OTHER:
+ mask = info_map_read(info_map,
engine_enabled_masks[GUC_GSC_OTHER_CLASS]);
+ break;
+
+ default:
+ mask = 0;
+ }
+
+ return mask;
+}
+
static int
guc_capture_prep_lists(struct intel_guc *guc)
{
@@ -678,9 +711,10 @@ guc_capture_prep_lists(struct intel_guc *guc)
for (i = 0; i < GUC_CAPTURE_LIST_INDEX_MAX; i++) {
for (j = 0; j < GUC_MAX_ENGINE_CLASSES; j++) {
+ u32 engine_mask =
guc_get_capture_engine_mask(_map, j);
/* null list if we dont have said engine or list */
- if (!info_map_read(_map, engine_enabled_masks[j]))
{
+ if (!engine_mask) {
if (ads_is_mapped) {
ads_blob_write(guc,
ads.capture_class[i][j], null_ggtt);
ads_blob_write(guc,
ads.capture_instance[i][j], null_ggtt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 1def0b6467c79..0ff864da92dfe 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -174,35 +174,31 @@ static const struct __guc_mmio_reg_descr
empty_regs_list[] = {
/* List of lists */
static const struct __guc_mmio_reg_descr_group gen8_lists[] = {
MAKE_REGLIST(gen8_global_regs, PF, GLOBAL, 0),
- MAKE_REGLIST(gen8_rc_class_regs, PF, ENGINE_CLASS, GUC_RENDER_CLASS),
- MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE, GUC_RENDER_CLASS),
- MAKE_REGLIST(gen8_rc_class_regs, PF, ENGINE_CLASS, GUC_COMPUTE_CLASS),
- MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE, GUC_COMPUTE_CLASS),
- MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEO_CLASS),
- MAKE_REGLIST(gen8_vd_inst_regs, PF, ENGINE_INSTANCE, GUC_VIDEO_CLASS),
- MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_VIDEOENHANCE_CLASS),
- MAKE_REGLIST(gen8_vec_inst_regs, PF, ENGINE_INSTANCE,
GUC_VIDEOENHANCE_CLASS),
- MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_BLITTER_CLASS),
- MAKE_REGLIST(gen8_blt_inst_regs, PF, ENGINE_INSTANCE,
GUC_BLITTER_CLASS),
- MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_GSC_OTHER_CLASS),
- MAKE_REGLIST(empty_regs_list, PF, ENGINE_INSTANCE, GUC_GSC_OTHER_CLASS),
+ MAKE_REGLIST(gen8_rc_class_regs, PF, ENGINE_CLASS,
GUC_CAPTURE_LIST_CLASS_RENDER_COMPUTE),
+ MAKE_REGLIST(gen8_rc_inst_regs, PF, ENGINE_INSTANCE,
GUC_CAPTURE_LIST_CLASS_RENDER_COMPUTE),
+ MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS,
GUC_CAPTURE_LIST_CLASS_VIDEO),
+ MAKE_REGLIST(gen8_vd_inst_regs, PF, ENGINE_INSTANCE,
GUC_CAPTURE_LIST_CLASS_VIDEO),
+ MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS,
GUC_CAPTURE_LIST_CLASS_VIDEOENHANCE),
+
Re: [Intel-gfx] [PATCH 5/6] drm/i915/pmu: Prepare for multi-tile non-engine counters
On Fri, 05 May 2023 17:58:15 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Tvrtko Ursulin
>
> Reserve some bits in the counter config namespace which will carry the
> tile id and prepare the code to handle this.
>
> No per tile counters have been added yet.
>
> v2:
> - Fix checkpatch issues
> - Use 4 bits for gt id in non-engine counters. Drop FIXME.
> - Set MAX GTs to 4. Drop FIXME.
>
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 150 +++-
> drivers/gpu/drm/i915/i915_pmu.h | 9 +-
> include/uapi/drm/i915_drm.h | 17 +++-
> 3 files changed, 129 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 669a42e44082..12b2f3169abf 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -56,11 +56,21 @@ static bool is_engine_config(u64 config)
> return config < __I915_PMU_OTHER(0);
> }
>
> +static unsigned int config_gt_id(const u64 config)
> +{
> + return config >> __I915_PMU_GT_SHIFT;
> +}
> +
> +static u64 config_counter(const u64 config)
> +{
> + return config & ~(~0ULL << __I915_PMU_GT_SHIFT);
ok, but another possibility:
return config & ~REG_GENMASK64(63, __I915_PMU_GT_SHIFT);
> +}
> +
> static unsigned int other_bit(const u64 config)
> {
> unsigned int val;
>
> - switch (config) {
> + switch (config_counter(config)) {
> case I915_PMU_ACTUAL_FREQUENCY:
> val = __I915_PMU_ACTUAL_FREQUENCY_ENABLED;
> break;
> @@ -78,15 +88,20 @@ static unsigned int other_bit(const u64 config)
> return -1;
> }
>
> - return I915_ENGINE_SAMPLE_COUNT + val;
> + return I915_ENGINE_SAMPLE_COUNT +
> +config_gt_id(config) * __I915_PMU_TRACKED_EVENT_COUNT +
> +val;
> }
>
> static unsigned int config_bit(const u64 config)
> {
> - if (is_engine_config(config))
> + if (is_engine_config(config)) {
> + GEM_BUG_ON(config_gt_id(config));
This GEM_BUG_ON is not needed since:
static bool is_engine_config(u64 config)
{
return config < __I915_PMU_OTHER(0);
}
> +
> return engine_config_sample(config);
> - else
> + } else {
> return other_bit(config);
> + }
> }
>
> static u64 config_mask(u64 config)
> @@ -104,6 +119,18 @@ static unsigned int event_bit(struct perf_event *event)
> return config_bit(event->attr.config);
> }
>
> +static u64 frequency_enabled_mask(void)
> +{
> + unsigned int i;
> + u64 mask = 0;
> +
> + for (i = 0; i < I915_PMU_MAX_GTS; i++)
> + mask |= config_mask(__I915_PMU_ACTUAL_FREQUENCY(i)) |
> + config_mask(__I915_PMU_REQUESTED_FREQUENCY(i));
> +
> + return mask;
> +}
> +
> static bool pmu_needs_timer(struct i915_pmu *pmu, bool gpu_active)
> {
> struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu);
> @@ -120,9 +147,7 @@ static bool pmu_needs_timer(struct i915_pmu *pmu, bool
> gpu_active)
>* Mask out all the ones which do not need the timer, or in
>* other words keep all the ones that could need the timer.
>*/
> - enable &= config_mask(I915_PMU_ACTUAL_FREQUENCY) |
> - config_mask(I915_PMU_REQUESTED_FREQUENCY) |
> - ENGINE_SAMPLE_MASK;
> + enable &= frequency_enabled_mask() | ENGINE_SAMPLE_MASK;
u32 enable & u64 frequency_enabled_mask
ugly but ok I guess? Or change enable to u64?
>
> /*
>* When the GPU is idle per-engine counters do not need to be
> @@ -164,9 +189,37 @@ static inline s64 ktime_since_raw(const ktime_t kt)
> return ktime_to_ns(ktime_sub(ktime_get_raw(), kt));
> }
>
> +static unsigned int
> +__sample_idx(struct i915_pmu *pmu, unsigned int gt_id, int sample)
> +{
> + unsigned int idx = gt_id * __I915_NUM_PMU_SAMPLERS + sample;
> +
> + GEM_BUG_ON(idx >= ARRAY_SIZE(pmu->sample));
Does this GEM_BUG_ON need to be split up as follows:
GEM_BUG_ON(gt_id >= I915_PMU_MAX_GTS);
GEM_BUG_ON(sample >= __I915_NUM_PMU_SAMPLERS);
Since that is what we really mean here isn't it?
> +
> + return idx;
> +}
> +
> +static u64 read_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample)
> +{
> + return pmu->sample[__sample_idx(pmu, gt_id, sample)].cur;
> +}
> +
> +static void
> +store_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample, u64 val)
> +{
> + pmu->sample[__sample_idx(pmu, gt_id, sample)].cur = val;
> +}
> +
> +static void
> +add_sample_mult(struct i915_pmu *pmu, unsigned int gt_id, int sample, u32
> val, u32 mul)
> +{
> + pmu->sample[__sample_idx(pmu, gt_id, sample)].cur += mul_u32_u32(val,
> mul);
> +}
Gripe: I think this code should have per event data structures which store
all information about a particular event. Rather than storing it in these
arrays common to all
[Intel-gfx] ✓ Fi.CI.BAT: success for mtl: add support for pmdemand (rev5)
== Series Details == Series: mtl: add support for pmdemand (rev5) URL : https://patchwork.freedesktop.org/series/116949/ State : success == Summary == CI Bug Log - changes from CI_DRM_13139 -> Patchwork_116949v5 Summary --- **WARNING** Minor unknown changes coming with Patchwork_116949v5 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_116949v5, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/index.html Participating hosts (40 -> 38) -- Additional (1): bat-rpls-2 Missing(3): fi-kbl-soraka bat-kbl-2 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_116949v5: ### IGT changes ### Warnings * igt@kms_psr@primary_mmap_gtt: - bat-rplp-1: [SKIP][1] ([i915#1072]) -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13139/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html Known issues Here are the changes found in Patchwork_116949v5 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@read: - bat-rpls-2: NOTRUN -> [SKIP][4] ([i915#2582]) +4 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@fb...@read.html * igt@gem_lmem_swapping@verify-random: - bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_pread_basic: - bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#3282]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-rpls-2: NOTRUN -> [SKIP][7] ([i915#7561]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-rpls-2: NOTRUN -> [SKIP][8] ([i915#6621]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_pm: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][9] ([i915#4258] / [i915#7913]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@requests: - bat-rpls-1: [PASS][10] -> [ABORT][11] ([i915#7911] / [i915#7920] / [i915#7953] / [i915#7982]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13139/bat-rpls-1/igt@i915_selftest@l...@requests.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@reset: - bat-rpls-2: NOTRUN -> [ABORT][12] ([i915#4983] / [i915#7461] / [i915#7913] / [i915#8347]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@kms_busy@basic: - bat-rpls-2: NOTRUN -> [SKIP][13] ([i915#1845]) +14 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@kms_b...@basic.html * igt@kms_chamelium_edid@hdmi-edid-read: - bat-rpls-2: NOTRUN -> [SKIP][14] ([i915#7828]) +7 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@kms_chamelium_e...@hdmi-edid-read.html * igt@kms_flip@basic-flip-vs-dpms: - bat-rpls-2: NOTRUN -> [SKIP][15] ([i915#3637]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@kms_f...@basic-flip-vs-dpms.html * igt@kms_force_connector_basic@force-load-detect: - bat-rpls-2: NOTRUN -> [SKIP][16] ([fdo#109285]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - bat-rpls-2: NOTRUN -> [SKIP][17] ([i915#1849]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v5/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1: - bat-dg2-8: [PASS][18] -> [FAIL][19] ([i915#7932]) [18]:
Re: [Intel-gfx] [PATCH v11 0/8] drm/i915/pxp: Add MTL PXP Support
Thank you for the patches and the reviews. Pushed. - Radhakrishna(RK) Sripada > -Original Message- > From: dri-devel On Behalf Of Alan > Previn > Sent: Thursday, May 11, 2023 4:18 PM > To: intel-gfx@lists.freedesktop.org > Cc: Teres Alexis, Alan Previn ; Ursulin, > Tvrtko ; Juston Li ; dri- > de...@lists.freedesktop.org; Ceraolo Spurio, Daniele > ; Landwerlin, Lionel G > ; Vivi, Rodrigo ; > Justen, Jordan L > Subject: [PATCH v11 0/8] drm/i915/pxp: Add MTL PXP Support > > This series enables PXP on MTL. On ADL/TGL platforms, we rely on > the mei driver via the i915-mei PXP component interface to establish > a connection to the security firmware via the HECI device interface. > That interface is used to create and teardown the PXP ARB session. > PXP ARB session is created when protected contexts are created. > > In this series, the front end behaviors and interfaces (uapi) remain > the same. We add backend support for MTL but with MTL we directly use > the GSC-CS engine on the MTL GPU device to send messages to the PXP > (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format > of the message is slightly different with a 2-layer packetization > that is explained in detail in Patch #3. Also, the second layer > which is the actual PXP firmware packet is now rev'd to version 4.3 > for MTL that is defined in Patch #5. > > Take note that Patch #4 adds the buffer allocation and gsccs-send- > message without actually being called by the arb-creation code > which gets added in Patch #5. Additionally, a seperate series being > reviewed is introducing a change for session teardown (in pxp front- > end layer that will need backend support by both legacy and gsccs). > If we squash all of these together (buffer-alloc, send-message, > arb-creation and, in future, session-termination), the single patch > will be rather large. That said, we are keeping Patch #4 and #5 > separate for now, but at merge time, we can squash them together > if maintainer requires it. > > Changes from prior revs: >v1 : - fixed when building with CONFIG_PXP disabled. > - more alignment with gsc_mtl_header structure from the HDCP >v2 : - (all following changes as per reviews from Daniele) > - squashed Patch #1 from v1 into the next one. > - replaced unnecessary "uses_gsccs" boolean in the pxp > with "HAS_ENGINE(pxp->ctrl_gt, GSC0)". > - moved the stashing of gsccs resources from a dynamically > allocated opaque handle to an explicit sub-struct in > 'struct intel_pxp'. > - moved the buffer object allocations from Patch #1 of this > series to Patch #5 (but keep the context allocation in > Patch #1). > - used the kernel default ppgtt for the gsccs context. > - optimized the buffer allocation and deallocation code > and drop the need to stash the drm_i915_gem_object. > - use a macro with the right mmio reg base (depending > on root-tile vs media-tile) along with common relative > offset to access all KCR registers thus minimizing > changes to the KCR register access codes. > - fixed bugs in the heci packet request submission code > in Patch #3 (of this series) > - add comments in the mtl-gsc-heci-header regarding the > host-session-handle. > - re-use tee-mutex instead of introducing a gsccs specific > cmd mutex. > - minor cosmetic improvements in Patch #5. > - before creating arb session, ensure intel_pxp_start > first ensures the GSC FW is up and running. > - use 2 second timeout for the pending-bit scenario when > sending command to GSC-FW as per specs. > - simplify intel_pxp_get_irq_gt with addition comments > - redo Patch #7 to minimize the changes without introducing > a common abstraction helper for suspend/resume/init/fini > codes that have to change the kcr power state. >v3 : - rebase onto latest drm-tip with the updated firmware > session invalidation flow > - on Patch#1: move 'mutex_init(>tee_mutex)' to a common > init place in intel_pxp_init since its needed everywhere > (Daniele) > - on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);" > (Daniele) > - on Patch#2: move the introduction of host_session_handle to > Patch#4 where it starts getting used. > - on Patch#4: move host-session-handle initialization to the > allocate-resources during gsccs-init (away from Patch#5) > and add the required call to PXP-firmware to cleanup the > host-session-handle in destroy-resources during gsccs-fini > - on Patch#5: add dispatching of arb session termination > firmware cmd during session teardown (as per latest > upstream flows) >v4 : - Added proper initialization and cleanup of
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for mtl: add support for pmdemand (rev5)
== Series Details == Series: mtl: add support for pmdemand (rev5) URL : https://patchwork.freedesktop.org/series/116949/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mtl: add support for pmdemand (rev5)
== Series Details == Series: mtl: add support for pmdemand (rev5) URL : https://patchwork.freedesktop.org/series/116949/ State : warning == Summary == Error: dim checkpatch failed 6f074611e692 drm/i915: fix the derating percentage for MTL 25b686634b4a drm/i915: update the QGV point frequency calculations 240020f2d4ed drm/i915: store the peak bw per QGV point 2f379cefdf09 drm/i915: extract intel_bw_check_qgv_points() 97b147d865bd drm/i915: modify max_bw to return index to intel_bw_info ffab0de08abd drm/i915/mtl: find the best QGV point for the SAGV configuration 6ef74bd7c7f9 drm/i915/mtl: Add support for PM DEMAND Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:81: WARNING:TYPO_SPELLING: 'paramters' may be misspelled - perhaps 'parameters'? #81: FILE: drivers/gpu/drm/i915/display/intel_display.c:6969: +* In D14 Pmdemand combines many paramters such as voltage index, plls, ^ -:109: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment #109: FILE: drivers/gpu/drm/i915/display/intel_display_core.h:350: + struct mutex lock; -:182: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #182: new file mode 100644 -:219: WARNING:LONG_LINE: line length of 119 exceeds 100 columns #219: FILE: drivers/gpu/drm/i915/display/intel_pmdemand.c:33: +#define to_intel_pmdemand_state(x) container_of((x) + BUILD_BUG_ON_ZERO(offsetof(struct intel_pmdemand_state, base)), \ -:597: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #597: FILE: drivers/gpu/drm/i915/display/intel_pmdemand.c:411: + drm_dbg_kms(>drm, + "initate pmdemand request values: (0x%x 0x%x)\n", -:601: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #601: FILE: drivers/gpu/drm/i915/display/intel_pmdemand.c:415: + intel_de_rmw(i915, XELPDP_INITIATE_PMDEMAND_REQUEST(1), 0, + XELPDP_PMDEMAND_REQ_ENABLE); -:758: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #758: FILE: drivers/gpu/drm/i915/i915_reg.h:4543: +#define XELPDP_PMDEMAND_QCLK_GV_BW(x) REG_FIELD_PREP(XELPDP_PMDEMAND_QCLK_GV_BW_MASK, x) -:760: WARNING:LONG_LINE: line length of 109 exceeds 100 columns #760: FILE: drivers/gpu/drm/i915/i915_reg.h:4545: +#define XELPDP_PMDEMAND_VOLTAGE_INDEX(x) REG_FIELD_PREP(XELPDP_PMDEMAND_VOLTAGE_INDEX_MASK, x) -:762: WARNING:LONG_LINE: line length of 109 exceeds 100 columns #762: FILE: drivers/gpu/drm/i915/i915_reg.h:4547: +#define XELPDP_PMDEMAND_QCLK_GV_INDEX(x) REG_FIELD_PREP(XELPDP_PMDEMAND_QCLK_GV_INDEX_MASK, x) -:764: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #764: FILE: drivers/gpu/drm/i915/i915_reg.h:4549: +#define XELPDP_PMDEMAND_PIPES(x) REG_FIELD_PREP(XELPDP_PMDEMAND_PIPES_MASK, x) -:766: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #766: FILE: drivers/gpu/drm/i915/i915_reg.h:4551: +#define XELPDP_PMDEMAND_DBUFS(x) REG_FIELD_PREP(XELPDP_PMDEMAND_DBUFS_MASK, x) -:772: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #772: FILE: drivers/gpu/drm/i915/i915_reg.h:4557: +#define XELPDP_PMDEMAND_CDCLK_FREQ(x) REG_FIELD_PREP(XELPDP_PMDEMAND_CDCLK_FREQ_MASK, x) -:774: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #774: FILE: drivers/gpu/drm/i915/i915_reg.h:4559: +#define XELPDP_PMDEMAND_DDICLK_FREQ(x) REG_FIELD_PREP(XELPDP_PMDEMAND_DDICLK_FREQ_MASK, x) -:776: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #776: FILE: drivers/gpu/drm/i915/i915_reg.h:4561: +#define XELPDP_PMDEMAND_SCALERS(x) REG_FIELD_PREP(XELPDP_PMDEMAND_SCALERS_MASK, x) total: 0 errors, 11 warnings, 3 checks, 697 lines checked 5859307b239e drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add MTL PXP Support (rev12)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev12) URL : https://patchwork.freedesktop.org/series/112647/ State : success == Summary == CI Bug Log - changes from CI_DRM_13139 -> Patchwork_112647v12 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/index.html Participating hosts (40 -> 40) -- Additional (1): bat-rpls-2 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_112647v12 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-rpls-2: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@read: - bat-rpls-2: NOTRUN -> [SKIP][2] ([i915#2582]) +4 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@fb...@read.html * igt@gem_lmem_swapping@verify-random: - bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_pread_basic: - bat-rpls-2: NOTRUN -> [SKIP][4] ([i915#3282]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#7561]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#6621]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_pm: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][7] ([i915#4258] / [i915#7913]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@mman: - bat-rpls-2: NOTRUN -> [TIMEOUT][8] ([i915#6794] / [i915#7392]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@i915_selftest@l...@mman.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-WARN][9] ([i915#6367] / [i915#7953]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-rpls-2: NOTRUN -> [ABORT][10] ([i915#6687]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-1: NOTRUN -> [ABORT][11] ([i915#6687] / [i915#7953] / [i915#7978]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_busy@basic: - bat-rpls-2: NOTRUN -> [SKIP][12] ([i915#1845]) +14 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@kms_b...@basic.html * igt@kms_chamelium_edid@hdmi-edid-read: - bat-rpls-2: NOTRUN -> [SKIP][13] ([i915#7828]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@kms_chamelium_e...@hdmi-edid-read.html * igt@kms_flip@basic-flip-vs-dpms: - bat-rpls-2: NOTRUN -> [SKIP][14] ([i915#3637]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@kms_f...@basic-flip-vs-dpms.html * igt@kms_force_connector_basic@force-load-detect: - bat-rpls-2: NOTRUN -> [SKIP][15] ([fdo#109285]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - bat-rpls-2: NOTRUN -> [SKIP][16] ([i915#1849]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][17] ([i915#1845] / [i915#5354]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_psr@sprite_plane_onoff: - bat-rpls-2: NOTRUN -> [SKIP][18] ([i915#1072]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v12/bat-rpls-2/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#3555] / [i915#4579])
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pxp: Add MTL PXP Support (rev12)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev12) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim checkpatch failed 74b5aab9a9a7 drm/i915/pxp: Add GSC-CS back-end resource init and cleanup Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:99: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #99: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 173 lines checked 3f6b4939a67a drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:109: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #109: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 153 lines checked eb5866cc6c22 drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC 6cd7e1873eed drm/i915/pxp: Add GSC-CS backend to send GSC fw messages -:109: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #109: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:43: + GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE)); total: 0 errors, 1 warnings, 0 checks, 326 lines checked 8b7b0e19551c drm/i915/pxp: Add ARB session creation and cleanup b0c5153ddee0 drm/i915/uapi/pxp: Add a GET_PARAM for PXP 970eacfab970 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component b36e2079fa07 drm/i915/pxp: Enable PXP with MTL-GSC-CS
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add MTL PXP Support (rev12)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev12) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND
Hello
Thanks for the comments. Pls see some inline replies..
On Thu, 2023-04-27 at 17:24 -0300, Gustavo Sousa wrote:
> Quoting Vinod Govindapillai (2023-04-27 12:00:15)
> > From: Mika Kahola
> >
> > Display14 introduces a new way to instruct the PUnit with
> > power and bandwidth requirements of DE. Add the functionality
> > to program the registers and handle waits using interrupts.
> > The current wait time for timeouts is programmed for 10 msecs to
> > factor in the worst case scenarios. Changes made to use REG_BIT
> > for a register that we touched(GEN8_DE_MISC_IER _MMIO).
> >
> > Wa_14016740474 is added which applies to Xe_LPD+ display
> >
> > v2: checkpatch warning fixes, simplify program pmdemand part
> >
> > v3: update to dbufs and pipes values to pmdemand register(stan)
> > Removed the macro usage in update_pmdemand_values()
> >
> > Bspec: 66451, 64636, 64602, 64603
> > Cc: Matt Atwood
> > Cc: Matt Roper
> > Cc: Lucas De Marchi
> > Cc: Gustavo Sousa
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Radhakrishna Sripada
> > Signed-off-by: Gustavo Sousa
> > Signed-off-by: Mika Kahola
> > Signed-off-by: Vinod Govindapillai
> > ---
> > drivers/gpu/drm/i915/Makefile | 3 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 7 +
> > .../gpu/drm/i915/display/intel_display_core.h | 6 +
> > .../drm/i915/display/intel_display_driver.c | 7 +
> > .../drm/i915/display/intel_display_power.c | 8 +
> > drivers/gpu/drm/i915/display/intel_pmdemand.c | 455 ++
> > drivers/gpu/drm/i915/display/intel_pmdemand.h | 24 +
> > drivers/gpu/drm/i915/i915_irq.c | 21 +-
> > drivers/gpu/drm/i915/i915_reg.h | 36 +-
> > 9 files changed, 562 insertions(+), 5 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
> > create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 9af76e376ca9..eb899fa86e51 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -281,7 +281,8 @@ i915-y += \
> > display/i9xx_wm.o \
> > display/skl_scaler.o \
> > display/skl_universal_plane.o \
> > - display/skl_watermark.o
> > + display/skl_watermark.o \
> > + display/intel_pmdemand.o
> > i915-$(CONFIG_ACPI) += \
> > display/intel_acpi.o \
> > display/intel_opregion.o
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index bf391a6cd8d6..f98e235fadc6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -99,6 +99,7 @@
> > #include "intel_pcode.h"
> > #include "intel_pipe_crc.h"
> > #include "intel_plane_initial.h"
> > +#include "intel_pmdemand.h"
> > #include "intel_pps.h"
> > #include "intel_psr.h"
> > #include "intel_sdvo.h"
> > @@ -6306,6 +6307,10 @@ int intel_atomic_check(struct drm_device *dev,
> > return ret;
> > }
> >
> > + ret = intel_pmdemand_atomic_check(state);
> > + if (ret)
> > + goto fail;
> > +
> > ret = intel_atomic_check_crtcs(state);
> > if (ret)
> > goto fail;
> > @@ -6960,6 +6965,7 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> > }
> >
> > intel_sagv_pre_plane_update(state);
> > + intel_pmdemand_pre_plane_update(state);
> >
> > /* Complete the events for pipes that have now been disabled */
> > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > @@ -7070,6 +7076,7 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> > intel_verify_planes(state);
> >
> > intel_sagv_post_plane_update(state);
> > + intel_pmdemand_post_plane_update(state);
> >
> > drm_atomic_helper_commit_hw_done(>base);
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> > b/drivers/gpu/drm/i915/display/intel_display_core.h
> > index 9f66d734edf6..9471a052aa57 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > @@ -345,6 +345,12 @@ struct intel_display {
> > struct intel_global_obj obj;
> > } dbuf;
> >
> > + struct {
> > + wait_queue_head_t waitqueue;
> > + struct mutex lock;
> > + struct intel_global_obj obj;
> > + } pmdemand;
> > +
> > struct {
> > /*
> > * dkl.phy_lock protects against concurrent access of the
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> > b/drivers/gpu/drm/i915/display/intel_display_driver.c
> > index 60ce10fc7205..79853d8c3240 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> > @@ -47,6 +47,7 @@
> >
[Intel-gfx] [PATCH v5 7/8] drm/i915/mtl: Add support for PM DEMAND
From: Mika Kahola
Display14 introduces a new way to instruct the PUnit with
power and bandwidth requirements of DE. Add the functionality
to program the registers and handle waits using interrupts.
The current wait time for timeouts is programmed for 10 msecs to
factor in the worst case scenarios. Changes made to use REG_BIT
for a register that we touched(GEN8_DE_MISC_IER _MMIO).
Wa_14016740474 is added which applies to Xe_LPD+ display
v2: checkpatch warning fixes, simplify program pmdemand part
v3: update to dbufs and pipes values to pmdemand register(stan)
Removed the macro usage in update_pmdemand_values()
v4: move the pmdemand_pre_plane_update before cdclk update
pmdemand_needs_update included cdclk params comparisons
pmdemand_state NULL check (Gustavo)
pmdemand.o in sorted order in the makefile (Jani)
update pmdemand misc irq handler loop (Gustavo)
active phys bitmask and programming correction (Gustavo)
Bspec: 66451, 64636, 64602, 64603
Cc: Matt Atwood
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Gustavo Sousa
Signed-off-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Gustavo Sousa
Signed-off-by: Mika Kahola
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 14 +
.../gpu/drm/i915/display/intel_display_core.h | 6 +
.../drm/i915/display/intel_display_driver.c | 7 +
.../drm/i915/display/intel_display_power.c| 8 +
drivers/gpu/drm/i915/display/intel_pmdemand.c | 465 ++
drivers/gpu/drm/i915/display/intel_pmdemand.h | 24 +
drivers/gpu/drm/i915/i915_irq.c | 23 +-
drivers/gpu/drm/i915/i915_reg.h | 36 +-
9 files changed, 580 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d97d45ae1a0d..a7c2cf21cbfc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -270,6 +270,7 @@ i915-y += \
display/intel_pch_display.o \
display/intel_pch_refclk.o \
display/intel_plane_initial.o \
+ display/intel_pmdemand.o \
display/intel_psr.o \
display/intel_quirks.o \
display/intel_sprite.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1d5d42a40803..dd390a0586ef 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -99,6 +99,7 @@
#include "intel_pcode.h"
#include "intel_pipe_crc.h"
#include "intel_plane_initial.h"
+#include "intel_pmdemand.h"
#include "intel_pps.h"
#include "intel_psr.h"
#include "intel_sdvo.h"
@@ -6315,6 +6316,10 @@ int intel_atomic_check(struct drm_device *dev,
return ret;
}
+ ret = intel_pmdemand_atomic_check(state);
+ if (ret)
+ goto fail;
+
ret = intel_atomic_check_crtcs(state);
if (ret)
goto fail;
@@ -6960,6 +6965,14 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
crtc->config = new_crtc_state;
+ /*
+* In D14 Pmdemand combines many paramters such as voltage index, plls,
+* cdclk frequency, QGV point selection parameter etc. Voltage index,
+* cdclk/ddiclk frequencies are supposed to be configured before the
+* cdclk config is set.
+*/
+ intel_pmdemand_pre_plane_update(state);
+
if (state->modeset) {
drm_atomic_helper_update_legacy_modeset_state(dev,
>base);
@@ -7079,6 +7092,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_verify_planes(state);
intel_sagv_post_plane_update(state);
+ intel_pmdemand_post_plane_update(state);
drm_atomic_helper_commit_hw_done(>base);
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 9f66d734edf6..9471a052aa57 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -345,6 +345,12 @@ struct intel_display {
struct intel_global_obj obj;
} dbuf;
+ struct {
+ wait_queue_head_t waitqueue;
+ struct mutex lock;
+ struct intel_global_obj obj;
+ } pmdemand;
+
struct {
/*
* dkl.phy_lock protects against concurrent access of the
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 60ce10fc7205..dc8de861339d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++
[Intel-gfx] [PATCH v5 8/8] drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder
While configuring pmdemand parameters, there could be
intel_get_crtc_new_encoder call where encoders could be 0. To avoid
invoking drm_warn in such cases, use a parameter to indicate drm_warn
should be suppressed.
v2: checkpatch warning fixes
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 10 ++
drivers/gpu/drm/i915/display/intel_display.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dpll.c| 8
drivers/gpu/drm/i915/display/intel_pch_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_pmdemand.c| 2 +-
drivers/gpu/drm/i915/display/intel_snps_phy.c| 2 +-
7 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index d94127e7448b..1a41a314f8d8 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2934,7 +2934,7 @@ void intel_c10pll_state_verify(struct intel_atomic_state
*state,
!intel_crtc_needs_fastset(new_crtc_state))
return;
- encoder = intel_get_crtc_new_encoder(state, new_crtc_state);
+ encoder = intel_get_crtc_new_encoder(state, new_crtc_state, true);
phy = intel_port_to_phy(i915, encoder->port);
if (!intel_is_c10phy(i915, phy))
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dd390a0586ef..fb2b7769 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -763,7 +763,8 @@ bool intel_has_pending_fb_unpin(struct drm_i915_private
*dev_priv)
*/
struct intel_encoder *
intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
- const struct intel_crtc_state *crtc_state)
+ const struct intel_crtc_state *crtc_state,
+ bool warn)
{
const struct drm_connector_state *connector_state;
const struct drm_connector *connector;
@@ -782,9 +783,10 @@ intel_get_crtc_new_encoder(const struct intel_atomic_state
*state,
num_encoders++;
}
- drm_WARN(state->base.dev, num_encoders != 1,
-"%d encoders for pipe %c\n",
-num_encoders, pipe_name(master_crtc->pipe));
+ if (warn)
+ drm_WARN(state->base.dev, num_encoders != 1,
+"%d encoders for pipe %c\n",
+num_encoders, pipe_name(master_crtc->pipe));
return encoder;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index ac95961f68ba..4620ed991ff0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -501,7 +501,8 @@ bool intel_plane_uses_fence(const struct intel_plane_state
*plane_state);
struct intel_encoder *
intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
- const struct intel_crtc_state *crtc_state);
+ const struct intel_crtc_state *crtc_state,
+ bool warn);
void intel_plane_disable_noatomic(struct intel_crtc *crtc,
struct intel_plane *plane);
void intel_set_plane_visible(struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
b/drivers/gpu/drm/i915/display/intel_dpll.c
index ca0f362a40e3..3101de274f9d 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -940,7 +940,7 @@ static int hsw_crtc_compute_clock(struct intel_atomic_state
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;
if (DISPLAY_VER(dev_priv) < 11 &&
@@ -969,7 +969,7 @@ static int hsw_crtc_get_shared_dpll(struct
intel_atomic_state *state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
if (DISPLAY_VER(dev_priv) < 11 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
@@ -984,7 +984,7 @@ static int dg2_crtc_compute_clock(struct intel_atomic_state
*state,
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
- intel_get_crtc_new_encoder(state, crtc_state);
+ intel_get_crtc_new_encoder(state, crtc_state, true);
int ret;
[Intel-gfx] [PATCH v5 4/8] drm/i915: extract intel_bw_check_qgv_points()
Extract intel_bw_check_qgv_points() from intel_bw_atomic_check
to facilitate future platform variations in handling SAGV
configurations.
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 235 +---
1 file changed, 130 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index db117638d23b..d83aafd0cc2b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -803,6 +803,128 @@ intel_atomic_get_bw_state(struct intel_atomic_state
*state)
return to_intel_bw_state(bw_state);
}
+static int icl_find_qgv_points(struct drm_i915_private *i915,
+ unsigned int data_rate,
+ unsigned int num_active_planes,
+ const struct intel_bw_state *old_bw_state,
+ struct intel_bw_state *new_bw_state)
+{
+ unsigned int max_bw_point = 0;
+ unsigned int max_bw = 0;
+ unsigned int num_psf_gv_points =
i915->display.bw.max[0].num_psf_gv_points;
+ unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+ u16 psf_points = 0;
+ u16 qgv_points = 0;
+ int i;
+ int ret;
+
+ ret = intel_atomic_lock_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < num_qgv_points; i++) {
+ unsigned int max_data_rate;
+
+ if (DISPLAY_VER(i915) > 11)
+ max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+ else
+ max_data_rate = icl_max_bw(i915, num_active_planes, i);
+ /*
+* We need to know which qgv point gives us
+* maximum bandwidth in order to disable SAGV
+* if we find that we exceed SAGV block time
+* with watermarks. By that moment we already
+* have those, as it is calculated earlier in
+* intel_atomic_check,
+*/
+ if (max_data_rate > max_bw) {
+ max_bw_point = i;
+ max_bw = max_data_rate;
+ }
+ if (max_data_rate >= data_rate)
+ qgv_points |= BIT(i);
+
+ drm_dbg_kms(>drm, "QGV point %d: max bw %d required %d\n",
+ i, max_data_rate, data_rate);
+ }
+
+ for (i = 0; i < num_psf_gv_points; i++) {
+ unsigned int max_data_rate = adl_psf_bw(i915, i);
+
+ if (max_data_rate >= data_rate)
+ psf_points |= BIT(i);
+
+ drm_dbg_kms(>drm, "PSF GV point %d: max bw %d"
+ " required %d\n",
+ i, max_data_rate, data_rate);
+ }
+
+ /*
+* BSpec states that we always should have at least one allowed point
+* left, so if we couldn't - simply reject the configuration for obvious
+* reasons.
+*/
+ if (qgv_points == 0) {
+ drm_dbg_kms(>drm, "No QGV points provide sufficient
memory"
+ " bandwidth %d for display configuration(%d active
planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ if (num_psf_gv_points > 0 && psf_points == 0) {
+ drm_dbg_kms(>drm, "No PSF GV points provide sufficient
memory"
+ " bandwidth %d for display configuration(%d active
planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ /*
+* Leave only single point with highest bandwidth, if
+* we can't enable SAGV due to the increased memory latency it may
+* cause.
+*/
+ if (!intel_can_enable_sagv(i915, new_bw_state)) {
+ qgv_points = BIT(max_bw_point);
+ drm_dbg_kms(>drm, "No SAGV, using single QGV point %d\n",
+ max_bw_point);
+ }
+
+ /*
+* We store the ones which need to be masked as that is what PCode
+* actually accepts as a parameter.
+*/
+ new_bw_state->qgv_points_mask =
+ ~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
+ ADLS_PCODE_REQ_PSF_PT(psf_points)) &
+ icl_qgv_points_mask(i915);
+
+ /*
+* If the actual mask had changed we need to make sure that
+* the commits are serialized(in case this is a nomodeset, nonblocking)
+*/
+ if (new_bw_state->qgv_points_mask != old_bw_state->qgv_points_mask) {
+ ret = intel_atomic_serialize_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int intel_bw_check_qgv_points(struct drm_i915_private *i915,
+
[Intel-gfx] [PATCH v5 6/8] drm/i915/mtl: find the best QGV point for the SAGV configuration
>From MTL onwards, we need to find the best QGV point based on
the required data rate and pass the peak BW of that point to
the punit to lock the corresponding QGV point.
Bspec: 64636
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 87 -
drivers/gpu/drm/i915/display/intel_bw.h | 6 ++
2 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index f466b4e087bb..36b2f18dc0c1 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -803,6 +803,85 @@ intel_atomic_get_bw_state(struct intel_atomic_state *state)
return to_intel_bw_state(bw_state);
}
+static int mtl_find_qgv_points(struct drm_i915_private *i915,
+ unsigned int data_rate,
+ unsigned int num_active_planes,
+ const struct intel_bw_state *old_bw_state,
+ struct intel_bw_state *new_bw_state)
+{
+ unsigned int best_rate = UINT_MAX;
+ unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
+ unsigned int qgv_peak_bw = 0;
+ int i;
+ int ret;
+
+ ret = intel_atomic_lock_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+
+ /*
+* If SAGV cannot be enabled, disable the pcode SAGV by passing all 1's
+* for qgv peak bw in PM Demand request. So assign UINT_MAX if SAGV is
+* not enabled. PM Demand code will clamp the value for the register
+*/
+ if (!intel_can_enable_sagv(i915, new_bw_state)) {
+ new_bw_state->qgv_point_peakbw = UINT_MAX;
+ drm_dbg_kms(>drm, "No SAGV, use UINT_MAX as peak bw.");
+ goto out;
+ }
+
+ /*
+* Find the best QGV point by comparing the data_rate with max data rate
+* offered per plane group
+*/
+ for (i = 0; i < num_qgv_points; i++) {
+ unsigned int bw_index =
+ tgl_max_bw_index(i915, num_active_planes, i);
+ unsigned int max_data_rate;
+
+ if (bw_index > ARRAY_SIZE(i915->display.bw.max))
+ continue;
+
+ max_data_rate = i915->display.bw.max[bw_index].deratedbw[i];
+
+ if (max_data_rate < data_rate)
+ continue;
+
+ if (max_data_rate - data_rate < best_rate) {
+ best_rate = max_data_rate - data_rate;
+ qgv_peak_bw = i915->display.bw.max[bw_index].peakbw[i];
+ }
+
+ drm_dbg_kms(>drm, "QGV point %d: max bw %d required %d
qgv_peak_bw: %d\n",
+ i, max_data_rate, data_rate, qgv_peak_bw);
+ }
+
+ drm_dbg_kms(>drm, "Matching peaks QGV bw: %d for required data
rate: %d\n",
+ qgv_peak_bw, data_rate);
+
+ /*
+* The display configuration cannot be supported if no QGV point
+* satisfying the required data rate is found
+*/
+ if (qgv_peak_bw == 0) {
+ drm_dbg_kms(>drm, "No QGV points for bw %d for display
configuration(%d active planes).\n",
+ data_rate, num_active_planes);
+ return -EINVAL;
+ }
+
+ /* MTL PM DEMAND expects QGV BW parameter in multiples of 100 mbps */
+ new_bw_state->qgv_point_peakbw = qgv_peak_bw / 100;
+
+out:
+ if (new_bw_state->qgv_point_peakbw != old_bw_state->qgv_point_peakbw) {
+ ret = intel_atomic_serialize_global_state(_bw_state->base);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int icl_find_qgv_points(struct drm_i915_private *i915,
unsigned int data_rate,
unsigned int num_active_planes,
@@ -928,8 +1007,12 @@ static int intel_bw_check_qgv_points(struct
drm_i915_private *i915,
data_rate = DIV_ROUND_UP(data_rate, 1000);
- return icl_find_qgv_points(i915, data_rate, num_active_planes,
- old_bw_state, new_bw_state);
+ if (DISPLAY_VER(i915) >= 14)
+ return mtl_find_qgv_points(i915, data_rate, num_active_planes,
+ old_bw_state, new_bw_state);
+ else
+ return icl_find_qgv_points(i915, data_rate, num_active_planes,
+ old_bw_state, new_bw_state);
}
static bool intel_bw_state_changed(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index f20292143745..67ae66a3fcdd 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -34,6 +34,12 @@ struct intel_bw_state {
/* bitmask of active pipes */
[Intel-gfx] [PATCH v5 5/8] drm/i915: modify max_bw to return index to intel_bw_info
MTL uses the peak BW of a QGV point to lock the required QGV
point instead of the QGV index. Instead of passing the deratedbw
of the selected bw_info, return the index to the selected
bw_info so that either deratedbw or peakbw can be used based on
the platform.
v2: use idx to store index returned by max_bw_index functions
v3: return UINT_MAX in icl_max_bw_index in case no match found
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 27 -
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index d83aafd0cc2b..f466b4e087bb 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -593,8 +593,8 @@ static void dg2_get_bw_info(struct drm_i915_private *i915)
i915->display.sagv.status = I915_SAGV_NOT_CONTROLLED;
}
-static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
- int num_planes, int qgv_point)
+static unsigned int icl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
{
int i;
@@ -615,14 +615,14 @@ static unsigned int icl_max_bw(struct drm_i915_private
*dev_priv,
return UINT_MAX;
if (num_planes >= bi->num_planes)
- return bi->deratedbw[qgv_point];
+ return i;
}
- return 0;
+ return UINT_MAX;
}
-static unsigned int tgl_max_bw(struct drm_i915_private *dev_priv,
- int num_planes, int qgv_point)
+static unsigned int tgl_max_bw_index(struct drm_i915_private *dev_priv,
+int num_planes, int qgv_point)
{
int i;
@@ -643,10 +643,10 @@ static unsigned int tgl_max_bw(struct drm_i915_private
*dev_priv,
return UINT_MAX;
if (num_planes <= bi->num_planes)
- return bi->deratedbw[qgv_point];
+ return i;
}
- return dev_priv->display.bw.max[0].deratedbw[qgv_point];
+ return 0;
}
static unsigned int adl_psf_bw(struct drm_i915_private *dev_priv,
@@ -823,12 +823,19 @@ static int icl_find_qgv_points(struct drm_i915_private
*i915,
return ret;
for (i = 0; i < num_qgv_points; i++) {
+ unsigned int idx;
unsigned int max_data_rate;
if (DISPLAY_VER(i915) > 11)
- max_data_rate = tgl_max_bw(i915, num_active_planes, i);
+ idx = tgl_max_bw_index(i915, num_active_planes, i);
else
- max_data_rate = icl_max_bw(i915, num_active_planes, i);
+ idx = icl_max_bw_index(i915, num_active_planes, i);
+
+ if (idx > ARRAY_SIZE(i915->display.bw.max))
+ continue;
+
+ max_data_rate = i915->display.bw.max[idx].deratedbw[i];
+
/*
* We need to know which qgv point gives us
* maximum bandwidth in order to disable SAGV
--
2.34.1
[Intel-gfx] [PATCH v5 3/8] drm/i915: store the peak bw per QGV point
In MTL onwards, pcode locks the GV point based on the peak BW
of a QGV point. So store the peak BW of all the QGV points.
v2: use DIV_ROUND_CLOSEST() for the peakBW calculation
Bspec: 64636
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 8 ++--
drivers/gpu/drm/i915/display/intel_display_core.h | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index c8075a37c3ab..db117638d23b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -534,10 +534,14 @@ static int tgl_get_bw_info(struct drm_i915_private
*dev_priv, const struct intel
bi->deratedbw[j] = min(maxdebw,
bw * (100 - sa->derating) / 100);
+ bi->peakbw[j] = DIV_ROUND_CLOSEST(sp->dclk *
+ num_channels *
+ qi.channel_width, 8);
drm_dbg_kms(_priv->drm,
- "BW%d / QGV %d: num_planes=%d
deratedbw=%u\n",
- i, j, bi->num_planes, bi->deratedbw[j]);
+ "BW%d / QGV %d: num_planes=%d deratedbw=%u
peakbw: %u\n",
+ i, j, bi->num_planes, bi->deratedbw[j],
+ bi->peakbw[j]);
}
for (j = 0; j < qi.num_psf_points; j++) {
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index e36f88a39b86..9f66d734edf6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -314,6 +314,8 @@ struct intel_display {
unsigned int deratedbw[I915_NUM_QGV_POINTS];
/* for each PSF GV point */
unsigned int psf_bw[I915_NUM_PSF_GV_POINTS];
+ /* Peak BW for each QGV point */
+ unsigned int peakbw[I915_NUM_QGV_POINTS];
u8 num_qgv_points;
u8 num_psf_gv_points;
u8 num_planes;
--
2.34.1
[Intel-gfx] [PATCH v5 1/8] drm/i915: fix the derating percentage for MTL
Follow the values from bspec for the percentage overhead for
efficiency in MTL BW calculations.
Bspec: 64631
Signed-off-by: Vinod Govindapillai
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 597d5816ad1b..ab405c48ca3a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -379,7 +379,7 @@ static const struct intel_sa_info mtl_sa_info = {
.deburst = 32,
.deprogbwlimit = 38, /* GB/s */
.displayrtids = 256,
- .derating = 20,
+ .derating = 10,
};
static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct
intel_sa_info *sa)
--
2.34.1
[Intel-gfx] [PATCH v5 2/8] drm/i915: update the QGV point frequency calculations
>From MTL onwwards, pcode locks the QGV point based on peak BW of the intended QGV point passed by the driver. So the peak BW calculation must match the value expected by the pcode. Update the calculations as per the Bspec. v2: use DIV_ROUND_* macro for the calculations (Ville) Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c index ab405c48ca3a..c8075a37c3ab 100644 --- a/drivers/gpu/drm/i915/display/intel_bw.c +++ b/drivers/gpu/drm/i915/display/intel_bw.c @@ -182,7 +182,7 @@ static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv, val2 = intel_uncore_read(_priv->uncore, MTL_MEM_SS_INFO_QGV_POINT_HIGH(point)); dclk = REG_FIELD_GET(MTL_DCLK_MASK, val); - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000); + sp->dclk = DIV_ROUND_CLOSEST(16667 * dclk + 500, 1000); sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val); sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val); -- 2.34.1
[Intel-gfx] [PATCH v11 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.
Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 18 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 6 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
5 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 72dd7b9f6dfd..e4a19161afce 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1212,6 +1212,7 @@ static const struct intel_device_info mtl_info = {
.has_mslice_steering = 0,
.has_snoop = 1,
.max_pat_index = 4,
+ .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f143eadbc253..bb2e15329f34 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -289,6 +289,14 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
}
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp)
+{
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ return GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+ else
+ return 250;
+}
+
static int __pxp_global_teardown_final(struct intel_pxp *pxp)
{
int timeout;
@@ -302,10 +310,7 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
- if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
- timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
- else
- timeout = 250;
+ timeout = intel_pxp_get_backend_timeout_ms(pxp);
if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
@@ -325,10 +330,7 @@ static int __pxp_global_teardown_restart(struct intel_pxp
*pxp)
*/
pxp_queue_termination(pxp);
- if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
- timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
- else
- timeout = 250;
+ timeout = intel_pxp_get_backend_timeout_ms(pxp);
if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 17e6dbc86b38..17254c3f1267 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp
*pxp);
void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp);
int intel_pxp_start(struct intel_pxp *pxp);
void intel_pxp_end(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..e07c5b380789 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_debugfs.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_types.h"
@@ -45,6 +46,7 @@ static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
struct intel_gt *gt = pxp->ctrl_gt;
+ int timeout_ms;
if (!intel_pxp_is_active(pxp))
return -ENODEV;
@@ -54,8 +56,10 @@ static int pxp_terminate_set(void *data, u64 val)
intel_pxp_irq_handler(pxp,
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
spin_unlock_irq(gt->irq_lock);
+ timeout_ms = intel_pxp_get_backend_timeout_ms(pxp);
+
if (!wait_for_completion_timeout(>termination,
-msecs_to_jiffies(100)))
+msecs_to_jiffies(timeout_ms)))
return -ETIMEDOUT;
return 0;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index e4d8242302c5..0a3e66b0265e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp,
u32 id, bool in_pla
KCR_SIP(pxp->kcr_base),
[Intel-gfx] [PATCH v5 0/8] mtl: add support for pmdemand
pmdemand support patches for MTL SAGV configuration support for MTL v2: added one missing patch in the previous version v3: chekcpatch warning fixes update index handling for the icl/tgl QGV point handling program pmdemand code simplified v4: update to debufs and pipe values pmdemand regiters removed the macro usage in update_pmdemand_values V5: Addressing comments from Gustavo and Jani And some other fixes for issues from CI Mika Kahola (1): drm/i915/mtl: Add support for PM DEMAND Vinod Govindapillai (7): drm/i915: fix the derating percentage for MTL drm/i915: update the QGV point frequency calculations drm/i915: store the peak bw per QGV point drm/i915: extract intel_bw_check_qgv_points() drm/i915: modify max_bw to return index to intel_bw_info drm/i915/mtl: find the best QGV point for the SAGV configuration drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_bw.c | 353 - drivers/gpu/drm/i915/display/intel_bw.h | 6 + drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 24 +- drivers/gpu/drm/i915/display/intel_display.h | 3 +- .../gpu/drm/i915/display/intel_display_core.h | 8 + .../drm/i915/display/intel_display_driver.c | 7 + .../drm/i915/display/intel_display_power.c| 8 + drivers/gpu/drm/i915/display/intel_dpll.c | 8 +- .../gpu/drm/i915/display/intel_pch_display.c | 2 +- drivers/gpu/drm/i915/display/intel_pmdemand.c | 465 ++ drivers/gpu/drm/i915/display/intel_pmdemand.h | 24 + drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 23 +- drivers/gpu/drm/i915/i915_reg.h | 36 +- 16 files changed, 839 insertions(+), 133 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h -- 2.34.1
[Intel-gfx] [PATCH v11 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use non-priveleged batches for submission to GSC engine
which require two buffers for the request:
- a buffer for the HECI packet that contains PXP FW commands
- a batch-buffer that contains the engine instruction for
sending the HECI packet to the GSC firmware.
Thus, add the allocation and freeing of these buffers in gsccs
init and fini.
The GSC-fw may reply to commands with a SUCCESS but with an
additional pending-bit set in the reply packet. This bit
means the GSC-FW is currently busy and the caller needs to
try again with the gsc_message_handle the fw returned. Thus,
add a wrapper to continuously retry send_message while
replaying the gsc_message_handle. Retries need to follow the
arch-spec count and delay until GSC-FW replies with the real
SUCCESS or timeout after that spec'd delay.
The GSC-fw requires a non-zero host_session_handle provided
by the caller to enable gsc_message_handle tracking. Thus,
allocate the host_session_handle at init and destroy it
at fini (the latter requiring an FYI to the gsc-firmware).
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 3 +-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 240 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 4 +
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 +
5 files changed, 254 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index e790608745d4..ef70e304904a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -51,7 +51,8 @@ struct intel_gsc_mtl_header {
* we distinguish the flags using OUTFLAG or INFLAG
*/
u32 flags;
-#define GSC_OUTFLAG_MSG_PENDING1
+#define GSC_OUTFLAG_MSG_PENDINGBIT(0)
+#define GSC_INFLAG_MSG_CLEANUP BIT(1)
u32 status;
} __packed;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..c65ada99e54f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,9 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
+
/* PXP-Input-Packet: HUC-Authentication */
struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index bad55719a7ac..16e3b73d0653 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,23 +6,232 @@
#include "gem/i915_gem_internal.h"
#include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_types.h"
+static int
+gsccs_send_message(struct intel_pxp *pxp,
+ void *msg_in, size_t msg_in_size,
+ void *msg_out, size_t msg_out_size_max,
+ size_t *msg_out_len,
+ u64 *gsc_msg_handle_retry)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct drm_i915_private *i915 = gt->i915;
+ struct gsccs_session_resources *exec_res = >gsccs_res;
+ struct intel_gsc_mtl_header *header = exec_res->pkt_vaddr;
+ struct intel_gsc_heci_non_priv_pkt pkt;
+ size_t max_msg_size;
+ u32 reply_size;
+ int ret;
+
+ if (!exec_res->ce)
+ return -ENODEV;
+
+ max_msg_size = PXP43_MAX_HECI_INOUT_SIZE - sizeof(*header);
+
+ if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+ return -ENOSPC;
+
+ if (!exec_res->pkt_vma || !exec_res->bb_vma)
+ return -ENOENT;
+
+ GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE));
+
+ mutex_lock(>tee_mutex);
+
+ memset(header, 0, sizeof(*header));
+ intel_gsc_uc_heci_cmd_emit_mtl_header(header, HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec_res->host_session_handle);
+
+ /* check if this is a host-session-handle cleanup call (empty packet) */
+ if (!msg_in && !msg_out)
+ header->flags |= GSC_INFLAG_MSG_CLEANUP;
+
+ /* copy caller provided gsc message
[Intel-gfx] [PATCH v11 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
3- PXP: This series.
NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.
NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
common helpers come in:
- On MTL, when an i915 subsystem needs to send a command request
to the security firmware, it will send that via the GSC-
engine-command-streamer.
- However those commands, (lets call them "gsc_specific_fw_api"
calls), are not understood by the GSC command streamer hw.
- The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
passes it along to the GSC firmware.
- The GSC FW on the other hand needs additional metadata to know
which usage service is being called (PXP, HDCP, proxy, etc) along
with session specific info. Thus an extra header called GSC-CS
HECI Memory Header, (C) in below diagram is prepended before
the FW specific API, (D).
- Thus, the structural layout of the request submitted would
need to look like the diagram below (for non-priv PXP).
- In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
will populate blob (C) while additional helpers, different for
PPGGTT (this patch) vs GGTT (HDCP series) will populate
blobs (A) and (B) below.
___
(A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
| | |
|_| |
| (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,| |
|| pkt-addr-out, pkt-size-out) |
|| MI_BATCH_BUFFER_END| | |
||| | |
| | |
|_| |
|
-
|
\|/
__V___
| _|
|(C)| ||
| | struct intel_gsc_mtl_header { ||
| | validity marker ||
| | heci_clent_id ||
| | ... ||
| | }||
| |___||
|(D)| ||
| | struct gsc_fw_specific_api_foobar { ||
| | ... ||
| | For an example, see ||
| | 'struct pxp43_create_arb_in' at ||
| | intel_pxp_cmd_interface_43.h ||
| | ||
| | } ||
| | Struture depends on command type ||
| | struct gsc_fw_specific_api_foobar { ||
| |___||
||
That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 102 ++
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 23
[Intel-gfx] [PATCH v11 5/8] drm/i915/pxp: Add ARB session creation and cleanup
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
that describe the possible error values when creating a context
with I915_CONTEXT_PARAM_PROTECTED_CONTENT:
Since the first merge of PXP support on ADL, i915 returns -ENXIO
if a dependency such as firmware or component driver was yet to
be loaded or returns -EIO if the creation attempt failed when
requested by the PXP firmware (specific firmware error responses
are reported in dmesg).
Add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.
For both cases, in the back-end gsccs functions for sending messages
to the firmware inspect the GSC-CS-Mem-Header's pending-bit which
means the GSC firmware is busy and we should retry.
Given the last hw requirement, lets also update functions in
front-end layer that wait for session creation or teardown
completion to use new worst case timeout periods.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 27 +++-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 21 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 130 ++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 12 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 11 +-
include/uapi/drm/i915_drm.h | 15 ++
6 files changed, 209 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 8949d4be7882..b600d68de2a4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -291,6 +291,8 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
static int __pxp_global_teardown_final(struct intel_pxp *pxp)
{
+ int timeout;
+
if (!pxp->arb_is_valid)
return 0;
/*
@@ -300,7 +302,12 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
- if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(250)))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+ else
+ timeout = 250;
+
+ if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
return 0;
@@ -308,6 +315,8 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
static int __pxp_global_teardown_restart(struct intel_pxp *pxp)
{
+ int timeout;
+
if (pxp->arb_is_valid)
return 0;
/*
@@ -316,7 +325,12 @@ static int __pxp_global_teardown_restart(struct intel_pxp
*pxp)
*/
pxp_queue_termination(pxp);
- if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(250)))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+ else
+ timeout = 250;
+
+ if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
return 0;
@@ -354,8 +368,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+ if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
+ return -ENXIO;
+ } else {
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
+ }
mutex_lock(>arb_mutex);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index c65ada99e54f..0919cd84 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -11,6 +11,7 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_INIT_SESSION 0x0036
/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
#define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
@@ -26,4 +27,24 @@ struct pxp43_start_huc_auth_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_in {
+ struct pxp_cmd_header header;
+ /* header.stream_id fields for vesion 4.3 of Init PXP session:
*/
+ #define PXP43_INIT_SESSION_VALID BIT(0)
+ #define PXP43_INIT_SESSION_APPTYPE BIT(1)
+ #define PXP43_INIT_SESSION_APPID GENMASK(17, 2)
+ u32 protection_mode;
+
[Intel-gfx] [PATCH v11 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
Because of the additional firmware, component-driver and
initialization depedencies required on MTL platform before a
PXP context can be created, UMD calling for PXP creation as a
way to get-caps can take a long time. An actual real world
customer stack has seen this happen in the 4-to-8 second range
after the kernel starts (which sees MESA's init appear in the
middle of this range as the compositor comes up). To avoid
unncessary delays experienced by the UMD for get-caps purposes,
add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
However, some failures can still occur after all the depedencies
are met (such as firmware init flow failure, bios configurations
or SOC fusing not allowing PXP enablement). Those scenarios will
only be known to user space when it attempts creating a PXP context
and is documented in the GEM UAPI headers.
While making this change, create a helper that is common to both
GET_PARAM caller and intel_pxp_start since the latter does
similar checks.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
Acked-by: Jordan Justen
---
drivers/gpu/drm/i915/i915_getparam.c | 7 +++
drivers/gpu/drm/i915/pxp/intel_pxp.c | 29 +---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
include/uapi/drm/i915_drm.h | 19 ++
4 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..6f11d7eaa91a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,8 @@
#include "gem/i915_gem_mman.h"
#include "gt/intel_engine_user.h"
+#include "pxp/intel_pxp.h"
+
#include "i915_cmd_parser.h"
#include "i915_drv.h"
#include "i915_getparam.h"
@@ -102,6 +104,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
if (value < 0)
return value;
break;
+ case I915_PARAM_PXP_STATUS:
+ value = intel_pxp_get_readiness_status(i915->pxp);
+ if (value < 0)
+ return value;
+ break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
* earlier versions as 0, in effect their value is undefined as
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index b600d68de2a4..f143eadbc253 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -358,23 +358,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
}
/*
- * the arb session is restarted from the irq work when we receive the
- * termination completion interrupt
+ * this helper is used by both intel_pxp_start and by
+ * the GET_PARAM IOCTL that user space calls. Thus, the
+ * return values here should match the UAPI spec.
*/
-int intel_pxp_start(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
{
- int ret = 0;
-
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
- return -ENXIO;
+ return 2;
} else {
if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ return 2;
}
+ return 1;
+}
+
+/*
+ * the arb session is restarted from the irq work when we receive the
+ * termination completion interrupt
+ */
+int intel_pxp_start(struct intel_pxp *pxp)
+{
+ int ret = 0;
+
+ ret = intel_pxp_get_readiness_status(pxp);
+ if (ret < 0)
+ return ret;
+ else if (ret > 1)
+ return -EIO; /* per UAPI spec, user may retry later */
mutex_lock(>arb_mutex);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 3ded0890cd27..17e6dbc86b38 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -26,6 +26,7 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
int intel_pxp_start(struct intel_pxp *pxp);
void intel_pxp_end(struct intel_pxp *pxp);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 0aa3190e7654..ba40855dbc93 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -771,6 +771,25 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57
+/*
+ * Query the status of PXP support in i915.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ * -ENODEV = PXP support is not available on the GPU device or in the
+ *
[Intel-gfx] [PATCH v11 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 32
drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6
5 files changed, 58 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 95e59ed6651d..8f888d36f16d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -107,7 +107,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case OTHER_CLASS:
if (instance == OTHER_GSC_HECI_2_INSTANCE)
return media_gt;
- if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ if ((instance == OTHER_GSC_INSTANCE || instance ==
OTHER_KCR_INSTANCE) &&
+ HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f93aa171aa1e..8949d4be7882 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
}
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+ u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES)
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+ intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, true);
}
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, false);
}
static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
+ if (pxp->ctrl_gt->type == GT_MEDIA)
+ pxp->kcr_base = MTL_KCR_BASE;
+ else
+ pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
ret = create_vcs_context(pxp);
@@ -369,14 +376,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
- kcr_pxp_enable(pxp->ctrl_gt);
+ kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
{
- kcr_pxp_disable(pxp->ctrl_gt);
-
+ kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#define
[Intel-gfx] [PATCH v11 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 15 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c| 3 ++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 4bc276daca16..8dc41de3f6f7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -10,6 +10,7 @@
#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
+#include "intel_pxp.h"
#include "intel_pxp_cmd_interface_42.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
@@ -422,10 +423,22 @@ gsccs_allocate_execution_resource(struct intel_pxp *pxp)
void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
{
+ intel_wakeref_t wakeref;
+
gsccs_destroy_execution_resource(pxp);
+ with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+ intel_pxp_fini_hw(pxp);
}
int intel_pxp_gsccs_init(struct intel_pxp *pxp)
{
- return gsccs_allocate_execution_resource(pxp);
+ int ret;
+ intel_wakeref_t wakeref;
+
+ ret = gsccs_allocate_execution_resource(pxp);
+ if (!ret) {
+ with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+ intel_pxp_init_hw(pxp);
+ }
+ return ret;
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
* The PXP component gets automatically unbound when we go into S3 and
* re-bound after we come out, so in that scenario we can defer the
* hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
*/
- if (!pxp->pxp_component)
+ if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
intel_pxp_init_hw(pxp);
--
2.39.0
[Intel-gfx] [PATCH v11 0/8] drm/i915/pxp: Add MTL PXP Support
This series enables PXP on MTL. On ADL/TGL platforms, we rely on the mei driver via the i915-mei PXP component interface to establish a connection to the security firmware via the HECI device interface. That interface is used to create and teardown the PXP ARB session. PXP ARB session is created when protected contexts are created. In this series, the front end behaviors and interfaces (uapi) remain the same. We add backend support for MTL but with MTL we directly use the GSC-CS engine on the MTL GPU device to send messages to the PXP (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format of the message is slightly different with a 2-layer packetization that is explained in detail in Patch #3. Also, the second layer which is the actual PXP firmware packet is now rev'd to version 4.3 for MTL that is defined in Patch #5. Take note that Patch #4 adds the buffer allocation and gsccs-send- message without actually being called by the arb-creation code which gets added in Patch #5. Additionally, a seperate series being reviewed is introducing a change for session teardown (in pxp front- end layer that will need backend support by both legacy and gsccs). If we squash all of these together (buffer-alloc, send-message, arb-creation and, in future, session-termination), the single patch will be rather large. That said, we are keeping Patch #4 and #5 separate for now, but at merge time, we can squash them together if maintainer requires it. Changes from prior revs: v1 : - fixed when building with CONFIG_PXP disabled. - more alignment with gsc_mtl_header structure from the HDCP v2 : - (all following changes as per reviews from Daniele) - squashed Patch #1 from v1 into the next one. - replaced unnecessary "uses_gsccs" boolean in the pxp with "HAS_ENGINE(pxp->ctrl_gt, GSC0)". - moved the stashing of gsccs resources from a dynamically allocated opaque handle to an explicit sub-struct in 'struct intel_pxp'. - moved the buffer object allocations from Patch #1 of this series to Patch #5 (but keep the context allocation in Patch #1). - used the kernel default ppgtt for the gsccs context. - optimized the buffer allocation and deallocation code and drop the need to stash the drm_i915_gem_object. - use a macro with the right mmio reg base (depending on root-tile vs media-tile) along with common relative offset to access all KCR registers thus minimizing changes to the KCR register access codes. - fixed bugs in the heci packet request submission code in Patch #3 (of this series) - add comments in the mtl-gsc-heci-header regarding the host-session-handle. - re-use tee-mutex instead of introducing a gsccs specific cmd mutex. - minor cosmetic improvements in Patch #5. - before creating arb session, ensure intel_pxp_start first ensures the GSC FW is up and running. - use 2 second timeout for the pending-bit scenario when sending command to GSC-FW as per specs. - simplify intel_pxp_get_irq_gt with addition comments - redo Patch #7 to minimize the changes without introducing a common abstraction helper for suspend/resume/init/fini codes that have to change the kcr power state. v3 : - rebase onto latest drm-tip with the updated firmware session invalidation flow - on Patch#1: move 'mutex_init(>tee_mutex)' to a common init place in intel_pxp_init since its needed everywhere (Daniele) - on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);" (Daniele) - on Patch#2: move the introduction of host_session_handle to Patch#4 where it starts getting used. - on Patch#4: move host-session-handle initialization to the allocate-resources during gsccs-init (away from Patch#5) and add the required call to PXP-firmware to cleanup the host-session-handle in destroy-resources during gsccs-fini - on Patch#5: add dispatching of arb session termination firmware cmd during session teardown (as per latest upstream flows) v4 : - Added proper initialization and cleanup of host-session-handle that the gsc firmware expects. - Fix the stream-session-key invalidation instruction for MTL. v5 : - In Patch #4, move the tee_mutex locking to after we check for valid vma allocations. - In Patch #5, wait for intel_huc_is_authenticated instead of intel_uc_fw_is_running(gsc-fw) before starting ARB session. - In Patch #5, increase the necessary timeouts at the top-level (PXP arb session creation / termination) to accomodate SLA of GSC firmware when busy with pending-bit responses. - In Patch #5, remove redundant host_session_handle init
[Intel-gfx] [PATCH v11 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.
Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 20 +--
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 63 ++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 2 -
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 8 +++
6 files changed, 117 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d97d45ae1a0d..7587fe856e67 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -343,6 +343,7 @@ i915-y += \
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+ pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..f93aa171aa1e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
#include "i915_drv.h"
#include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- ret = intel_pxp_tee_component_init(pxp);
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ ret = intel_pxp_gsccs_init(pxp);
+ else
+ ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
@@ -165,9 +169,12 @@ static struct intel_gt
*find_gt_for_required_protected_content(struct drm_i915_p
/*
* For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
* on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC and HUC firmware are coming online
*/
- if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+ if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+ intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw) &&
+ intel_uc_fw_is_loadable(>media_gt->uc.huc.fw))
return i915->media_gt;
/*
@@ -207,7 +214,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
+ /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+ mutex_init(>pxp->tee_mutex);
/*
* If full PXP feature is not available but HuC is loaded by GSC on
pre-MTL
@@ -229,7 +238,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- intel_pxp_tee_component_fini(i915->pxp);
+ if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+ intel_pxp_gsccs_fini(i915->pxp);
+ else
+ intel_pxp_tee_component_fini(i915->pxp);
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..bad55719a7ac
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+ struct gsccs_session_resources *exec_res = >gsccs_res;
+
+ if (exec_res->ce)
+ intel_context_put(exec_res->ce);
+
+ memset(exec_res, 0, sizeof(*exec_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+ struct intel_gt *gt =
Re: [Intel-gfx] [PATCH v2 25/27] KVM: x86/mmu: Drop @slot param from exported/external page-track APIs
On Mon, May 08, 2023, Yan Zhao wrote:
> On Thu, May 04, 2023 at 10:17:20AM +0800, Yan Zhao wrote:
> > On Wed, May 03, 2023 at 04:16:10PM -0700, Sean Christopherson wrote:
> > > Finally getting back to this series...
> > >
> > > On Thu, Mar 23, 2023, Yan Zhao wrote:
> > > > On Fri, Mar 17, 2023 at 04:28:56PM +0800, Yan Zhao wrote:
> > > > > On Fri, Mar 10, 2023 at 04:22:56PM -0800, Sean Christopherson wrote:
> > > > > ...
> > > > > > +int kvm_write_track_add_gfn(struct kvm *kvm, gfn_t gfn)
> > > > > > +{
> > > > > > + struct kvm_memory_slot *slot;
> > > > > > + int idx;
> > > > > > +
> > > > > > + idx = srcu_read_lock(>srcu);
> > > > > > +
> > > > > > + slot = gfn_to_memslot(kvm, gfn);
> > > > > > + if (!slot) {
> > > > > > + srcu_read_unlock(>srcu, idx);
> > > > > > + return -EINVAL;
> > > > > > + }
> > > > > > +
> > > > > Also fail if slot->flags & KVM_MEMSLOT_INVALID is true?
> > > > > There should exist a window for external users to see an invalid slot
> > > > > when a slot is about to get deleted/moved.
> > > > > (It happens before MOVE is rejected in
> > > > > kvm_arch_prepare_memory_region()).
> > > >
> > > > Or using
> > > > if (!kvm_is_visible_memslot(slot)) {
> > > > srcu_read_unlock(>srcu, idx);
> > > > return -EINVAL;
> > > > }
> > >
> Hi Sean,
> After more thoughts, do you think checking KVM internal memslot is necessary?
I don't think it's necessary per se, but I also can't think of any reason to
allow
it.
> slot = gfn_to_memslot(kvm, gfn);
> if (!slot || slot->id >= KVM_USER_MEM_SLOTS) {
> srcu_read_unlock(>srcu, idx);
> return -EINVAL;
> }
>
> Do we allow write tracking to APIC access page when APIC-write VM exit
> is not desired?
Allow? Yes.
But KVM doesn't use write-tracking for anything APICv related, e.g. to disable
APICv, KVM instead zaps the SPTEs for the APIC access page and on page fault
goes
straight to MMIO emulation.
Theoretically, the guest could create an intermediate PTE in the APIC access
page
and AFAICT KVM would shadow the access and write-protect the APIC access page.
But that's benign as the resulting emulation would be handled just like emulated
APIC MMIO.
FWIW, the other internal memslots, TSS and idenity mapped page tables, are used
if and only if paging is disabled in the guest, i.e. there are no guest PTEs for
KVM to shadow (and paging must be enabled to enable VMX, so nested EPT is also
ruled out). So this is theoretically possible only for the APIC access page.
That changes with KVMGT, but that again should not be problematic. KVM will
emulate in response to the write-protected page and things go on. E.g. it's
arguably much weirder that the guest can read/write the identity mapped page
tables that are used for EPT without unrestricted guest.
There's no sane reason to allow creating PTEs in the APIC page, but I'm also not
all that motivated to "fix" things. account_shadowed() isn't expected to fail,
so KVM would need to check further up the stack, e.g. in walk_addr_generic() by
open coding a form of kvm_vcpu_gfn_to_hva_prot().
I _think_ that's the only place KVM would need to add a check, as KVM already
checks that the root, i.e. CR3, is in a "visible" memslot. I suppose KVM could
just synthesize triple fault, like it does for the root/CR3 case, but I don't
like making up behavior.
In other words, I'm not opposed to disallowing write-tracking internal memslots,
but I can't think of anything that will break, and so for me personally at
least,
the ROI isn't sufficient to justify writing tests and dealing with any fallout.
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Init DDI ports based on port_mask
== Series Details ==
Series: drm/i915: Init DDI ports based on port_mask
URL : https://patchwork.freedesktop.org/series/117641/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13138 -> Patchwork_117641v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117641v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117641v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/index.html
Participating hosts (41 -> 39)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117641v1:
### IGT changes ###
Possible regressions
* igt@i915_module_load@load:
- fi-hsw-4770:[PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/fi-hsw-4770/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/fi-hsw-4770/igt@i915_module_l...@load.html
Warnings
* igt@kms_psr@sprite_plane_onoff:
- bat-rplp-1: [SKIP][3] ([i915#1072]) -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html
Known issues
Here are the changes found in Patchwork_117641v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][7] -> [DMESG-WARN][8] ([i915#7699] /
[i915#7953])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][9] -> [ABORT][10] ([i915#4983] / [i915#7461] /
[i915#7953] / [i915#8347] / [i915#8384])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/bat-rpls-1/igt@i915_selftest@l...@reset.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][11] ([i915#6367])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][12] ([i915#6687])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#1845] / [i915#5354]) +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
Possible fixes
* igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][14] ([i915#4983] / [i915#7461] / [i915#7913]
/ [i915#7981] / [i915#8347]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/bat-rpls-2/igt@i915_selftest@l...@reset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- {bat-mtlp-6}: [DMESG-WARN][16] ([i915#6367] / [i915#7953]) ->
[PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [FAIL][18] ([i915#7932]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117641v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1072]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Init DDI ports based on port_mask
== Series Details == Series: drm/i915: Init DDI ports based on port_mask URL : https://patchwork.freedesktop.org/series/117641/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Init DDI ports based on port_mask
== Series Details == Series: drm/i915: Init DDI ports based on port_mask URL : https://patchwork.freedesktop.org/series/117641/ State : warning == Summary == Error: dim checkpatch failed 7fa5a06bde61 drm/i915: Remove bogus DDI-F from hsw/bdw output init 6ce69347aa4f drm/i915: Introduce device info port_mask -:101: WARNING:LONG_LINE: line length of 127 exceeds 100 columns #101: FILE: drivers/gpu/drm/i915/i915_pci.c:440: + .__runtime.port_mask = BIT(PORT_A) | BIT(PORT_B) | BIT(PORT_C) | BIT(PORT_D), /* DP A, SDVO/HDMI/DP B, HDMI/DP C/D */ \ -:109: WARNING:LONG_LINE: line length of 127 exceeds 100 columns #109: FILE: drivers/gpu/drm/i915/i915_pci.c:474: + .__runtime.port_mask = BIT(PORT_A) | BIT(PORT_B) | BIT(PORT_C) | BIT(PORT_D), /* DP A, SDVO/HDMI/DP B, HDMI/DP C/D */ \ -:117: WARNING:LONG_LINE: line length of 127 exceeds 100 columns #117: FILE: drivers/gpu/drm/i915/i915_pci.c:530: + .__runtime.port_mask = BIT(PORT_A) | BIT(PORT_B) | BIT(PORT_C) | BIT(PORT_D), /* DP A, SDVO/HDMI/DP B, HDMI/DP C/D */ \ -:133: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #133: FILE: drivers/gpu/drm/i915/i915_pci.c:625: + .__runtime.port_mask = BIT(PORT_A) | BIT(PORT_B) | BIT(PORT_C) | BIT(PORT_D) | BIT(PORT_E), \ -:182: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #182: FILE: drivers/gpu/drm/i915/i915_pci.c:975: + BIT(PORT_TC1) | BIT(PORT_TC2) | BIT(PORT_TC3) | BIT(PORT_TC4) | BIT(PORT_TC5) | BIT(PORT_TC5), total: 0 errors, 5 warnings, 0 checks, 221 lines checked df8440f39780 drm/i915: Assert that device info bitmasks have enough bits 0e900d67d1e2 drm/i915: Assert that the port being initialized is valid 348418653bae drm/i915: Beef up SDVO/HDMI port checks bc3590232d71 drm/i915: Init DDI outputs based on port_mask on skl+ 9569bea38e15 drm/i915: Convert HSW/BDW to use port_mask for DDI probe
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: drop dependency on VLV_DISPLAY_BASE (rev2)
== Series Details ==
Series: drm/i915/gt: drop dependency on VLV_DISPLAY_BASE (rev2)
URL : https://patchwork.freedesktop.org/series/117620/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13138 -> Patchwork_117620v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/index.html
Participating hosts (41 -> 40)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117620v2 that come from known issues:
### IGT changes ###
Possible fixes
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [FAIL][1] ([i915#7932]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
Warnings
* igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][3] ([i915#4983] / [i915#7461] / [i915#7913] /
[i915#7981] / [i915#8347]) -> [ABORT][4] ([i915#4983] / [i915#7461] /
[i915#7913] / [i915#8347])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13138/bat-rpls-2/igt@i915_selftest@l...@reset.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/bat-rpls-2/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#7461]: https://gitlab.freedesktop.org/drm/intel/issues/7461
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7953]: https://gitlab.freedesktop.org/drm/intel/issues/7953
[i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981
[i915#8347]: https://gitlab.freedesktop.org/drm/intel/issues/8347
Build changes
-
* Linux: CI_DRM_13138 -> Patchwork_117620v2
CI-20190529: 20190529
CI_DRM_13138: b35107d813ef012806df9a1ff9f37adf0400 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7285: d1cbf2bad9c2664ab8bd3bd0946510a52800912f @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_117620v2: b35107d813ef012806df9a1ff9f37adf0400 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
e3c79c487d6b drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v2/index.html
Re: [Intel-gfx] [PATCH 2/2] drm/i915/mtl: Add handling for MTL ccs modifiers
On Thu, May 11, 2023 at 01:37:14PM +0300, Juha-Pekka Heikkila wrote:
> Add Tile4 ccs modifiers w/ auxbuffer handling
Commit message should include the workarounds implemented
Wa_14017240301.
>
Bspec: 49251, 49252, 49253
with white space revisions, and commit message update:
Reviewed-by: Matt Atwood
> Signed-off-by: Juha-Pekka Heikkila
> Reviewed-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 42 ++-
> .../drm/i915/display/skl_universal_plane.c| 22 +-
> 2 files changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index c004f08fcfe1..f9420a68ed3c 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -157,6 +157,32 @@ struct intel_modifier_desc {
>
> static const struct intel_modifier_desc intel_modifiers[] = {
> {
> + .modifier = I915_FORMAT_MOD_4_TILED_MTL_MC_CCS,
> + .display_ver = { 14, 14 },
> + .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
> +
> + .ccs.packed_aux_planes = BIT(1),
> + .ccs.planar_aux_planes = BIT(2) | BIT(3),
> +
> + FORMAT_OVERRIDE(gen12_ccs_formats),
> + }, {
> + .modifier = I915_FORMAT_MOD_4_TILED_MTL_RC_CCS,
> + .display_ver = { 14, 14 },
> + .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_RC,
> +
> + .ccs.packed_aux_planes = BIT(1),
> +
> + FORMAT_OVERRIDE(gen12_ccs_formats),
> + }, {
> + .modifier = I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC,
> + .display_ver = { 14, 14 },
> + .plane_caps = INTEL_PLANE_CAP_TILING_4 |
> INTEL_PLANE_CAP_CCS_RC_CC,
> +
> + .ccs.cc_planes = BIT(2),
> + .ccs.packed_aux_planes = BIT(1),
> +
> + FORMAT_OVERRIDE(gen12_ccs_cc_formats),
> + }, {
> .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
> .display_ver = { 13, 13 },
> .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
> @@ -370,6 +396,14 @@ static bool plane_has_modifier(struct drm_i915_private
> *i915,
> if (!plane_caps_contain_all(plane_caps, md->plane_caps))
> return false;
>
> + /*
> + * Separate AuxCCS and Flat CCS modifiers to be run only on platforms
> + * where supported.
> + */
> + if (intel_fb_is_ccs_modifier(md->modifier) &&
> +HAS_FLAT_CCS(i915) != !md->ccs.packed_aux_planes)
please align HAS_FLAT_CCS with intel_fb_is_css_modifier
> + return false;
> +
> return true;
> }
>
> @@ -489,7 +523,7 @@ static bool intel_fb_is_gen12_ccs_aux_plane(const struct
> drm_framebuffer *fb, in
> {
> const struct intel_modifier_desc *md = lookup_modifier(fb->modifier);
>
> - return check_modifier_display_ver_range(md, 12, 13) &&
> + return check_modifier_display_ver_range(md, 12, 14) &&
> ccs_aux_plane_mask(md, fb->format) & BIT(color_plane);
> }
>
> @@ -605,6 +639,9 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
> int color_plane)
> if (intel_fb_is_ccs_aux_plane(fb, color_plane))
> return 128;
> fallthrough;
> + case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
> + case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
> + case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> @@ -791,6 +828,9 @@ unsigned int intel_surf_alignment(const struct
> drm_framebuffer *fb,
> case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> + case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
> + case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
> + case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
> return 16 * 1024;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 8ea0598a5a07..f6f760e59c9e 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -789,6 +789,14 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
> PLANE_CTL_CLEAR_COLOR_DISABLE;
> case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
> return PLANE_CTL_TILED_4 |
> PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
> + case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
> + return PLANE_CTL_TILED_4 |
> + PLANE_CTL_RENDER_DECOMPRESSION_ENABLE |
> + PLANE_CTL_CLEAR_COLOR_DISABLE;
> + case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
> +
Re: [Intel-gfx] [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.
Hey, On 2023-05-11 12:14, Tvrtko Ursulin wrote: > > On 10/05/2023 19:46, Tejun Heo wrote: >> Hello, >> >> On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote: >>> The misc controller is not granular enough. A single computer may have any >>> number of >>> graphics cards, some of them with multiple regions of vram inside a single >>> card. >> >> Extending the misc controller to support dynamic keys shouldn't be that >> difficult. >> >> ... >>> In the next version, I will move all the code for handling the resource >>> limit to >>> TTM's eviction layer, because otherwise it cannot handle the resource limit >>> correctly. >>> >>> The effect of moving the code to TTM, is that it will make the code even >>> more generic >>> for drivers that have vram and use TTM. When using TTM, you only have to >>> describe your >>> VRAM, update some fields in the TTM manager and (un)register your device >>> with the >>> cgroup handler on (un)load. It's quite trivial to add vram accounting to >>> amdgpu and >>> nouveau. [2] >>> >>> If you want to add a knob for scheduling weight for a process, it makes >>> sense to >>> also add resource usage as a knob, otherwise the effect of that knob is very >>> limited. So even for Tvrtko's original proposed usecase, it would make >>> sense. >> >> It does make sense but unlike Tvrtko's scheduling weights what's being >> proposed doesn't seem to encapsulate GPU memory resource in a generic enough >> manner at least to my untrained eyes. ie. w/ drm.weight, I don't need any >> specific knoweldge of how a specific GPU operates to say "this guy should >> get 2x processing power over that guy". This more or less holds for other >> major resources including CPU, memory and IO. What you're proposing seems a >> lot more tied to hardware details and users would have to know a lot more >> about how memory is configured on that particular GPU. >> >> Now, if this is inherent to how all, or at least most, GPUs operate, sure, >> but otherwise let's start small in terms of interface and not take up space >> which should be for something universal. If this turns out to be the way, >> expanding to take up the generic interface space isn't difficult. >> >> I don't know GPU space so please educate me where I'm wrong. > > I was hoping it might be passable in principle (in some form, pending > discussion on semantics) given how Maarten's proposal starts with only very > specific per-device-per-memory regions controls, which is applicable to many > devices. And hard limit at that, which probably has less complicated > semantics, or at least implementation. > > My understanding of the proposal is that the allocation either fits, or it > evicts from the parent's hierarchy (if possible) and then fits, or it fails. > Which sounds simple enough. Yeah, for vram itś that simple. I think for mapped and sysmem regions we may require the possiblity to ignore the limits as well, as it's possible to move to those regions from eviction. We probably don't want eviction to fail because of too low limits. > I do however agree that it is a limited use case. So from the negative side > of the debating camp I have to ask if this use case could be simply satisfied > by providing a driver/device global over commit yes/no control? In other > words, is it really important to partition the vram space ahead of time, and > from the kernel side too? Wouldn't the relevant (highly specialised) > applications work just fine with global over commit disabled? Even if the > option to configure their maximum allowed working set from the userspace side > was needed. Disabling overcommit? Do you mean pinning the memory workload? This causes a denial of service if done without limits, and that's what we're trying to avoid. There is no need for immunity from eviction. Overcommit is still useful inside the cgroup itself, we only want immunity from being evicted by another process performing another workload. > Or if we conclude cgroup controller is the way to go, would adding less > specific limits make it more palatable? I am thinking here some generic > "device memory resident". Not per device, not per memory region. So > userspace/admins have some chance of configuring generic limits. That would > require coming up with more generic use cases though so another thing to > discuss. Like who would use that and for what. You would run into ambiguity with that. I think it's fine to assume any number of vram regions. In most cases, the number is 1. I don't see that number going much higher, 2 is already on the high side. A simple controller could just half each region separately. > Assuming also we can agree that "device memory resident" is a stable/solid > concept across drm. Should be easier than for integrated GPUs, for which I > have to admit I currently don't remember if allocations are already > consistently covered by the memory controller. Even if they are ownership is > probably
Re: [Intel-gfx] [PATCH 1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers
On Thu, May 11, 2023 at 01:37:13PM +0300, Juha-Pekka Heikkila wrote:
> Add Tile4 type ccs modifiers with aux buffer needed for MTL
>
Bspec: 49251, 49252, 49253
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula
Reviewed-by: Matt Atwood
> Signed-off-by: Juha-Pekka Heikkila
> ---
> include/uapi/drm/drm_fourcc.h | 43 +++
> 1 file changed, 43 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index de703c6be969..cbe214adf1e4 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -657,6 +657,49 @@ extern "C" {
> */
> #define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12)
>
> +/*
> + * Intel color control surfaces (CCS) for display ver 14 render compression.
nit: Color Control Surfaces, ver.
> + *
> + * The main surface is tile4 and at plane index 0, the CCS is linear and
> + * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
> + * main surface. In other words, 4 bits in CCS map to a main surface cache
> + * line pair. The main surface pitch is required to be a multiple of four
> + * tile4 widths.
> + */
> +#define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS fourcc_mod_code(INTEL, 13)
> +
> +/*
> + * Intel color control surfaces (CCS) for display ver 14 media compression
nit: Color Control Surfaces, ver.
> + *
> + * The main surface is tile4 and at plane index 0, the CCS is linear and
> + * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
> + * main surface. In other words, 4 bits in CCS map to a main surface cache
> + * line pair. The main surface pitch is required to be a multiple of four
> + * tile4 widths. For semi-planar formats like NV12, CCS planes follow the
> + * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
> + * planes 2 and 3 for the respective CCS.
> + */
> +#define I915_FORMAT_MOD_4_TILED_MTL_MC_CCS fourcc_mod_code(INTEL, 14)
> +
> +/*
> + * Intel Color Control Surface with Clear Color (CCS) for display ver 14
> render
nit: ver.
> + * compression.
> + *
> + * The main surface is tile4 and is at plane index 0 whereas CCS is linear
> + * and at index 1. The clear color is stored at index 2, and the pitch should
> + * be ignored. The clear color structure is 256 bits. The first 128 bits
> + * represents Raw Clear Color Red, Green, Blue and Alpha color each
> represented
> + * by 32 bits. The raw clear color is consumed by the 3d engine and generates
> + * the converted clear color of size 64 bits. The first 32 bits store the
> Lower
> + * Converted Clear Color value and the next 32 bits store the Higher
> Converted
> + * Clear Color value when applicable. The Converted Clear Color values are
> + * consumed by the DE. The last 64 bits are used to store Color Discard
> Enable
> + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
> + * corresponds to an area of 4x1 tiles in the main surface. The main surface
> + * pitch is required to be a multiple of 4 tile widths.
> + */
> +#define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15)
> +
> /*
> * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> *
> --
> 2.25.1
>
Re: [Intel-gfx] [PATCH v4 14/14] drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects
On Wed, May 10, 2023 at 01:31:31PM +0300, Imre Deak wrote:
> If the output on a DP-alt link with its sink disconnected is kept
> enabled for too long (about 20 sec), then some IOM/TCSS firmware timeout
> will cause havoc on the PCI bus, at least for other GFX devices on it
> which will stop powering up. Since user space is not guaranteed to do a
> disabling modeset in time, switch such disconnected but active links to
> TBT mode - which is without such shortcomings - with a 2 second delay.
>
> If the above condition is detected already during the driver load/system
> resume sanitization step disable the output instead, as at that point no
> user space or kernel client depends on a consistent output state yet and
> because subsequent atomic modeset on such connectors - without the
> actual sink capabilities available - can fail.
>
> An active/disconnected port as above will also block the HPD status of
> other active/disconnected ports to get updated (stuck in the connected
> state), until the former port is disabled, its PHY is disconnected and
> a ~10 ms delay has elapsed. This means the link state for all TypeC
> ports/CRTCs must be rechecked after a CRTC is disabled due to the above
> reason. For this disconnect the PHY synchronously after the CRTC/port is
> disabled and recheck all CRTCs for the above condition whenever such a
> port is disabled.
>
> To account for a race condition during driver loading where the sink is
> disconnected after the above sanitization step and before the HPD
> interrupts get enabled, do an explicit check/link reset if needed from
> the encoder's late_register hook, which is called after the HPD
> interrupts are enabled already.
>
> v2:
> - Handle an active/disconnected port blocking the HPD state update of
> another active/disconnected port.
> - Cancel the delayed work resetting the link also from the encoder
> enable/suspend/shutdown hooks.
> - Rebase on the earlier intel_modeset_lock_ctx_retry() addition,
> fixing here the missed atomic state reset in case of a retry.
> - Fix handling of an error return from intel_atomic_get_crtc_state().
> - Recheck if the port needs to be reset after all the atomic state
> is locked and async commits are waited on.
>
> v3:
> - Add intel_crtc_needs_link_reset(), instead of open-coding it,
> keep intel_crtc_has_encoders(). (Ville)
> - Fix state dumping and use a bitmask to track disabled CRTCs in
> intel_sanitize_all_crtcs(). (Ville)
> - Set internal in intel_atomic_state right after allocating it.
> (Ville)
> - Recheck all CRTCs (not yet force-disabled) after a CRTC is
> force-disabled for any reason (not only due to a link state)
> in intel_sanitize_all_crtcs().
> - Reduce delay after CRTC disabling to 20ms, and use the simpler
> msleep().
> - Clarify code comment about HPD behaviour in
> intel_sanitize_all_crtcs().
> - Move all the TC link reset logic to intel_tc.c .
> - Cancel the link reset work synchronously during system suspend,
> driver unload and shutdown.
>
> v4:
> - Rebased on previous patch, which allows calling the TC port
> suspend/cleanup handlers without modeset locks held; remove the
> display driver suspended assert from the link reset work
> accordingly.
>
> Cc: Kai-Heng Feng
> Cc: Ville Syrjälä
> Tested-by: Kai-Heng Feng
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5860
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 32 +++-
> drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
> drivers/gpu/drm/i915/display/intel_dp.h | 3 +
> .../drm/i915/display/intel_modeset_setup.c| 85 --
> drivers/gpu/drm/i915/display/intel_tc.c | 156 +-
> drivers/gpu/drm/i915/display/intel_tc.h | 5 +-
> 6 files changed, 262 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 7d09bd2412352..b443a79bc9803 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3313,6 +3313,8 @@ static void intel_disable_ddi(struct intel_atomic_state
> *state,
> const struct intel_crtc_state *old_crtc_state,
> const struct drm_connector_state *old_conn_state)
> {
> + intel_tc_port_link_cancel_reset_work(enc_to_dig_port(encoder));
> +
> intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
>
> if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
> @@ -3381,6 +3383,8 @@ intel_ddi_pre_pll_enable(struct intel_atomic_state
> *state,
> enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> bool is_tc_port = intel_phy_is_tc(dev_priv, phy);
>
> + intel_tc_port_link_cancel_reset_work(dig_port);
Can the reset work still be schduled at this time?
> +
> if (is_tc_port) {
> struct intel_crtc *master_crtc =
>
Re: [Intel-gfx] [PATCH 6/6] drm/i915/pmu: Export counters from all tiles
On Fri, 05 May 2023 17:58:16 -0700, Umesh Nerlige Ramappa wrote:
>
One drive-by comment:
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 12b2f3169abf..284e5c5b97bb 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -546,8 +546,9 @@ config_status(struct drm_i915_private *i915, u64 config)
> struct intel_gt *gt = to_gt(i915);
>
> unsigned int gt_id = config_gt_id(config);
> + unsigned int max_gt_id = HAS_EXTRA_GT_LIST(i915) ? 1 : 0;
But in Patch 5 we have:
#define I915_PMU_MAX_GTS (4)
>
> - if (gt_id)
> + if (gt_id > max_gt_id)
> return -ENOENT;
>
> switch (config_counter(config)) {
> @@ -561,6 +562,8 @@ config_status(struct drm_i915_private *i915, u64 config)
> return -ENODEV;
> break;
> case I915_PMU_INTERRUPTS:
> + if (gt_id)
> + return -ENOENT;
> break;
> case I915_PMU_RC6_RESIDENCY:
> if (!gt->rc6.supported)
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning
On Wed, 10 May 2023 11:36:06 -0700, Ashutosh Dixit wrote:
>
> Loading i915 on UBSAN enabled kernels (CONFIG_UBSAN/CONFIG_UBSAN_BOOL)
> causes the following warning:
>
> UBSAN: invalid-load in drivers/gpu/drm/i915/gt/uc/intel_uc.c:558:2
> load of value 255 is not a valid value for type '_Bool'
> Call Trace:
>dump_stack_lvl+0x57/0x7d
>ubsan_epilogue+0x5/0x40
>__ubsan_handle_load_invalid_value.cold+0x43/0x48
>__uc_init_hw+0x76a/0x903 [i915]
>...
>i915_driver_probe+0xfb1/0x1eb0 [i915]
>i915_pci_probe+0xbe/0x2d0 [i915]
>
> The warning happens because during probe i915_hwmon is still not available
> which results in the output boolean variable *old remaining
> uninitialized.
Note that the variable was uninitialized in this case but it was never used
uninitialized (the variable was not needed when it was uninitialized). So
there was no bug in the code. UBSAN warning is just complaining about the
uninitialized variable being passed into a function (where it is not used).
Also the variable can be initialized in the caller (__uc_init_hw) too and
it will fix this issue. However in __uc_init_hw the assumption is that the
variable will be initialized in the callee (i915_hwmon_power_max_disable),
so that is how I have done it in this patch.
I thought these clarifications will help with the review.
Thanks.
--
Ashutosh
> Silence the warning by initializing the variable to an arbitrary value.
>
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index a3bdd9f68a458..685663861bc0b 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -502,8 +502,11 @@ void i915_hwmon_power_max_disable(struct
> drm_i915_private *i915, bool *old)
> struct i915_hwmon *hwmon = i915->hwmon;
> u32 r;
>
> - if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> + if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit)) {
> + /* Fix uninitialized bool variable warning */
> + *old = false;
> return;
> + }
>
> mutex_lock(>hwmon_lock);
>
> --
> 2.38.0
>
Re: [Intel-gfx] [PATCH v4 13/14] drm/i915/tc: Call TypeC port flush_work/cleanup without modeset locks held
On Wed, May 10, 2023 at 05:10:22PM +0300, Imre Deak wrote:
> On Wed, May 10, 2023 at 05:03:17PM +0300, Ville Syrjälä wrote:
> > On Wed, May 10, 2023 at 01:31:30PM +0300, Imre Deak wrote:
> > > Call the TypeC port flush_work and cleanup handlers without the modeset
> > > locks held. These don't require the locks, as the work takes - as it
> > > should be able to at any point in time - any locks it needs and by the
> > > time cleanup is called and after cleanup returns the encoder is not in
> > > use.
> > >
> > > This is required by the next patch canceling a TypeC port work
> > > synchronously during encoder suspend and shutdown, where the work can
> > > take modeset locks as well, hence the canceling must be done without
> > > holding the locks.
> > >
> > > I also considered moving the modeset locking down to each encoder
> > > suspend()/shutdown() hook instead, however locking the full modeset
> > > state for each encoder separately would be odd, and the bigger change -
> > > affecting all encoders - is beyond the scope of this patchset.
> >
> > Hmm. What is it in the encoder shutdown/suspend hooks that
> > actually needs the modeset locks?
>
> In the case of intel_dp_encoder_suspend() for instance, I assume
> nothing, since the VDD work and intel_pps_vdd_off_sync() should take
> whatever locks they require.
>
> So presumably most (all) of those could be made lockless. However, I
> would like to leave that kind of change for a follow-up if possible, not
> to affect in this patchset any other encoder types (again because of
> possible need for CC stable).
Yeah sure. A bit irksome to have to add vfuncs and whatnot for
it though, but it's not the end of the world.
Reviewed-by: Ville Syrjälä
>
> >
> > >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 27 +--
> > > .../drm/i915/display/intel_display_types.h| 12 +
> > > drivers/gpu/drm/i915/i915_driver.c| 8 ++
> > > 3 files changed, 33 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 813be957ed11b..7d09bd2412352 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -4617,31 +4617,27 @@ static bool intel_ddi_is_tc(struct
> > > drm_i915_private *i915, enum port port)
> > >
> > > static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
> > > {
> > > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > - enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > -
> > > intel_dp_encoder_suspend(encoder);
> > > +}
> > >
> > > - if (!intel_phy_is_tc(i915, phy))
> > > - return;
> > > +static void intel_ddi_tc_encoder_suspend_complete(struct intel_encoder
> > > *encoder)
> > > +{
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > >
> > > intel_tc_port_flush_work(dig_port);
> > > }
> > >
> > > static void intel_ddi_encoder_shutdown(struct intel_encoder *encoder)
> > > {
> > > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > - enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > -
> > > intel_dp_encoder_shutdown(encoder);
> > > intel_hdmi_encoder_shutdown(encoder);
> > > +}
> > >
> > > - if (!intel_phy_is_tc(i915, phy))
> > > - return;
> > > +static void intel_ddi_tc_encoder_shutdown_complete(struct intel_encoder
> > > *encoder)
> > > +{
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > >
> > > intel_tc_port_cleanup(dig_port);
> > > }
> > > @@ -4908,6 +4904,9 @@ void intel_ddi_init(struct drm_i915_private
> > > *dev_priv, enum port port)
> > > is_legacy ? "legacy" : "non-legacy");
> > > }
> > >
> > > + encoder->suspend_complete =
> > > intel_ddi_tc_encoder_suspend_complete;
> > > + encoder->shutdown_complete =
> > > intel_ddi_tc_encoder_shutdown_complete;
> > > +
> > > if (intel_tc_port_init(dig_port, is_legacy) < 0)
> > > goto err;
> > > }
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 270c4c84a2920..88b2a55d19f21 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -233,13 +233,25 @@ struct intel_encoder {
> > >* Called during system suspend after all pending
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers
== Series Details == Series: series starting with [1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers URL : https://patchwork.freedesktop.org/series/117625/ State : success == Summary == CI Bug Log - changes from CI_DRM_13134_full -> Patchwork_117625v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (7 -> 7) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_117625v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-hang: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-snb6/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][4] -> [ABORT][5] ([i915#5566]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/shard-apl3/igt@gen9_exec_pa...@allowed-all.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-apl6/igt@gen9_exec_pa...@allowed-all.html * igt@i915_module_load@reload-with-fault-injection: - shard-snb: [PASS][6] -> [INCOMPLETE][7] ([i915#8294]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/shard-snb6/igt@i915_module_l...@reload-with-fault-injection.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-snb7/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_pm_rps@engine-order: - shard-apl: [PASS][8] -> [FAIL][9] ([i915#6537]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/shard-apl6/igt@i915_pm_...@engine-order.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-apl7/igt@i915_pm_...@engine-order.html * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-async-flip: - shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271]) +77 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-snb6/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html * igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3886]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-glk3/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-apl: [PASS][12] -> [FAIL][13] ([i915#2346]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a2: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#79]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/shard-glk7/igt@kms_flip@flip-vs-expired-vbl...@c-hdmi-a2.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-glk1/igt@kms_flip@flip-vs-expired-vbl...@c-hdmi-a2.html * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1: - shard-apl: [PASS][16] -> [ABORT][17] ([i915#180]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/shard-apl1/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-apl6/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html * igt@kms_hdr@invalid-hdr: - shard-glk: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4579]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-glk3/igt@kms_...@invalid-hdr.html * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-vga-1: - shard-snb: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4579]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-snb2/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-...@pipe-b-vga-1.html * igt@kms_psr2_su@page_flip-nv12: - shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/shard-glk3/igt@kms_psr2_su@page_flip-nv12.html * igt@kms_vblank@pipe-d-wait-busy-hang: - shard-glk: NOTRUN -> [SKIP][21] ([fdo#109271]) +38 similar issues [21]:
[Intel-gfx] [PATCH 7/7] drm/i915: Convert HSW/BDW to use port_mask for DDI probe
From: Ville Syrjälä
Make HSW/BDW use port_mask for output probing as well.
To achieve that the strap checks are moved into
intel_ddi_init() itself. Or should we move them to the
runtime port_mask init instead? Maybe not since the hardware
is still there, just not connected to anything.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 27
drivers/gpu/drm/i915/display/intel_display.c | 17 +---
2 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a5ca4b9d1e3e..6c07f32d7116 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4660,6 +4660,27 @@ static void intel_ddi_encoder_shutdown(struct
intel_encoder *encoder)
#define port_tc_name(port) ((port) - PORT_TC1 + '1')
#define tc_port_name(tc_port) ((tc_port) - TC_PORT_1 + '1')
+static bool port_strap_detected(struct drm_i915_private *i915, enum port port)
+{
+ /* straps not used on skl+ */
+ if (DISPLAY_VER(i915) >= 9)
+ return true;
+
+ switch (port) {
+ case PORT_A:
+ return intel_de_read(i915, DDI_BUF_CTL(PORT_A)) &
DDI_INIT_DISPLAY_DETECTED;
+ case PORT_B:
+ return intel_de_read(i915, SFUSE_STRAP) &
SFUSE_STRAP_DDIB_DETECTED;
+ case PORT_C:
+ return intel_de_read(i915, SFUSE_STRAP) &
SFUSE_STRAP_DDIC_DETECTED;
+ case PORT_D:
+ return intel_de_read(i915, SFUSE_STRAP) &
SFUSE_STRAP_DDID_DETECTED;
+ default:
+ MISSING_CASE(port);
+ return false;
+ }
+}
+
void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
{
struct intel_digital_port *dig_port;
@@ -4668,6 +4689,12 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
+ if (!port_strap_detected(dev_priv, port)) {
+ drm_dbg_kms(_priv->drm,
+ "Port %c strap not detected\n", port_name(port));
+ return;
+ }
+
if (!assert_port_valid(dev_priv, port))
return;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index fd3b5fc801e6..2b08352570b5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7350,7 +7350,7 @@ void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
- if (DISPLAY_VER(dev_priv) >= 9) {
+ if (HAS_DDI(dev_priv)) {
enum port port;
for_each_port_masked(port, RUNTIME_INFO(dev_priv)->port_mask)
@@ -7363,24 +7363,9 @@ void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
vlv_dsi_init(dev_priv);
- } else if (HAS_DDI(dev_priv)) {
- u32 found;
if (intel_ddi_crt_present(dev_priv))
intel_crt_init(dev_priv);
-
- /* Haswell uses DDI functions to detect digital outputs. */
- found = intel_de_read(dev_priv, DDI_BUF_CTL(PORT_A)) &
DDI_INIT_DISPLAY_DETECTED;
- if (found)
- intel_ddi_init(dev_priv, PORT_A);
-
- found = intel_de_read(dev_priv, SFUSE_STRAP);
- if (found & SFUSE_STRAP_DDIB_DETECTED)
- intel_ddi_init(dev_priv, PORT_B);
- if (found & SFUSE_STRAP_DDIC_DETECTED)
- intel_ddi_init(dev_priv, PORT_C);
- if (found & SFUSE_STRAP_DDID_DETECTED)
- intel_ddi_init(dev_priv, PORT_D);
} else if (HAS_PCH_SPLIT(dev_priv)) {
int found;
--
2.39.3
[Intel-gfx] [PATCH 6/7] drm/i915: Init DDI outputs based on port_mask on skl+
From: Ville Syrjälä
Instead of listing every platform's possible DDI outputs
in intel_setup_outputs() just loop over the new port_mask
to achieve the same thing.
HSW/BDW were left as is since they still look at the straps
as well.
DSI is still a mess. For now just check for the relevant
platforms explicitly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 80
1 file changed, 13 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a96714ea752a..fd3b5fc801e6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7350,73 +7350,19 @@ void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
- if (IS_METEORLAKE(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_TC1);
- intel_ddi_init(dev_priv, PORT_TC2);
- intel_ddi_init(dev_priv, PORT_TC3);
- intel_ddi_init(dev_priv, PORT_TC4);
- } else if (IS_DG2(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_C);
- intel_ddi_init(dev_priv, PORT_D_XELPD);
- intel_ddi_init(dev_priv, PORT_TC1);
- } else if (IS_ALDERLAKE_P(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_TC1);
- intel_ddi_init(dev_priv, PORT_TC2);
- intel_ddi_init(dev_priv, PORT_TC3);
- intel_ddi_init(dev_priv, PORT_TC4);
- icl_dsi_init(dev_priv);
- } else if (IS_ALDERLAKE_S(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_TC1);
- intel_ddi_init(dev_priv, PORT_TC2);
- intel_ddi_init(dev_priv, PORT_TC3);
- intel_ddi_init(dev_priv, PORT_TC4);
- } else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_TC1);
- intel_ddi_init(dev_priv, PORT_TC2);
- } else if (DISPLAY_VER(dev_priv) >= 12) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_TC1);
- intel_ddi_init(dev_priv, PORT_TC2);
- intel_ddi_init(dev_priv, PORT_TC3);
- intel_ddi_init(dev_priv, PORT_TC4);
- intel_ddi_init(dev_priv, PORT_TC5);
- intel_ddi_init(dev_priv, PORT_TC6);
- icl_dsi_init(dev_priv);
- } else if (IS_JSL_EHL(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_C);
- intel_ddi_init(dev_priv, PORT_D);
- icl_dsi_init(dev_priv);
- } else if (DISPLAY_VER(dev_priv) == 11) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_C);
- intel_ddi_init(dev_priv, PORT_D);
- intel_ddi_init(dev_priv, PORT_E);
- intel_ddi_init(dev_priv, PORT_F);
- icl_dsi_init(dev_priv);
- } else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_C);
- vlv_dsi_init(dev_priv);
- } else if (DISPLAY_VER(dev_priv) >= 9) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_C);
- intel_ddi_init(dev_priv, PORT_D);
- intel_ddi_init(dev_priv, PORT_E);
+ if (DISPLAY_VER(dev_priv) >= 9) {
+ enum port port;
+
+ for_each_port_masked(port, RUNTIME_INFO(dev_priv)->port_mask)
+ intel_ddi_init(dev_priv, port);
+
+ /* FIXME do something about DSI */
+ if (IS_ALDERLAKE_P(dev_priv) || IS_TIGERLAKE(dev_priv) ||
+ DISPLAY_VER(dev_priv) == 11)
+ icl_dsi_init(dev_priv);
+
+ if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
+ vlv_dsi_init(dev_priv);
} else if (HAS_DDI(dev_priv)) {
u32 found;
--
2.39.3
[Intel-gfx] [PATCH 5/7] drm/i915: Beef up SDVO/HDMI port checks
From: Ville Syrjälä
The SDVO code already warns when the port in question doesn't
actually support SDVO. Let's make that also bail the encoder
registration like the generic assert_port_valid() we added.
And add a similar thing for g4x HDMI, mainly because on g4x
itsefl port D only supports DP but not SDVO/HDMI. For the
other platforms the generic port_mask check should actually
be sufficient, but since we're here might as well list the
ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_hdmi.c | 17 +
drivers/gpu/drm/i915/display/intel_sdvo.c | 17 -
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 59704939c111..8c71e3ede680 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -659,6 +659,20 @@ int g4x_hdmi_connector_atomic_check(struct drm_connector
*connector,
return ret;
}
+static bool is_hdmi_port_valid(struct drm_i915_private *i915, enum port port)
+{
+ if (IS_G4X(i915) || IS_VALLEYVIEW(i915))
+ return port == PORT_B || port == PORT_C;
+ else
+ return port == PORT_B || port == PORT_C || port == PORT_D;
+}
+
+static bool assert_hdmi_port_valid(struct drm_i915_private *i915, enum port
port)
+{
+ return !drm_WARN(>drm, !is_hdmi_port_valid(i915, port),
+"Platform does not support HDMI %c\n",
port_name(port));
+}
+
void g4x_hdmi_init(struct drm_i915_private *dev_priv,
i915_reg_t hdmi_reg, enum port port)
{
@@ -670,6 +684,9 @@ void g4x_hdmi_init(struct drm_i915_private *dev_priv,
if (!assert_port_valid(dev_priv, port))
return;
+ if (!assert_hdmi_port_valid(dev_priv, port))
+ return;
+
devdata = intel_bios_encoder_data_lookup(dev_priv, port);
/* FIXME bail? */
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index 6ed613558cf8..e6b140b073c3 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -3314,13 +3314,19 @@ intel_sdvo_init_ddc_proxy(struct intel_sdvo *sdvo,
return i2c_add_adapter(>ddc) == 0;
}
-static void assert_sdvo_port_valid(const struct drm_i915_private *dev_priv,
- enum port port)
+static bool is_sdvo_port_valid(struct drm_i915_private *dev_priv, enum port
port)
{
if (HAS_PCH_SPLIT(dev_priv))
- drm_WARN_ON(_priv->drm, port != PORT_B);
+ return port == PORT_B;
else
- drm_WARN_ON(_priv->drm, port != PORT_B && port != PORT_C);
+ return port == PORT_B || port == PORT_C;
+}
+
+static bool assert_sdvo_port_valid(struct drm_i915_private *dev_priv,
+ enum port port)
+{
+ return !drm_WARN(_priv->drm, !is_sdvo_port_valid(dev_priv, port),
+"Platform does not support SDVO %c\n",
port_name(port));
}
bool intel_sdvo_init(struct drm_i915_private *dev_priv,
@@ -,7 +3339,8 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
if (!assert_port_valid(dev_priv, port))
return false;
- assert_sdvo_port_valid(dev_priv, port);
+ if (!assert_sdvo_port_valid(dev_priv, port))
+ return false;
intel_sdvo = kzalloc(sizeof(*intel_sdvo), GFP_KERNEL);
if (!intel_sdvo)
--
2.39.3
[Intel-gfx] [PATCH 1/7] drm/i915: Remove bogus DDI-F from hsw/bdw output init
From: Ville Syrjälä
HSW/BDW don't have DDI-F so don't go looking for one.
Seems to have been accidentally left behind when the
skl+ stuff got split out in commit 097d9e902068
("drm/i915/display: remove strap checks from gen 9").
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1d5d42a40803..c1e0d439db79 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7429,8 +7429,6 @@ void intel_setup_outputs(struct drm_i915_private
*dev_priv)
intel_ddi_init(dev_priv, PORT_C);
if (found & SFUSE_STRAP_DDID_DETECTED)
intel_ddi_init(dev_priv, PORT_D);
- if (found & SFUSE_STRAP_DDIF_DETECTED)
- intel_ddi_init(dev_priv, PORT_F);
} else if (HAS_PCH_SPLIT(dev_priv)) {
int found;
--
2.39.3
[Intel-gfx] [PATCH 4/7] drm/i915: Assert that the port being initialized is valid
From: Ville Syrjälä
Sprinkle some asserts to catch any mishaps in the port_mask
vs. output init.
For DDI/DP/HDMI/SDVO I decided that we want to bail out for
an invalid port since those are the encoder types where
we might want consider driving the whole thing from the VBT
child device list, and bogus VBTs could be a real issue
(if for no other reason than the i915.vbt_firmware).
For DVO and HSW/BDW CRT port I just threw the assert in
there for good measure.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c| 3 +++
drivers/gpu/drm/i915/display/g4x_hdmi.c | 3 +++
drivers/gpu/drm/i915/display/intel_crt.c | 2 ++
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
drivers/gpu/drm/i915/display/intel_display.h | 2 ++
drivers/gpu/drm/i915/display/intel_dvo.c | 2 ++
drivers/gpu/drm/i915/display/intel_sdvo.c| 3 +++
8 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index 920d570f7594..493aaa5e0dfb 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -1259,6 +1259,9 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
struct drm_encoder *encoder;
struct intel_connector *intel_connector;
+ if (!assert_port_valid(dev_priv, port))
+ return false;
+
devdata = intel_bios_encoder_data_lookup(dev_priv, port);
/* FIXME bail? */
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 5c187e6e0472..59704939c111 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -667,6 +667,9 @@ void g4x_hdmi_init(struct drm_i915_private *dev_priv,
struct intel_encoder *intel_encoder;
struct intel_connector *intel_connector;
+ if (!assert_port_valid(dev_priv, port))
+ return;
+
devdata = intel_bios_encoder_data_lookup(dev_priv, port);
/* FIXME bail? */
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index f0f4897b3c3c..753ce2d5d2db 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -1061,6 +1061,8 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
}
if (HAS_DDI(dev_priv)) {
+ assert_port_valid(dev_priv, PORT_E);
+
crt->base.port = PORT_E;
crt->base.get_config = hsw_crt_get_config;
crt->base.get_hw_state = intel_ddi_get_hw_state;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0ba5492c0604..a5ca4b9d1e3e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4668,6 +4668,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
+ if (!assert_port_valid(dev_priv, port))
+ return;
+
/*
* On platforms with HTI (aka HDPORT), if it's enabled at boot it may
* have taken over some of the PHYs and made them unavailable to the
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c1e0d439db79..a96714ea752a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7334,6 +7334,12 @@ static bool intel_ddi_crt_present(struct
drm_i915_private *dev_priv)
return true;
}
+bool assert_port_valid(struct drm_i915_private *i915, enum port port)
+{
+ return !drm_WARN(>drm, !(RUNTIME_INFO(i915)->port_mask &
BIT(port)),
+"Platform does not support port %c\n",
port_name(port));
+}
+
void intel_setup_outputs(struct drm_i915_private *dev_priv)
{
struct intel_encoder *encoder;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index ac95961f68ba..a01af95ffa2e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -538,6 +538,8 @@ void assert_transcoder(struct drm_i915_private *dev_priv,
#define assert_transcoder_enabled(d, t) assert_transcoder(d, t, true)
#define assert_transcoder_disabled(d, t) assert_transcoder(d, t, false)
+bool assert_port_valid(struct drm_i915_private *i915, enum port port);
+
/* Use I915_STATE_WARN(x) and I915_STATE_WARN_ON() (rather than WARN() and
* WARN_ON()) for hw state sanity checks to check for unexpected conditions
* which may not necessarily be a user visible problem. This will either
diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c
b/drivers/gpu/drm/i915/display/intel_dvo.c
index 9884678743b6..b386894c3a6d 100644
--- a/drivers/gpu/drm/i915/display/intel_dvo.c
+++
[Intel-gfx] [PATCH 3/7] drm/i915: Assert that device info bitmasks have enough bits
From: Ville Syrjälä Sprinkle in some BUILD_BUG_ON()s to make sure some of the bitmasks used in the device info have enough bits. Do we have a better place for this sort of stuff? Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_device_info.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index bb10e8e78a94..ce257446b712 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -414,6 +414,10 @@ void intel_device_info_runtime_init(struct drm_i915_private *dev_priv) struct intel_runtime_info *runtime = RUNTIME_INFO(dev_priv); enum pipe pipe; + BUILD_BUG_ON(BITS_PER_TYPE(runtime->pipe_mask) < I915_MAX_PIPES); + BUILD_BUG_ON(BITS_PER_TYPE(runtime->cpu_transcoder_mask) < I915_MAX_TRANSCODERS); + BUILD_BUG_ON(BITS_PER_TYPE(runtime->port_mask) < I915_MAX_PORTS); + /* Wa_14011765242: adl-s A0,A1 */ if (IS_ADLS_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A2)) for_each_pipe(dev_priv, pipe) -- 2.39.3
[Intel-gfx] [PATCH 2/7] drm/i915: Introduce device info port_mask
From: Ville Syrjälä
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the
device info. The other outputs (LVDS/TV/DSI/VGA) are left
out since for most of them we don't consider them as "ports".
DSI we should probably perhaps include somehow in the device
info. Just not sure how. Or we just introduce a HAS_DSI() and
call it a day?
TODO: figure out what to do about the subplatform stuff. Would
it be better to declare those directly with a different
device info or not? Also not sure the icl port-f stuff
matters even. Bspec claims there are icl SKUs with far
less ports than that and we don't seem to check for those
either?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_pci.c | 33
drivers/gpu/drm/i915/intel_device_info.c | 5
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 72dd7b9f6dfd..46511a0fbc3e 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -256,29 +256,34 @@
static const struct intel_device_info i830_info = {
I830_FEATURES,
PLATFORM(INTEL_I830),
+ .__runtime.port_mask = BIT(PORT_A) | BIT(PORT_B) | BIT(PORT_C), /* DVO
A/B/C */
};
static const struct intel_device_info i845g_info = {
I845_FEATURES,
PLATFORM(INTEL_I845G),
+ .__runtime.port_mask = BIT(PORT_B) | BIT(PORT_C), /* DVO B/C */
};
static const struct intel_device_info i85x_info = {
I830_FEATURES,
PLATFORM(INTEL_I85X),
.__runtime.fbc_mask = BIT(INTEL_FBC_A),
+ .__runtime.port_mask = BIT(PORT_B) | BIT(PORT_C), /* DVO B/C */
};
static const struct intel_device_info i865g_info = {
I845_FEATURES,
PLATFORM(INTEL_I865G),
.__runtime.fbc_mask = BIT(INTEL_FBC_A),
+ .__runtime.port_mask = BIT(PORT_B) | BIT(PORT_C), /* DVO B/C */
};
#define GEN3_FEATURES \
GEN(3), \
.__runtime.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B), \
.__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B),
\
+ .__runtime.port_mask = BIT(PORT_B) | BIT(PORT_C), /* SDVO B/C */ \
.display.has_gmch = 1, \
.gpu_reset_clobbers_display = true, \
.__runtime.platform_engine_mask = BIT(RCS0), \
@@ -391,6 +396,7 @@ static const struct intel_device_info pnv_m_info = {
static const struct intel_device_info i965g_info = {
GEN4_FEATURES,
PLATFORM(INTEL_I965G),
+ .__runtime.port_mask = BIT(PORT_B) | BIT(PORT_C), /* SDVO B/C */
.display.has_overlay = 1,
.hws_needs_physical = 1,
.has_snoop = false,
@@ -401,6 +407,7 @@ static const struct intel_device_info i965gm_info = {
PLATFORM(INTEL_I965GM),
.is_mobile = 1,
.__runtime.fbc_mask = BIT(INTEL_FBC_A),
+ .__runtime.port_mask = BIT(PORT_B) | BIT(PORT_C), /* SDVO B/C */
.display.has_overlay = 1,
.display.supports_tv = 1,
.hws_needs_physical = 1,
@@ -410,6 +417,7 @@ static const struct intel_device_info i965gm_info = {
static const struct intel_device_info g45_info = {
GEN4_FEATURES,
PLATFORM(INTEL_G45),
+ .__runtime.port_mask = BIT(PORT_B) | BIT(PORT_C) | BIT(PORT_D), /*
SDVO/HDMI/DP B/C, DP D */
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(VCS0),
.gpu_reset_clobbers_display = false,
};
@@ -419,6 +427,7 @@ static const struct intel_device_info gm45_info = {
PLATFORM(INTEL_GM45),
.is_mobile = 1,
.__runtime.fbc_mask = BIT(INTEL_FBC_A),
+ .__runtime.port_mask = BIT(PORT_B) | BIT(PORT_C) | BIT(PORT_D), /*
SDVO/HDMI/DP B/C, DP D */
.display.supports_tv = 1,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(VCS0),
.gpu_reset_clobbers_display = false,
@@ -428,6 +437,7 @@ static const struct intel_device_info gm45_info = {
GEN(5), \
.__runtime.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B), \
.__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B),
\
+ .__runtime.port_mask = BIT(PORT_A) | BIT(PORT_B) | BIT(PORT_C) |
BIT(PORT_D), /* DP A, SDVO/HDMI/DP B, HDMI/DP C/D */ \
.display.has_hotplug = 1, \
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(VCS0), \
.has_3d_pipeline = 1, \
@@ -461,6 +471,7 @@ static const struct intel_device_info ilk_m_info = {
GEN(6), \
.__runtime.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B), \
.__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B),
\
+ .__runtime.port_mask = BIT(PORT_A) | BIT(PORT_B) | BIT(PORT_C) |
BIT(PORT_D), /* DP A, SDVO/HDMI/DP B, HDMI/DP C/D */ \
.display.has_hotplug = 1, \
.__runtime.fbc_mask = BIT(INTEL_FBC_A), \
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0), \
@@ -516,6 +527,7 @@ static const struct intel_device_info snb_m_gt2_info = {
[Intel-gfx] [PATCH 0/7] drm/i915: Init DDI ports based on port_mask
From: Ville Syrjälä Introduce port_mask into the device info and utilize it it initalize DDI ports instead of hand rolling each intel_ddi_init() call per platform+port. This is an intermediate step towards initializing DDI/DP/HDMI/DSI ports purely based on VBT information. Ville Syrjälä (7): drm/i915: Remove bogus DDI-F from hsw/bdw output init drm/i915: Introduce device info port_mask drm/i915: Assert that device info bitmasks have enough bits drm/i915: Assert that the port being initialized is valid drm/i915: Beef up SDVO/HDMI port checks drm/i915: Init DDI outputs based on port_mask on skl+ drm/i915: Convert HSW/BDW to use port_mask for DDI probe drivers/gpu/drm/i915/display/g4x_dp.c| 3 + drivers/gpu/drm/i915/display/g4x_hdmi.c | 20 drivers/gpu/drm/i915/display/intel_crt.c | 2 + drivers/gpu/drm/i915/display/intel_ddi.c | 30 ++ drivers/gpu/drm/i915/display/intel_display.c | 103 --- drivers/gpu/drm/i915/display/intel_display.h | 2 + drivers/gpu/drm/i915/display/intel_dvo.c | 2 + drivers/gpu/drm/i915/display/intel_sdvo.c| 20 +++- drivers/gpu/drm/i915/i915_pci.c | 33 ++ drivers/gpu/drm/i915/intel_device_info.c | 9 ++ drivers/gpu/drm/i915/intel_device_info.h | 1 + 11 files changed, 136 insertions(+), 89 deletions(-) -- 2.39.3
[Intel-gfx] [linux-next:master] BUILD SUCCESS WITH WARNING aabe491169befbe5481144acf575a0260939764a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: aabe491169befbe5481144acf575a0260939764a Add linux-next specific files for 20230511 Warning reports: https://lore.kernel.org/oe-kbuild-all/202304140707.coh337ux-...@intel.com Warning: (recently discovered and may have been fixed) drivers/base/regmap/regcache-maple.c:113:23: warning: 'lower_index' is used uninitialized [-Wuninitialized] drivers/base/regmap/regcache-maple.c:113:36: warning: 'lower_last' is used uninitialized [-Wuninitialized] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6395:21: warning: variable 'count' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:499:13: warning: variable 'j' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable] Unverified Warning (likely false positive, please contact us if interested): drivers/gpu/drm/i915/display/intel_psr.c:2999:0-23: WARNING: i915_edp_psr_debug_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE fs/ext4/super.c:4724 ext4_check_feature_compatibility() warn: bitwise AND condition is false here fs/ext4/verity.c:316 ext4_get_verity_descriptor_location() error: uninitialized symbol 'desc_size_disk'. Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- alpha-randconfig-m031-20230511 | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- alpha-randconfig-s032-20230509 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arc-allyesconfig | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | |-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arc-randconfig-r043-20230511 | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | |-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arm-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arm-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arm64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- csky-randconfig-r021-20230511 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- csky-randconfig-r023-20230511 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- i386-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- ia64-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- loongarch-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- loongarch-defconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- mips-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- mips-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- parisc-randconfig-m041-20230509 | |-- fs-ext4-super.c-ext4_check_feature_compatibility()-warn:bitwise-AND-condition-is-false-here | `-- fs
Re: [Intel-gfx] [PATCH v8 0/2] drm/i915: use pat_index instead of cache_level
Hi Fei,
Pushed to drm-intel-gt-next.
There was a "pinky" promise that Tvrtko asked you (and I feel
involved, as well) to make. Let's make sure to follow up on that.
Andi
On Tue, May 09, 2023 at 09:51:58AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> This patch set was posted at
> https://patchwork.freedesktop.org/series/116868/
> Change title since the PTE patch was merged separately.
>
> These patches are extracted from series
> https://patchwork.freedesktop.org/series/115980/
>
> This series refactor the cache policy programming so that the PTE
> encode functions can be unified across all GEN12 platforms. This
> refactor is also important in implementing the design which allows
> uerspace to directly set cache policy for each Buffer Object.
>
> v2: drop one patch that was merged separately
> 341ad0e8e254 drm/i915/mtl: Add PTE encode function
> v3: disable {get, set}_caching ioctl
> v4: fix missing unlock introduced in v3, and
> solve a rebase conflict
> v5: replace obj->cache_level with pat_set_by_user,
> fix i915_cache_level_str() for legacy platforms.
> v6: squash the pte_encode patch because separating them causes
> bisect probelm. Also addressing some review comments from
> Tvrtko and Matt.
> v7: fix checkpatch errors and warnings.
> v8: BUILD_BUG_ON instead of WARN_ON_ONCE. Some updates in
> comments.
>
> Fei Yang (2):
> drm/i915: preparation for using PAT index
> drm/i915: use pat_index instead of cache_level
>
> drivers/gpu/drm/i915/display/intel_dpt.c | 12 +--
> drivers/gpu/drm/i915/gem/i915_gem_domain.c| 58 +-
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 +++-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 11 ++-
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 60 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 ++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 53 -
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 -
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 8 +-
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
> drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 10 ++-
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 78 +-
> drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 3 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 76 +-
> drivers/gpu/drm/i915/gt/intel_gtt.h | 18 ++---
> drivers/gpu/drm/i915/gt/intel_migrate.c | 47 ++-
> drivers/gpu/drm/i915/gt/intel_migrate.h | 13 ++-
> drivers/gpu/drm/i915/gt/intel_ppgtt.c | 4 +-
> drivers/gpu/drm/i915/gt/selftest_migrate.c| 47 +--
> drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +-
> drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_tlb.c| 4 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 ++-
> drivers/gpu/drm/i915/i915_debugfs.c | 53 ++---
> drivers/gpu/drm/i915/i915_gem.c | 27 ++-
> drivers/gpu/drm/i915/i915_gpu_error.c | 8 +-
> drivers/gpu/drm/i915/i915_pci.c | 79 ---
> drivers/gpu/drm/i915/i915_vma.c | 16 ++--
> drivers/gpu/drm/i915/i915_vma.h | 2 +-
> drivers/gpu/drm/i915/i915_vma_types.h | 2 -
> drivers/gpu/drm/i915/intel_device_info.h | 5 ++
> drivers/gpu/drm/i915/selftests/i915_gem.c | 5 +-
> .../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++--
> .../drm/i915/selftests/intel_memory_region.c | 4 +-
> .../gpu/drm/i915/selftests/mock_gem_device.c | 9 +++
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 8 +-
> 40 files changed, 557 insertions(+), 237 deletions(-)
>
> --
> 2.25.1
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
On Thu, May 11, 2023 at 06:21:53PM +0300, Jani Nikula wrote: > CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in > intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV > display base area. > > Add VLV_GUNIT_BASE to drop dependency on VLV_DISPLAY_BASE and thus > display/intel_display_reg_defs.h in intel_gt_regs.h. > > v2: Add VLV_GUNIT_BASE (Ville) > > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index b8a39c219b60..718cb2c80f79 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -7,7 +7,8 @@ > #define __INTEL_GT_REGS__ > > #include "i915_reg_defs.h" > -#include "display/intel_display_reg_defs.h" /* VLV_DISPLAY_BASE */ > + > +#define VLV_GUNIT_BASE 0x18 > > /* > * The perf control registers are technically multicast registers, but the > @@ -1469,7 +1470,7 @@ > #define GEN12_RCU_MODE _MMIO(0x14800) > #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0) > > -#define CHV_FUSE_GT _MMIO(VLV_DISPLAY_BASE + 0x2168) > +#define CHV_FUSE_GT _MMIO(VLV_GUNIT_BASE + 0x2168) > #define CHV_FGT_DISABLE_SS0(1 << 10) > #define CHV_FGT_DISABLE_SS1(1 << 11) > #define CHV_FGT_EU_DIS_SS0_R0_SHIFT16 > -- > 2.39.2 -- Ville Syrjälä Intel
[Intel-gfx] [PATCH v2] drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV display base area. Add VLV_GUNIT_BASE to drop dependency on VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in intel_gt_regs.h. v2: Add VLV_GUNIT_BASE (Ville) Cc: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index b8a39c219b60..718cb2c80f79 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -7,7 +7,8 @@ #define __INTEL_GT_REGS__ #include "i915_reg_defs.h" -#include "display/intel_display_reg_defs.h"/* VLV_DISPLAY_BASE */ + +#define VLV_GUNIT_BASE 0x18 /* * The perf control registers are technically multicast registers, but the @@ -1469,7 +1470,7 @@ #define GEN12_RCU_MODE _MMIO(0x14800) #define GEN12_RCU_MODE_CCS_ENABLEREG_BIT(0) -#define CHV_FUSE_GT_MMIO(VLV_DISPLAY_BASE + 0x2168) +#define CHV_FUSE_GT_MMIO(VLV_GUNIT_BASE + 0x2168) #define CHV_FGT_DISABLE_SS0 (1 << 10) #define CHV_FGT_DISABLE_SS1 (1 << 11) #define CHV_FGT_EU_DIS_SS0_R0_SHIFT 16 -- 2.39.2
[Intel-gfx] ✗ Fi.CI.IGT: failure for Fix modeset locking issue in HDCP MST (rev2)
== Series Details == Series: Fix modeset locking issue in HDCP MST (rev2) URL : https://patchwork.freedesktop.org/series/117615/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13133_full -> Patchwork_117615v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_117615v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_117615v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (8 -> 7) -- Missing(1): shard-rkl0 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_117615v2_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-apl: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-apl1/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl4/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html Known issues Here are the changes found in Patchwork_117615v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][3] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_lmem_swapping@smem-oom: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl2/igt@gem_lmem_swapp...@smem-oom.html * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271]) +43 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl2/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html * igt@i915_pipe_stress@stress-xrgb-untiled: - shard-apl: NOTRUN -> [FAIL][10] ([i915#7036]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl2/igt@i915_pipe_str...@stress-xrgb-untiled.html * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3886]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl2/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html * igt@kms_content_protection@atomic@pipe-a-dp-1: - shard-apl: NOTRUN -> [TIMEOUT][12] ([i915#7173]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl1/igt@kms_content_protection@ato...@pipe-a-dp-1.html * igt@kms_content_protection@mei_interface: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4579]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl2/igt@kms_content_protection@mei_interface.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-apl: [PASS][14] -> [FAIL][15] ([i915#2346]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-apl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a1: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#79]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/shard-glk4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a1.html * igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#2122]) [18]:
Re: [Intel-gfx] [PATCH] drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
On Thu, May 11, 2023 at 03:46:14PM +0300, Jani Nikula wrote: > On Thu, 11 May 2023, Ville Syrjälä wrote: > > On Thu, May 11, 2023 at 03:31:16PM +0300, Jani Nikula wrote: > >> On Thu, 11 May 2023, Ville Syrjälä wrote: > >> > On Thu, May 11, 2023 at 12:04:27PM +0300, Jani Nikula wrote: > >> >> CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in > >> >> intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV > >> >> display base area. > >> >> > >> >> Use the 0x182168 MMIO address directly to drop dependency on > >> >> VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in > >> >> intel_gt_regs.h. > >> >> > >> >> Cc: Ville Syrjälä > >> >> Signed-off-by: Jani Nikula > >> >> --- > >> >> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +-- > >> >> 1 file changed, 1 insertion(+), 2 deletions(-) > >> >> > >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > >> >> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > >> >> index b8a39c219b60..f38550dae6b8 100644 > >> >> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > >> >> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > >> >> @@ -7,7 +7,6 @@ > >> >> #define __INTEL_GT_REGS__ > >> >> > >> >> #include "i915_reg_defs.h" > >> >> -#include "display/intel_display_reg_defs.h"/* VLV_DISPLAY_BASE */ > >> >> > >> >> /* > >> >> * The perf control registers are technically multicast registers, but > >> >> the > >> >> @@ -1469,7 +1468,7 @@ > >> >> #define GEN12_RCU_MODE _MMIO(0x14800) > >> >> #define GEN12_RCU_MODE_CCS_ENABLEREG_BIT(0) > >> >> > >> >> -#define CHV_FUSE_GT_MMIO(VLV_DISPLAY_BASE > >> >> + 0x2168) > >> >> +#define CHV_FUSE_GT_MMIO(0x182168) > >> > > >> > Or mmaybe s/VLV_DISPLAY_BASE/VLV_GUNIT_BASE/ here? Although all the > >> > other Gunit register defintions are still in i915_reg.h, and using > >> > VLV_DISPLAY_BASE. Not sure what to do about all that... > >> > >> Works for me, as long as I can drop the dependency on > >> display/intel_display_reg_defs.h. > >> > >> Just let me know. > > > > I'd probably go with the VLV_GUNIT_BASE approach. We can think > > about what to do with all the other Gunit registers later. > > Hmm, where to put VLV_GUNIT_BASE, then? > > To avoid deps on display/, it would be here, i915_reg_defs.h, or a new > file that would mostly just contain this kind of offsets. I suppose it could just live in intel_gt_regs.h for the moment? -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: drop display/ prefix from include
On Thu, 11 May 2023, "Kandpal, Suraj" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Thursday, May 11, 2023 2:26 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Nikula, Jani ; Teres Alexis, Alan Previn
>> ; Kandpal, Suraj
>> ; Shankar, Uma
>> Subject: [PATCH] drm/i915/hdcp: drop display/ prefix from include
>>
>> The display prefix is unnecessary within the display sub-directory.
>>
>
> LGTM.
>
> Reviewed-by: Suraj Kandpal
Thanks, pushed to din.
>
>> Cc: Alan Previn
>> Cc: Suraj Kandpal
>> Cc: Uma Shankar
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
>> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
>> index 7e52aea6aa17..4056bb2323ca 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
>> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
>> @@ -5,11 +5,11 @@
>>
>> #include
>>
>> -#include "display/intel_hdcp_gsc.h"
>> #include "gem/i915_gem_region.h"
>> #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
>> #include "i915_drv.h"
>> #include "i915_utils.h"
>> +#include "intel_hdcp_gsc.h"
>>
>> bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915) {
>> --
>> 2.39.2
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/2] drm/i915/mtl: Add MTL performance tuning changes
Quoting Radhakrishna Sripada (2023-05-10 19:35:52)
>MTL reuses the tuning parameters for DG2. Extend the dg2
>performance tuning parameters to MTL.
>
>Bspec: 68331
>Cc: Matt Roper
>Cc: Gustavo Sousa
>Signed-off-by: Radhakrishna Sripada
Commit cebc13de7e70 ("drm/i915: Whitelist COMMON_SLICE_CHICKEN3 for UMD
access") already whitelisted one of the registers supposed to be tweaked by UMD
and I did check that all remaining registers from the performance tuning list
are now covered by this patch.
Reviewed-by: Gustavo Sousa
>---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>index 786349e95487..b222a3d367c9 100644
>--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>@@ -817,6 +817,8 @@ static void mtl_ctx_workarounds_init(struct
>intel_engine_cs *engine,
> {
> struct drm_i915_private *i915 = engine->i915;
>
>+dg2_ctx_gt_tuning_init(engine, wal);
>+
> if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
> /* Wa_14014947963 */
>@@ -1754,7 +1756,7 @@ static void gt_tuning_settings(struct intel_gt *gt,
>struct i915_wa_list *wal)
> wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0,
> XEHPC_HOSTCACHEEN);
> }
>
>-if (IS_DG2(gt->i915)) {
>+if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915)) {
> wa_mcr_write_or(wal, XEHP_L3SCQREG7,
> BLEND_FILL_CACHING_OPT_DIS);
> wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
> }
>@@ -2944,7 +2946,7 @@ static void
> add_render_compute_tuning_settings(struct drm_i915_private *i915,
>struct i915_wa_list *wal)
> {
>-if (IS_DG2(i915))
>+if (IS_DG2(i915) || IS_METEORLAKE(i915))
> wa_mcr_write_clr_set(wal, RT_CTRL, STACKID_CTRL,
> STACKID_CTRL_512);
>
> /*
>--
>2.34.1
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL
Quoting Radhakrishna Sripada (2023-05-10 19:35:51) >The dg2 workaround which is used for performance tuning >is needed for Meteorlake. > >Bspec: 68331 >Cc: Matt Roper >Cc: Gustavo Sousa >Signed-off-by: Radhakrishna Sripada The workaround for MTL seems to be necessary only prior to B0 steppings. I wonder if we would have any significant benefit from having the performance tuning done with the workaround infrastructure for B0+ steppings. My gut tells me that having two separate implementations for the performance tuning would not be worth it - someone more experienced with the driver might have the right answer here. Anyways, Reviewed-by: Gustavo Sousa >--- > drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c >b/drivers/gpu/drm/i915/gt/intel_lrc.c >index 81a96c52a92b..78ec350188b6 100644 >--- a/drivers/gpu/drm/i915/gt/intel_lrc.c >+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c >@@ -1370,7 +1370,7 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context >*ce, u32 *cs) > cs, GEN12_GFX_CCS_AUX_NV); > > /* Wa_16014892111 */ >-if (IS_DG2(ce->engine->i915)) >+if (IS_DG2(ce->engine->i915) || IS_METEORLAKE(ce->engine->i915)) > cs = dg2_emit_draw_watermark_setting(cs); > > return cs; >-- >2.34.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
== Series Details ==
Series: drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
URL : https://patchwork.freedesktop.org/series/117620/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13133_full -> Patchwork_117620v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Known issues
Here are the changes found in Patchwork_117620v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][3] -> [INCOMPLETE][4] ([i915#7790])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-snb4/igt@i915_pm_...@reset.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-snb4/igt@i915_pm_...@reset.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][5] ([i915#7173])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-apl7/igt@kms_content_protection@ato...@pipe-a-dp-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][6] -> [FAIL][7] ([i915#2346])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-apl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: [PASS][8] -> [FAIL][9] ([i915#4767])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-apl1/igt@kms_fbcon_...@fbc-suspend.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@b-hdmi-a1:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2122])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-glk1/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-hdmi-a1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-glk3/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-hdmi-a1.html
*
igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4579]) +16
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-snb1/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0...@pipe-b-hdmi-a-1.html
*
igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-a-vga-1:
- shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271]) +24 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-snb6/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0...@pipe-a-vga-1.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-tglu}: [ABORT][14] ([i915#7953] / [i915#8211] / [i915#8234])
-> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-tglu-3/igt@gem_barrier_race@remote-requ...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-tglu-2/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][16] ([i915#6268]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-tglu-7/igt@gem_ctx_e...@basic-nohangcheck.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-tglu-4/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_eio@hibernate:
- {shard-tglu}: [ABORT][18] ([i915#7953] / [i915#7975] / [i915#8213]
/ [i915#8398]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-tglu-10/igt@gem_...@hibernate.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-tglu-9/igt@gem_...@hibernate.html
* igt@gem_eio@wait-immediate:
- shard-apl: [DMESG-WARN][20] ([i915#62]) -> [PASS][21] +44
similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-apl7/igt@gem_...@wait-immediate.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/shard-apl7/igt@gem_...@wait-immediate.html
* igt@gem_exec_endless@dispatch@rcs0:
- {shard-rkl}:[TIMEOUT][22] ([i915#3778]) -> [PASS][23]
[22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers
== Series Details ==
Series: series starting with [1/2] drm/fourcc: define Intel Meteorlake related
ccs modifiers
URL : https://patchwork.freedesktop.org/series/117625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13134 -> Patchwork_117625v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/index.html
Participating hosts (41 -> 39)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117625v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][1] ([i915#7077])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html
* igt@i915_selftest@live@guc:
- bat-rpls-1: [PASS][2] -> [DMESG-WARN][3] ([i915#7852] /
[i915#7953])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/bat-rpls-1/igt@i915_selftest@l...@guc.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-rpls-1/igt@i915_selftest@l...@guc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][4] ([i915#6687])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#7828])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-adlm-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [PASS][6] -> [FAIL][7] ([i915#7932])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlm-1: NOTRUN -> [SKIP][8] ([i915#1845])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-adlm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [SKIP][9] ([i915#3555] / [i915#4579])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@dmabuf@all-tests@dma_fence:
- bat-adlm-1: [DMESG-FAIL][10] -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/bat-adlm-1/igt@dmabuf@all-tests@dma_fence.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-adlm-1/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- bat-adlm-1: [ABORT][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/bat-adlm-1/igt@dmabuf@all-te...@sanitycheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-adlm-1/igt@dmabuf@all-te...@sanitycheck.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {bat-mtlp-8}: [TIMEOUT][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][16] ([i915#4983] / [i915#7461] / [i915#7913]
/ [i915#8347]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/bat-rpls-2/igt@i915_selftest@l...@reset.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
Warnings
* igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: [ABORT][18] -> [SKIP][19] ([i915#1072])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13134/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117625v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7077]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers
== Series Details == Series: series starting with [1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers URL : https://patchwork.freedesktop.org/series/117625/ State : warning == Summary == Error: dim checkpatch failed 1e7c30956aac drm/fourcc: define Intel Meteorlake related ccs modifiers e9f5cbfb4b33 drm/i915/mtl: Add handling for MTL ccs modifiers -:57: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #57: FILE: drivers/gpu/drm/i915/display/intel_fb.c:404: + if (intel_fb_is_ccs_modifier(md->modifier) && + HAS_FLAT_CCS(i915) != !md->ccs.packed_aux_planes) total: 0 errors, 0 warnings, 1 checks, 116 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers
== Series Details == Series: series starting with [1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers URL : https://patchwork.freedesktop.org/series/117625/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH] drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
On Thu, 11 May 2023, Ville Syrjälä wrote: > On Thu, May 11, 2023 at 03:31:16PM +0300, Jani Nikula wrote: >> On Thu, 11 May 2023, Ville Syrjälä wrote: >> > On Thu, May 11, 2023 at 12:04:27PM +0300, Jani Nikula wrote: >> >> CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in >> >> intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV >> >> display base area. >> >> >> >> Use the 0x182168 MMIO address directly to drop dependency on >> >> VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in >> >> intel_gt_regs.h. >> >> >> >> Cc: Ville Syrjälä >> >> Signed-off-by: Jani Nikula >> >> --- >> >> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +-- >> >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h >> >> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h >> >> index b8a39c219b60..f38550dae6b8 100644 >> >> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h >> >> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h >> >> @@ -7,7 +7,6 @@ >> >> #define __INTEL_GT_REGS__ >> >> >> >> #include "i915_reg_defs.h" >> >> -#include "display/intel_display_reg_defs.h" /* VLV_DISPLAY_BASE */ >> >> >> >> /* >> >> * The perf control registers are technically multicast registers, but >> >> the >> >> @@ -1469,7 +1468,7 @@ >> >> #define GEN12_RCU_MODE _MMIO(0x14800) >> >> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0) >> >> >> >> -#define CHV_FUSE_GT _MMIO(VLV_DISPLAY_BASE >> >> + 0x2168) >> >> +#define CHV_FUSE_GT _MMIO(0x182168) >> > >> > Or mmaybe s/VLV_DISPLAY_BASE/VLV_GUNIT_BASE/ here? Although all the >> > other Gunit register defintions are still in i915_reg.h, and using >> > VLV_DISPLAY_BASE. Not sure what to do about all that... >> >> Works for me, as long as I can drop the dependency on >> display/intel_display_reg_defs.h. >> >> Just let me know. > > I'd probably go with the VLV_GUNIT_BASE approach. We can think > about what to do with all the other Gunit registers later. Hmm, where to put VLV_GUNIT_BASE, then? To avoid deps on display/, it would be here, i915_reg_defs.h, or a new file that would mostly just contain this kind of offsets. BR, Jani. > >> >> BR, >> Jani. >> >> >> > >> >> #define CHV_FGT_DISABLE_SS0(1 << 10) >> >> #define CHV_FGT_DISABLE_SS1(1 << 11) >> >> #define CHV_FGT_EU_DIS_SS0_R0_SHIFT16 >> >> -- >> >> 2.39.2 >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 7/7] drm/i915: Define more PS_CTRL bits
On Thu, 2023-05-11 at 14:54 +0300, Ville Syrjälä wrote: > On Thu, May 11, 2023 at 10:29:01AM +0300, Luca Coelho wrote: > > On Wed, 2023-04-26 at 16:50 +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > To avoid annoying spec lookups let's define more PS_CTRL > > > bits in the header. > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/i915_reg.h | 11 +++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > > b/drivers/gpu/drm/i915/i915_reg.h > > > index f5ae8d1eb6ff..e08bb15eddcf 100644 > > > --- a/drivers/gpu/drm/i915/i915_reg.h > > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > > @@ -4055,6 +4055,9 @@ > > > #define _PS_2B_CTRL 0x68A80 > > > #define _PS_1C_CTRL 0x69180 > > > #define PS_SCALER_EN REG_BIT(31) > > > +#define PS_SCALER_TYPE_MASKREG_BIT(30) /* icl+ */ > > > +#define PS_SCALER_TYPE_NON_LINEAR > > > REG_FIELD_PREP(PS_SCALER_TYPE_MASK, 0) > > > +#define PS_SCALER_TYPE_LINEAR > > > REG_FIELD_PREP(PS_SCALER_TYPE_MASK, 1) > > > #define SKL_PS_SCALER_MODE_MASKREG_GENMASK(29, 28) /* > > > skl/bxt */ > > > #define SKL_PS_SCALER_MODE_DYN > > > REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 0) > > > #define SKL_PS_SCALER_MODE_HQ > > > REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 1) > > > @@ -4062,6 +4065,7 @@ > > > #define PS_SCALER_MODE_MASKREG_BIT(29) /* glk-tgl > > > */ > > > #define PS_SCALER_MODE_NORMAL > > > REG_FIELD_PREP(PS_SCALER_MODE_MASK, 0) > > > #define PS_SCALER_MODE_PLANAR > > > REG_FIELD_PREP(PS_SCALER_MODE_MASK, 1) > > > +#define PS_ADAPTIVE_FILTERING_EN REG_BIT(28) /* icl+ */ > > > #define PS_BINDING_MASKREG_GENMASK(27, 25) > > > #define PS_BINDING_PIPE > > > REG_FIELD_PREP(PS_BINDING_MASK, 0) > > > #define PS_BINDING_PLANE(plane_id) > > > REG_FIELD_PREP(PS_BINDING_MASK, (plane_id) + 1) > > > @@ -4070,8 +4074,15 @@ > > > #define PS_FILTER_PROGRAMMED > > > REG_FIELD_PREP(PS_FILTER_MASK, 1) > > > #define PS_FILTER_EDGE_ENHANCE REG_FIELD_PREP(PS_FILTER_MASK, > > > 2) > > > #define PS_FILTER_BILINEAR > > > REG_FIELD_PREP(PS_FILTER_MASK, 3) > > > +#define PS_ADAPTIVE_FILTER_MASKREG_BIT(22) /* icl+ */ > > > +#define PS_ADAPTIVE_FILTER_MEDIUM > > > REG_FIELD_PREP(PS_ADAPTIVE_FILTER_MASK, 0) > > > +#define PS_ADAPTIVE_FILTER_EDGE_ENHANCE > > > REG_FIELD_PREP(PS_ADAPTIVE_FILTER_MASK, 1) > > > +#define PS_PIPE_SCALER_LOC_MASKREG_BIT(21) /* icl+ */ > > > +#define PS_PIPE_SCALER_LOC_AFTER_OUTPUT_CSC > > > REG_FIELD_PREP(PS_SCALER_LOCATION_MASK, 0) /* non-linear */ > > > +#define PS_PIPE_SCALER_LOC_AFTER_CSC > > > REG_FIELD_PREP(PS_SCALER_LOCATION_MASK, 1) /* linear */ > > > #define PS_VERT3TAPREG_BIT(21) /* skl/bxt > > > */ > > > #define PS_VERT_INT_INVERT_FIELD REG_BIT(20) > > > +#define PS_PROG_SCALE_FACTOR REG_BIT(19) /* tgl+ */ > > > > This one is actually a two-bit field, isn't it? 19:18. And why not > > define the values for it here too, like with the previous ones? > > It's still a single bit in current hardware. Oh, sorry, I checked the wrong specs. In that case: Reviewed-by: Luca Coelho -- Cheers, Luca.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hdcp: drop display/ prefix from include
== Series Details ==
Series: drm/i915/hdcp: drop display/ prefix from include
URL : https://patchwork.freedesktop.org/series/117619/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13133_full -> Patchwork_117619v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117619v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_big_fb@linear-max-hw-stride-32bpp-rotate-180:
- {shard-dg1}:[PASS][1] -> [DMESG-WARN][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-dg1-18/igt@kms_big...@linear-max-hw-stride-32bpp-rotate-180.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-dg1-15/igt@kms_big...@linear-max-hw-stride-32bpp-rotate-180.html
Known issues
Here are the changes found in Patchwork_117619v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-apl: NOTRUN -> [FAIL][3] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl1/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@smem-oom:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl1/igt@gem_lmem_swapp...@smem-oom.html
* igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271]) +43 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl1/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html
* igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-apl: NOTRUN -> [FAIL][8] ([i915#7036])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl1/igt@i915_pipe_str...@stress-xrgb-untiled.html
* igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886]) +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl1/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_color@ctm-green-to-red@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271]) +9 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-snb1/igt@kms_color@ctm-green-to-...@pipe-a-hdmi-a-1.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][11] ([i915#7173])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl7/igt@kms_content_protection@ato...@pipe-a-dp-1.html
* igt@kms_content_protection@mei_interface:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4579]) +3
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl1/igt@kms_content_protection@mei_interface.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][13] -> [FAIL][14] ([i915#2346]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-b-vga-1:
- shard-snb: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4579]) +6
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-snb5/igt@kms_plane_scaling@planes-downscale-factor-0...@pipe-b-vga-1.html
* igt@kms_writeback@writeback-check-output:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2437])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/shard-apl1/igt@kms_writeb...@writeback-check-output.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][17] ([i915#7742]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/shard-rkl-3/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[18]:
Re: [Intel-gfx] [PATCH] drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
On Thu, May 11, 2023 at 03:31:16PM +0300, Jani Nikula wrote: > On Thu, 11 May 2023, Ville Syrjälä wrote: > > On Thu, May 11, 2023 at 12:04:27PM +0300, Jani Nikula wrote: > >> CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in > >> intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV > >> display base area. > >> > >> Use the 0x182168 MMIO address directly to drop dependency on > >> VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in > >> intel_gt_regs.h. > >> > >> Cc: Ville Syrjälä > >> Signed-off-by: Jani Nikula > >> --- > >> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +-- > >> 1 file changed, 1 insertion(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > >> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > >> index b8a39c219b60..f38550dae6b8 100644 > >> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > >> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > >> @@ -7,7 +7,6 @@ > >> #define __INTEL_GT_REGS__ > >> > >> #include "i915_reg_defs.h" > >> -#include "display/intel_display_reg_defs.h" /* VLV_DISPLAY_BASE */ > >> > >> /* > >> * The perf control registers are technically multicast registers, but the > >> @@ -1469,7 +1468,7 @@ > >> #define GEN12_RCU_MODE_MMIO(0x14800) > >> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0) > >> > >> -#define CHV_FUSE_GT _MMIO(VLV_DISPLAY_BASE > >> + 0x2168) > >> +#define CHV_FUSE_GT _MMIO(0x182168) > > > > Or mmaybe s/VLV_DISPLAY_BASE/VLV_GUNIT_BASE/ here? Although all the > > other Gunit register defintions are still in i915_reg.h, and using > > VLV_DISPLAY_BASE. Not sure what to do about all that... > > Works for me, as long as I can drop the dependency on > display/intel_display_reg_defs.h. > > Just let me know. I'd probably go with the VLV_GUNIT_BASE approach. We can think about what to do with all the other Gunit registers later. > > BR, > Jani. > > > > > >> #define CHV_FGT_DISABLE_SS0 (1 << 10) > >> #define CHV_FGT_DISABLE_SS1 (1 << 11) > >> #define CHV_FGT_EU_DIS_SS0_R0_SHIFT 16 > >> -- > >> 2.39.2 > > -- > Jani Nikula, Intel Open Source Graphics Center -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
On Thu, 11 May 2023, Ville Syrjälä wrote: > On Thu, May 11, 2023 at 12:04:27PM +0300, Jani Nikula wrote: >> CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in >> intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV >> display base area. >> >> Use the 0x182168 MMIO address directly to drop dependency on >> VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in >> intel_gt_regs.h. >> >> Cc: Ville Syrjälä >> Signed-off-by: Jani Nikula >> --- >> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h >> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h >> index b8a39c219b60..f38550dae6b8 100644 >> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h >> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h >> @@ -7,7 +7,6 @@ >> #define __INTEL_GT_REGS__ >> >> #include "i915_reg_defs.h" >> -#include "display/intel_display_reg_defs.h" /* VLV_DISPLAY_BASE */ >> >> /* >> * The perf control registers are technically multicast registers, but the >> @@ -1469,7 +1468,7 @@ >> #define GEN12_RCU_MODE _MMIO(0x14800) >> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0) >> >> -#define CHV_FUSE_GT _MMIO(VLV_DISPLAY_BASE + 0x2168) >> +#define CHV_FUSE_GT _MMIO(0x182168) > > Or mmaybe s/VLV_DISPLAY_BASE/VLV_GUNIT_BASE/ here? Although all the > other Gunit register defintions are still in i915_reg.h, and using > VLV_DISPLAY_BASE. Not sure what to do about all that... Works for me, as long as I can drop the dependency on display/intel_display_reg_defs.h. Just let me know. BR, Jani. > >> #define CHV_FGT_DISABLE_SS0 (1 << 10) >> #define CHV_FGT_DISABLE_SS1 (1 << 11) >> #define CHV_FGT_EU_DIS_SS0_R0_SHIFT 16 >> -- >> 2.39.2 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
On Thu, May 11, 2023 at 12:04:27PM +0300, Jani Nikula wrote: > CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in > intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV > display base area. > > Use the 0x182168 MMIO address directly to drop dependency on > VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in > intel_gt_regs.h. > > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index b8a39c219b60..f38550dae6b8 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -7,7 +7,6 @@ > #define __INTEL_GT_REGS__ > > #include "i915_reg_defs.h" > -#include "display/intel_display_reg_defs.h" /* VLV_DISPLAY_BASE */ > > /* > * The perf control registers are technically multicast registers, but the > @@ -1469,7 +1468,7 @@ > #define GEN12_RCU_MODE _MMIO(0x14800) > #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0) > > -#define CHV_FUSE_GT _MMIO(VLV_DISPLAY_BASE + 0x2168) > +#define CHV_FUSE_GT _MMIO(0x182168) Or mmaybe s/VLV_DISPLAY_BASE/VLV_GUNIT_BASE/ here? Although all the other Gunit register defintions are still in i915_reg.h, and using VLV_DISPLAY_BASE. Not sure what to do about all that... > #define CHV_FGT_DISABLE_SS0(1 << 10) > #define CHV_FGT_DISABLE_SS1(1 << 11) > #define CHV_FGT_EU_DIS_SS0_R0_SHIFT16 > -- > 2.39.2 -- Ville Syrjälä Intel
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel, Here goes drm-intel-fixes for v6.4-rc2. Important fix to taint kernel when force_probe is used, two display fixes (null deref/div-by-zero) and a GuC error capture register list correction. Regards, Joonas PS. Again had to remove one commit with incorrect Fixes: tag so check CI for results before you merge. *** drm-intel-fixes-2023-05-11-1: - Fix to taint kernel when force_probe is used - Null deref and div-by-zero fixes for display - GuC error capture fix for Xe devices The following changes since commit ac9a78681b921877518763ba0e89202254349d1b: Linux 6.4-rc1 (2023-05-07 13:34:35 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-05-11-1 for you to fetch changes up to 79c901c93562bdf1c84ce6c1b744fbbe4389a6eb: drm/i915: taint kernel when force probing unsupported devices (2023-05-11 14:11:59 +0300) - Fix to taint kernel when force_probe is used - Null deref and div-by-zero fixes for display - GuC error capture fix for Xe devices Jani Nikula (1): drm/i915: taint kernel when force probing unsupported devices John Harrison (1): drm/i915/guc: Don't capture Gen8 regs on Xe devices Nikita Zhandarovich (1): drm/i915/dp: prevent potential div-by-zero Stanislav Lisovskiy (1): drm/i915: Fix NULL ptr deref by checking new_crtc_state drivers/gpu/drm/i915/Kconfig | 12 +++- drivers/gpu/drm/i915/display/intel_atomic_plane.c | 4 ++-- drivers/gpu/drm/i915/display/intel_dp.c | 5 + drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 7 +-- drivers/gpu/drm/i915/i915_pci.c | 6 ++ 5 files changed, 25 insertions(+), 9 deletions(-)
Re: [Intel-gfx] [PATCH v7 2/2] drm/i915: use pat_index instead of cache_level
On 09/05/2023 18:12, Yang, Fei wrote:
> On 09/05/2023 00:48, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> Currently the KMD is using enum i915_cache_level to set caching
policy for
>> buffer objects. This is flaky because the PAT index which really
controls
>> the caching behavior in PTE has far more levels than what's defined
in the
>> enum. In addition, the PAT index is platform dependent, having to
translate
>> between i915_cache_level and PAT index is not reliable, and makes
the code
>> more complicated.
>>
>> From UMD's perspective there is also a necessity to set caching
policy for
>> performance fine tuning. It's much easier for the UMD to directly
use PAT
>> index because the behavior of each PAT index is clearly defined in
Bspec.
>> Having the abstracted i915_cache_level sitting in between would only
cause
>> more ambiguity. PAT is expected to work much like MOCS already works
today,
>> and by design userspace is expected to select the index that exactly
>> matches the desired behavior described in the hardware specification.
>>
>> For these reasons this patch replaces i915_cache_level with PAT
index. Also
>> note, the cache_level is not completely removed yet, because the KMD
still
>> has the need of creating buffer objects with simple cache settings
such as
>> cached, uncached, or writethrough. For kernel objects, cache_level
is used
>> for simplicity and backward compatibility. For Pre-gen12 platforms
PAT can
>> have 1:1 mapping to i915_cache_level, so these two are
interchangeable. see
>> the use of LEGACY_CACHELEVEL.
>>
>> One consequence of this change is that gen8_pte_encode is no longer
working
>> for gen12 platforms due to the fact that gen12 platforms has
different PAT
>> definitions. In the meantime the mtl_pte_encode introduced
specfically for
>> MTL becomes generic for all gen12 platforms. This patch renames the MTL
>> PTE encode function into gen12_pte_encode and apply it to all gen12.
Even
>> though this change looks unrelated, but separating them would
temporarily
>> break gen12 PTE encoding, thus squash them in one patch.
>>
>> Special note: this patch changes the way caching behavior is
controlled in
>> the sense that some objects are left to be managed by userspace. For
such
>> objects we need to be careful not to change the userspace settings.There
>> are kerneldoc and comments added around obj->cache_coherent,
cache_dirty,
>> and how to bypass the checkings by i915_gem_object_has_cache_level. For
>> full understanding, these changes need to be looked at together with the
>> two follow-up patches, one disables the {set|get}_caching ioctl's
and the
>> other adds set_pat extension to the GEM_CREATE uAPI.
>>
>> Bspec: 63019
>>
>> Cc: Chris Wilson
>> Signed-off-by: Fei Yang
>> Reviewed-by: Andi Shyti
>> Reviewed-by: Matt Roper
[snip]
>> + node.start,
>> + i915_gem_get_pat_index(i915,
>> +
I915_CACHE_NONE), 0);
>> wmb(); /* flush modifications to the GGTT
(insert_page) */
>> } else {
>> page_base += offset & PAGE_MASK;
>> @@ -1142,6 +1148,19 @@ int i915_gem_init(struct drm_i915_private
*dev_priv)
>> unsigned int i;
>> int ret;
>>
>> + /*
>> + * In the proccess of replacing cache_level with pat_index a
tricky
>> + * dependency is created on the definition of the enum
i915_cache_level.
>> + * in case this enum is changed, PTE encode would be broken.
>
>_I_n
Sorry, what does this mean?
Start of sentence, capital 'i'.
[snip]
> With a pinky promise to improve this all in the near future I won't
> grumble to loudly. :) I haven't read all the details, I leave that to
> other reviewers, and also assuming some final tweaks as indicated above
> please.
Thanks for all the suggestions, really appreciated.
May I add your Acked-by?
I can't make myself do it since I really don't like the design that
much. That's why I said I will not grumble too loudly.
Jira for follow up clean since we both agreed something more elegant is
possible would be appreciated though.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH v2 7/7] drm/i915: Define more PS_CTRL bits
On Thu, May 11, 2023 at 10:29:01AM +0300, Luca Coelho wrote: > On Wed, 2023-04-26 at 16:50 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > To avoid annoying spec lookups let's define more PS_CTRL > > bits in the header. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/i915_reg.h | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > b/drivers/gpu/drm/i915/i915_reg.h > > index f5ae8d1eb6ff..e08bb15eddcf 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -4055,6 +4055,9 @@ > > #define _PS_2B_CTRL 0x68A80 > > #define _PS_1C_CTRL 0x69180 > > #define PS_SCALER_EN REG_BIT(31) > > +#define PS_SCALER_TYPE_MASK REG_BIT(30) /* icl+ */ > > +#define PS_SCALER_TYPE_NON_LINEAR > > REG_FIELD_PREP(PS_SCALER_TYPE_MASK, 0) > > +#define PS_SCALER_TYPE_LINEAR > > REG_FIELD_PREP(PS_SCALER_TYPE_MASK, 1) > > #define SKL_PS_SCALER_MODE_MASK REG_GENMASK(29, 28) /* skl/bxt > > */ > > #define SKL_PS_SCALER_MODE_DYN > > REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 0) > > #define SKL_PS_SCALER_MODE_HQ > > REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 1) > > @@ -4062,6 +4065,7 @@ > > #define PS_SCALER_MODE_MASK REG_BIT(29) /* glk-tgl > > */ > > #define PS_SCALER_MODE_NORMAL > > REG_FIELD_PREP(PS_SCALER_MODE_MASK, 0) > > #define PS_SCALER_MODE_PLANAR > > REG_FIELD_PREP(PS_SCALER_MODE_MASK, 1) > > +#define PS_ADAPTIVE_FILTERING_EN REG_BIT(28) /* icl+ */ > > #define PS_BINDING_MASK REG_GENMASK(27, 25) > > #define PS_BINDING_PIPE REG_FIELD_PREP(PS_BINDING_MASK, > > 0) > > #define PS_BINDING_PLANE(plane_id) > > REG_FIELD_PREP(PS_BINDING_MASK, (plane_id) + 1) > > @@ -4070,8 +4074,15 @@ > > #define PS_FILTER_PROGRAMMED > > REG_FIELD_PREP(PS_FILTER_MASK, 1) > > #define PS_FILTER_EDGE_ENHANCE REG_FIELD_PREP(PS_FILTER_MASK, > > 2) > > #define PS_FILTER_BILINEAR > > REG_FIELD_PREP(PS_FILTER_MASK, 3) > > +#define PS_ADAPTIVE_FILTER_MASK REG_BIT(22) /* icl+ */ > > +#define PS_ADAPTIVE_FILTER_MEDIUM > > REG_FIELD_PREP(PS_ADAPTIVE_FILTER_MASK, 0) > > +#define PS_ADAPTIVE_FILTER_EDGE_ENHANCE > > REG_FIELD_PREP(PS_ADAPTIVE_FILTER_MASK, 1) > > +#define PS_PIPE_SCALER_LOC_MASK REG_BIT(21) /* icl+ */ > > +#define PS_PIPE_SCALER_LOC_AFTER_OUTPUT_CSC > > REG_FIELD_PREP(PS_SCALER_LOCATION_MASK, 0) /* non-linear */ > > +#define PS_PIPE_SCALER_LOC_AFTER_CSC > > REG_FIELD_PREP(PS_SCALER_LOCATION_MASK, 1) /* linear */ > > #define PS_VERT3TAP REG_BIT(21) /* skl/bxt > > */ > > #define PS_VERT_INT_INVERT_FIELD REG_BIT(20) > > +#define PS_PROG_SCALE_FACTOR REG_BIT(19) /* tgl+ */ > > This one is actually a two-bit field, isn't it? 19:18. And why not > define the values for it here too, like with the previous ones? It's still a single bit in current hardware. > > > #define PS_PWRUP_PROGRESSREG_BIT(17) > > #define PS_V_FILTER_BYPASS REG_BIT(8) > > #define PS_VADAPT_EN REG_BIT(7) /* skl/bxt */ > > -- > Cheers, > Luca. -- Ville Syrjälä Intel
[Intel-gfx] ✓ Fi.CI.BAT: success for Fix modeset locking issue in HDCP MST (rev2)
== Series Details == Series: Fix modeset locking issue in HDCP MST (rev2) URL : https://patchwork.freedesktop.org/series/117615/ State : success == Summary == CI Bug Log - changes from CI_DRM_13133 -> Patchwork_117615v2 Summary --- **WARNING** Minor unknown changes coming with Patchwork_117615v2 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_117615v2, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/index.html Participating hosts (41 -> 40) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_117615v2: ### IGT changes ### Warnings * igt@prime_vgem@basic-write: - bat-atsm-1: [SKIP][1] ([fdo#109295]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-atsm-1/igt@prime_v...@basic-write.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-atsm-1/igt@prime_v...@basic-write.html Known issues Here are the changes found in Patchwork_117615v2 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_backlight@basic-brightness@edp-1: - bat-rplp-1: NOTRUN -> [ABORT][3] ([i915#7077]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html * igt@i915_selftest@live@migrate: - bat-adlp-9: [PASS][4] -> [DMESG-FAIL][5] ([i915#7699] / [i915#7913]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-adlp-9/igt@i915_selftest@l...@migrate.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-adlp-9/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-WARN][6] ([i915#6367]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-rpls-2/igt@i915_selftest@l...@slpc.html - bat-rpls-1: NOTRUN -> [DMESG-WARN][7] ([i915#6367] / [i915#7953]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-rpls-2: NOTRUN -> [ABORT][8] ([i915#6687]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-1: NOTRUN -> [ABORT][9] ([i915#6687] / [i915#7953] / [i915#7978]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1: - bat-dg2-8: [PASS][10] -> [FAIL][11] ([i915#7932]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html * igt@kms_setmode@basic-clone-single-crtc: - bat-rplp-1: NOTRUN -> [SKIP][12] ([i915#3555] / [i915#4579]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html Possible fixes * igt@i915_selftest@live@gt_lrc: - bat-rpls-1: [INCOMPLETE][13] ([i915#4983] / [i915#7953]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@reset: - bat-rpls-2: [ABORT][15] ([i915#4983] / [i915#7461] / [i915#7913] / [i915#7981] / [i915#8347]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-rpls-2/igt@i915_selftest@l...@reset.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1: - bat-dg2-8: [FAIL][17] ([i915#7932]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html Warnings * igt@kms_psr@primary_mmap_gtt: - bat-rplp-1: [ABORT][19] -> [SKIP][20] ([i915#1072]) [19]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fix modeset locking issue in HDCP MST (rev2)
== Series Details == Series: Fix modeset locking issue in HDCP MST (rev2) URL : https://patchwork.freedesktop.org/series/117615/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
== Series Details ==
Series: drm/i915/gt: drop dependency on VLV_DISPLAY_BASE
URL : https://patchwork.freedesktop.org/series/117620/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13133 -> Patchwork_117620v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/index.html
Participating hosts (41 -> 38)
--
Missing(3): fi-kbl-soraka bat-rpls-2 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117620v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@dmabuf@all-tests@dma_fence:
- fi-glk-j4005: [PASS][1] -> [ABORT][2] ([i915#8144])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/fi-glk-j4005/igt@dmabuf@all-tests@dma_fence.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/fi-glk-j4005/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@dma_fence_chain:
- fi-glk-j4005: [PASS][3] -> [DMESG-FAIL][4] ([i915#8144])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/fi-glk-j4005/igt@dmabuf@all-tests@dma_fence_chain.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/fi-glk-j4005/igt@dmabuf@all-tests@dma_fence_chain.html
* igt@gem_exec_suspend@basic-s0@lmem0:
- bat-dg1-7: [PASS][5] -> [FAIL][6] ([fdo#103375] / [i915#8011])
+1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-dg1-7/igt@gem_exec_suspend@basic...@lmem0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-dg1-7/igt@gem_exec_suspend@basic...@lmem0.html
* igt@gem_exec_suspend@basic-s3@smem:
- bat-dg1-7: [PASS][7] -> [FAIL][8] ([fdo#103375]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-dg1-7/igt@gem_exec_suspend@basic...@smem.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-dg1-7/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][9] ([i915#7077])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][10] -> [DMESG-FAIL][11] ([i915#5334])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- bat-atsm-1: [PASS][12] -> [DMESG-FAIL][13] ([i915#7699] /
[i915#7913])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-atsm-1/igt@i915_selftest@l...@migrate.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-atsm-1/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-WARN][14] ([i915#6367] / [i915#7953])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][15] ([i915#6687] / [i915#7953] /
[i915#7978])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][16] -> [FAIL][17] ([i915#7932]) +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
* igt@kms_pipe_crc_basic@read-crc:
- bat-adlp-9: NOTRUN -> [SKIP][18] ([i915#3546]) +1 similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [SKIP][19] ([i915#3555] / [i915#4579])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- bat-rpls-1: [INCOMPLETE][20] ([i915#4983] / [i915#7953]) ->
[PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117620v1/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][22] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][23]
[22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: implement internal workqueues
== Series Details ==
Series: drm/i915: implement internal workqueues
URL : https://patchwork.freedesktop.org/series/117618/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13132_full -> Patchwork_117618v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_117618v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_mmap_gtt@fault-concurrent-x:
- shard-snb: [PASS][3] -> [ABORT][4] ([i915#5161])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-snb1/igt@gem_mmap_...@fault-concurrent-x.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-snb7/igt@gem_mmap_...@fault-concurrent-x.html
* igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-snb: [PASS][5] -> [FAIL][6] ([i915#8295])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-snb4/igt@gem_pp...@blt-vs-render-ctx0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-snb1/igt@gem_pp...@blt-vs-render-ctx0.html
* igt@kms_color@ctm-0-25@pipe-b-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4579]) +8
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-snb1/igt@kms_color@ctm-0...@pipe-b-hdmi-a-1.html
* igt@kms_color@ctm-green-to-red@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271]) +11 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-snb1/igt@kms_color@ctm-green-to-...@pipe-a-hdmi-a-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#2122]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-glk5/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ab-hdmi-a1-hdmi-a2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-glk2/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ab-hdmi-a1-hdmi-a2.html
* igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1:
- shard-apl: [PASS][13] -> [FAIL][14] ([i915#1188])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-apl1/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-apl4/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
* igt@kms_properties@crtc-properties-legacy:
- shard-snb: [PASS][15] -> [SKIP][16] ([fdo#109271]) +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-snb4/igt@kms_propert...@crtc-properties-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-snb1/igt@kms_propert...@crtc-properties-legacy.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-tglu}: [ABORT][17] ([i915#7953] / [i915#8211] / [i915#8234])
-> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-tglu-9/igt@gem_barrier_race@remote-requ...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-tglu-9/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_endless@dispatch@rcs0:
- {shard-rkl}:[TIMEOUT][19] ([i915#3778]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-rkl-4/igt@gem_exec_endless@dispa...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-rkl-3/igt@gem_exec_endless@dispa...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][21] ([i915#2842]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/shard-rkl-4/igt@gem_exec_fair@basic-n...@vcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/shard-rkl-7/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_mmap_offset@clear@smem0:
- {shard-dg1}:[FAIL][23] ([i915#7962]) -> [PASS][24]
[23]:
[Intel-gfx] [PATCH 2/2] drm/i915/mtl: Add handling for MTL ccs modifiers
Add Tile4 ccs modifiers w/ auxbuffer handling
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_fb.c | 42 ++-
.../drm/i915/display/skl_universal_plane.c| 22 +-
2 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index c004f08fcfe1..f9420a68ed3c 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -157,6 +157,32 @@ struct intel_modifier_desc {
static const struct intel_modifier_desc intel_modifiers[] = {
{
+ .modifier = I915_FORMAT_MOD_4_TILED_MTL_MC_CCS,
+ .display_ver = { 14, 14 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
+
+ .ccs.packed_aux_planes = BIT(1),
+ .ccs.planar_aux_planes = BIT(2) | BIT(3),
+
+ FORMAT_OVERRIDE(gen12_ccs_formats),
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED_MTL_RC_CCS,
+ .display_ver = { 14, 14 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_RC,
+
+ .ccs.packed_aux_planes = BIT(1),
+
+ FORMAT_OVERRIDE(gen12_ccs_formats),
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC,
+ .display_ver = { 14, 14 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4 |
INTEL_PLANE_CAP_CCS_RC_CC,
+
+ .ccs.cc_planes = BIT(2),
+ .ccs.packed_aux_planes = BIT(1),
+
+ FORMAT_OVERRIDE(gen12_ccs_cc_formats),
+ }, {
.modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
.display_ver = { 13, 13 },
.plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
@@ -370,6 +396,14 @@ static bool plane_has_modifier(struct drm_i915_private
*i915,
if (!plane_caps_contain_all(plane_caps, md->plane_caps))
return false;
+ /*
+* Separate AuxCCS and Flat CCS modifiers to be run only on platforms
+* where supported.
+*/
+ if (intel_fb_is_ccs_modifier(md->modifier) &&
+ HAS_FLAT_CCS(i915) != !md->ccs.packed_aux_planes)
+ return false;
+
return true;
}
@@ -489,7 +523,7 @@ static bool intel_fb_is_gen12_ccs_aux_plane(const struct
drm_framebuffer *fb, in
{
const struct intel_modifier_desc *md = lookup_modifier(fb->modifier);
- return check_modifier_display_ver_range(md, 12, 13) &&
+ return check_modifier_display_ver_range(md, 12, 14) &&
ccs_aux_plane_mask(md, fb->format) & BIT(color_plane);
}
@@ -605,6 +639,9 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
return 128;
fallthrough;
+ case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
+ case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
@@ -791,6 +828,9 @@ unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
+ case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
+ case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
return 16 * 1024;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 8ea0598a5a07..f6f760e59c9e 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -789,6 +789,14 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
PLANE_CTL_CLEAR_COLOR_DISABLE;
case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
return PLANE_CTL_TILED_4 |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
+ case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS:
+ return PLANE_CTL_TILED_4 |
+ PLANE_CTL_RENDER_DECOMPRESSION_ENABLE |
+ PLANE_CTL_CLEAR_COLOR_DISABLE;
+ case I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC:
+ return PLANE_CTL_TILED_4 |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
+ case I915_FORMAT_MOD_4_TILED_MTL_MC_CCS:
+ return PLANE_CTL_TILED_4 | PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
return PLANE_CTL_TILED_Y |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
@@ -2160,6 +2168,11 @@
[Intel-gfx] [PATCH 1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers
Add Tile4 type ccs modifiers with aux buffer needed for MTL
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Signed-off-by: Juha-Pekka Heikkila
---
include/uapi/drm/drm_fourcc.h | 43 +++
1 file changed, 43 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index de703c6be969..cbe214adf1e4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -657,6 +657,49 @@ extern "C" {
*/
#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12)
+/*
+ * Intel color control surfaces (CCS) for display ver 14 render compression.
+ *
+ * The main surface is tile4 and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * tile4 widths.
+ */
+#define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS fourcc_mod_code(INTEL, 13)
+
+/*
+ * Intel color control surfaces (CCS) for display ver 14 media compression
+ *
+ * The main surface is tile4 and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * tile4 widths. For semi-planar formats like NV12, CCS planes follow the
+ * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
+ * planes 2 and 3 for the respective CCS.
+ */
+#define I915_FORMAT_MOD_4_TILED_MTL_MC_CCS fourcc_mod_code(INTEL, 14)
+
+/*
+ * Intel Color Control Surface with Clear Color (CCS) for display ver 14 render
+ * compression.
+ *
+ * The main surface is tile4 and is at plane index 0 whereas CCS is linear
+ * and at index 1. The clear color is stored at index 2, and the pitch should
+ * be ignored. The clear color structure is 256 bits. The first 128 bits
+ * represents Raw Clear Color Red, Green, Blue and Alpha color each represented
+ * by 32 bits. The raw clear color is consumed by the 3d engine and generates
+ * the converted clear color of size 64 bits. The first 32 bits store the Lower
+ * Converted Clear Color value and the next 32 bits store the Higher Converted
+ * Clear Color value when applicable. The Converted Clear Color values are
+ * consumed by the DE. The last 64 bits are used to store Color Discard Enable
+ * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
+ * corresponds to an area of 4x1 tiles in the main surface. The main surface
+ * pitch is required to be a multiple of 4 tile widths.
+ */
+#define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: drop display/ prefix from include
== Series Details ==
Series: drm/i915/hdcp: drop display/ prefix from include
URL : https://patchwork.freedesktop.org/series/117619/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13133 -> Patchwork_117619v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/index.html
Participating hosts (41 -> 40)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117619v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][1] ([i915#7077])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-WARN][2] ([i915#6367] / [i915#7953])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][3] ([i915#6687])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][4] ([i915#6687] / [i915#7953] /
[i915#7978])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][5] ([i915#3546]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [SKIP][6] ([i915#3555] / [i915#4579])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- bat-rpls-1: [INCOMPLETE][7] ([i915#4983] / [i915#7953]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-6}: [ABORT][9] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-mtlp-6/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][11] ([i915#4983] / [i915#7461] / [i915#7913]
/ [i915#7981] / [i915#8347]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-rpls-2/igt@i915_selftest@l...@reset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1:
- bat-dg2-8: [FAIL][13] ([i915#7932]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
Warnings
* igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: [ABORT][15] -> [SKIP][16] ([i915#1072])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13133/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117619v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
Re: [Intel-gfx] [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.
On 10/05/2023 19:46, Tejun Heo wrote: Hello, On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote: The misc controller is not granular enough. A single computer may have any number of graphics cards, some of them with multiple regions of vram inside a single card. Extending the misc controller to support dynamic keys shouldn't be that difficult. ... In the next version, I will move all the code for handling the resource limit to TTM's eviction layer, because otherwise it cannot handle the resource limit correctly. The effect of moving the code to TTM, is that it will make the code even more generic for drivers that have vram and use TTM. When using TTM, you only have to describe your VRAM, update some fields in the TTM manager and (un)register your device with the cgroup handler on (un)load. It's quite trivial to add vram accounting to amdgpu and nouveau. [2] If you want to add a knob for scheduling weight for a process, it makes sense to also add resource usage as a knob, otherwise the effect of that knob is very limited. So even for Tvrtko's original proposed usecase, it would make sense. It does make sense but unlike Tvrtko's scheduling weights what's being proposed doesn't seem to encapsulate GPU memory resource in a generic enough manner at least to my untrained eyes. ie. w/ drm.weight, I don't need any specific knoweldge of how a specific GPU operates to say "this guy should get 2x processing power over that guy". This more or less holds for other major resources including CPU, memory and IO. What you're proposing seems a lot more tied to hardware details and users would have to know a lot more about how memory is configured on that particular GPU. Now, if this is inherent to how all, or at least most, GPUs operate, sure, but otherwise let's start small in terms of interface and not take up space which should be for something universal. If this turns out to be the way, expanding to take up the generic interface space isn't difficult. I don't know GPU space so please educate me where I'm wrong. I was hoping it might be passable in principle (in some form, pending discussion on semantics) given how Maarten's proposal starts with only very specific per-device-per-memory regions controls, which is applicable to many devices. And hard limit at that, which probably has less complicated semantics, or at least implementation. My understanding of the proposal is that the allocation either fits, or it evicts from the parent's hierarchy (if possible) and then fits, or it fails. Which sounds simple enough. I do however agree that it is a limited use case. So from the negative side of the debating camp I have to ask if this use case could be simply satisfied by providing a driver/device global over commit yes/no control? In other words, is it really important to partition the vram space ahead of time, and from the kernel side too? Wouldn't the relevant (highly specialised) applications work just fine with global over commit disabled? Even if the option to configure their maximum allowed working set from the userspace side was needed. Or if we conclude cgroup controller is the way to go, would adding less specific limits make it more palatable? I am thinking here some generic "device memory resident". Not per device, not per memory region. So userspace/admins have some chance of configuring generic limits. That would require coming up with more generic use cases though so another thing to discuss. Like who would use that and for what. Assuming also we can agree that "device memory resident" is a stable/solid concept across drm. Should be easier than for integrated GPUs, for which I have to admit I currently don't remember if allocations are already consistently covered by the memory controller. Even if they are ownership is probably wrong. Group ownership is possibly a concern in this proposal too. Because I remember the previous attempt of adding some drm stats to memcg explained that for instance on Android all buffers are allocated by a central process and then handed over to other processes. So transferring ownership was explained as critical. Regards, Tvrtko P.S. On the matter of naming the uapi interface - in any case I wouldn't use the "unqualified" drm namespace such as drm.max/current/capacity. I think all those should include a specific prefix to signify it is about memory. In some way.
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Daniel, Next pull request, with the previous one included too: drm-misc-fixes-2023-05-11: drm-misc-fixes for v6.4-rc2: - More DSC macro fixes. - Small mipi-dsi fix. - Scheduler timeout handling fix. --- drm-misc-fixes for v6.4-rc1: - Fix DSC macros. - Fix VESA format for simplefb. - Prohibit potential out-of-bounds access in generic fbdev emulation. - Improve AST2500+ compat on ARM. The following changes since commit b63a553e8f5aa6574eeb535a551817a93c426d8c: drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume (2023-04-17 23:40:40 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-05-11 for you to fetch changes up to 2da5bffe9eaa5819a868e8eaaa11b3fd0f16a691: drm/sched: Check scheduler work queue before calling timeout handling (2023-05-10 10:28:01 -0400) drm-misc-fixes for v6.4-rc2: - More DSC macro fixes. - Small mipi-dsi fix. - Scheduler timeout handling fix. --- drm-misc-fixes for v6.4-rc1: - Fix DSC macros. - Fix VESA format for simplefb. - Prohibit potential out-of-bounds access in generic fbdev emulation. - Improve AST2500+ compat on ARM. Jammy Huang (1): drm/ast: Fix ARM compatibility Jani Nikula (2): drm/dsc: fix drm_edp_dsc_sink_output_bpp() DPCD high byte usage drm/dsc: fix DP_DSC_MAX_BPP_DELTA_* macro values Kees Cook (1): drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes Pierre Asselin (1): firmware/sysfb: Fix VESA format selection Saravana Kannan (1): drm/mipi-dsi: Set the fwnode for mipi_dsi_device Sui Jingfeng (1): drm/fbdev-generic: prohibit potential out-of-bounds access Vitaly Prosyak (1): drm/sched: Check scheduler work queue before calling timeout handling drivers/firmware/sysfb_simplefb.c| 4 +++- drivers/gpu/drm/ast/ast_main.c | 9 + drivers/gpu/drm/drm_fb_helper.c | 16 drivers/gpu/drm/drm_mipi_dsi.c | 2 +- drivers/gpu/drm/nouveau/include/nvif/if0012.h| 4 +++- drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h | 3 ++- drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c | 2 +- drivers/gpu/drm/scheduler/sched_main.c | 2 +- include/drm/display/drm_dp.h | 5 ++--- include/drm/display/drm_dp_helper.h | 5 ++--- 10 files changed, 32 insertions(+), 20 deletions(-) - On 2023-05-11 10:01, Thomas Zimmermann wrote: > A friendly ping to merge this PR. The patches appear to be missing from > drm-fixes. > > Am 26.04.23 um 07:59 schrieb Maarten Lankhorst: >> Hi Dave, Daniel, >> >> drm-misc-fixes pull request for rc1. drm-misc-next-fixes coming up.. next >> >> ~Maarten >> >> drm-misc-fixes-2023-04-26: >> drm-misc-fixes for v6.4-rc1: >> - Fix DSC macros. >> - Fix VESA format for simplefb. >> - Prohibit potential out-of-bounds access in generic fbdev emulation. >> - Improve AST2500+ compat on ARM. >> The following changes since commit b63a553e8f5aa6574eeb535a551817a93c426d8c: >> >> drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume (2023-04-17 >> 23:40:40 +0200) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-04-26 >> >> for you to fetch changes up to 0d68683838f2850dd8ff31f1121e05bfb7a2def0: >> >> drm/dsc: fix DP_DSC_MAX_BPP_DELTA_* macro values (2023-04-24 22:40:57 >> +0300) >> >> >> drm-misc-fixes for v6.4-rc1: >> - Fix DSC macros. >> - Fix VESA format for simplefb. >> - Prohibit potential out-of-bounds access in generic fbdev emulation. >> - Improve AST2500+ compat on ARM. >> >> >> Jammy Huang (1): >> drm/ast: Fix ARM compatibility >> >> Jani Nikula (2): >> drm/dsc: fix drm_edp_dsc_sink_output_bpp() DPCD high byte usage >> drm/dsc: fix DP_DSC_MAX_BPP_DELTA_* macro values >> >> Pierre Asselin (1): >> firmware/sysfb: Fix VESA format selection >> >> Sui Jingfeng (1): >> drm/fbdev-generic: prohibit potential out-of-bounds access >> >> drivers/firmware/sysfb_simplefb.c | 4 +++- >> drivers/gpu/drm/ast/ast_main.c | 9 + >> drivers/gpu/drm/drm_fb_helper.c | 16 >> include/drm/display/drm_dp.h | 5 ++--- >> include/drm/display/drm_dp_helper.h | 5 ++--- >> 5 files changed, 24 insertions(+), 15 deletions(-) >> >> >
Re: [Intel-gfx] [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.
Hey, On 2023-05-10 20:46, Tejun Heo wrote: > Hello, > > On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote: >> The misc controller is not granular enough. A single computer may have any >> number of >> graphics cards, some of them with multiple regions of vram inside a single >> card. > Extending the misc controller to support dynamic keys shouldn't be that > difficult. > > ... >> In the next version, I will move all the code for handling the resource >> limit to >> TTM's eviction layer, because otherwise it cannot handle the resource limit >> correctly. >> >> The effect of moving the code to TTM, is that it will make the code even >> more generic >> for drivers that have vram and use TTM. When using TTM, you only have to >> describe your >> VRAM, update some fields in the TTM manager and (un)register your device >> with the >> cgroup handler on (un)load. It's quite trivial to add vram accounting to >> amdgpu and >> nouveau. [2] >> >> If you want to add a knob for scheduling weight for a process, it makes >> sense to >> also add resource usage as a knob, otherwise the effect of that knob is very >> limited. So even for Tvrtko's original proposed usecase, it would make sense. > It does make sense but unlike Tvrtko's scheduling weights what's being > proposed doesn't seem to encapsulate GPU memory resource in a generic enough > manner at least to my untrained eyes. ie. w/ drm.weight, I don't need any > specific knoweldge of how a specific GPU operates to say "this guy should > get 2x processing power over that guy". This more or less holds for other > major resources including CPU, memory and IO. What you're proposing seems a > lot more tied to hardware details and users would have to know a lot more > about how memory is configured on that particular GPU. There's not much need of knowing the specifics of a card, but there might be a need of knowing the workload to determine what allocation limits to set. I've left region to be implementation specific, but it would make sense to standardise it. TTM, the layer used by drivers that support VRAM, have the following regions: * sysmem - All system memory allocated; includes evicted VRAM. * mapped - All physical system memory that is mapped to the GPU, when unbound moves to sysmem. When evicting VRAM to sysmem, it's temporarily mapped here. * vramN - All VRAM regions of the device. * driver specific regions - probably doesn't make sense to put in cgroup at all, this includes stolen from the PoC. That leaves the question, what regions would make sense for a cgroup? Since vramN can be moved to mapped and sysmem (VRAM eviction, suspend/resume, driver_madvise), it becomes a subject of debate if we should include the other regions, since things become complicated fast. For the first iteration, I focus on a single category, vramN. Even when not knowing anything about a GPU, it will be easy to partition its memory like that. If you can assign a weight for the scheduler, then you can also partition it's vram by parsing /drm.capacity for total amount, and then splitting it across cgroups. > Now, if this is inherent to how all, or at least most, GPUs operate, sure, > but otherwise let's start small in terms of interface and not take up space > which should be for something universal. If this turns out to be the way, > expanding to take up the generic interface space isn't difficult. > > I don't know GPU space so please educate me where I'm wrong. Most GPU's have dedicated vram that works roughly in the same way, some integrated chips like i915 or arm use shared memory from the host system only. I would say amd, nvidia and intel's chips with dedicated memory work roughly in the same way for vram. I hope this explains it a little bit more, ~Maarten
[Intel-gfx] [PATCH v2 2/2] drm/i915/hdcp: Fix modeset locking issue in hdcp mst
Since topology state is being added to drm_atomic_state now all
drm_modeset_lock required are being taken from core this raises
an issue when we try to loop over connector and assign vcpi id to
our streams as we did not have atomic state to derive acquire_ctx
from hence we fill in stream info if dpmst encoder is found before
enabling hdcp.
--v2
-move prepare streams to beginning of intel_hdcp_enable to avoid
checking of mst encoder twice [Ankit]
Cc: Jani Nikula
Cc: Ankit Nautiyal
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 39 ++-
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index e2c5781ad0ab..bf40d1c7aaa1 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -30,7 +30,8 @@
#define KEY_LOAD_TRIES 5
#define HDCP2_LC_RETRY_CNT 3
-static int intel_conn_to_vcpi(struct intel_connector *connector)
+static int intel_conn_to_vcpi(struct drm_atomic_state *state,
+ struct intel_connector *connector)
{
struct drm_dp_mst_topology_mgr *mgr;
struct drm_dp_mst_atomic_payload *payload;
@@ -42,10 +43,10 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
return 0;
mgr = connector->port->mgr;
- drm_modeset_lock(>base.lock, NULL);
+ drm_modeset_lock(>base.lock, state->acquire_ctx);
mst_state = to_drm_dp_mst_topology_state(mgr->base.state);
payload = drm_atomic_get_mst_payload_state(mst_state, connector->port);
- if (drm_WARN_ON(mgr->dev, !payload))
+ if (!payload)
goto out;
vcpi = payload->vcpi;
@@ -54,7 +55,6 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
goto out;
}
out:
- drm_modeset_unlock(>base.lock);
return vcpi;
}
@@ -69,7 +69,8 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
* policy to mark different content_types for different streams.
*/
static int
-intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
+intel_hdcp_required_content_stream(struct intel_digital_port *dig_port,
+ struct intel_atomic_state *state)
{
struct drm_connector_list_iter conn_iter;
struct intel_digital_port *conn_dig_port;
@@ -81,9 +82,6 @@ intel_hdcp_required_content_stream(struct intel_digital_port
*dig_port)
data->k = 0;
- if (dig_port->hdcp_auth_status)
- return 0;
-
drm_connector_list_iter_begin(>drm, _iter);
for_each_intel_connector_iter(connector, _iter) {
if (connector->base.status == connector_status_disconnected)
@@ -99,7 +97,8 @@ intel_hdcp_required_content_stream(struct intel_digital_port
*dig_port)
if (!enforce_type0 && !dig_port->hdcp_mst_type1_capable)
enforce_type0 = true;
- data->streams[data->k].stream_id =
intel_conn_to_vcpi(connector);
+ data->streams[data->k].stream_id =
+ intel_conn_to_vcpi(>base, connector);
data->k++;
/* if there is only one active stream */
@@ -122,7 +121,8 @@ intel_hdcp_required_content_stream(struct
intel_digital_port *dig_port)
return 0;
}
-static int intel_hdcp_prepare_streams(struct intel_connector *connector)
+static int intel_hdcp_prepare_streams(struct intel_atomic_state *state,
+ struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
@@ -133,7 +133,7 @@ static int intel_hdcp_prepare_streams(struct
intel_connector *connector)
data->k = 1;
data->streams[0].stream_type = hdcp->content_type;
} else {
- ret = intel_hdcp_required_content_stream(dig_port);
+ ret = intel_hdcp_required_content_stream(dig_port, state);
if (ret)
return ret;
}
@@ -1917,14 +1917,6 @@ static int hdcp2_authenticate_and_encrypt(struct
intel_connector *connector)
for (i = 0; i < tries && !dig_port->hdcp_auth_status; i++) {
ret = hdcp2_authenticate_sink(connector);
if (!ret) {
- ret = intel_hdcp_prepare_streams(connector);
- if (ret) {
- drm_dbg_kms(>drm,
- "Prepare streams failed.(%d)\n",
- ret);
- break;
- }
-
ret = hdcp2_propagate_stream_management_info(connector);
if (ret) {
[Intel-gfx] [PATCH v2 1/2] drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function
Pass all the parameter in intel_encoder->enable()
to intel_hdcp_enable as we need intel_atomic_state
later down to get acquire_ctx.
Cc: Jani Nikula
Cc: Ankit Nautiyal
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_ddi.c| 4 +---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +---
drivers/gpu/drm/i915/display/intel_hdcp.c | 16 +---
drivers/gpu/drm/i915/display/intel_hdcp.h | 6 --
4 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 29e4bfab4635..2d3071e46567 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3264,9 +3264,7 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state,
- (u8)conn_state->hdcp_content_type);
+ intel_hdcp_enable(state, encoder, crtc_state, conn_state);
}
static void intel_disable_ddi_dp(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2c49d9ab86a2..da1666c7c2ee 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -800,9 +800,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state
*state,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector),
- pipe_config,
- (u8)conn_state->hdcp_content_type);
+ intel_hdcp_enable(state, encoder, pipe_config, conn_state);
}
static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 650232c4892b..e2c5781ad0ab 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2330,10 +2330,14 @@ int intel_hdcp_init(struct intel_connector *connector,
return 0;
}
-int intel_hdcp_enable(struct intel_connector *connector,
- const struct intel_crtc_state *pipe_config, u8
content_type)
+int intel_hdcp_enable(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *pipe_config,
+ const struct drm_connector_state *conn_state)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
@@ -2352,7 +2356,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
mutex_lock(_port->hdcp_mutex);
drm_WARN_ON(_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
- hdcp->content_type = content_type;
+ hdcp->content_type = (u8)conn_state->content_type;
if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
@@ -2483,9 +2487,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state
*state,
}
if (desired_and_not_enabled || content_protection_type_changed)
- intel_hdcp_enable(connector,
- crtc_state,
- (u8)conn_state->hdcp_content_type);
+ intel_hdcp_enable(state, encoder, crtc_state, conn_state);
}
void intel_hdcp_component_fini(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 8f53b0c7fe5c..ce283f4f69fd 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -28,8 +28,10 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
int intel_hdcp_init(struct intel_connector *connector,
struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *hdcp_shim);
-int intel_hdcp_enable(struct intel_connector *connector,
- const struct intel_crtc_state *pipe_config, u8
content_type);
+int intel_hdcp_enable(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const
[Intel-gfx] [PATCH v2 0/2] Fix modeset locking issue in HDCP MST
HDCP MST scenario sees modeset locking issue ever since topology_state was added to drm_atomic_state and all modeset locks were being taken for us causing a locking issue to occur when we iterate over connectors to assign vcpi id, the fix being to pass acquire_ctx to drm_modeset_lock --v2 -call intel_hdcp_prepare_stream instead of intel_hdcp_required_stream in the beginning [Ankit] -replace intel_connector argument with intel_encoder [Jani] Signed-off-by: Suraj Kandpal Suraj Kandpal (2): drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function drm/i915/hdcp: Fix modeset locking issue in hdcp mst drivers/gpu/drm/i915/display/intel_ddi.c| 4 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 55 ++--- drivers/gpu/drm/i915/display/intel_hdcp.h | 6 ++- 4 files changed, 32 insertions(+), 37 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 2/2] drm/i915/hdcp: Fix modeset locking issue in hdcp mst
On 5/11/2023 11:27 AM, Suraj Kandpal wrote:
Since topology state is being added to drm_atomic_state now all
drm_modeset_lock required are being taken from core this raises
an issue when we try to loop over connector and assign vcpi id to
our streams as we did not have atomic state to derive acquire_ctx
from hence we fill in stream info if dpmst encoder is found before
enabling hdcp.
Cc: Jani Nikula
Cc: Ankit Nautiyal
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_display_types.h| 2 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 26 ++-
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 35c260bd1461..aecd84b66735 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1813,6 +1813,8 @@ struct intel_digital_port {
struct hdcp_port_data hdcp_port_data;
/* Whether the MST topology supports HDCP Type 1 Content */
bool hdcp_mst_type1_capable;
+ /* If streams for HDCP MST are assigned with vcpi id and stream type */
+ int hdcp_mst_streams_ready;
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1928c80cb6a2..d2874431c9d3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -30,7 +30,8 @@
#define KEY_LOAD_TRIES5
#define HDCP2_LC_RETRY_CNT3
-static int intel_conn_to_vcpi(struct intel_connector *connector)
+static int intel_conn_to_vcpi(struct drm_atomic_state *state,
+ struct intel_connector *connector)
{
struct drm_dp_mst_topology_mgr *mgr;
struct drm_dp_mst_atomic_payload *payload;
@@ -42,7 +43,7 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
return 0;
mgr = connector->port->mgr;
- drm_modeset_lock(>base.lock, NULL);
+ drm_modeset_lock(>base.lock, state->acquire_ctx);
mst_state = to_drm_dp_mst_topology_state(mgr->base.state);
payload = drm_atomic_get_mst_payload_state(mst_state, connector->port);
if (drm_WARN_ON(mgr->dev, !payload))
@@ -54,7 +55,6 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
goto out;
}
out:
- drm_modeset_unlock(>base.lock);
return vcpi;
}
@@ -69,7 +69,8 @@ static int intel_conn_to_vcpi(struct intel_connector *connector)
* policy to mark different content_types for different streams.
*/
static int
-intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
+intel_hdcp_required_content_stream(struct intel_digital_port *dig_port,
+ struct intel_atomic_state *state)
{
struct drm_connector_list_iter conn_iter;
struct intel_digital_port *conn_dig_port;
@@ -81,9 +82,6 @@ intel_hdcp_required_content_stream(struct intel_digital_port
*dig_port)
data->k = 0;
- if (dig_port->hdcp_auth_status)
- return 0;
-
drm_connector_list_iter_begin(>drm, _iter);
for_each_intel_connector_iter(connector, _iter) {
if (connector->base.status == connector_status_disconnected)
@@ -99,7 +97,8 @@ intel_hdcp_required_content_stream(struct intel_digital_port
*dig_port)
if (!enforce_type0 && !dig_port->hdcp_mst_type1_capable)
enforce_type0 = true;
- data->streams[data->k].stream_id = intel_conn_to_vcpi(connector);
+ data->streams[data->k].stream_id =
+ intel_conn_to_vcpi(>base, connector);
data->k++;
/* if there is only one active stream */
@@ -127,15 +126,12 @@ static int intel_hdcp_prepare_streams(struct
intel_connector *connector)
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct intel_hdcp *hdcp = >hdcp;
- int ret;
if (!intel_encoder_is_mst(intel_attached_encoder(connector))) {
data->k = 1;
data->streams[0].stream_type = hdcp->content_type;
} else {
- ret = intel_hdcp_required_content_stream(dig_port);
- if (ret)
- return ret;
+ return dig_port->hdcp_mst_streams_ready;
}
return 0;
@@ -2373,6 +2369,12 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
if (intel_hdcp2_capable(connector)) {
+ if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+ dig_port->hdcp_mst_streams_ready =
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: implement internal workqueues
== Series Details ==
Series: drm/i915: implement internal workqueues
URL : https://patchwork.freedesktop.org/series/117618/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13132 -> Patchwork_117618v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/index.html
Participating hosts (41 -> 40)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117618v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#4983] / [i915#7461] /
[i915#7953] / [i915#8347] / [i915#8384])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/bat-rpls-1/igt@i915_selftest@l...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][3] ([i915#6367])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][4] ([i915#6687])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
Possible fixes
* igt@i915_module_load@reload:
- fi-kbl-soraka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/fi-kbl-soraka/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: [INCOMPLETE][7] ([i915#7156] / [i915#7913]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][9] ([i915#4983] / [i915#7461] / [i915#7913] /
[i915#8347]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/bat-rpls-2/igt@i915_selftest@l...@reset.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- {bat-mtlp-6}: [DMESG-WARN][11] ([i915#6367] / [i915#7953]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1:
- bat-dg2-8: [FAIL][13] ([i915#7932]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13132/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
[i915#7461]: https://gitlab.freedesktop.org/drm/intel/issues/7461
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7953]: https://gitlab.freedesktop.org/drm/intel/issues/7953
[i915#8347]: https://gitlab.freedesktop.org/drm/intel/issues/8347
[i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384
Build changes
-
* Linux: CI_DRM_13132 -> Patchwork_117618v1
CI-20190529: 20190529
CI_DRM_13132: 4760cbc0f5aa85cd9a0ff94ecc58ea3f5e087ea7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7285: d1cbf2bad9c2664ab8bd3bd0946510a52800912f @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_117618v1: 4760cbc0f5aa85cd9a0ff94ecc58ea3f5e087ea7 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
d1f4b0a226dc drm/i915/selftests: add local workqueue for SW fence selftest
98688cdecd49 drm/i915/gt: create workqueue dedicated to wake references
52a7006c7e77 drm/i915: add a dedicated workqueue inside drm_i915_private
== Logs ==
For more details see:
Re: [Intel-gfx] [PATCH 1/2] drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, May 11, 2023 1:27 PM
> To: Kandpal, Suraj ; intel-
> g...@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Kandpal, Suraj
>
> Subject: Re: [PATCH 1/2] drm/i915/hdcp: add intel_atomic_state argument to
> hdcp_enable function
>
> On Thu, 11 May 2023, Suraj Kandpal wrote:
> > Pass all the parameter in intel_encoder->enable() to intel_hdcp_enable
> > as we need intel_atomic_state later down to get acquire_ctx.
>
> You're passing connector, not encoder, though.
>
Ohh missed that will fix in the newer revision
Regards,
Suraj Kandpal
> BR,
> Jani.
>
> >
> > Cc: Jani Nikula
> > Cc: Ankit Nautiyal
> > Signed-off-by: Suraj Kandpal
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c| 5 +++--
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++--
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 12 +++-
> > drivers/gpu/drm/i915/display/intel_hdcp.h | 6 --
> > 4 files changed, 16 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 29e4bfab4635..e838d56415cd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3264,9 +3264,10 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> > /* Enable hdcp if it's desired */
> > if (conn_state->content_protection ==
> > DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state-
> >connector),
> > + intel_hdcp_enable(state, to_intel_connector(conn_state-
> >connector),
> > crtc_state,
> > - (u8)conn_state->hdcp_content_type);
> > + conn_state);
> > +
> > }
> >
> > static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 2c49d9ab86a2..e1e040434a97 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -800,9 +800,9 @@ static void intel_mst_enable_dp(struct
> intel_atomic_state *state,
> > /* Enable hdcp if it's desired */
> > if (conn_state->content_protection ==
> > DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state-
> >connector),
> > + intel_hdcp_enable(state, to_intel_connector(conn_state-
> >connector),
> > pipe_config,
> > - (u8)conn_state->hdcp_content_type);
> > + conn_state);
> > }
> >
> > static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder
> > *encoder, diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 650232c4892b..1928c80cb6a2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2330,8 +2330,10 @@ int intel_hdcp_init(struct intel_connector
> *connector,
> > return 0;
> > }
> >
> > -int intel_hdcp_enable(struct intel_connector *connector,
> > - const struct intel_crtc_state *pipe_config, u8
> content_type)
> > +int intel_hdcp_enable(struct intel_atomic_state *state,
> > + struct intel_connector *connector,
> > + const struct intel_crtc_state *pipe_config,
> > + const struct drm_connector_state *conn_state)
> > {
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > @@ -2352,7 +2354,7 @@ int intel_hdcp_enable(struct intel_connector
> *connector,
> > mutex_lock(_port->hdcp_mutex);
> > drm_WARN_ON(_priv->drm,
> > hdcp->value ==
> DRM_MODE_CONTENT_PROTECTION_ENABLED);
> > - hdcp->content_type = content_type;
> > + hdcp->content_type = (u8)conn_state->content_type;
> >
> > if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
> > hdcp->cpu_transcoder = pipe_config-
> >mst_master_transcoder;
> > @@ -2483,9 +2485,9 @@ void intel_hdcp_update_pipe(struct
> intel_atomic_state *state,
> > }
> >
> > if (desired_and_not_enabled || content_protection_type_changed)
> > - intel_hdcp_enable(connector,
> > + intel_hdcp_enable(state, connector,
> > crtc_state,
> > - (u8)conn_state->hdcp_content_type);
> > + conn_state);
> > }
> >
> > void intel_hdcp_component_fini(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp.h
> > index 8f53b0c7fe5c..6aaec4df6f6c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> > +++
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: drop display/ prefix from include
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, May 11, 2023 2:26 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Teres Alexis, Alan Previn
> ; Kandpal, Suraj
> ; Shankar, Uma
> Subject: [PATCH] drm/i915/hdcp: drop display/ prefix from include
>
> The display prefix is unnecessary within the display sub-directory.
>
LGTM.
Reviewed-by: Suraj Kandpal
> Cc: Alan Previn
> Cc: Suraj Kandpal
> Cc: Uma Shankar
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> index 7e52aea6aa17..4056bb2323ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> @@ -5,11 +5,11 @@
>
> #include
>
> -#include "display/intel_hdcp_gsc.h"
> #include "gem/i915_gem_region.h"
> #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
> #include "i915_drv.h"
> #include "i915_utils.h"
> +#include "intel_hdcp_gsc.h"
>
> bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915) {
> --
> 2.39.2
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: implement internal workqueues
== Series Details == Series: drm/i915: implement internal workqueues URL : https://patchwork.freedesktop.org/series/117618/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: implement internal workqueues
== Series Details == Series: drm/i915: implement internal workqueues URL : https://patchwork.freedesktop.org/series/117618/ State : warning == Summary == Error: dim checkpatch failed 501007ed8e45 drm/i915: add a dedicated workqueue inside drm_i915_private -:622: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!dev_priv->i915_wq" #622: FILE: drivers/gpu/drm/i915/i915_driver.c:136: + if (dev_priv->i915_wq == NULL) total: 0 errors, 0 warnings, 1 checks, 501 lines checked c4a59f545f7a drm/i915/gt: create workqueue dedicated to wake references -:156: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!wf->wq" #156: FILE: drivers/gpu/drm/i915/intel_wakeref.c:109: + if (wf->wq == NULL) total: 0 errors, 0 warnings, 1 checks, 160 lines checked 0e6e672b91b6 drm/i915/selftests: add local workqueue for SW fence selftest -:30: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!wq" #30: FILE: drivers/gpu/drm/i915/selftests/i915_sw_fence.c:530: + if (wq == NULL) total: 0 errors, 0 warnings, 1 checks, 38 lines checked
