Re: [Intel-gfx] [PATCH 3/3] drm/i915/hdcp: Add more conditions to enable hdcp

2023-10-26 Thread Nautiyal, Ankit K



On 10/26/2023 5:41 PM, Suraj Kandpal wrote:

When we dock a monitor we end up with a enable and disable connector
cycle but if hdcp content is running we get the userspace in


I was wondering if there should have been a uevent sent when driver 
changes the state from enabled to undesired,


but as per documentation we send the uevent only from enabled->desired 
or desired->enabled.


Anyway, this change looks good to me.


enabled state and driver maintaining a undesired state which causes
the content to stop playing and we only enabe hdcp if the userspace


Nitpick : enable


state in desired. This patch fixes that.

--v2
-Move code to intel_hdcp [Jani]

Signed-off-by: Suraj Kandpal 



Reviewed-by: Ankit Nautiyal 


---
  drivers/gpu/drm/i915/display/intel_hdcp.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 44c0a93f3af8..39b3f7c0c77c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2409,9 +2409,19 @@ void intel_hdcp_enable(struct intel_atomic_state *state,
   const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state)
  {
-   /* Enable hdcp if it's desired */
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
+   struct intel_hdcp *hdcp = >hdcp;
+
+   /*
+* Enable hdcp if it's desired or if userspace is enabled and
+* driver set its state to undesired
+*/
if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+   (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_ENABLED && hdcp->value ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
_intel_hdcp_enable(state, encoder, crtc_state, conn_state);
  }
  


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/lnl: Assign correct phys (rev3)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/lnl: Assign correct phys (rev3)
URL   : https://patchwork.freedesktop.org/series/125322/
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.BAT: failure for Apply Wa_16018031267 / Wa_16018063123

2023-10-26 Thread Patchwork
== Series Details ==

Series: Apply Wa_16018031267 / Wa_16018063123
URL   : https://patchwork.freedesktop.org/series/125650/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13799 -> Patchwork_125650v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125650v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125650v1, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125650v1/index.html

Participating hosts (36 -> 36)
--

  Additional (3): bat-dg2-8 bat-dg2-9 fi-bsw-n3050 
  Missing(3): bat-adlp-11 fi-snb-2520m bat-dg1-5 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_125650v1:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- fi-ivb-3770:[PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html

  
Known issues


  Here are the changes found in Patchwork_125650v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@lmem0:
- bat-atsm-1: NOTRUN -> [DMESG-WARN][3] ([i915#8841]) +4 other 
tests dmesg-warn
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-atsm-1/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050:   NOTRUN -> [SKIP][4] ([fdo#109271]) +18 other tests 
skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_mmap@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][5] ([i915#4083])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-9/igt@gem_m...@basic.html
- bat-dg2-8:  NOTRUN -> [SKIP][6] ([i915#4083])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][7] ([i915#4077]) +2 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-9/igt@gem_mmap_...@basic.html
- bat-dg2-8:  NOTRUN -> [SKIP][8] ([i915#4077]) +2 other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-8/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][9] ([i915#4079]) +1 other test skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-9/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg2-8:  NOTRUN -> [SKIP][10] ([i915#4079]) +1 other test skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-8/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-9:  NOTRUN -> [SKIP][11] ([i915#6621])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-9/igt@i915_pm_...@basic-api.html
- bat-dg2-8:  NOTRUN -> [SKIP][12] ([i915#6621])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-8/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][13] -> [DMESG-FAIL][14] ([i915#5334])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-atsm-1: NOTRUN -> [SKIP][15] ([i915#6645])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html
- bat-dg2-8:  NOTRUN -> [SKIP][16] ([i915#6645])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][17] ([i915#5190])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-9/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
- bat-dg2-8:  NOTRUN -> [SKIP][18] ([i915#5190])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125650v1/bat-dg2-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][19] ([i915#4215] / 

Re: [Intel-gfx] [PATCH] drm/i915/gem: Allow users to disable waitboost

2023-10-26 Thread kernel test robot



Hello,

kernel test robot noticed "assertion_failure" on:

commit: 54fef7ea35dadd66193b98805b0bc42ef2b279db ("[PATCH] drm/i915/gem: Allow 
users to disable waitboost")
url: 
https://github.com/intel-lab-lkp/linux/commits/Vinay-Belgaumkar/drm-i915-gem-Allow-users-to-disable-waitboost/20230921-060357
base: git://anongit.freedesktop.org/drm-intel for-linux-next
patch link: 
https://lore.kernel.org/all/20230920215624.3482244-1-vinay.belgaum...@intel.com/
patch subject: [PATCH] drm/i915/gem: Allow users to disable waitboost

in testcase: igt
version: igt-x86_64-0f075441-1_20230520
with following parameters:

group: group-23



compiler: gcc-12
test machine: 20 threads 1 sockets (Commet Lake) with 16G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-lkp/202310271326.abb748d0-oliver.s...@intel.com



user  :notice: [   42.847071] Starting subtest: engines-cleanup

user  :notice: [   42.854776] Starting dynamic subtest: rcs0

user  :notice: [   42.863938] (gem_ctx_persistence:833) CRITICAL: Test 
assertion failure function test_nonpersistent_cleanup, file 
../tests/i915/gem_ctx_persistence.c:283:

user  :notice: [   42.882029] (gem_ctx_persistence:833) CRITICAL: Failed 
assertion: gem_wait(i915, spin->handle, ) == 0

user  :notice: [   42.895541] (gem_ctx_persistence:833) CRITICAL: error: -22 != 0



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20231027/202310271326.abb748d0-oliver.s...@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki



[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Apply Wa_16018031267 / Wa_16018063123

2023-10-26 Thread Patchwork
== Series Details ==

Series: Apply Wa_16018031267 / Wa_16018063123
URL   : https://patchwork.freedesktop.org/series/125650/
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 Apply Wa_16018031267 / Wa_16018063123

2023-10-26 Thread Patchwork
== Series Details ==

Series: Apply Wa_16018031267 / Wa_16018063123
URL   : https://patchwork.freedesktop.org/series/125650/
State : warning

== Summary ==

Error: dim checkpatch failed
c7c9a792cec0 drm/i915: Reserve some kernel space per vm
02f4f3cc637c drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
-:39: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine' - possible 
side-effects?
#39: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:85:
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+   IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+   engine->class == COPY_ENGINE_CLASS && engine->instance == 0)

-:39: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'engine' may be better as 
'(engine)' to avoid precedence issues
#39: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:85:
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+   IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+   engine->class == COPY_ENGINE_CLASS && engine->instance == 0)

-:59: 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
#59: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:836:
+   GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);

-:174: 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
#174: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1498:
+   GEM_BUG_ON(cs - start > I915_GTT_PAGE_SIZE / sizeof(*cs));

total: 0 errors, 2 warnings, 2 checks, 168 lines checked
64efa77effe0 drm/i915/gt: add selftest to exercise WABB
45764d23564b drm/i915: Set copy engine arbitration for Wa_16018031267 / 
Wa_16018063123




[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Remove assignment from if condition

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Remove assignment from if condition
URL   : https://patchwork.freedesktop.org/series/125637/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13799 -> Patchwork_125637v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125637v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125637v1, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125637v1/index.html

Participating hosts (36 -> 38)
--

  Additional (4): fi-kbl-soraka bat-dg2-9 fi-bsw-n3050 fi-pnv-d510 
  Missing(2): fi-snb-2520m bat-dg1-5 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_125637v1:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-bsw-nick:[PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/fi-bsw-nick/igt@i915_selftest@live@gt_heartbeat.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/fi-bsw-nick/igt@i915_selftest@live@gt_heartbeat.html

  
Known issues


  Here are the changes found in Patchwork_125637v1 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- bat-adlp-11:[PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/bat-adlp-11/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-adlp-11/boot.html

  
 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][5] ([i915#8293]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/fi-hsw-4770/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg2-9:  NOTRUN -> [INCOMPLETE][7] ([i915#9275])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3@lmem0:
- bat-atsm-1: NOTRUN -> [DMESG-WARN][8] ([i915#8841]) +4 other 
tests dmesg-warn
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-atsm-1/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050:   NOTRUN -> [SKIP][11] ([fdo#109271]) +18 other tests 
skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_mmap@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][12] ([i915#4083])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-dg2-9/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][13] ([i915#4077]) +2 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-dg2-9/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][14] ([i915#4079]) +1 other test skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-dg2-9/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-9:  NOTRUN -> [SKIP][15] ([i915#6621])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-dg2-9/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][16] ([i915#1886])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-atsm-1: NOTRUN -> [SKIP][17] ([i915#6645])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][18] ([i915#5190])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125637v1/bat-dg2-9/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
- fi-hsw-4770:NOTRUN -> [SKIP][19] ([fdo#109271] / 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init (rev4)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init (rev4)
URL   : https://patchwork.freedesktop.org/series/125576/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13799 -> Patchwork_125576v4


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/index.html

Participating hosts (36 -> 34)
--

  Additional (1): bat-dg2-9 
  Missing(3): bat-mtlp-8 fi-snb-2520m bat-dg1-5 

Known issues


  Here are the changes found in Patchwork_125576v4 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@lmem0:
- bat-atsm-1: NOTRUN -> [DMESG-WARN][1] ([i915#8841]) +4 other 
tests dmesg-warn
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-atsm-1/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@gem_mmap@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][3] ([i915#4077]) +2 other tests skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][4] ([i915#4079]) +1 other test skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-9:  NOTRUN -> [SKIP][5] ([i915#6621])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#6645])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][7] ([i915#5190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][8] ([i915#4215] / [i915#5190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- bat-dg2-9:  NOTRUN -> [SKIP][9] ([i915#4212]) +6 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg2-9:  NOTRUN -> [SKIP][10] ([i915#4212] / [i915#5608])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][11] ([i915#4103] / [i915#4213] / 
[i915#5608]) +1 other test skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg2-9:  NOTRUN -> [SKIP][12] ([fdo#109285])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-dg2-9:  NOTRUN -> [SKIP][13] ([i915#5274])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][14] -> [FAIL][15] ([IGT#3])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][16] ([i915#1836])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_psr@sprite_plane_onoff:
- bat-dg2-9:  NOTRUN -> [SKIP][17] ([i915#1072]) +3 other tests skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-dg2-9:  NOTRUN -> [SKIP][18] ([i915#3555] / [i915#4098])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v4/bat-dg2-9/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-flip:
- bat-dg2-9:  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: Additional conditions to enable hdcp (rev4)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: Additional conditions to enable hdcp (rev4)
URL   : https://patchwork.freedesktop.org/series/125550/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13799 -> Patchwork_125550v4


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/index.html

Participating hosts (36 -> 37)
--

  Additional (2): fi-bsw-n3050 fi-pnv-d510 
  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_125550v4 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/bat-jsl-1/boot.html

  
 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/fi-hsw-4770/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@lmem0:
- bat-atsm-1: NOTRUN -> [DMESG-WARN][5] ([i915#8841]) +4 other 
tests dmesg-warn
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/bat-atsm-1/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050:   NOTRUN -> [SKIP][6] ([fdo#109271]) +18 other tests 
skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#6645])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#5190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][9] -> [FAIL][10] ([IGT#3])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
- fi-bsw-n3050:   NOTRUN -> [FAIL][11] ([IGT#3])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-bsw-n3050/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271]) +12 other tests 
skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#1845] / [i915#9197]) +1 
other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-5:
- bat-adlp-11:[PASS][14] -> [DMESG-WARN][15] ([i915#4309])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13799/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-5.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-5.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][16] ([i915#1836])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1:
- fi-hsw-4770:NOTRUN -> [DMESG-WARN][17] ([i915#8841]) +6 other 
tests dmesg-warn
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-hsw-4770/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-vga-1.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][18] ([fdo#109271]) +29 other tests 
skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1072]) +3 
other tests skip
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v4/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][20] -> [PASS][21]
   [20]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/hdcp: Additional conditions to enable hdcp (rev4)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: Additional conditions to enable hdcp (rev4)
URL   : https://patchwork.freedesktop.org/series/125550/
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 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Include drm_drv.h in intel_display_params.c

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/display: Include drm_drv.h in intel_display_params.c
URL   : https://patchwork.freedesktop.org/series/125630/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13797 -> Patchwork_125630v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/index.html

Participating hosts (38 -> 38)
--

  Additional (1): fi-pnv-d510 
  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_125630v1 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/fi-bsw-n3050/boot.html
- bat-adlp-11:[PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-adlp-11/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-adlp-11/boot.html

  
 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][5] ([i915#8293]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/fi-hsw-4770/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/fi-hsw-4770/boot.html
- bat-jsl-1:  [FAIL][7] ([i915#8293]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-jsl-1/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-jsl-1:  NOTRUN -> [SKIP][9] ([i915#9318])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg2-9:  [PASS][10] -> [INCOMPLETE][11] ([i915#9275])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][12] ([i915#2190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- bat-jsl-1:  NOTRUN -> [SKIP][13] ([i915#4613]) +3 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#5190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-jsl-1:  NOTRUN -> [SKIP][15] ([i915#4103]) +1 other test skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-jsl-1:  NOTRUN -> [SKIP][16] ([i915#3555]) +1 other test skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-jsl-1/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-jsl-1:  NOTRUN -> [SKIP][17] ([fdo#109285])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-jsl-1/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271]) +12 other tests 
skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][19] -> [ABORT][20] ([i915#8668])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1:
- fi-hsw-4770:NOTRUN -> [DMESG-WARN][21] ([i915#8841]) +6 other 
tests dmesg-warn
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125630v1/fi-hsw-4770/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-vga-1.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][22] ([fdo#109271]) +29 other tests 
skip
   [22]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Remove unncessary {} from if-else

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Remove unncessary {} from if-else
URL   : https://patchwork.freedesktop.org/series/125629/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13797 -> Patchwork_125629v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/index.html

Participating hosts (38 -> 38)
--

  Additional (2): fi-kbl-soraka fi-pnv-d510 
  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_125629v1 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/fi-bsw-n3050/boot.html

  
 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-jsl-1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-jsl-1:  NOTRUN -> [SKIP][5] ([i915#9318])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- bat-jsl-1:  NOTRUN -> [SKIP][9] ([i915#4613]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][10] ([i915#1886])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][11] -> [DMESG-FAIL][12] ([i915#7699])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-jsl-1:  NOTRUN -> [SKIP][13] ([i915#4103]) +1 other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][14] ([fdo#109271]) +9 other tests 
skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/fi-kbl-soraka/igt@kms_...@dsc-basic.html
- bat-jsl-1:  NOTRUN -> [SKIP][15] ([i915#3555]) +1 other test skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-jsl-1/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-jsl-1:  NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-jsl-1/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][17] ([i915#3546]) +2 other tests skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][18] ([fdo#109271]) +29 other tests 
skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [DMESG-FAIL][19] ([i915#5334]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125629v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_busy@basic@modeset:
- bat-adlp-11:[DMESG-WARN][21] ([i915#4309]) -> [PASS][22]
   [21]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/pmu: add pmu_to_i915() helper (rev3)

2023-10-26 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/pmu: add pmu_to_i915() helper (rev3)
URL   : https://patchwork.freedesktop.org/series/125464/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13797 -> Patchwork_125464v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125464v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125464v3, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125464v3/index.html

Participating hosts (38 -> 37)
--

  Additional (2): fi-kbl-soraka fi-pnv-d510 
  Missing(3): bat-mtlp-8 fi-snb-2520m fi-bsw-n3050 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_125464v3:

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-skl-guc: [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/fi-skl-guc/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/fi-skl-guc/igt@i915_module_l...@load.html

  
Known issues


  Here are the changes found in Patchwork_125464v3 that come from known issues:

### CI changes ###

 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/fi-hsw-4770/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/fi-hsw-4770/boot.html
- bat-jsl-1:  [FAIL][5] ([i915#8293]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-jsl-1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-jsl-1:  NOTRUN -> [SKIP][7] ([i915#9318])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/bat-jsl-1/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- bat-jsl-1:  NOTRUN -> [SKIP][11] ([i915#4613]) +3 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][12] ([i915#1886])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][13] -> [DMESG-FAIL][14] ([i915#7699])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#5190])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-jsl-1:  NOTRUN -> [SKIP][16] ([i915#4103]) +1 other test skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][17] ([fdo#109271]) +9 other tests 
skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/fi-kbl-soraka/igt@kms_...@dsc-basic.html
- bat-jsl-1:  NOTRUN -> [SKIP][18] ([i915#3555]) +1 other test skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125464v3/bat-jsl-1/igt@kms_...@dsc-basic.html

  * igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[PASS][19] -> [DMESG-WARN][20] ([i915#6868])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13797/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
   [20]: 

[Intel-gfx] [PATCH] drm/i915: Skip pxp init if gt is wedged

2023-10-26 Thread Zhanjun Dong
gt wedged is fatal error, skip the pxp init on this situation.

Signed-off-by: Zhanjun Dong 
---
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index dc327cf40b5a..923f233c91e1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -212,6 +212,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!gt)
return -ENODEV;
 
+   if (intel_gt_is_wedged(gt))
+   return -ENODEV;
+
/*
 * At this point, we will either enable full featured PXP capabilities
 * including session and object management, or we will init the backend 
tee
-- 
2.34.1



[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: fix Makefile sort and indent

2023-10-26 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/2] drm/i915: fix Makefile sort and indent
URL   : https://patchwork.freedesktop.org/series/125626/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13795 -> Patchwork_125626v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/index.html

Participating hosts (37 -> 22)
--

  Additional (2): fi-tgl-1115g4 bat-mtlp-8 
  Missing(17): fi-kbl-7567u bat-adls-5 bat-dg1-5 fi-bsw-n3050 fi-skl-guc 
bat-dg2-13 fi-snb-2520m bat-adlp-6 fi-hsw-4770 fi-bsw-nick fi-elk-e7500 
fi-pnv-d510 bat-rplp-1 bat-rpls-1 fi-blb-e6850 bat-jsl-3 fi-skl-6600u 

Known issues


  Here are the changes found in Patchwork_125626v1 that come from known issues:

### CI changes ###

 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][1] ([i915#8293]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13795/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
- bat-jsl-1:  NOTRUN -> [SKIP][4] ([i915#9318])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html
- fi-tgl-1115g4:  NOTRUN -> [SKIP][5] ([i915#9318])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
- bat-jsl-1:  NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#4613]) +3 other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-mtlp-8: NOTRUN -> [SKIP][9] ([i915#4613]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html
- bat-jsl-1:  NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#4083])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-mtlp-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][12] ([i915#4077]) +3 other tests skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-mtlp-8/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#4079]) +1 other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#6621])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_mocs:
- bat-dg2-11: [PASS][15] -> [INCOMPLETE][16] ([i915#9253])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13795/bat-dg2-11/igt@i915_selftest@live@gt_mocs.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-dg2-11/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@hugepages:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][17] ([i915#8962])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-mtlp-8/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@workarounds:
- bat-dg2-11: [PASS][18] -> [DMESG-FAIL][19] ([i915#9500])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13795/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/bat-dg2-11/igt@i915_selftest@l...@workarounds.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4:  NOTRUN -> [INCOMPLETE][20] ([i915#7443])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125626v1/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html
- bat-mtlp-8: NOTRUN -> [SKIP][21] ([i915#6645])
   [21]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Apply notify_guc to all GTs (rev2)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: Apply notify_guc to all GTs (rev2)
URL   : https://patchwork.freedesktop.org/series/125560/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13792 -> Patchwork_125560v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125560v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125560v2, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125560v2/index.html

Participating hosts (39 -> 38)
--

  Additional (1): fi-kbl-soraka 
  Missing(2): bat-mtlp-8 fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_125560v2:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-6: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13792/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg2-9:  [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13792/bat-dg2-9/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/bat-dg2-9/igt@i915_selftest@l...@hangcheck.html

  
Known issues


  Here are the changes found in Patchwork_125560v2 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][5] -> [FAIL][6] ([i915#8293])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13792/bat-jsl-1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/bat-jsl-1/boot.html

  
 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][7] ([i915#8293]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13792/fi-hsw-4770/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_lrc:
- bat-dg2-11: [PASS][11] -> [INCOMPLETE][12] ([i915#9413])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13792/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][13] ([i915#1886])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#5190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_dsc@dsc-basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][15] ([fdo#109271]) +9 other tests 
skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/fi-kbl-soraka/igt@kms_...@dsc-basic.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][16] -> [FAIL][17] ([IGT#3])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13792/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271]) +12 other tests 
skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][19] ([i915#3546]) +2 other tests skip
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v2/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][20] -> [ABORT][21] 

[Intel-gfx] [PATCH v2 2/2] drm/i915/lnl: Fix check for TC phy

2023-10-26 Thread Lucas De Marchi
With MTL adding PICA between the port and the real phy, the path
add for DG2 stopped being followed and newer platforms are simply using
the older path for TC phys. LNL is no different than MTL in this aspect,
so just add it to the mess. In future the phy and port designation and
deciding if it's TC should better be cleaned up.

To make it just a bit better, also change intel_phy_is_snps() to show
this is DG2-only.

Signed-off-by: Lucas De Marchi 
Reviewed-by: Gustavo Sousa 
---
 drivers/gpu/drm/i915/display/intel_display.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 28d85e1e858e..1caf46e3e569 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1784,31 +1784,31 @@ bool intel_phy_is_combo(struct drm_i915_private 
*dev_priv, enum phy phy)
 
 bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
 {
+   /*
+* DG2's "TC1", although TC-capable output, doesn't share the same flow
+* as other platforms on the display engine side and rather rely on the
+* SNPS PHY, that is programmed separately
+*/
if (IS_DG2(dev_priv))
-   /* DG2's "TC1" output uses a SNPS PHY */
return false;
-   else if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER_FULL(dev_priv) == 
IP_VER(14, 0))
+
+   if (DISPLAY_VER(dev_priv) >= 13)
return phy >= PHY_F && phy <= PHY_I;
else if (IS_TIGERLAKE(dev_priv))
return phy >= PHY_D && phy <= PHY_I;
else if (IS_ICELAKE(dev_priv))
return phy >= PHY_C && phy <= PHY_F;
-   else
-   return false;
+
+   return false;
 }
 
 bool intel_phy_is_snps(struct drm_i915_private *dev_priv, enum phy phy)
 {
-   if (phy == PHY_NONE)
-   return false;
-   else if (IS_DG2(dev_priv))
-   /*
-* All four "combo" ports and the TC1 port (PHY E) use
-* Synopsis PHYs.
-*/
-   return phy <= PHY_E;
-
-   return false;
+   /*
+* For DG2, and for DG2 only, all four "combo" ports and the TC1 port
+* (PHY E) use Synopsis PHYs. See intel_phy_is_tc().
+*/
+   return IS_DG2(dev_priv) && phy > PHY_NONE && phy <= PHY_E;
 }
 
 enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
-- 
2.40.1



[Intel-gfx] [PATCH v2 0/2] drm/i915/lnl: Assign correct phys

2023-10-26 Thread Lucas De Marchi
For this series to work, we still need a separate patch on the xe side
so it defines the LNL platform macro to be used by display.

One thing missing for LNL during the previous patches was the
port <-> phy assignment. With the bspec now clarified, this is the
minimum changes needed for LNL.  As the commit messages say and after
looking at the history of the code, it seems we were thinking to go one
direction abstraction-wise with DG2, but reverted course with MTL. The
end result right now is a very confusing mix of port/phy/tc_port.
I was hoping to do a cleanup now, but we probably need some consensus on
the approach as it'd be an intrusive change.

Here are some thoughts after looking again at the current state of the
code:

1) What is the port -> phy conversion for? AFAIR this was because from
the display engine side we want, some registers have bit offsets based
on the port and others are based on the PHY. I think now we can

a) Remove enum tc_port and have only `enum port` and `enum phy`.
   Those should be sufficient for all platform needs afaics

b) Add phy to intel_encoder (or intel_digital_port). It's
   appalling number of places we convert from port to phy. That
   would just be initialized during init.

2) It looks we need to better abstract the phy handling. Right now it's
very confusing with dkl, c10/c20 (that leak the abstraction from
intel_cx0_phy.c to everywhere in the driver), snps and the older
combo/tc being a superset of them.  I'm still not sure what to do here.
One thing that we can probably do is to remove the dg2-special case and
let the "is tc" be about the **port being connected to a TC-capable phy**.
Bspec always refer to those as TC / USBC. Then dkl, c10, c20, snps
would all be in the same abstraction layer.


Lucas De Marchi (2):
  drm/i915/lnl: Extend C10/C20 phy
  Subject: [PATCH] drm/i915/lnl: Fix check for TC phy

 drivers/gpu/drm/i915/display/intel_cx0_phy.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c | 28 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 3 files changed, 16 insertions(+), 15 deletions(-)

-- 
2.40.1



[Intel-gfx] [PATCH v2 1/2] drm/i915/lnl: Extend C10/C20 phy

2023-10-26 Thread Lucas De Marchi
For Lunar Lake, DDI-A is connected to C10 PHY, while TC1-TC3 are connected
to C20 phy, like in Meteor Lake. Update the check in intel_is_c10phy()
accordingly.

This reverts the change in commit e388ae97e225 ("drm/i915/display:
Eliminate IS_METEORLAKE checks") that turned that into a display engine
version check. The phy <-> port connection is very SoC-specific and not
related to that version.

IS_LUNARLAKE() is defined to 0 in i915 as it's expected that the
(upcoming) xe driver is the one defining the platform, with i915 only
driving the display side.

Bspec: 70818
Reviewed-by: Gustavo Sousa 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index d414f6b7f993..e775f4721158 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -31,7 +31,7 @@
 
 bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
 {
-   if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
+   if ((IS_LUNARLAKE(i915) || IS_METEORLAKE(i915)) && phy < PHY_C)
return true;
 
return false;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6a2a78c61f21..259884b10d9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -575,6 +575,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_DG2(i915)   IS_PLATFORM(i915, INTEL_DG2)
 #define IS_PONTEVECCHIO(i915) IS_PLATFORM(i915, INTEL_PONTEVECCHIO)
 #define IS_METEORLAKE(i915) IS_PLATFORM(i915, INTEL_METEORLAKE)
+#define IS_LUNARLAKE(i915) 0
 
 #define IS_DG2_G10(i915) \
IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G10)
-- 
2.40.1



[Intel-gfx] [PATCH v6 4/4] drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123

2023-10-26 Thread Andrzej Hajda
From: Jonathan Cavitt 

Set copy engine arbitration into round robin mode
for part of Wa_16018031267 / Wa_16018063123 mitigation.

Signed-off-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andrzej Hajda 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +++
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index b8618ee3e3041a..c0c8c12edea104 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -124,6 +124,9 @@
 #define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4) 
/* gen8+ */
 #define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ 
*/
 #define ECOSKPD(base)  _MMIO((base) + 0x1d0)
+#define   XEHP_BLITTER_SCHEDULING_MODE_MASKREG_GENMASK(12, 11)
+#define   XEHP_BLITTER_ROUND_ROBIN_MODE\
+   REG_FIELD_PREP(XEHP_BLITTER_SCHEDULING_MODE_MASK, 1)
 #define   ECO_CONSTANT_BUFFER_SR_DISABLE   REG_BIT(4)
 #define   ECO_GATING_CX_ONLY   REG_BIT(3)
 #define   GEN6_BLITTER_FBC_NOTIFY  REG_BIT(3)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 192ac0e59afa13..108d9326735910 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2782,6 +2782,11 @@ xcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
 RING_SEMA_WAIT_POLL(engine->mmio_base),
 1);
}
+   /* Wa_16018031267, Wa_16018063123 */
+   if (NEEDS_FASTCOLOR_BLT_WABB(engine))
+   wa_masked_field_set(wal, ECOSKPD(engine->mmio_base),
+   XEHP_BLITTER_SCHEDULING_MODE_MASK,
+   XEHP_BLITTER_ROUND_ROBIN_MODE);
 }
 
 static void

-- 
2.34.1



[Intel-gfx] [PATCH v6 3/4] drm/i915/gt: add selftest to exercise WABB

2023-10-26 Thread Andrzej Hajda
Test re-uses logic form indirect ctx BB selftest.

Signed-off-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andrzej Hajda 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/selftest_lrc.c | 65 --
 1 file changed, 47 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 823d38aa393467..e17b8777d21dc9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1555,7 +1555,7 @@ static int live_lrc_isolation(void *arg)
return err;
 }
 
-static int indirect_ctx_submit_req(struct intel_context *ce)
+static int wabb_ctx_submit_req(struct intel_context *ce)
 {
struct i915_request *rq;
int err = 0;
@@ -1579,7 +1579,8 @@ static int indirect_ctx_submit_req(struct intel_context 
*ce)
 #define CTX_BB_CANARY_INDEX  (CTX_BB_CANARY_OFFSET / sizeof(u32))
 
 static u32 *
-emit_indirect_ctx_bb_canary(const struct intel_context *ce, u32 *cs)
+emit_wabb_ctx_canary(const struct intel_context *ce,
+u32 *cs, bool per_ctx)
 {
*cs++ = MI_STORE_REGISTER_MEM_GEN8 |
MI_SRM_LRM_GLOBAL_GTT |
@@ -1587,26 +1588,43 @@ emit_indirect_ctx_bb_canary(const struct intel_context 
*ce, u32 *cs)
*cs++ = i915_mmio_reg_offset(RING_START(0));
*cs++ = i915_ggtt_offset(ce->state) +
context_wa_bb_offset(ce) +
-   CTX_BB_CANARY_OFFSET;
+   CTX_BB_CANARY_OFFSET +
+   (per_ctx ? PAGE_SIZE : 0);
*cs++ = 0;
 
return cs;
 }
 
+static u32 *
+emit_indirect_ctx_bb_canary(const struct intel_context *ce, u32 *cs)
+{
+   return emit_wabb_ctx_canary(ce, cs, false);
+}
+
+static u32 *
+emit_per_ctx_bb_canary(const struct intel_context *ce, u32 *cs)
+{
+   return emit_wabb_ctx_canary(ce, cs, true);
+}
+
 static void
-indirect_ctx_bb_setup(struct intel_context *ce)
+wabb_ctx_setup(struct intel_context *ce, bool per_ctx)
 {
-   u32 *cs = context_wabb(ce, false);
+   u32 *cs = context_wabb(ce, per_ctx);
 
cs[CTX_BB_CANARY_INDEX] = 0xdeadf00d;
 
-   setup_indirect_ctx_bb(ce, ce->engine, emit_indirect_ctx_bb_canary);
+   if (per_ctx)
+   setup_per_ctx_bb(ce, ce->engine, emit_per_ctx_bb_canary);
+   else
+   setup_indirect_ctx_bb(ce, ce->engine, 
emit_indirect_ctx_bb_canary);
 }
 
-static bool check_ring_start(struct intel_context *ce)
+static bool check_ring_start(struct intel_context *ce, bool per_ctx)
 {
const u32 * const ctx_bb = (void *)(ce->lrc_reg_state) -
-   LRC_STATE_OFFSET + context_wa_bb_offset(ce);
+   LRC_STATE_OFFSET + context_wa_bb_offset(ce) +
+   (per_ctx ? PAGE_SIZE : 0);
 
if (ctx_bb[CTX_BB_CANARY_INDEX] == ce->lrc_reg_state[CTX_RING_START])
return true;
@@ -1618,21 +1636,21 @@ static bool check_ring_start(struct intel_context *ce)
return false;
 }
 
-static int indirect_ctx_bb_check(struct intel_context *ce)
+static int wabb_ctx_check(struct intel_context *ce, bool per_ctx)
 {
int err;
 
-   err = indirect_ctx_submit_req(ce);
+   err = wabb_ctx_submit_req(ce);
if (err)
return err;
 
-   if (!check_ring_start(ce))
+   if (!check_ring_start(ce, per_ctx))
return -EINVAL;
 
return 0;
 }
 
-static int __live_lrc_indirect_ctx_bb(struct intel_engine_cs *engine)
+static int __lrc_wabb_ctx(struct intel_engine_cs *engine, bool per_ctx)
 {
struct intel_context *a, *b;
int err;
@@ -1667,14 +1685,14 @@ static int __live_lrc_indirect_ctx_bb(struct 
intel_engine_cs *engine)
 * As ring start is restored apriori of starting the indirect ctx bb and
 * as it will be different for each context, it fits to this purpose.
 */
-   indirect_ctx_bb_setup(a);
-   indirect_ctx_bb_setup(b);
+   wabb_ctx_setup(a, per_ctx);
+   wabb_ctx_setup(b, per_ctx);
 
-   err = indirect_ctx_bb_check(a);
+   err = wabb_ctx_check(a, per_ctx);
if (err)
goto unpin_b;
 
-   err = indirect_ctx_bb_check(b);
+   err = wabb_ctx_check(b, per_ctx);
 
 unpin_b:
intel_context_unpin(b);
@@ -1688,7 +1706,7 @@ static int __live_lrc_indirect_ctx_bb(struct 
intel_engine_cs *engine)
return err;
 }
 
-static int live_lrc_indirect_ctx_bb(void *arg)
+static int lrc_wabb_ctx(void *arg, bool per_ctx)
 {
struct intel_gt *gt = arg;
struct intel_engine_cs *engine;
@@ -1697,7 +1715,7 @@ static int live_lrc_indirect_ctx_bb(void *arg)
 
for_each_engine(engine, gt, id) {
intel_engine_pm_get(engine);
-   err = __live_lrc_indirect_ctx_bb(engine);
+   err = __lrc_wabb_ctx(engine, per_ctx);
intel_engine_pm_put(engine);
 
if (igt_flush_test(gt->i915))
@@ -1710,6 +1728,16 @@ static int 

[Intel-gfx] [PATCH v6 2/4] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123

2023-10-26 Thread Andrzej Hajda
Apply WABB blit for Wa_16018031267 / Wa_16018063123.

v3: drop unused enum definition
v4: move selftest to separate patch, use wa only on BCS0.
v5: fixed selftest caller to context_wabb

Signed-off-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andrzej Hajda 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_engine_regs.h |   3 +
 drivers/gpu/drm/i915/gt/intel_gt.h  |   4 ++
 drivers/gpu/drm/i915/gt/intel_lrc.c | 100 +++-
 drivers/gpu/drm/i915/gt/selftest_lrc.c  |   2 +-
 4 files changed, 105 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index fdd4ddd3a978a2..b8618ee3e3041a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -118,6 +118,9 @@
 #define   CCID_EXTENDED_STATE_RESTORE  BIT(2)
 #define   CCID_EXTENDED_STATE_SAVE BIT(3)
 #define RING_BB_PER_CTX_PTR(base)  _MMIO((base) + 0x1c0) /* gen8+ 
*/
+#define   PER_CTX_BB_FORCE BIT(2)
+#define   PER_CTX_BB_VALID BIT(0)
+
 #define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4) 
/* gen8+ */
 #define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ 
*/
 #define ECOSKPD(base)  _MMIO((base) + 0x1d0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 970bedf6b78a7b..9ffdb05e231e21 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -82,6 +82,10 @@ struct drm_printer;
  ##__VA_ARGS__);   \
 } while (0)
 
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+   IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+   engine->class == COPY_ENGINE_CLASS && engine->instance == 0)
+
 static inline bool gt_is_root(struct intel_gt *gt)
 {
return !gt->info.id;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index eaf66d90316655..7c367ba8d9dcf1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct 
intel_engine_cs *engine)
return 0;
 }
 
+static void
+lrc_setup_bb_per_ctx(u32 *regs,
+const struct intel_engine_cs *engine,
+u32 ctx_bb_ggtt_addr)
+{
+   GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
+   regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
+   ctx_bb_ggtt_addr |
+   PER_CTX_BB_FORCE |
+   PER_CTX_BB_VALID;
+}
+
 static void
 lrc_setup_indirect_ctx(u32 *regs,
   const struct intel_engine_cs *engine,
@@ -1020,7 +1032,13 @@ static u32 context_wa_bb_offset(const struct 
intel_context *ce)
return PAGE_SIZE * ce->wa_bb_page;
 }
 
-static u32 *context_indirect_bb(const struct intel_context *ce)
+/*
+ * per_ctx below determines which WABB section is used.
+ * When true, the function returns the location of the
+ * PER_CTX_BB.  When false, the function returns the
+ * location of the INDIRECT_CTX.
+ */
+static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
 {
void *ptr;
 
@@ -1029,6 +1047,7 @@ static u32 *context_indirect_bb(const struct 
intel_context *ce)
ptr = ce->lrc_reg_state;
ptr -= LRC_STATE_OFFSET; /* back to start of context image */
ptr += context_wa_bb_offset(ce);
+   ptr += per_ctx ? PAGE_SIZE : 0;
 
return ptr;
 }
@@ -1105,7 +1124,8 @@ __lrc_alloc_state(struct intel_context *ce, struct 
intel_engine_cs *engine)
 
if (GRAPHICS_VER(engine->i915) >= 12) {
ce->wa_bb_page = context_size / PAGE_SIZE;
-   context_size += PAGE_SIZE;
+   /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
+   context_size += PAGE_SIZE * 2;
}
 
if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {
@@ -1407,12 +1427,85 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context 
*ce, u32 *cs)
return gen12_emit_aux_table_inv(ce->engine, cs);
 }
 
+static u32 *xehp_emit_fastcolor_blt_wabb(const struct intel_context *ce, u32 
*cs)
+{
+   struct intel_gt *gt = ce->engine->gt;
+   int mocs = gt->mocs.uc_index << 1;
+
+   /**
+* Wa_16018031267 / Wa_16018063123 requires that SW forces the
+* main copy engine arbitration into round robin mode.  We
+* additionally need to submit the following WABB blt command
+* to produce 4 subblits with each subblit generating 0 byte
+* write requests as WABB:
+*
+* XY_FASTCOLOR_BLT
+*  BG0-> 510E
+*  BG1-> 003F (Dest pitch)
+*  BG2->  (X1, Y1) = (0, 0)
+*  BG3-> 00040001 (X2, Y2) = (1, 4)
+*  BG4-> 

[Intel-gfx] [PATCH v6 1/4] drm/i915: Reserve some kernel space per vm

2023-10-26 Thread Andrzej Hajda
Reserve one page in each vm for kernel space to use for things
such as workarounds.

v2: use real memory, do not decrease vm.total
v4: reserve only one page and explain flag
v5: remove allocated object on ppgtt cleanup
v6: decrease vm->total by reservation size

Suggested-by: Chris Wilson 
Signed-off-by: Andrzej Hajda 
Reviewed-by: Jonathan Cavitt 
Reviewed-by: Nirmoy Das 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 43 
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  4 
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 9895e18df0435a..fa46d2308b0ed3 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -5,6 +5,7 @@
 
 #include 
 
+#include "gem/i915_gem_internal.h"
 #include "gem/i915_gem_lmem.h"
 
 #include "gen8_ppgtt.h"
@@ -222,6 +223,9 @@ static void gen8_ppgtt_cleanup(struct i915_address_space 
*vm)
 {
struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
 
+   if (vm->rsvd.obj)
+   i915_gem_object_put(vm->rsvd.obj);
+
if (intel_vgpu_active(vm->i915))
gen8_ppgtt_notify_vgt(ppgtt, false);
 
@@ -950,6 +954,41 @@ gen8_alloc_top_pd(struct i915_address_space *vm)
return ERR_PTR(err);
 }
 
+static int gen8_init_rsvd(struct i915_address_space *vm)
+{
+   struct drm_i915_private *i915 = vm->i915;
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int ret;
+
+   /* The memory will be used only by GPU. */
+   obj = i915_gem_object_create_lmem(i915, PAGE_SIZE,
+ I915_BO_ALLOC_VOLATILE |
+ I915_BO_ALLOC_GPU_ONLY);
+   if (IS_ERR(obj))
+   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   vma = i915_vma_instance(obj, vm, NULL);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
+   goto unref;
+   }
+
+   ret = i915_vma_pin(vma, 0, 0, PIN_USER | PIN_HIGH);
+   if (ret)
+   goto unref;
+
+   vm->rsvd.vma = i915_vma_make_unshrinkable(vma);
+   vm->rsvd.obj = obj;
+   vm->total -= vma->node.size;
+   return 0;
+unref:
+   i915_gem_object_put(obj);
+   return ret;
+}
+
 /*
  * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP registers
  * with a net effect resembling a 2-level page table in normal x86 terms. Each
@@ -1031,6 +1070,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
if (intel_vgpu_active(gt->i915))
gen8_ppgtt_notify_vgt(ppgtt, true);
 
+   err = gen8_init_rsvd(>vm);
+   if (err)
+   goto err_put;
+
return ppgtt;
 
 err_put:
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index b471edac269920..028a5a988eea02 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -249,6 +249,10 @@ struct i915_address_space {
struct work_struct release_work;
 
struct drm_mm mm;
+   struct {
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   } rsvd;
struct intel_gt *gt;
struct drm_i915_private *i915;
struct device *dma;

-- 
2.34.1



[Intel-gfx] [PATCH v6 0/4] Apply Wa_16018031267 / Wa_16018063123

2023-10-26 Thread Andrzej Hajda
Hi all,

This the series from Jonathan:
[PATCH v12 0/4] Apply Wa_16018031267 / Wa_16018063123
taken over by me.

This patchset requires IGT changes fixing handling gtt sizes
not being power of 2:
https://patchwork.freedesktop.org/series/125640/

Changes in this version are described in the patches, in short:
v2:
- use real memory as WABB destination,
- address CI compains - do not decrease vm.total,
- minor reordering.
v3:
- fixed typos,
- removed spare defs,
- added tags
v4:
- removed NULL PTE patch,
- separate selftest to separate patch,
- use BB only on BCS0
v5:
- fixed reserved memory allocation
v6:
- decresase vm->total by reserved size

Regards
Andrzej

Andrzej Hajda (1):
  drm/i915: Reserve some kernel space per vm

Jonathan Cavitt (3):
  drm/i915: Enable NULL PTE support for vm scratch
  drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
  drm/i915: Set copy engine arbitration for Wa_16018031267 /
Wa_16018063123

.../drm/i915/gem/selftests/i915_gem_context.c |   6 ++
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  41 +++
 drivers/gpu/drm/i915/gt/intel_engine_regs.h   |   6 ++
 drivers/gpu/drm/i915/gt/intel_gt.h|   4 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   2 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 100 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |   5 +
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  65 
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_pci.c   |   2 +
 drivers/gpu/drm/i915/intel_device_info.h  |   1 +
 12 files changed, 215 insertions(+), 21 deletions(-)

Test-with: 20231026-gtt_size_fix-v1-2-882d0e002...@intel.com
---
- Link to v3: 
https://lore.kernel.org/r/20231023-wabb-v3-0-1a4fbc632...@intel.com
- Link to v4: 
https://lore.kernel.org/r/20231023-wabb-v4-0-f75dec962...@intel.com
- Link to v5: 
https://lore.kernel.org/r/20231025-wabb-v5-0-398e42309...@intel.com

---
Andrzej Hajda (3):
  drm/i915: Reserve some kernel space per vm
  drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
  drm/i915/gt: add selftest to exercise WABB

Jonathan Cavitt (1):
  drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123

 drivers/gpu/drm/i915/gt/gen8_ppgtt.c|  43 
 drivers/gpu/drm/i915/gt/intel_engine_regs.h |   6 ++
 drivers/gpu/drm/i915/gt/intel_gt.h  |   4 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h |   4 ++
 drivers/gpu/drm/i915/gt/intel_lrc.c | 100 +++-
 drivers/gpu/drm/i915/gt/intel_workarounds.c |   5 ++
 drivers/gpu/drm/i915/gt/selftest_lrc.c  |  65 +-
 7 files changed, 206 insertions(+), 21 deletions(-)
---
base-commit: 201c8a7bd1f3f415920a2df4b8a8817e973f42fe
change-id: 20231020-wabb-bbe9324a69a8

Best regards,
-- 
Andrzej Hajda 



Re: [Intel-gfx] [PATCH 2/2] drm/i915/lnl: Fix check for TC phy

2023-10-26 Thread Gustavo Sousa
Quoting Lucas De Marchi (2023-10-25 12:44:09-03:00)
>On Mon, Oct 23, 2023 at 12:28:46PM -0300, Gustavo Sousa wrote:
>>Quoting Lucas De Marchi (2023-10-20 13:04:48-03:00)
>>>On Thu, Oct 19, 2023 at 01:04:40PM -0300, Gustavo Sousa wrote:
Quoting Lucas De Marchi (2023-10-18 19:24:41-03:00)
>With MTL adding PICA between the port and the real phy, the path
>add for DG2 stopped being followed and newer platforms are simply using
>the older path for TC phys. LNL is no different than MTL in this aspect,
>so just add it to the mess. In future the phy and port designation and
>deciding if it's TC should better be cleaned up.
>
>To make it just a bit better, also change intel_phy_is_snps() to show
>this is DG2-only.
>
>Signed-off-by: Lucas De Marchi 
>---
> drivers/gpu/drm/i915/display/intel_display.c | 29 ++--
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>b/drivers/gpu/drm/i915/display/intel_display.c
>index 28d85e1e858e..0797ace31417 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -1784,31 +1784,32 @@ bool intel_phy_is_combo(struct drm_i915_private 
>*dev_priv, enum phy phy)
>
> bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> {
>+/* DG2's "TC1" output uses a SNPS PHY and is handled separately */
> if (IS_DG2(dev_priv))
>-/* DG2's "TC1" output uses a SNPS PHY */
> return false;
>-else if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER_FULL(dev_priv) 
>== IP_VER(14, 0))
>+
>+/*
>+ * TODO: This should mostly match intel_port_to_phy(), 
>considering the
>+ * ports already encode if they are connected to a TC phy in 
>their name.
>+ */
>+if (IS_LUNARLAKE(dev_priv) || IS_METEORLAKE(dev_priv) ||
>+IS_ALDERLAKE_P(dev_priv))

Just like already done with the previous patch, I think we should have a
paragraph in the commit message justifying s/DISPLAY_VER_FULL(dev_priv) ==
IP_VER(14, 0)/IS_METEORLAKE(dev_priv)/.
>>>
>>>humn... after giving this a second thought, I will take this back.
>>>intel_phy_is_tc() is different than the check in the first patch and
>>>it's actually something dependent on display engine. Here the check is
>>>about is this a DDIA/DDIB or a TC1-TC4? This will change how some
>>>registers in the display engine are programmed:
>>
>>Hm, yeah. I overlooked that... But we are looking into the PHY
>>regardless. Is the mapping "phy number -> port type" really associated
>>to the display engine rather than to the SoC?
>
>we are converting back and forth. The phy number always come from the
>port by using intel_port_to_phy(). See intel_ddi_init() for example:
>
>intel_ddi_init()
>{
>port = intel_bios_encoder_port(devdata);
>...
>phy = intel_port_to_phy(dev_priv, port);
>}
>
>intel_port_to_phy() does use the display engine version and a
>platform-based check in a few cases. Looking at the history, this was
>added for EHL, where the ports DDI-A and DDI-D are muxed to one PHY,
>called PHY-A.  Then some registers need to use that number to configure
>the registers.
>
>4+ years later I don't see the bspec doing any better job on the
>registers that are using the phy vs port and this is derived mostly on a
>case by case basis :(
>
>Looking at intel_port_to_phy() and ignoring EHL/JSL as outlier, all the
>others are basically answering the question "from the display pov, where
>does the native/combo port end and we start the ports connected to "TC
>ports". From those, then DG2 starts to be the outlier as it identifies
>itself as neither combo nor tc, but rather snps. XeLPD is very
>"creative" as we assigned a PORT_D_XELPD = PORT_TC5 to make it work
>with the register offsets from the display engine pov they replaced
>TC5/TC6. Then the phy_is_tc() also has to workaround that, as those are
>not TC phys :-/

Thanks for the history! :-)

>
>I think a better abstraction looking back would be to nuke this
>intel_port_to_* / intel_phy_to_* / intel_phy_is_tc. Then we only set
>that during ddi init.
>
>Note that this is all different than the is this a C10 or C20 phy
>question.  The display engine has no idea about that and doesn't care.
>Until a few days ago it was not even documented in bspec as this is a
>SoC characteristics.

Got it.

>
>To summarize: I think here we should keep the display engine version
>check, resorting to platform checks for the exceptions to match what
>intel_port_to_phy() does.  Long term we need to better abstract/document
>that, but that is for another day.
>
>Lucas De Marchi
>
>>
>>--
>>Gustavo Sousa
>>
>>>
>>>$ git grep intel_phy_is_tc -- 
>>> 

Re: [Intel-gfx] [PATCH] MAINTAINERS: drm/ci: add entries for xfail files

2023-10-26 Thread Maxime Ripard
On Tue, 19 Sep 2023 15:22:49 -0300, Helen Koike wrote:
> DRM CI keeps track of which tests are failing, flaking or being skipped
> by the ci in the expectations files. Add entries for those files to the
> corresponding driver maintainer, so they can be notified when they
> change.
> 
> 

Applied to drm/drm-misc (drm-misc-next).

Thanks!
Maxime



[Intel-gfx] [PULL] drm-intel-fixes

2023-10-26 Thread Rodrigo Vivi
Hi Dave and Daniel,

Here goes drm-intel-fixes-2023-10-26:

- Determine context valid in OA reports (Umesh)
- Hold GT forcewake during steering operations (Matt Roper)
- Check if PMU is closed before stopping event (Umesh)

Thanks,
Rodrigo.

The following changes since commit 05d3ef8bba77c1b5f98d941d8b2d4aeab8118ef1:

  Linux 6.6-rc7 (2023-10-22 12:11:21 -1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-10-26

for you to fetch changes up to 4cbed7702eb775cca22fff6827a549092cb59f61:

  drm/i915/pmu: Check if pmu is closed before stopping event (2023-10-25 
08:44:30 -0400)


- Determine context valid in OA reports (Umesh)
- Hold GT forcewake during steering operations (Matt Roper)
- Check if PMU is closed before stopping event (Umesh)


Matt Roper (1):
  drm/i915/mcr: Hold GT forcewake during steering operations

Umesh Nerlige Ramappa (2):
  drm/i915/perf: Determine context valid in OA reports
  drm/i915/pmu: Check if pmu is closed before stopping event

 drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24 ++--
 drivers/gpu/drm/i915/i915_perf.c   |  4 ++--
 drivers/gpu/drm/i915/i915_pmu.c|  9 +
 3 files changed, 33 insertions(+), 4 deletions(-)


Re: [Intel-gfx] [PATCH 1/7] drm: Do not round to megabytes for greater than 1MiB sizes in fdinfo stats

2023-10-26 Thread Tvrtko Ursulin



On 28/09/2023 13:47, Tvrtko Ursulin wrote:


On 27/09/2023 14:48, Steven Price wrote:

On 27/09/2023 14:38, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

It is better not to lose precision and not revert to 1 MiB size
granularity for every size greater than 1 MiB.

Sizes in KiB should not be so troublesome to read (and in fact machine
parsing is I expect the norm here), they align with other api like
/proc/meminfo, and they allow writing tests for the interface without
having to embed drm.ko implementation knowledge into them. (Like knowing
that minimum buffer size one can use for successful verification has 
to be

1MiB aligned, and on top account for any pre-existing memory utilisation
outside of driver's control.)

But probably even more importantly I think that it is just better to 
show
the accurate sizes and not arbitrary lose precision for a little bit 
of a

stretched use case of eyeballing fdinfo text directly.

Signed-off-by: Tvrtko Ursulin 
Cc: Rob Clark 
Cc: Adrián Larumbe 
Cc: steven.pr...@arm.com


Reviewed-by: Steven Price 


Thanks! Rob? Can we have your blessing? Could you live with KiBs? :)


Acked received on #dri-devel:

[12:15]  robclark: ping on 
https://lists.freedesktop.org/archives/dri-devel/2023-September/424905.html - can you 
live with it or object?
[14:41]  tursulin: a-b

Adding the drm-misc maintainers with an ask to merge please.

Regards,

Tvrtko



Regards,

Tvrtko


---
  drivers/gpu/drm/drm_file.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index e692770ef6d3..ecb5038009e7 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -913,7 +913,7 @@ static void print_size(struct drm_printer *p, 
const char *stat,

  unsigned u;
  for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
-    if (sz < SZ_1K)
+    if (sz == 0 || !IS_ALIGNED(sz, SZ_1K))
  break;
  sz = div_u64(sz, SZ_1K);
  }




Re: [Intel-gfx] [PATCH] drm/i915/gt: Remove assignment from if condition

2023-10-26 Thread Tvrtko Ursulin



On 26/10/2023 14:58, Gilbert Adikankwu wrote:

Initialize variable "entry" during declaration. Remove assignment from if
condition.

Fix checkpatch.pl error:
ERROR: do not use assignment in if condition

Signed-off-by: Gilbert Adikankwu 
---
  drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index e8f42ec6b1b4..cbc4ecf26d8b 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1751,7 +1751,7 @@ static bool gen8_csb_parse(const u64 csb)
  static noinline u64
  wa_csb_read(const struct intel_engine_cs *engine, u64 * const csb)
  {
-   u64 entry;
+   u64 entry = READ_ONCE(*csb);
  
  	/*

 * Reading from the HWSP has one particular advantage: we can detect
@@ -1763,7 +1763,7 @@ wa_csb_read(const struct intel_engine_cs *engine, u64 * 
const csb)
 * tgl,dg1:HSDES#22011327657
 */
preempt_disable();
-   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 10)) {
+   if (wait_for_atomic_us(entry != -1, 10)) {


Wait_for_atomic_us is a macro which needs to keep reading the csb until 
it changes so this will not work.


Regards,

Tvrtko


int idx = csb - engine->execlists.csb_status;
int status;
  


Re: [Intel-gfx] [PATCH v3] drm/i915/dsb: DSB code refactoring

2023-10-26 Thread Ville Syrjälä
On Sun, Oct 08, 2023 at 03:42:06PM +0530, Animesh Manna wrote:
> Refactor DSB implementation to be compatible with Xe driver.
> 
> v1: RFC version.
> v2: Make intel_dsb structure opaque from external usage. [Jani]
> v3: Rebased on latest.
> 
> Cc: Jani Nikula 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/Makefile |  1 +
>  drivers/gpu/drm/i915/display/intel_dsb.c  | 84 ---
>  .../gpu/drm/i915/display/intel_dsb_buffer.c   | 64 ++
>  .../gpu/drm/i915/display/intel_dsb_buffer.h   | 26 ++
>  4 files changed, 126 insertions(+), 49 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dsb_buffer.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dsb_buffer.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index dec78efa452a..7c3f91c2375a 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -260,6 +260,7 @@ i915-y += \
>   display/intel_dpt.o \
>   display/intel_drrs.o \
>   display/intel_dsb.o \
> + display/intel_dsb_buffer.o \
>   display/intel_fb.o \
>   display/intel_fb_pin.o \
>   display/intel_fbc.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 3e32aa49b8eb..ec89d968a873 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -13,12 +13,13 @@
>  #include "intel_de.h"
>  #include "intel_display_types.h"
>  #include "intel_dsb.h"
> +#include "intel_dsb_buffer.h"
>  #include "intel_dsb_regs.h"
>  #include "intel_vblank.h"
>  #include "intel_vrr.h"
>  #include "skl_watermark.h"
>  
> -struct i915_vma;
> +#define CACHELINE_BYTES 64
>  
>  enum dsb_id {
>   INVALID_DSB = -1,
> @@ -31,8 +32,7 @@ enum dsb_id {
>  struct intel_dsb {
>   enum dsb_id id;
>  
> - u32 *cmd_buf;
> - struct i915_vma *vma;
> + struct intel_dsb_buffer dsb_buf;
>   struct intel_crtc *crtc;
>  
>   /*
> @@ -108,15 +108,17 @@ static void intel_dsb_dump(struct intel_dsb *dsb)
>  {
>   struct intel_crtc *crtc = dsb->crtc;
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> - const u32 *buf = dsb->cmd_buf;
>   int i;
>  
>   drm_dbg_kms(>drm, "[CRTC:%d:%s] DSB %d commands {\n",
>   crtc->base.base.id, crtc->base.name, dsb->id);
>   for (i = 0; i < ALIGN(dsb->free_pos, 64 / 4); i += 4)
>   drm_dbg_kms(>drm,
> - " 0x%08x: 0x%08x 0x%08x 0x%08x 0x%08x\n",
> - i * 4, buf[i], buf[i+1], buf[i+2], buf[i+3]);
> + " 0x%08x: 0x%08x 0x%08x 0x%08x 0x%08x\n", i * 4,
> + intel_dsb_buffer_read(>dsb_buf, i),
> + intel_dsb_buffer_read(>dsb_buf, i + 1),
> + intel_dsb_buffer_read(>dsb_buf, i + 2),
> + intel_dsb_buffer_read(>dsb_buf, i + 3));
>   drm_dbg_kms(>drm, "}\n");
>  }
>  
> @@ -128,8 +130,6 @@ static bool is_dsb_busy(struct drm_i915_private *i915, 
> enum pipe pipe,
>  
>  static void intel_dsb_emit(struct intel_dsb *dsb, u32 ldw, u32 udw)
>  {
> - u32 *buf = dsb->cmd_buf;
> -
>   if (!assert_dsb_has_room(dsb))
>   return;
>  
> @@ -138,14 +138,13 @@ static void intel_dsb_emit(struct intel_dsb *dsb, u32 
> ldw, u32 udw)
>  
>   dsb->ins_start_offset = dsb->free_pos;
>  
> - buf[dsb->free_pos++] = ldw;
> - buf[dsb->free_pos++] = udw;
> + intel_dsb_buffer_write(>dsb_buf, dsb->free_pos++, ldw);
> + intel_dsb_buffer_write(>dsb_buf, dsb->free_pos++, udw);
>  }
>  
>  static bool intel_dsb_prev_ins_is_write(struct intel_dsb *dsb,
>   u32 opcode, i915_reg_t reg)
>  {
> - const u32 *buf = dsb->cmd_buf;
>   u32 prev_opcode, prev_reg;
>  
>   /*
> @@ -156,8 +155,10 @@ static bool intel_dsb_prev_ins_is_write(struct intel_dsb 
> *dsb,
>   if (dsb->free_pos == 0)
>   return false;
>  
> - prev_opcode = buf[dsb->ins_start_offset + 1] & ~DSB_REG_VALUE_MASK;
> - prev_reg = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
> + prev_opcode = intel_dsb_buffer_read(>dsb_buf,
> + dsb->ins_start_offset + 1) >> 
> DSB_OPCODE_SHIFT;
> + prev_reg =  intel_dsb_buffer_read(>dsb_buf,
> +   dsb->ins_start_offset + 1) & 
> DSB_REG_VALUE_MASK;
>  
>   return prev_opcode == opcode && prev_reg == i915_mmio_reg_offset(reg);
>  }
> @@ -190,6 +191,8 @@ static bool intel_dsb_prev_ins_is_indexed_write(struct 
> intel_dsb *dsb, i915_reg_
>  void intel_dsb_reg_write(struct intel_dsb *dsb,
>i915_reg_t reg, u32 val)
>  {
> + u32 old_val;
> +
>   /*
>* For example the buffer will look like below for 3 dwords for auto
>* increment register:
> @@ -213,31 +216,32 @@ void 

Re: [Intel-gfx] [PATCH v3] drm/i915/dsb: DSB code refactoring

2023-10-26 Thread Manna, Animesh


> -Original Message-
> From: Luca Coelho 
> Sent: Thursday, October 26, 2023 1:08 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/dsb: DSB code refactoring
> 
> On Sun, 2023-10-08 at 15:42 +0530, Animesh Manna wrote:
> > Refactor DSB implementation to be compatible with Xe driver.
> >
> > v1: RFC version.
> > v2: Make intel_dsb structure opaque from external usage. [Jani]
> > v3: Rebased on latest.
> >
> > Cc: Jani Nikula 
> > Signed-off-by: Animesh Manna 
> > ---
> 
> Looks great overall! Just a couple of small comments below.

Thanks for review.

> 
> 
> [...]
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > index 3e32aa49b8eb..ec89d968a873 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > @@ -13,12 +13,13 @@
> >  #include "intel_de.h"
> >  #include "intel_display_types.h"
> >  #include "intel_dsb.h"
> > +#include "intel_dsb_buffer.h"
> >  #include "intel_dsb_regs.h"
> >  #include "intel_vblank.h"
> >  #include "intel_vrr.h"
> >  #include "skl_watermark.h"
> >
> > -struct i915_vma;
> > +#define CACHELINE_BYTES 64
> 
> I see that this macro is defined in GT and you want to avoid depending on
> the definition from GT, but you don't make any other changes related to the
> cacheline size here, so maybe this change should be a separate patch? Also,
> it looks a bit magic without an explanation on where the number is coming
> from.

For Xe driver macro definition in GT may not accessible, so have redefined in 
Intel_dsb.c itself. It's related to dsb so kept in the same patch.
DSB command buffer is cacheline aligned. DSB support added from gen12 and size 
of cacheline size will be 64 bytes. As per bspec each cacheline can have 8 
dsb-instructions and 64 bits per instruction.

> 
> 
> [...]
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb_buffer.c
> > b/drivers/gpu/drm/i915/display/intel_dsb_buffer.c
> > new file mode 100644
> > index ..723937591831
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/display/intel_dsb_buffer.c
> > @@ -0,0 +1,64 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright 2023, Intel Corporation.
> > + */
> > +
> > +#include "gem/i915_gem_internal.h"
> > +#include "i915_drv.h"
> > +#include "i915_vma.h"
> > +#include "intel_display_types.h"
> > +#include "intel_dsb_buffer.h"
> > +
> > +u32 intel_dsb_buffer_ggtt_offset(struct intel_dsb_buffer *dsb_buf) {
> > +   return i915_ggtt_offset(dsb_buf->vma); }
> > +
> > +void intel_dsb_buffer_write(struct intel_dsb_buffer *dsb_buf, u32
> > +idx, u32 val) {
> > +   dsb_buf->cmd_buf[idx] = val;
> > +}
> > +
> > +u32 intel_dsb_buffer_read(struct intel_dsb_buffer *dsb_buf, u32 idx)
> > +{
> > +   return dsb_buf->cmd_buf[idx];
> > +}
> > +
> > +void intel_dsb_buffer_memset(struct intel_dsb_buffer *dsb_buf, u32
> > +idx, u32 val, u32 sz) {
> > +   memset(_buf->cmd_buf[idx], val, sz);
> 
> I think you should check the array boundaries here, to be sure.
> Probably a good idea to do with the other functions as well, but I think this 
> is
> the most critical and easiest to make mistakes with.

assert_dsb_has_room() function is taking care for not crossing the boundaries. 
Here will check from the allocated buffer-size versus used/unused buffer.
Specifically intel_dsb_buffer_memset() is called from intel_dsb_align_tail() 
where zero get set for unused cacheline space. No chance to cross the 
boundaries in this case.
Please let me know for any further info.

Regards,
Animesh

> 
> --
> Cheers,
> Luca.



[Intel-gfx] [PATCH] drm/i915/gt: Remove assignment from if condition

2023-10-26 Thread Gilbert Adikankwu
Initialize variable "entry" during declaration. Remove assignment from if
condition.

Fix checkpatch.pl error:
ERROR: do not use assignment in if condition

Signed-off-by: Gilbert Adikankwu 
---
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index e8f42ec6b1b4..cbc4ecf26d8b 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1751,7 +1751,7 @@ static bool gen8_csb_parse(const u64 csb)
 static noinline u64
 wa_csb_read(const struct intel_engine_cs *engine, u64 * const csb)
 {
-   u64 entry;
+   u64 entry = READ_ONCE(*csb);
 
/*
 * Reading from the HWSP has one particular advantage: we can detect
@@ -1763,7 +1763,7 @@ wa_csb_read(const struct intel_engine_cs *engine, u64 * 
const csb)
 * tgl,dg1:HSDES#22011327657
 */
preempt_disable();
-   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 10)) {
+   if (wait_for_atomic_us(entry != -1, 10)) {
int idx = csb - engine->execlists.csb_status;
int status;
 
-- 
2.34.1



Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: remove display device info from i915 capabilities

2023-10-26 Thread Jani Nikula
On Thu, 19 Oct 2023, "Borah, Chaitanya Kumar"  
wrote:
>> -Original Message-
>> From: Govindapillai, Vinod 
>> Sent: Wednesday, October 18, 2023 3:57 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Govindapillai, Vinod ; Sharma, Swati2
>> ; Borah, Chaitanya Kumar
>> 
>> Subject: [PATCH v4 2/2] drm/i915: remove display device info from i915
>> capabilities
>> 
>> Display device and display runtime info is exposed as part of
>> i915_display_capabilities debugfs entry. Remove this information from i915_
>> capabilities as it is now reduntant.
>> 
>> Signed-off-by: Vinod Govindapillai 
>
> LGTM.
>
> Reviewed-by: Chaitanya Kumar Borah 

Thanks for the patch and review, pushed to drm-intel-next.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c | 1 -
>>  1 file changed, 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index e9b79c2c37d8..bb48feb3b12e 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -67,7 +67,6 @@ static int i915_capabilities(struct seq_file *m, void 
>> *data)
>>  seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(i915));
>> 
>>  intel_device_info_print(INTEL_INFO(i915), RUNTIME_INFO(i915), );
>> -intel_display_device_info_print(DISPLAY_INFO(i915),
>> DISPLAY_RUNTIME_INFO(i915), );
>>  i915_print_iommu_status(i915, );
>>  intel_gt_info_print(_gt(i915)->info, );
>>  intel_driver_caps_print(>caps, );
>> --
>> 2.34.1
>

-- 
Jani Nikula, Intel


Re: [Intel-gfx] [PATCH v2] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-26 Thread Hogander, Jouni
On Thu, 2023-10-26 at 15:46 +0300, Ville Syrjälä wrote:
> On Thu, Oct 26, 2023 at 09:40:23AM +, Hogander, Jouni wrote:
> > On Wed, 2023-10-25 at 17:18 +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 20, 2023 at 12:41:03PM +0300, Jouni Högander wrote:
> > > > We are preparing for Xe driver. Xe driver doesn't have
> > > > i915_sw_fence
> > > > implementation. Lets drop i915_sw_fence usage from display code
> > > > and
> > > > use dma_fence interfaces directly.
> > > > 
> > > > For this purpose stack dma fences from related objects into new
> > > > plane
> > > > state. Drm_gem_plane_helper_prepare_fb can be used for fences
> > > > in
> > > > new
> > > > fb. Separate local implementation is used for Stacking fences
> > > > from
> > > > old fb
> > > > into new plane state. Then wait for these stacked fences during
> > > > atomic
> > > > commit. There is no be need for separate GPU reset handling in
> > > > intel_atomic_commit_fence_wait as the fences are signaled when
> > > > GPU
> > > > hang is
> > > > detected and GPU is being reset.
> > > > 
> > > > v2:
> > > >   - Add fences from old fb into new_plane_state->uapi.fence
> > > > rather
> > > > than
> > > >     into old_plane_state->uapi.fence
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Maarten Lankhorst 
> > > > Cc: José Roberto de Souza 
> > > > 
> > > > Signed-off-by: Jouni Högander 
> > > > Reviewed-by: Maarten Lankhorst
> > > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
> > > >  .../gpu/drm/i915/display/intel_atomic_plane.c | 89
> > > > +++
> > > > 
> > > >  drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
> > > > 
> > > > -
> > > >  .../drm/i915/display/intel_display_types.h    |  2 -
> > > >  4 files changed, 77 insertions(+), 95 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > index 5d18145da279..ec0d5168b503 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct
> > > > drm_atomic_state *_state)
> > > >  
> > > > drm_atomic_state_default_release(>base);
> > > > kfree(state->global_objs);
> > > > -
> > > > -   i915_sw_fence_fini(>commit_ready);
> > > > -
> > > > kfree(state);
> > > >  }
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > index b1074350616c..20fd12df6850 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > @@ -31,7 +31,10 @@
> > > >   * prepare/check/commit/cleanup steps.
> > > >   */
> > > >  
> > > > +#include 
> > > > +
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  
> > > > @@ -1012,6 +1015,44 @@ int
> > > > intel_plane_check_src_coordinates(struct
> > > > intel_plane_state *plane_state)
> > > > return 0;
> > > >  }
> > > >  
> > > > +static int add_fences(struct dma_resv *obj,
> > > > + struct drm_plane_state *dst)
> > > 
> > > I would name things differently:
> > > s/obj/resv/
> > > s/dst/plane_state/
> > > 
> > > The function name should probably be a bit more 
> > > descriptive as well.
> > > 
> > > > +{
> > > > +   struct dma_fence *fence = dma_fence_get(dst->fence);
> > > > +   enum dma_resv_usage usage;
> > > > +   struct dma_fence *new;
> > > > +   int ret;
> > > > +
> > > > +   usage = fence ? DMA_RESV_USAGE_KERNEL :
> > > > DMA_RESV_USAGE_WRITE;
> > > > +
> > > > +   ret = dma_resv_get_singleton(obj, usage, );
> > > > +   if (ret)
> > > > +   goto error;
> > > > +
> > > > +   if (new && fence) {
> > > > +   struct dma_fence_chain *chain =
> > > > dma_fence_chain_alloc();
> > > > +
> > > > +   if (!chain) {
> > > > +   ret = -ENOMEM;
> > > > +   goto error;
> > > > +   }
> > > > +
> > > > +   dma_fence_chain_init(chain, fence, new, 1);
> > > > +   fence = >base;
> > > > +
> > > > +   } else if (new) {
> > > > +   fence = new;
> > > > +   }
> > > > +
> > > > +   dma_fence_put(dst->fence);
> > > > +   dst->fence = fence;
> > > > +   return 0;
> > > > +
> > > > +error:
> > > > +   dma_fence_put(fence);
> > > > +   return ret;
> > > > +}
> > > > +
> > > >  /**
> > > >   * intel_prepare_plane_fb - Prepare fb for usage on plane
> > > >   * @_plane: drm plane to prepare for
> > > > @@ -1035,7 +1076,7 @@ intel_prepare_plane_fb(struct drm_plane
> > > > *_plane,
> > > > struct intel_atomic_state *state =
> > > > to_intel_atomic_state(new_plane_state-
> > > > >uapi.state);
> > > > struct drm_i915_private *dev_priv = to_i915(plane-
> > > > > 

[Intel-gfx] [PATCH v3] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init

2023-10-26 Thread Nirmoy Das
Fix below compiler warning:

intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
   ^~
intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
into a destination of size 8
  snprintf(tc->port_name, sizeof(tc->port_name),
  ^~
"%c/TC#%d", port_name(port), tc_port + 1);
~

v2: use kasprintf(Imre)
v3: use const for port_name, and fix tc mem leak(Imre)

Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new intel_tc_port 
struct")
Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Jani Nikula 
Signed-off-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 37b0f8529b4f..f64d348a969e 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -58,7 +58,7 @@ struct intel_tc_port {
struct delayed_work link_reset_work;
int link_refcount;
bool legacy_port:1;
-   char port_name[8];
+   const char *port_name;
enum tc_port_mode mode;
enum tc_port_mode init_mode;
enum phy_fia phy_fia;
@@ -1875,8 +1875,12 @@ int intel_tc_port_init(struct intel_digital_port 
*dig_port, bool is_legacy)
else
tc->phy_ops = _tc_phy_ops;
 
-   snprintf(tc->port_name, sizeof(tc->port_name),
-"%c/TC#%d", port_name(port), tc_port + 1);
+   tc->port_name = kasprintf(GFP_KERNEL, "%c/TC#%d", port_name(port),
+ tc_port + 1);
+   if (!tc->port_name) {
+   kfree(tc);
+   return -ENOMEM;
+   }
 
mutex_init(>lock);
/* TODO: Combine the two works */
@@ -1897,6 +1901,7 @@ void intel_tc_port_cleanup(struct intel_digital_port 
*dig_port)
 {
intel_tc_port_suspend(dig_port);
 
+   kfree(dig_port->tc->port_name);
kfree(dig_port->tc);
dig_port->tc = NULL;
 }
-- 
2.42.0



Re: [Intel-gfx] [PATCH] drm/i915/gt: Remove unncessary {} from if-else

2023-10-26 Thread Andi Shyti
Hi Gilbert,

On Thu, Oct 26, 2023 at 11:56:23AM +0100, Gilbert Adikankwu wrote:
> Fix checkpatch.pl error:
> 
> WARNING: braces {} are not necessary for any arm of this statement
> 
> Signed-off-by: Gilbert Adikankwu 

Reviewed-by: Andi Shyti 

Andi


Re: [Intel-gfx] [PATCH v2] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-26 Thread Ville Syrjälä
On Thu, Oct 26, 2023 at 09:40:23AM +, Hogander, Jouni wrote:
> On Wed, 2023-10-25 at 17:18 +0300, Ville Syrjälä wrote:
> > On Fri, Oct 20, 2023 at 12:41:03PM +0300, Jouni Högander wrote:
> > > We are preparing for Xe driver. Xe driver doesn't have
> > > i915_sw_fence
> > > implementation. Lets drop i915_sw_fence usage from display code and
> > > use dma_fence interfaces directly.
> > > 
> > > For this purpose stack dma fences from related objects into new
> > > plane
> > > state. Drm_gem_plane_helper_prepare_fb can be used for fences in
> > > new
> > > fb. Separate local implementation is used for Stacking fences from
> > > old fb
> > > into new plane state. Then wait for these stacked fences during
> > > atomic
> > > commit. There is no be need for separate GPU reset handling in
> > > intel_atomic_commit_fence_wait as the fences are signaled when GPU
> > > hang is
> > > detected and GPU is being reset.
> > > 
> > > v2:
> > >   - Add fences from old fb into new_plane_state->uapi.fence rather
> > > than
> > >     into old_plane_state->uapi.fence
> > > 
> > > Cc: Ville Syrjälä 
> > > Cc: Maarten Lankhorst 
> > > Cc: José Roberto de Souza 
> > > 
> > > Signed-off-by: Jouni Högander 
> > > Reviewed-by: Maarten Lankhorst 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
> > >  .../gpu/drm/i915/display/intel_atomic_plane.c | 89 +++
> > > 
> > >  drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
> > > -
> > >  .../drm/i915/display/intel_display_types.h    |  2 -
> > >  4 files changed, 77 insertions(+), 95 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > index 5d18145da279..ec0d5168b503 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct
> > > drm_atomic_state *_state)
> > >  
> > > drm_atomic_state_default_release(>base);
> > > kfree(state->global_objs);
> > > -
> > > -   i915_sw_fence_fini(>commit_ready);
> > > -
> > > kfree(state);
> > >  }
> > >  
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > index b1074350616c..20fd12df6850 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > @@ -31,7 +31,10 @@
> > >   * prepare/check/commit/cleanup steps.
> > >   */
> > >  
> > > +#include 
> > > +
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  
> > > @@ -1012,6 +1015,44 @@ int intel_plane_check_src_coordinates(struct
> > > intel_plane_state *plane_state)
> > > return 0;
> > >  }
> > >  
> > > +static int add_fences(struct dma_resv *obj,
> > > + struct drm_plane_state *dst)
> > 
> > I would name things differently:
> > s/obj/resv/
> > s/dst/plane_state/
> > 
> > The function name should probably be a bit more 
> > descriptive as well.
> > 
> > > +{
> > > +   struct dma_fence *fence = dma_fence_get(dst->fence);
> > > +   enum dma_resv_usage usage;
> > > +   struct dma_fence *new;
> > > +   int ret;
> > > +
> > > +   usage = fence ? DMA_RESV_USAGE_KERNEL :
> > > DMA_RESV_USAGE_WRITE;
> > > +
> > > +   ret = dma_resv_get_singleton(obj, usage, );
> > > +   if (ret)
> > > +   goto error;
> > > +
> > > +   if (new && fence) {
> > > +   struct dma_fence_chain *chain =
> > > dma_fence_chain_alloc();
> > > +
> > > +   if (!chain) {
> > > +   ret = -ENOMEM;
> > > +   goto error;
> > > +   }
> > > +
> > > +   dma_fence_chain_init(chain, fence, new, 1);
> > > +   fence = >base;
> > > +
> > > +   } else if (new) {
> > > +   fence = new;
> > > +   }
> > > +
> > > +   dma_fence_put(dst->fence);
> > > +   dst->fence = fence;
> > > +   return 0;
> > > +
> > > +error:
> > > +   dma_fence_put(fence);
> > > +   return ret;
> > > +}
> > > +
> > >  /**
> > >   * intel_prepare_plane_fb - Prepare fb for usage on plane
> > >   * @_plane: drm plane to prepare for
> > > @@ -1035,7 +1076,7 @@ intel_prepare_plane_fb(struct drm_plane
> > > *_plane,
> > > struct intel_atomic_state *state =
> > > to_intel_atomic_state(new_plane_state->uapi.state);
> > > struct drm_i915_private *dev_priv = to_i915(plane-
> > > >base.dev);
> > > -   const struct intel_plane_state *old_plane_state =
> > > +   struct intel_plane_state *old_plane_state =
> > > intel_atomic_get_old_plane_state(state, plane);
> > > struct drm_i915_gem_object *obj =
> > > intel_fb_obj(new_plane_state->hw.fb);
> > > struct drm_i915_gem_object *old_obj =
> > > intel_fb_obj(old_plane_state->hw.fb);
> > > @@ -1057,56 

Re: [Intel-gfx] [topic/core-for-CI][PATCH 0/2] Drop some unnecessary patches

2023-10-26 Thread Ville Syrjälä
On Wed, Oct 25, 2023 at 02:41:50PM +0300, Jani Nikula wrote:
> On Tue, 24 Oct 2023, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Try to drop a few seemingly unnecessary patches from core-for-CI.
> 
> Yay, ack!

Didn't spot any regressions in the CI results, so force pushed
topic/core-for-CI with these dropped. Didn't bother with a rebase.

> 
> >
> > Ville Syrjälä (2):
> >   Revert "freezer: Dump more info on whoever is trying to get frozen
> > with locks held"
> >   Revert "iommu: Remove iova cpu hotplugging flushing"
> >
> >  drivers/iommu/iova.c   | 28 
> >  include/linux/cpuhotplug.h |  1 +
> >  include/linux/iova.h   |  1 +
> >  kernel/freezer.c   | 12 ++--
> >  4 files changed, 32 insertions(+), 10 deletions(-)
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] [PATCH] file, i915: fix file reference for mmap_singleton()

2023-10-26 Thread Jann Horn
On Wed, Oct 25, 2023 at 2:01 PM Christian Brauner  wrote:
> Today we got a report at [1] for rcu stalls on the i915 testsuite in [2]
> due to the conversion of files to SLAB_TYPSSAFE_BY_RCU. Afaict,
> get_file_rcu() goes into an infinite loop trying to carefully verify
> that i915->gem.mmap_singleton hasn't changed - see the splat below.
>
> So I stared at this code to figure out what it actually does. It seems
> that the i915->gem.mmap_singleton pointer itself never had rcu semantics.
>
> The i915->gem.mmap_singleton is replaced in
> file->f_op->release::singleton_release():
>
> static int singleton_release(struct inode *inode, struct file *file)
> {
> struct drm_i915_private *i915 = file->private_data;
>
> cmpxchg(>gem.mmap_singleton, file, NULL);
> drm_dev_put(>drm);
>
> return 0;
> }
>
> The cmpxchg() is ordered against a concurrent update of
> i915->gem.mmap_singleton from mmap_singleton(). IOW, when
> mmap_singleton() fails to get a reference on i915->gem.mmap_singleton
> via mmap_singleton():
>
> rcu_read_lock();
> file = get_file_rcu(>gem.mmap_singleton);
> rcu_read_unlock();
>
> mmap_singleton() allocates a new file via anon_inode_getfile() and does
>
> smp_store_mb(i915->gem.mmap_singleton, file);
>
> So, afaiu, then what happens in the case of this bug is that at some
> point fput() is called and drops the file->f_count to zero but obviously
> leaving the pointer in i915->gem.mmap_singleton in tact until
> file->f_op->release::singleton_release() is called.
>
> Now, there might be possibly larger delays until
> file->f_op->release::singleton_release() is called and
> i915->gem.mmap_singleton is set to NULL?
>
> Say concurrently another task hits mmap_singleton() and does:
>
> rcu_read_lock();
> file = get_file_rcu(>gem.mmap_singleton);
> rcu_read_unlock();
>
> When get_file_rcu() fails to get a reference via atomic_inc_not_zero()
> it will try the reload from i915->gem.mmap_singleton assuming it has
> comparable semantics as __fget_files_rcu() that also reloads on
> atomic_inc_not_zero() failure.
>
> But since i915->gem.mmap_singleton doesn't have proper rcu semantics it
> reloads the same pointer again, trying the same atomic_inc_not_zero()
> again and doing so until file->f_op->release::singleton_release() of the
> old file has been called.
>
> So, in contrast to __fget_files_rcu() here we want to not retry when
> atomic_inc_not_zero() has failed. We only want to retry in case we
> managed to get a reference but the pointer did change on reload.
[...]
> Link: [1]: 
> https://lore.kernel.org/intel-gfx/sj1pr11mb6129cb39eed831784c331bafb9...@sj1pr11mb6129.namprd11.prod.outlook.com
> Link: [2]: 
> https://intel-gfx-ci.01.org/tree/linux-next/next-20231013/bat-dg2-11/igt@i915_selftest@l...@mman.html#dmesg-warnings10963
> Signed-off-by: Christian Brauner 

Patch makes sense to me. I'm not sure why you changed EAGAIN to
EINVAL, and it's obviously a bit ugly, but it looks like a valid fix
for what the SLUB_TYPESAFE_BY_RCU conversion broke.

Reviewed-by: Jann Horn 


But as a side note, I am a bit confused about how the concurrency of
the existing code is supposed to work... it looks like two parallel
calls to mmap_singleton() can end up returning different pointers, and
then the singleton is not actually a singleton anymore? If that part
of the existing code is wrong even before the SLAB_TYPESAFE_BY_RCU
conversion, we might later have to open-code get_file_rcu() in
mmap_singleton(), so that we can do a cmpxchg at the end that checks
whether the i915->gem.mmap_singleton pointer is still the same?

Like:

static struct file *mmap_singleton(struct drm_i915_private *i915)
{
struct file *file, *new_file;

rcu_read_lock();
file = READ_ONCE(i915->gem.mmap_singleton);
if (file && atomic_long_inc_not_zero(>f_count)) {
rcu_read_unlock();
return file;
}
rcu_read_unlock();

new_file = anon_inode_getfile("i915.gem", _fops,
i915, O_RDWR);
if (IS_ERR(new_file))
return new_file;

/* Everyone shares a single global address space */
new_file->f_mapping = i915->drm.anon_inode->i_mapping;

if (try_cmpxchg(>gem.mmap_singleton, , new_file)) {
// something with drm_dev refcount ?
return new_file;
}

// something with drm_dev refcount ?
fput(new_file);

return file;
}

It would be nice to get some i915 maintainer's comment on how the
singleton stuff is supposed to work.

> ---
>
> Jann, Linus,
>
> Since you've been quite involved, can you check that what I'm babbling
> here makes sense? If this isn't the fix then I would have to drop the
> SLAB_TYPESAFE_BY_RCU conversion patch for now since I'd like to send PRs
> by the end of the week.
>
> This is on top of
> 

Re: [Intel-gfx] [PATCH 2/3] drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function

2023-10-26 Thread Jani Nikula
On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
> Let's convert intel_hdcp_enable to a blanket function
> which just has some conditions which needs to be checked
> before connectors enable hdcp.
> This cleans up code and avoids code duplication.
>
> --v3
> -Keep function name as intel_hdcp_enable() [Jani]
>
> Signed-off-by: Suraj Kandpal 

Reviewed-by: Jani Nikula 

-- 
Jani Nikula, Intel


Re: [Intel-gfx] [PATCH 1/3] drm/i915/hdcp: Rename HCDP 1.4 enablement function

2023-10-26 Thread Jani Nikula
On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
> Rename hdcp 1.4 enablement function from _intel_hdcp_enable to
> intel_hdcp1_enable to better represent what version of hdcp is
> being enabled
>
> Signed-off-by: Suraj Kandpal 

Reviewed-by: Jani Nikula 

-- 
Jani Nikula, Intel


Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Limit max_requested_bpc based on src DSC bpc limits

2023-10-26 Thread Ville Syrjälä
On Thu, Oct 26, 2023 at 11:24:38AM +0530, Nautiyal, Ankit K wrote:
> 
> On 10/25/2023 6:20 PM, Ville Syrjälä wrote:
> > On Wed, Oct 25, 2023 at 05:43:18PM +0530, Ankit Nautiyal wrote:
> >> At the moment the max requested bpc is limited to 6 to 10/12.
> >> For platforms that support DSC, min and max src bpc with DSC are
> >> different.
> >>
> >> Account for DSC bpc limitations, when setting min and max value for
> >> max_requested_bpc property.
> > NAK. DSC capabiliies change dynamically, the property does not.
> 
> Hmm, perhaps I should remove the check for sink DSC support and have 
> only Platform check HAS_DSC.
> 
> The problem I am trying to fix is that our HW does not support DSC with 
> 6bpc, but we are allowing the max_requested_bpc to be 6 bpc.
> 
> This can be a problem with some eDP panels that support modes like 
> 4k@120 which will always need DSC and when max requested bpc property is 
> set to 6.
> 
> I am wondering how to avoid this. Does it make sense to have the min 
> value for the max_requested_bpc to be 8, for platforms that support DSC?

I think the easy fix is to just use 'min_bpc = max(dsc_min_bpc, max_bpc*3)'
with DSC. And likely we should do something like that for YCbCr output
as well.

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] [PATCH] drm/i915/mtl: avoid stringop-overflow warning

2023-10-26 Thread Jani Nikula
On Mon, 23 Oct 2023, Jani Nikula  wrote:
> On Mon, 16 Oct 2023, Arnd Bergmann  wrote:
>> From: Arnd Bergmann 
>>
>> The newly added memset() causes a warning for some reason I could not figure 
>> out:
>>
>> In file included from arch/x86/include/asm/string.h:3,
>>  from drivers/gpu/drm/i915/gt/intel_rc6.c:6:
>> In function 'rc6_res_reg_init',
>> inlined from 'intel_rc6_init' at 
>> drivers/gpu/drm/i915/gt/intel_rc6.c:610:2:
>> arch/x86/include/asm/string_32.h:195:29: error: '__builtin_memset' writing 
>> 16 bytes into a region of size 0 overflows the destination 
>> [-Werror=stringop-overflow=]
>>   195 | #define memset(s, c, count) __builtin_memset(s, c, count)
>>   | ^
>> drivers/gpu/drm/i915/gt/intel_rc6.c:584:9: note: in expansion of macro 
>> 'memset'
>>   584 | memset(rc6->res_reg, INVALID_MMIO_REG.reg, 
>> sizeof(rc6->res_reg));
>>   | ^~
>> In function 'intel_rc6_init':
>>
>> Change it to an normal initializer and an added memcpy() that does not have
>> this problem.
>>
>> Fixes: 4bb9ca7ee0745 ("drm/i915/mtl: C6 residency and C state type for MTL 
>> SAMedia")
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++--
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
>> b/drivers/gpu/drm/i915/gt/intel_rc6.c
>> index 8b67abd720be8..7090e4be29cb6 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_rc6.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
>> @@ -581,19 +581,23 @@ static void __intel_rc6_disable(struct intel_rc6 *rc6)
>>  
>>  static void rc6_res_reg_init(struct intel_rc6 *rc6)
>>  {
>> -memset(rc6->res_reg, INVALID_MMIO_REG.reg, sizeof(rc6->res_reg));
>
> That's just bollocks. memset() is byte granularity, while
> INVALID_MMIO_REG.reg is u32. If the value was anything other than 0,
> this would break.
>
> And you're not supposed to look at the guts of i915_reg_t to begin with,
> that's why it's a typedef. Basically any code that accesses the members
> of i915_reg_t outside of its implementation are doing it wrong.
>
> Reviewed-by: Jani Nikula 

Thanks for the patch, pushed to drm-intel-gt-next.

BR,
Jani.

>
>
>> +i915_reg_t res_reg[INTEL_RC6_RES_MAX] = {
>> +[0 ... INTEL_RC6_RES_MAX - 1] = INVALID_MMIO_REG,
>> +};
>>  
>>  switch (rc6_to_gt(rc6)->type) {
>>  case GT_MEDIA:
>> -rc6->res_reg[INTEL_RC6_RES_RC6] = MTL_MEDIA_MC6;
>> +res_reg[INTEL_RC6_RES_RC6] = MTL_MEDIA_MC6;
>>  break;
>>  default:
>> -rc6->res_reg[INTEL_RC6_RES_RC6_LOCKED] = GEN6_GT_GFX_RC6_LOCKED;
>> -rc6->res_reg[INTEL_RC6_RES_RC6] = GEN6_GT_GFX_RC6;
>> -rc6->res_reg[INTEL_RC6_RES_RC6p] = GEN6_GT_GFX_RC6p;
>> -rc6->res_reg[INTEL_RC6_RES_RC6pp] = GEN6_GT_GFX_RC6pp;
>> +res_reg[INTEL_RC6_RES_RC6_LOCKED] = GEN6_GT_GFX_RC6_LOCKED;
>> +res_reg[INTEL_RC6_RES_RC6] = GEN6_GT_GFX_RC6;
>> +res_reg[INTEL_RC6_RES_RC6p] = GEN6_GT_GFX_RC6p;
>> +res_reg[INTEL_RC6_RES_RC6pp] = GEN6_GT_GFX_RC6pp;
>>  break;
>>  }
>> +
>> +memcpy(rc6->res_reg, res_reg, sizeof(res_reg));
>>  }
>>  
>>  void intel_rc6_init(struct intel_rc6 *rc6)

-- 
Jani Nikula, Intel


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Improve BW management on MST links (rev5)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Improve BW management on MST links (rev5)
URL   : https://patchwork.freedesktop.org/series/125490/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13782_full -> Patchwork_125490v5_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125490v5_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125490v5_full, please notify your bug team 
(lgci.bug.fil...@intel.com) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (12 -> 0)
--

  ERROR: It appears as if the changes made in Patchwork_125490v5_full prevented 
too many machines from booting.

  Missing(12): shard-mtlp0 shard-skl shard-tglu shard-rkl0 shard-dg1 
shard-apl shard-glk shard-mtlp shard-snb shard-rkl shard-dg2 shard-dg20 


Changes
---

  No changes found


Build changes
-

  * CI: CI-20190529 -> None
  * IGT: IGT_7552 -> None
  * Linux: CI_DRM_13782 -> Patchwork_125490v5

  CI-20190529: 20190529
  CI_DRM_13782: 16c18fef1215015ab3d1a0dd3b06cf6131fe23bd @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7552: 557856802dfee103802f1157f97c65bb476d5468 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_125490v5: 16c18fef1215015ab3d1a0dd3b06cf6131fe23bd @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125490v5/index.html


Re: [Intel-gfx] Regression on linux-next (next-20231013)

2023-10-26 Thread Christian Brauner
On Thu, Oct 26, 2023 at 10:14:23AM +, Borah, Chaitanya Kumar wrote:
> Hello Christian,
> 
> > -Original Message-
> > From: Borah, Chaitanya Kumar
> > Sent: Wednesday, October 25, 2023 7:15 PM
> > To: Christian Brauner 
> > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > ; Saarinen, Jani 
> > Subject: RE: Regression on linux-next (next-20231013)
> > 
> > Hello Christian,
> > 
> > > -Original Message-
> > > From: Christian Brauner 
> > > Sent: Wednesday, October 25, 2023 1:02 PM
> > > To: Borah, Chaitanya Kumar 
> > > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > > ; Saarinen, Jani
> > > 
> > > Subject: Re: Regression on linux-next (next-20231013)
> > >
> > > On Wed, Oct 25, 2023 at 06:32:01AM +, Borah, Chaitanya Kumar wrote:
> > > >  Hello Christian,
> > > >
> > > >  Hope you are doing well. I am Chaitanya from the linux graphics
> > > > team in
> > > Intel.
> > > >
> > > >  This mail is regarding a regression we are seeing in our CI runs[1]
> > > > on linux-next  repository.
> > >
> > > Any chance I can reproduce this locally?
> > 
> > Thank you for your response.
> > 
> > I see that you have already floated a patch [1] to fix the issue. We will 
> > test it
> > and get back to you ASAP.
> 
> The solution is working for us.
> 
> Also, linux-next turned green.

Great! That already has the final version of the patch.

> http://gfx-ci.igk.intel.com/tree/linux-next/igt@i915_selftest@l...@mman.html
> 
> Thank you.

Thanks for the report!


[Intel-gfx] [PATCH 3/3] drm/i915/hdcp: Add more conditions to enable hdcp

2023-10-26 Thread Suraj Kandpal
When we dock a monitor we end up with a enable and disable connector
cycle but if hdcp content is running we get the userspace in
enabled state and driver maintaining a undesired state which causes
the content to stop playing and we only enabe hdcp if the userspace
state in desired. This patch fixes that.

--v2
-Move code to intel_hdcp [Jani]

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 44c0a93f3af8..39b3f7c0c77c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2409,9 +2409,19 @@ void intel_hdcp_enable(struct intel_atomic_state *state,
   const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state)
 {
-   /* Enable hdcp if it's desired */
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
+   struct intel_hdcp *hdcp = >hdcp;
+
+   /*
+* Enable hdcp if it's desired or if userspace is enabled and
+* driver set its state to undesired
+*/
if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+   (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_ENABLED && hdcp->value ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
_intel_hdcp_enable(state, encoder, crtc_state, conn_state);
 }
 
-- 
2.25.1



[Intel-gfx] [PATCH 2/3] drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function

2023-10-26 Thread Suraj Kandpal
Let's convert intel_hdcp_enable to a blanket function
which just has some conditions which needs to be checked
before connectors enable hdcp.
This cleans up code and avoids code duplication.

--v3
-Keep function name as intel_hdcp_enable() [Jani]

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 21 -
 drivers/gpu/drm/i915/display/intel_hdcp.h   |  8 
 4 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9151d5add960..b644cf981846 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
else
intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+   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 7b4628f4f124..4366da79fe81 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
 
intel_audio_codec_enable(encoder, pipe_config, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
+   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 7c0cfcb48521..44c0a93f3af8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2324,10 +2324,10 @@ intel_hdcp_set_streams(struct intel_digital_port 
*dig_port,
return 0;
 }
 
-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)
+static 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 *i915 = to_i915(encoder->base.dev);
struct intel_connector *connector =
@@ -2404,6 +2404,17 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
return ret;
 }
 
+void intel_hdcp_enable(struct intel_atomic_state *state,
+  struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
+{
+   /* Enable hdcp if it's desired */
+   if (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+}
+
 int intel_hdcp_disable(struct intel_connector *connector)
 {
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
@@ -2491,7 +2502,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state 
*state,
}
 
if (desired_and_not_enabled || content_protection_type_changed)
-   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+   _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
 }
 
 void intel_hdcp_component_fini(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 5997c52a0958..a9c784fd9ba5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -28,10 +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_atomic_state *state,
- struct intel_encoder *encoder,
- const struct intel_crtc_state *pipe_config,
- const struct drm_connector_state *conn_state);
+void intel_hdcp_enable(struct intel_atomic_state *state,
+

[Intel-gfx] [PATCH 0/3] drm/i915/hdcp: Additional conditions to enable hdcp

2023-10-26 Thread Suraj Kandpal
We are seeing a issue when we close the lid of a laptop or dock a
monitor hdcp content is not being reenabled automatically this is
because when we dock a monitor we end up with a enable and
disable connector cycle but if hdcp content is running we get the
userspace in enabled state and driver maintaining a undesired
state which causes the content to stop playing and we only enabe
hdcp if the userspace state in desired.
This first and second patch refactors the code while the third one adds the
new conditions to enable hdcp.

Signed-off-by: Suraj Kandpal 

Suraj Kandpal (3):
  drm/i915/hdcp: Rename HCDP 1.4 enablement function
  drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function
  drm/i915/hdcp: Add more conditions to enable hdcp

 drivers/gpu/drm/i915/display/intel_ddi.c|  5 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +--
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 37 -
 drivers/gpu/drm/i915/display/intel_hdcp.h   |  8 ++---
 4 files changed, 35 insertions(+), 20 deletions(-)

-- 
2.25.1



[Intel-gfx] [PATCH 1/3] drm/i915/hdcp: Rename HCDP 1.4 enablement function

2023-10-26 Thread Suraj Kandpal
Rename hdcp 1.4 enablement function from _intel_hdcp_enable to
intel_hdcp1_enable to better represent what version of hdcp is
being enabled

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c89da3568ebd..7c0cfcb48521 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -923,7 +923,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
return 0;
 }
 
-static int _intel_hdcp_enable(struct intel_connector *connector)
+static int intel_hdcp1_enable(struct intel_connector *connector)
 {
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
@@ -1058,7 +1058,7 @@ static int intel_hdcp_check_link(struct intel_connector 
*connector)
goto out;
}
 
-   ret = _intel_hdcp_enable(connector);
+   ret = intel_hdcp1_enable(connector);
if (ret) {
drm_err(>drm, "Failed to enable hdcp (%d)\n", ret);
intel_hdcp_update_value(connector,
@@ -2388,7 +2388,7 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
 */
if (ret && intel_hdcp_capable(connector) &&
hdcp->content_type != DRM_MODE_HDCP_CONTENT_TYPE1) {
-   ret = _intel_hdcp_enable(connector);
+   ret = intel_hdcp1_enable(connector);
}
 
if (!ret) {
-- 
2.25.1



Re: [Intel-gfx] [PATCH 2/3] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Kandpal, Suraj



> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, October 26, 2023 3:34 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj 
> Subject: Re: [PATCH 2/3] drm/i915/hdcp: Create a blanket hdcp enable function
> 
> On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
> > Let's create a blanket function which just has some conditions which
> > need to be checked before connectors enable hdcp.
> > This cleans up code and avoids code duplication.
> 
> This series has two 2/3 patches... confused me, probably going to confuse CI
> too...
> 
Weird will send out a new patch series just in case
Though the patchwork seems to catch it properly
https://patchwork.freedesktop.org/series/125550/

Regards,
Suraj Kandpal
> BR,
> Jani.
> 
> 
> >
> > --v3
> > -Keep function name as intel_hdcp_enable() [Jani]
> >
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
> >  drivers/gpu/drm/i915/display/intel_hdcp.c   | 21 -
> >  drivers/gpu/drm/i915/display/intel_hdcp.h   |  8 
> >  4 files changed, 22 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 9151d5add960..b644cf981846 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> > else
> > intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
> >
> > -   /* Enable hdcp if it's desired */
> > -   if (conn_state->content_protection ==
> > -   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > -   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> > +   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 7b4628f4f124..4366da79fe81 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct
> > intel_atomic_state *state,
> >
> > intel_audio_codec_enable(encoder, pipe_config, conn_state);
> >
> > -   /* Enable hdcp if it's desired */
> > -   if (conn_state->content_protection ==
> > -   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > -   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
> > +   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 7c0cfcb48521..44c0a93f3af8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2324,10 +2324,10 @@ intel_hdcp_set_streams(struct intel_digital_port
> *dig_port,
> > return 0;
> >  }
> >
> > -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)
> > +static 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 *i915 = to_i915(encoder->base.dev);
> > struct intel_connector *connector =
> > @@ -2404,6 +2404,17 @@ int intel_hdcp_enable(struct intel_atomic_state
> *state,
> > return ret;
> >  }
> >
> > +void intel_hdcp_enable(struct intel_atomic_state *state,
> > +  struct intel_encoder *encoder,
> > +  const struct intel_crtc_state *crtc_state,
> > +  const struct drm_connector_state *conn_state) {
> > +   /* Enable hdcp if it's desired */
> > +   if (conn_state->content_protection ==
> > +   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > +   _intel_hdcp_enable(state, encoder, crtc_state, conn_state); }
> > +
> >  int intel_hdcp_disable(struct intel_connector *connector)  {
> > struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > @@ -2491,7 +2502,7 @@ void intel_hdcp_update_pipe(struct
> intel_atomic_state *state,
> > }
> >
> > if (desired_and_not_enabled || content_protection_type_changed)
> > -   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> > +   _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> >  }
> >
> >  void intel_hdcp_component_fini(struct 

Re: [Intel-gfx] [PATCH] drm/i915/display: Include drm_drv.h in intel_display_params.c

2023-10-26 Thread Jani Nikula
On Thu, 26 Oct 2023, Jouni Högander  wrote:
> intel_display_params.c is accessing drm_drv->name. Due to this include
> drm_drv.h to avoid build problem with Xe.
>
> Signed-off-by: Jouni Högander 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_display_params.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c 
> b/drivers/gpu/drm/i915/display/intel_display_params.c
> index 11e03cfb774d..cd1dd2fbd8a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_params.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_params.c
> @@ -3,6 +3,8 @@
>   * Copyright © 2023 Intel Corporation
>   */
>  
> +#include 
> +
>  #include "intel_display_params.h"
>  #include "i915_drv.h"

-- 
Jani Nikula, Intel


[Intel-gfx] [PATCH] drm/i915/display: Include drm_drv.h in intel_display_params.c

2023-10-26 Thread Jouni Högander
intel_display_params.c is accessing drm_drv->name. Due to this include
drm_drv.h to avoid build problem with Xe.

Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_display_params.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c 
b/drivers/gpu/drm/i915/display/intel_display_params.c
index 11e03cfb774d..cd1dd2fbd8a4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_params.c
+++ b/drivers/gpu/drm/i915/display/intel_display_params.c
@@ -3,6 +3,8 @@
  * Copyright © 2023 Intel Corporation
  */
 
+#include 
+
 #include "intel_display_params.h"
 #include "i915_drv.h"
 
-- 
2.34.1



[Intel-gfx] [PULL] drm-misc-fixes

2023-10-26 Thread Thomas Zimmermann
Hi,

this is the week's PR for drm-misc-fixes.

Best regards
Thomas

drm-misc-fixes-2023-10-26:
Short summary of fixes pull:

amdgpu:
- ignore duplicated BOs in CS parser
- remove redundant call to amdgpu_ctx_priority_is_valid()

amdkfd:
- reserve fence slot while locking BO

dp_mst:
- Fix NULL deref in get_mst_branch_device_by_guid_helper()

logicvc:
- Kconfig: Select REGMAP and REGMAP_MMIO

ivpu:
- Fix missing VPUIP interrupts
The following changes since commit 8f5ad367e8b884772945c6c9fb622ac94b7d3e32:

  accel/ivpu: Extend address range for MMU mmap (2023-10-19 08:01:20 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-10-26

for you to fetch changes up to b132ac51d7a50c37683be56c96ff64f8c887930f:

  accel/ivpu/37xx: Fix missing VPUIP interrupts (2023-10-26 07:43:28 +0200)


Short summary of fixes pull:

amdgpu:
- ignore duplicated BOs in CS parser
- remove redundant call to amdgpu_ctx_priority_is_valid()

amdkfd:
- reserve fence slot while locking BO

dp_mst:
- Fix NULL deref in get_mst_branch_device_by_guid_helper()

logicvc:
- Kconfig: Select REGMAP and REGMAP_MMIO

ivpu:
- Fix missing VPUIP interrupts


Christian König (2):
  drm/amdgpu: ignore duplicate BOs again
  drm/amdkfd: reserve a fence slot while locking the BO

Karol Wachowski (1):
  accel/ivpu/37xx: Fix missing VPUIP interrupts

Luben Tuikov (1):
  drm/amdgpu: Remove redundant call to priority_is_valid()

Lukasz Majczak (1):
  drm/dp_mst: Fix NULL deref in get_mst_branch_device_by_guid_helper()

Sui Jingfeng (1):
  drm/logicvc: Kconfig: select REGMAP and REGMAP_MMIO

 drivers/accel/ivpu/ivpu_hw_37xx.c| 11 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 15 ---
 drivers/gpu/drm/display/drm_dp_mst_topology.c|  6 +++---
 drivers/gpu/drm/logicvc/Kconfig  |  2 ++
 6 files changed, 21 insertions(+), 18 deletions(-)

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper

2023-10-26 Thread Andi Shyti
On Thu, Oct 26, 2023 at 11:51:02AM +0100, Tvrtko Ursulin wrote:
> On 26/10/2023 11:36, Andi Shyti wrote:
> > > On 26/10/2023 11:22, Jani Nikula wrote:
> > > > On Wed, 25 Oct 2023, Andi Shyti  wrote:
> > > > > On Wed, Oct 25, 2023 at 11:20:25AM +0100, Tvrtko Ursulin wrote:
> > > > > > 
> > > > > > On 24/10/2023 13:42, Jani Nikula wrote:
> > > > > > > On Tue, 24 Oct 2023, Andi Shyti  
> > > > > > > wrote:
> > > > > > > > Hi Jani,
> > > > > > > > 
> > > > > > > > On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula wrote:
> > > > > > > > > It's tedious to duplicate the container_of() everywhere. Add 
> > > > > > > > > a helper.
> > > > > > > > > 
> > > > > > > > > Also do the logical steps of first getting from struct 
> > > > > > > > > perf_event to
> > > > > > > > > struct i915_pmu, and then from struct i915_pmu to struct
> > > > > > > > > drm_i915_private if needed, instead of perf_event->i915->pmu. 
> > > > > > > > > Not all
> > > > > > > > > places even need the i915 pointer.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Jani Nikula 
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/i915/i915_pmu.c | 45 
> > > > > > > > > +++--
> > > > > > > > > 1 file changed, 20 insertions(+), 25 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > > > > > > > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > > > > index dcae2fcd8d36..d45b40ec6d47 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > > > > @@ -31,6 +31,11 @@
> > > > > > > > > static cpumask_t i915_pmu_cpumask;
> > > > > > > > > static unsigned int i915_pmu_target_cpu = -1;
> > > > > > > > > +static struct i915_pmu *event_to_pmu(struct perf_event 
> > > > > > > > > *event)
> > > > > > > > 
> > > > > > > > I would call it perfevent (or perf_event), event is too generic.
> > > > > > > > We have other kind of events, too.
> > > > > > > 
> > > > > > > Fair enough.
> > > > > > 
> > > > > > Counter argument is that i915_pmu.c consistently names this event 
> > > > > > (which is
> > > > > > likely lifted from other PMU drivers) so is the proposal to churn 
> > > > > > it all, or
> > > > > > create an inconsistency?
> > > > > 
> > > > > The first that comes to my mind is that the debugger is also
> > > > > using the term "event"... on the other hand there is no debugger
> > > > > in i915.
> > > > 
> > > > Have you settled on this? I don't care either way, could apply either
> > > > patch.
> > 
> > no... unfortunately not...
> 
> :(
> 
> $ grep "struct perf_event \*event" . -r | wc -l
> 1912
> $ grep "struct perf_event \*perf_event" . -r | wc -l
> 5
> 
> ;)

with "I haven't settled on this", I meant that the debugger has
not been posted upstream for i915 and it won't be. It's going to
go in the XE driver.

> Now seriously, I don't mind perf_event, as long as _whole_ i915_pmu.c is
> switched over. At which point I questioned would the churn be worth it.

I like Jani's patch, of course your grep search concludes the
the discussion, so that I'm not going to argue agains "event"
as name :-)

Acked-by: Andi Shyti 

Andi


[Intel-gfx] [PATCH] drm/i915/gt: Remove unncessary {} from if-else

2023-10-26 Thread Gilbert Adikankwu
Fix checkpatch.pl error:

WARNING: braces {} are not necessary for any arm of this statement

Signed-off-by: Gilbert Adikankwu 
---
 drivers/gpu/drm/i915/gt/intel_sseu.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c 
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index f602895f6d0d..6a3246240e81 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -849,13 +849,12 @@ void intel_sseu_print_topology(struct drm_i915_private 
*i915,
   const struct sseu_dev_info *sseu,
   struct drm_printer *p)
 {
-   if (sseu->max_slices == 0) {
+   if (sseu->max_slices == 0)
drm_printf(p, "Unavailable\n");
-   } else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+   else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
sseu_print_xehp_topology(sseu, p);
-   } else {
+   else
sseu_print_hsw_topology(sseu, p);
-   }
 }
 
 void intel_sseu_print_ss_info(const char *type,
-- 
2.34.1



Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper

2023-10-26 Thread Tvrtko Ursulin




On 26/10/2023 11:36, Andi Shyti wrote:

Hi,


On 26/10/2023 11:22, Jani Nikula wrote:

On Wed, 25 Oct 2023, Andi Shyti  wrote:

On Wed, Oct 25, 2023 at 11:20:25AM +0100, Tvrtko Ursulin wrote:


On 24/10/2023 13:42, Jani Nikula wrote:

On Tue, 24 Oct 2023, Andi Shyti  wrote:

Hi Jani,

On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula wrote:

It's tedious to duplicate the container_of() everywhere. Add a helper.

Also do the logical steps of first getting from struct perf_event to
struct i915_pmu, and then from struct i915_pmu to struct
drm_i915_private if needed, instead of perf_event->i915->pmu. Not all
places even need the i915 pointer.

Signed-off-by: Jani Nikula 
---
drivers/gpu/drm/i915/i915_pmu.c | 45 +++--
1 file changed, 20 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dcae2fcd8d36..d45b40ec6d47 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -31,6 +31,11 @@
static cpumask_t i915_pmu_cpumask;
static unsigned int i915_pmu_target_cpu = -1;
+static struct i915_pmu *event_to_pmu(struct perf_event *event)


I would call it perfevent (or perf_event), event is too generic.
We have other kind of events, too.


Fair enough.


Counter argument is that i915_pmu.c consistently names this event (which is
likely lifted from other PMU drivers) so is the proposal to churn it all, or
create an inconsistency?


The first that comes to my mind is that the debugger is also
using the term "event"... on the other hand there is no debugger
in i915.


Have you settled on this? I don't care either way, could apply either
patch.


no... unfortunately not...


:(

$ grep "struct perf_event \*event" . -r | wc -l
1912
$ grep "struct perf_event \*perf_event" . -r | wc -l
5

;)

Now seriously, I don't mind perf_event, as long as _whole_ i915_pmu.c is 
switched over. At which point I questioned would the churn be worth it.


Regards,

Tvrtko


To me it is clear that preference should be to remain consistent within the
file, that is, leave it as you originally had.


... so I'm not going to be strong on this... please feel free to
ignore my comment, then.

Thanks!
Andi


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL (rev2)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL (rev2)
URL   : https://patchwork.freedesktop.org/series/125293/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13783 -> Patchwork_125293v2


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/index.html

Participating hosts (37 -> 36)
--

  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_125293v2 that come from known issues:

### CI changes ###

 Possible fixes 

  * boot:
- fi-bsw-n3050:   [FAIL][1] ([i915#8293]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13783/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/fi-bsw-n3050/boot.html
- fi-hsw-4770:[FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13783/fi-hsw-4770/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/fi-hsw-4770/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050:   NOTRUN -> [SKIP][6] ([fdo#109271]) +18 other tests 
skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][7] -> [DMESG-FAIL][8] ([i915#7699])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13783/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-pnv-d510:[PASS][9] -> [ABORT][10] ([i915#9572])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13783/fi-pnv-d510/igt@i915_susp...@basic-s2idle-without-i915.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/fi-pnv-d510/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-bsw-n3050:   NOTRUN -> [FAIL][11] ([IGT#3])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/fi-bsw-n3050/igt@kms_hdmi_inj...@inject-audio.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [DMESG-FAIL][12] ([i915#5334] / [i915#7872]) -> 
[PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13783/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
  [i915#7952]: https://gitlab.freedesktop.org/drm/intel/issues/7952
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
  [i915#9572]: https://gitlab.freedesktop.org/drm/intel/issues/9572


Build changes
-

  * Linux: CI_DRM_13783 -> Patchwork_125293v2

  CI-20190529: 20190529
  CI_DRM_13783: effc8753aee06b5bd8f6f93dcdee9bb759efc8e7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7552: 557856802dfee103802f1157f97c65bb476d5468 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_125293v2: effc8753aee06b5bd8f6f93dcdee9bb759efc8e7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

6480ce1d5340 drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v2/index.html


Re: [Intel-gfx] [PATCH] drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier

2023-10-26 Thread Kahola, Mika
> -Original Message-
> From: Hogander, Jouni 
> Sent: Wednesday, October 25, 2023 4:05 PM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/display: Support PSR entry VSC packet to be 
> transmitted one frame earlier
> 
> On Wed, 2023-10-25 at 12:46 +0300, Mika Kahola wrote:
> > Display driver shall read DPCD 00071h[3:1] during configuration to get
> > PSR setup time. This register provides the setup time requirement on
> > the VSC SDP entry packet. If setup time cannot be met with the current
> > timings (e.g., PSR setup time + other blanking requirements > blanking
> > time), driver should enable sending VSC SDP one frame earlier before
> > sending the capture frame.
> >
> > BSpec: 69895 (PSR Entry Setup Frames 17:16)
> >
> > Signed-off-by: Mika Kahola 
> > ---
> >  .../drm/i915/display/intel_display_types.h    |  1 +
> >  drivers/gpu/drm/i915/display/intel_psr.c  | 35 -
> > --
> >  drivers/gpu/drm/i915/display/intel_psr_regs.h |  2 ++
> >  3 files changed, 33 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 65ea37fe8cff..a0bcab6f2bec 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1710,6 +1710,7 @@ struct intel_psr {
> > u32 dc3co_exitline;
> > u32 dc3co_exit_delay;
> > struct delayed_work dc3co_work;
> > +   u8 entry_setup_frames;
> 
> eDP spec is speaking about 1 frame. Our HW seem to have possibility to have 
> several.

That's true. The bitfield is two bits wide so anything from zero to three 
frames are, in theory, allowed.
Since the description talks only having one frame earlier, I sticked to this 
idea.

> 
> >  };
> >
> >  struct intel_dp {
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 4f1f31fc9529..0acb4edae128 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -592,6 +592,9 @@ static void intel_psr_enable_sink(struct intel_dp
> > *intel_dp)
> > if (intel_dp->psr.req_psr2_sdp_prior_scanline)
> > dpcd_val |= DP_PSR_SU_REGION_SCANLINE_CAPTURE;
> >
> > +   if (intel_dp->psr.entry_setup_frames > 0)
> > +   dpcd_val |= DP_PSR_FRAME_CAPTURE;
> > +
> > drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
> >
> > drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D0); @@ -690,6 +693,9 @@ static void
> > hsw_activate_psr1(struct intel_dp
> > *intel_dp)
> > if (DISPLAY_VER(dev_priv) >= 8)
> > val |= EDP_PSR_CRC_ENABLE;
> >
> > +   if (intel_dp->psr.entry_setup_frames > 0)
> > +   val |= EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp-
> > >psr.entry_setup_frames);
> > +
> > intel_de_rmw(dev_priv, psr_ctl_reg(dev_priv, cpu_transcoder),
> >  ~EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK, val);
> >  }
> > @@ -731,6 +737,7 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > +   u8 frames_before_su_entry;
> > u32 val = EDP_PSR2_ENABLE;
> >
> > val |=
> > EDP_PSR2_IDLE_FRAMES(psr_compute_idle_frames(intel_dp));
> > @@ -741,7 +748,10 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <=
> > 12)
> > val |= EDP_Y_COORDINATE_ENABLE;
> >
> > -   val |= EDP_PSR2_FRAME_BEFORE_SU(max_t(u8, intel_dp-
> > >psr.sink_sync_latency + 1, 2));
> > +   frames_before_su_entry = max_t(u8,
> > +  intel_dp-
> > >psr.sink_sync_latency + 1,
> > +  2);
> > +   val |= EDP_PSR2_FRAME_BEFORE_SU(frames_before_su_entry);
> 
> I think you want to do this only once. Below or here.

This might end up as a separate function so I will program this value only once 
there.

> 
> > val |= intel_psr2_get_tp_time(intel_dp);
> >
> > if (DISPLAY_VER(dev_priv) >= 12) { @@ -785,6 +795,14 @@ static
> > void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > if (intel_dp->psr.req_psr2_sdp_prior_scanline)
> > val |= EDP_PSR2_SU_SDP_SCANLINE;
> >
> > +   /* Entry setup frames must be at least 1 less than frames
> > before SU entry */
> > +   if (intel_dp->psr.entry_setup_frames > 0) {
> > +   val |= EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp-
> > >psr.entry_setup_frames);
> 
> This is not the correct register. You want to have this in PSR_CTL (not 
> PSR2_CTL).

Yes, this ends up in the wrong place. I'll fix this.

> 
> > +
> > +   if (intel_dp->psr.entry_setup_frames >=
> > 

Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper

2023-10-26 Thread Andi Shyti
Hi,

> On 26/10/2023 11:22, Jani Nikula wrote:
> > On Wed, 25 Oct 2023, Andi Shyti  wrote:
> > > On Wed, Oct 25, 2023 at 11:20:25AM +0100, Tvrtko Ursulin wrote:
> > > > 
> > > > On 24/10/2023 13:42, Jani Nikula wrote:
> > > > > On Tue, 24 Oct 2023, Andi Shyti  wrote:
> > > > > > Hi Jani,
> > > > > > 
> > > > > > On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula wrote:
> > > > > > > It's tedious to duplicate the container_of() everywhere. Add a 
> > > > > > > helper.
> > > > > > > 
> > > > > > > Also do the logical steps of first getting from struct perf_event 
> > > > > > > to
> > > > > > > struct i915_pmu, and then from struct i915_pmu to struct
> > > > > > > drm_i915_private if needed, instead of perf_event->i915->pmu. Not 
> > > > > > > all
> > > > > > > places even need the i915 pointer.
> > > > > > > 
> > > > > > > Signed-off-by: Jani Nikula 
> > > > > > > ---
> > > > > > >drivers/gpu/drm/i915/i915_pmu.c | 45 
> > > > > > > +++--
> > > > > > >1 file changed, 20 insertions(+), 25 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > > > > > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > > index dcae2fcd8d36..d45b40ec6d47 100644
> > > > > > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > > @@ -31,6 +31,11 @@
> > > > > > >static cpumask_t i915_pmu_cpumask;
> > > > > > >static unsigned int i915_pmu_target_cpu = -1;
> > > > > > > +static struct i915_pmu *event_to_pmu(struct perf_event *event)
> > > > > > 
> > > > > > I would call it perfevent (or perf_event), event is too generic.
> > > > > > We have other kind of events, too.
> > > > > 
> > > > > Fair enough.
> > > > 
> > > > Counter argument is that i915_pmu.c consistently names this event 
> > > > (which is
> > > > likely lifted from other PMU drivers) so is the proposal to churn it 
> > > > all, or
> > > > create an inconsistency?
> > > 
> > > The first that comes to my mind is that the debugger is also
> > > using the term "event"... on the other hand there is no debugger
> > > in i915.
> > 
> > Have you settled on this? I don't care either way, could apply either
> > patch.

no... unfortunately not...

> To me it is clear that preference should be to remain consistent within the
> file, that is, leave it as you originally had.

... so I'm not going to be strong on this... please feel free to
ignore my comment, then.

Thanks!
Andi


Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper

2023-10-26 Thread Tvrtko Ursulin



On 26/10/2023 11:22, Jani Nikula wrote:

On Wed, 25 Oct 2023, Andi Shyti  wrote:

On Wed, Oct 25, 2023 at 11:20:25AM +0100, Tvrtko Ursulin wrote:


On 24/10/2023 13:42, Jani Nikula wrote:

On Tue, 24 Oct 2023, Andi Shyti  wrote:

Hi Jani,

On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula wrote:

It's tedious to duplicate the container_of() everywhere. Add a helper.

Also do the logical steps of first getting from struct perf_event to
struct i915_pmu, and then from struct i915_pmu to struct
drm_i915_private if needed, instead of perf_event->i915->pmu. Not all
places even need the i915 pointer.

Signed-off-by: Jani Nikula 
---
   drivers/gpu/drm/i915/i915_pmu.c | 45 +++--
   1 file changed, 20 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dcae2fcd8d36..d45b40ec6d47 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -31,6 +31,11 @@
   static cpumask_t i915_pmu_cpumask;
   static unsigned int i915_pmu_target_cpu = -1;
+static struct i915_pmu *event_to_pmu(struct perf_event *event)


I would call it perfevent (or perf_event), event is too generic.
We have other kind of events, too.


Fair enough.


Counter argument is that i915_pmu.c consistently names this event (which is
likely lifted from other PMU drivers) so is the proposal to churn it all, or
create an inconsistency?


The first that comes to my mind is that the debugger is also
using the term "event"... on the other hand there is no debugger
in i915.


Have you settled on this? I don't care either way, could apply either
patch.


To me it is clear that preference should be to remain consistent within 
the file, that is, leave it as you originally had.


Regards,

Tvrtko


Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper

2023-10-26 Thread Jani Nikula
On Wed, 25 Oct 2023, Andi Shyti  wrote:
> On Wed, Oct 25, 2023 at 11:20:25AM +0100, Tvrtko Ursulin wrote:
>> 
>> On 24/10/2023 13:42, Jani Nikula wrote:
>> > On Tue, 24 Oct 2023, Andi Shyti  wrote:
>> > > Hi Jani,
>> > > 
>> > > On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula wrote:
>> > > > It's tedious to duplicate the container_of() everywhere. Add a helper.
>> > > > 
>> > > > Also do the logical steps of first getting from struct perf_event to
>> > > > struct i915_pmu, and then from struct i915_pmu to struct
>> > > > drm_i915_private if needed, instead of perf_event->i915->pmu. Not all
>> > > > places even need the i915 pointer.
>> > > > 
>> > > > Signed-off-by: Jani Nikula 
>> > > > ---
>> > > >   drivers/gpu/drm/i915/i915_pmu.c | 45 
>> > > > +++--
>> > > >   1 file changed, 20 insertions(+), 25 deletions(-)
>> > > > 
>> > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
>> > > > b/drivers/gpu/drm/i915/i915_pmu.c
>> > > > index dcae2fcd8d36..d45b40ec6d47 100644
>> > > > --- a/drivers/gpu/drm/i915/i915_pmu.c
>> > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
>> > > > @@ -31,6 +31,11 @@
>> > > >   static cpumask_t i915_pmu_cpumask;
>> > > >   static unsigned int i915_pmu_target_cpu = -1;
>> > > > +static struct i915_pmu *event_to_pmu(struct perf_event *event)
>> > > 
>> > > I would call it perfevent (or perf_event), event is too generic.
>> > > We have other kind of events, too.
>> > 
>> > Fair enough.
>> 
>> Counter argument is that i915_pmu.c consistently names this event (which is
>> likely lifted from other PMU drivers) so is the proposal to churn it all, or
>> create an inconsistency?
>
> The first that comes to my mind is that the debugger is also
> using the term "event"... on the other hand there is no debugger
> in i915.

Have you settled on this? I don't care either way, could apply either
patch.

BR,
Jani.



-- 
Jani Nikula, Intel


Re: [Intel-gfx] [PATCH v2] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init

2023-10-26 Thread Nirmoy Das



On 10/26/2023 12:11 PM, Imre Deak wrote:

On Thu, Oct 26, 2023 at 12:05:13PM +0300, Imre Deak wrote:

On Wed, Oct 25, 2023 at 07:08:34PM +0200, Nirmoy Das wrote:

Fix below compiler warning:

intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
^~
intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
into a destination of size 8
   snprintf(tc->port_name, sizeof(tc->port_name),
   ^~
 "%c/TC#%d", port_name(port), tc_port + 1);
 ~

v2: use kasprintf(Imre)

Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new intel_tc_port 
struct")
Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Jani Nikula 
Signed-off-by: Nirmoy Das 

Reviewed-by: Imre Deak 

Nit: port_name could be const.


---
  drivers/gpu/drm/i915/display/intel_tc.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 37b0f8529b4f..0fa54450d51b 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -58,7 +58,7 @@ struct intel_tc_port {
struct delayed_work link_reset_work;
int link_refcount;
bool legacy_port:1;
-   char port_name[8];
+   char *port_name;
enum tc_port_mode mode;
enum tc_port_mode init_mode;
enum phy_fia phy_fia;
@@ -1875,8 +1875,10 @@ int intel_tc_port_init(struct intel_digital_port 
*dig_port, bool is_legacy)
else
tc->phy_ops = _tc_phy_ops;
  
-	snprintf(tc->port_name, sizeof(tc->port_name),

-"%c/TC#%d", port_name(port), tc_port + 1);
+   tc->port_name = kasprintf(GFP_KERNEL, "%c/TC#%d", port_name(port),
+ tc_port + 1);
+   if (!tc->port_name)
+   return -ENOMEM;

Missed it, but this needs to free tc;


Oh, thanks for catching it.


Regards,

Nirmoy



  
  	mutex_init(>lock);

/* TODO: Combine the two works */
@@ -1897,6 +1899,7 @@ void intel_tc_port_cleanup(struct intel_digital_port 
*dig_port)
  {
intel_tc_port_suspend(dig_port);
  
+	kfree(dig_port->tc->port_name);

kfree(dig_port->tc);
dig_port->tc = NULL;
  }
--
2.41.0



Re: [Intel-gfx] Regression on linux-next (next-20231013)

2023-10-26 Thread Borah, Chaitanya Kumar
Hello Christian,

> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Wednesday, October 25, 2023 7:15 PM
> To: Christian Brauner 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: RE: Regression on linux-next (next-20231013)
> 
> Hello Christian,
> 
> > -Original Message-
> > From: Christian Brauner 
> > Sent: Wednesday, October 25, 2023 1:02 PM
> > To: Borah, Chaitanya Kumar 
> > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > ; Saarinen, Jani
> > 
> > Subject: Re: Regression on linux-next (next-20231013)
> >
> > On Wed, Oct 25, 2023 at 06:32:01AM +, Borah, Chaitanya Kumar wrote:
> > >  Hello Christian,
> > >
> > >  Hope you are doing well. I am Chaitanya from the linux graphics
> > > team in
> > Intel.
> > >
> > >  This mail is regarding a regression we are seeing in our CI runs[1]
> > > on linux-next  repository.
> >
> > Any chance I can reproduce this locally?
> 
> Thank you for your response.
> 
> I see that you have already floated a patch [1] to fix the issue. We will 
> test it
> and get back to you ASAP.

The solution is working for us.

Also, linux-next turned green.

http://gfx-ci.igk.intel.com/tree/linux-next/igt@i915_selftest@l...@mman.html

Thank you.

Regards

Chaitanya

> 
> In case, you still need it.
> 
> If you happen to have a device with intel CPU on it (we are seeing it in
> machines as old as Gen3[2]), you can follow the below steps.
> 
> 1. Get the latest drm-tip from https://cgit.freedesktop.org/drm-tip/ and 
> install
> it on the machine
> 
> 2. Get IGT suite from https://gitlab.freedesktop.org/drm/igt-gpu-tools
> 
> 3. Build the test suite
> You can use the instructions in the README.md file for building the suite.
> 
> We use ubuntu and I generally do the following
> 
>   a) Make sure the packages listed in Dockerfile.build-debian-minimal
> and Dockerfile.build-debian are installed.
>   b) meson build && ninja -C build
> 
> 4. If everything goes fine, there should be a "build" folder created within 
> the
> base folder of your repository
> Then run the test using the following command.
> 
>   sudo build/tests/i915_selftest --run-subtest live
> 
> Regards
> 
> Chaitanya
> 
> 
> [1] https://lore.kernel.org/intel-gfx/20231025-formfrage-watscheln-
> 84526cd3bd7d@brauner/
> [2] http://gfx-ci.igk.intel.com/tree/linux-
> next/igt@i915_selftest@l...@mman.html



[Intel-gfx] [CI 2/2] drm/i915: move Makefile display debugfs files next to display

2023-10-26 Thread Jani Nikula
Keep the display build lists together.

v2: Rebase

Reviewed-by: Nirmoy Das 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d1f53dbf95f2..239da40a401f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -95,10 +95,7 @@ i915-$(CONFIG_COMPAT) += \
i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += \
i915_debugfs.o \
-   i915_debugfs_params.o \
-   display/intel_display_debugfs.o \
-   display/intel_display_debugfs_params.o \
-   display/intel_pipe_crc.o
+   i915_debugfs_params.o
 i915-$(CONFIG_PERF_EVENTS) += \
i915_pmu.o
 
@@ -320,6 +317,10 @@ i915-$(CONFIG_ACPI) += \
display/intel_opregion.o
 i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
display/intel_fbdev.o
+i915-$(CONFIG_DEBUG_FS) += \
+   display/intel_display_debugfs.o \
+   display/intel_display_debugfs_params.o \
+   display/intel_pipe_crc.o
 
 # modesetting output/encoder code
 i915-y += \
-- 
2.39.2



[Intel-gfx] [CI 1/2] drm/i915: fix Makefile sort and indent

2023-10-26 Thread Jani Nikula
Unify the line continuations and indents, and sort the build lists.

Reviewed-by: Nirmoy Das 
Signed-off-by: Jani Nikula 

---

Note: This is easiest to review by applying and looking at 'git show -w'
---
 drivers/gpu/drm/i915/Makefile | 169 ++
 1 file changed, 89 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3b9dcb606fc1..d1f53dbf95f2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -47,33 +47,34 @@ subdir-ccflags-y += -I$(srctree)/$(src)
 # Please keep these build lists sorted!
 
 # core driver code
-i915-y += i915_driver.o \
- i915_drm_client.o \
- i915_config.o \
- i915_getparam.o \
- i915_ioctl.o \
- i915_irq.o \
- i915_mitigations.o \
- i915_module.o \
- i915_params.o \
- i915_pci.o \
- i915_scatterlist.o \
- i915_suspend.o \
- i915_switcheroo.o \
- i915_sysfs.o \
- i915_utils.o \
- intel_clock_gating.o \
- intel_device_info.o \
- intel_memory_region.o \
- intel_pcode.o \
- intel_region_ttm.o \
- intel_runtime_pm.o \
- intel_sbi.o \
- intel_step.o \
- intel_uncore.o \
- intel_wakeref.o \
- vlv_sideband.o \
- vlv_suspend.o
+i915-y += \
+   i915_config.o \
+   i915_driver.o \
+   i915_drm_client.o \
+   i915_getparam.o \
+   i915_ioctl.o \
+   i915_irq.o \
+   i915_mitigations.o \
+   i915_module.o \
+   i915_params.o \
+   i915_pci.o \
+   i915_scatterlist.o \
+   i915_suspend.o \
+   i915_switcheroo.o \
+   i915_sysfs.o \
+   i915_utils.o \
+   intel_clock_gating.o \
+   intel_device_info.o \
+   intel_memory_region.o \
+   intel_pcode.o \
+   intel_region_ttm.o \
+   intel_runtime_pm.o \
+   intel_sbi.o \
+   intel_step.o \
+   intel_uncore.o \
+   intel_wakeref.o \
+   vlv_sideband.o \
+   vlv_suspend.o
 
 # core peripheral code
 i915-y += \
@@ -90,14 +91,16 @@ i915-y += \
i915_syncmap.o \
i915_user_extensions.o
 
-i915-$(CONFIG_COMPAT)   += i915_ioc32.o
+i915-$(CONFIG_COMPAT) += \
+   i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += \
i915_debugfs.o \
i915_debugfs_params.o \
display/intel_display_debugfs.o \
display/intel_display_debugfs_params.o \
display/intel_pipe_crc.o
-i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
+i915-$(CONFIG_PERF_EVENTS) += \
+   i915_pmu.o
 
 # "Graphics Technology" (aka we talk to the gpu)
 gt-y += \
@@ -154,7 +157,8 @@ gt-y += \
gt/sysfs_engines.o
 
 # x86 intel-gtt module support
-gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
+gt-$(CONFIG_X86) += \
+   gt/intel_ggtt_gmch.o
 # autogenerated null render state
 gt-y += \
gt/gen6_renderstate.o \
@@ -173,9 +177,9 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer.o \
gem/i915_gem_internal.o \
-   gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
gem/i915_gem_mman.o \
+   gem/i915_gem_object.o \
gem/i915_gem_pages.o \
gem/i915_gem_phys.o \
gem/i915_gem_pm.o \
@@ -192,57 +196,61 @@ gem-y += \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
 i915-y += \
- $(gem-y) \
- i915_active.o \
- i915_cmd_parser.o \
- i915_deps.o \
- i915_gem_evict.o \
- i915_gem_gtt.o \
- i915_gem_ww.o \
- i915_gem.o \
- i915_query.o \
- i915_request.o \
- i915_scheduler.o \
- i915_trace_points.o \
- i915_ttm_buddy_manager.o \
- i915_vma.o \
- i915_vma_resource.o
+   $(gem-y) \
+   i915_active.o \
+   i915_cmd_parser.o \
+   i915_deps.o \
+   i915_gem.o \
+   i915_gem_evict.o \
+   i915_gem_gtt.o \
+   i915_gem_ww.o \
+   i915_query.o \
+   i915_request.o \
+   i915_scheduler.o \
+   i915_trace_points.o \
+   i915_ttm_buddy_manager.o \
+   i915_vma.o \
+   i915_vma_resource.o
 
 # general-purpose microcontroller (GuC) support
 i915-y += \
- gt/uc/intel_gsc_fw.o \
- gt/uc/intel_gsc_proxy.o \
- gt/uc/intel_gsc_uc.o \
- gt/uc/intel_gsc_uc_debugfs.o \
- gt/uc/intel_gsc_uc_heci_cmd_submit.o \
- gt/uc/intel_guc.o \
- gt/uc/intel_guc_ads.o \
- gt/uc/intel_guc_capture.o \
- gt/uc/intel_guc_ct.o \
- gt/uc/intel_guc_debugfs.o \
- gt/uc/intel_guc_fw.o \
- gt/uc/intel_guc_hwconfig.o \
- gt/uc/intel_guc_log.o \
- gt/uc/intel_guc_log_debugfs.o \
- gt/uc/intel_guc_rc.o \
- gt/uc/intel_guc_slpc.o \
- gt/uc/intel_guc_submission.o \
- gt/uc/intel_huc.o \
- gt/uc/intel_huc_debugfs.o \
- gt/uc/intel_huc_fw.o \
- gt/uc/intel_uc.o \
- 

Re: [Intel-gfx] [PATCH v2] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init

2023-10-26 Thread Imre Deak
On Thu, Oct 26, 2023 at 12:05:13PM +0300, Imre Deak wrote:
> On Wed, Oct 25, 2023 at 07:08:34PM +0200, Nirmoy Das wrote:
> > Fix below compiler warning:
> > 
> > intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
> > writing between 1 and 11 bytes into a region of size 3
> > [-Werror=format-truncation=]
> > "%c/TC#%d", port_name(port), tc_port + 1);
> >^~
> > intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
> > into a destination of size 8
> >   snprintf(tc->port_name, sizeof(tc->port_name),
> >   ^~
> > "%c/TC#%d", port_name(port), tc_port + 1);
> > ~
> > 
> > v2: use kasprintf(Imre)
> > 
> > Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new 
> > intel_tc_port struct")
> > Cc: Mika Kahola 
> > Cc: Imre Deak 
> > Cc: Jani Nikula 
> > Signed-off-by: Nirmoy Das 
> 
> Reviewed-by: Imre Deak 
> 
> Nit: port_name could be const.
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_tc.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index 37b0f8529b4f..0fa54450d51b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -58,7 +58,7 @@ struct intel_tc_port {
> > struct delayed_work link_reset_work;
> > int link_refcount;
> > bool legacy_port:1;
> > -   char port_name[8];
> > +   char *port_name;
> > enum tc_port_mode mode;
> > enum tc_port_mode init_mode;
> > enum phy_fia phy_fia;
> > @@ -1875,8 +1875,10 @@ int intel_tc_port_init(struct intel_digital_port 
> > *dig_port, bool is_legacy)
> > else
> > tc->phy_ops = _tc_phy_ops;
> >  
> > -   snprintf(tc->port_name, sizeof(tc->port_name),
> > -"%c/TC#%d", port_name(port), tc_port + 1);
> > +   tc->port_name = kasprintf(GFP_KERNEL, "%c/TC#%d", port_name(port),
> > + tc_port + 1);
> > +   if (!tc->port_name)
> > +   return -ENOMEM;

Missed it, but this needs to free tc;

> >  
> > mutex_init(>lock);
> > /* TODO: Combine the two works */
> > @@ -1897,6 +1899,7 @@ void intel_tc_port_cleanup(struct intel_digital_port 
> > *dig_port)
> >  {
> > intel_tc_port_suspend(dig_port);
> >  
> > +   kfree(dig_port->tc->port_name);
> > kfree(dig_port->tc);
> > dig_port->tc = NULL;
> >  }
> > -- 
> > 2.41.0
> > 


Re: [Intel-gfx] [PATCH 2/3] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Jani Nikula
On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
> Let's create a blanket function which just has some conditions
> which need to be checked before connectors enable hdcp.
> This cleans up code and avoids code duplication.

This series has two 2/3 patches... confused me, probably going to
confuse CI too...

BR,
Jani.


>
> --v3
> -Keep function name as intel_hdcp_enable() [Jani]
>
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
>  drivers/gpu/drm/i915/display/intel_hdcp.c   | 21 -
>  drivers/gpu/drm/i915/display/intel_hdcp.h   |  8 
>  4 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 9151d5add960..b644cf981846 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
> *state,
>   else
>   intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
>  
> - /* Enable hdcp if it's desired */
> - if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> + 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 7b4628f4f124..4366da79fe81 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct 
> intel_atomic_state *state,
>  
>   intel_audio_codec_enable(encoder, pipe_config, conn_state);
>  
> - /* Enable hdcp if it's desired */
> - if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(state, encoder, pipe_config, conn_state);
> + 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 7c0cfcb48521..44c0a93f3af8 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -2324,10 +2324,10 @@ intel_hdcp_set_streams(struct intel_digital_port 
> *dig_port,
>   return 0;
>  }
>  
> -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)
> +static 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 *i915 = to_i915(encoder->base.dev);
>   struct intel_connector *connector =
> @@ -2404,6 +2404,17 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
>   return ret;
>  }
>  
> +void intel_hdcp_enable(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +const struct drm_connector_state *conn_state)
> +{
> + /* Enable hdcp if it's desired */
> + if (conn_state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_DESIRED)
> + _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> +}
> +
>  int intel_hdcp_disable(struct intel_connector *connector)
>  {
>   struct intel_digital_port *dig_port = 
> intel_attached_dig_port(connector);
> @@ -2491,7 +2502,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state 
> *state,
>   }
>  
>   if (desired_and_not_enabled || content_protection_type_changed)
> - intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> + _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
>  }
>  
>  void intel_hdcp_component_fini(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
> b/drivers/gpu/drm/i915/display/intel_hdcp.h
> index 5997c52a0958..a9c784fd9ba5 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> @@ -28,10 +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_atomic_state 

Re: [Intel-gfx] [PATCH v2] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-26 Thread Hogander, Jouni
On Wed, 2023-10-25 at 17:18 +0300, Ville Syrjälä wrote:
> On Fri, Oct 20, 2023 at 12:41:03PM +0300, Jouni Högander wrote:
> > We are preparing for Xe driver. Xe driver doesn't have
> > i915_sw_fence
> > implementation. Lets drop i915_sw_fence usage from display code and
> > use dma_fence interfaces directly.
> > 
> > For this purpose stack dma fences from related objects into new
> > plane
> > state. Drm_gem_plane_helper_prepare_fb can be used for fences in
> > new
> > fb. Separate local implementation is used for Stacking fences from
> > old fb
> > into new plane state. Then wait for these stacked fences during
> > atomic
> > commit. There is no be need for separate GPU reset handling in
> > intel_atomic_commit_fence_wait as the fences are signaled when GPU
> > hang is
> > detected and GPU is being reset.
> > 
> > v2:
> >   - Add fences from old fb into new_plane_state->uapi.fence rather
> > than
> >     into old_plane_state->uapi.fence
> > 
> > Cc: Ville Syrjälä 
> > Cc: Maarten Lankhorst 
> > Cc: José Roberto de Souza 
> > 
> > Signed-off-by: Jouni Högander 
> > Reviewed-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
> >  .../gpu/drm/i915/display/intel_atomic_plane.c | 89 +++
> > 
> >  drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
> > -
> >  .../drm/i915/display/intel_display_types.h    |  2 -
> >  4 files changed, 77 insertions(+), 95 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index 5d18145da279..ec0d5168b503 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct
> > drm_atomic_state *_state)
> >  
> > drm_atomic_state_default_release(>base);
> > kfree(state->global_objs);
> > -
> > -   i915_sw_fence_fini(>commit_ready);
> > -
> > kfree(state);
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index b1074350616c..20fd12df6850 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -31,7 +31,10 @@
> >   * prepare/check/commit/cleanup steps.
> >   */
> >  
> > +#include 
> > +
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -1012,6 +1015,44 @@ int intel_plane_check_src_coordinates(struct
> > intel_plane_state *plane_state)
> > return 0;
> >  }
> >  
> > +static int add_fences(struct dma_resv *obj,
> > + struct drm_plane_state *dst)
> 
> I would name things differently:
> s/obj/resv/
> s/dst/plane_state/
> 
> The function name should probably be a bit more 
> descriptive as well.
> 
> > +{
> > +   struct dma_fence *fence = dma_fence_get(dst->fence);
> > +   enum dma_resv_usage usage;
> > +   struct dma_fence *new;
> > +   int ret;
> > +
> > +   usage = fence ? DMA_RESV_USAGE_KERNEL :
> > DMA_RESV_USAGE_WRITE;
> > +
> > +   ret = dma_resv_get_singleton(obj, usage, );
> > +   if (ret)
> > +   goto error;
> > +
> > +   if (new && fence) {
> > +   struct dma_fence_chain *chain =
> > dma_fence_chain_alloc();
> > +
> > +   if (!chain) {
> > +   ret = -ENOMEM;
> > +   goto error;
> > +   }
> > +
> > +   dma_fence_chain_init(chain, fence, new, 1);
> > +   fence = >base;
> > +
> > +   } else if (new) {
> > +   fence = new;
> > +   }
> > +
> > +   dma_fence_put(dst->fence);
> > +   dst->fence = fence;
> > +   return 0;
> > +
> > +error:
> > +   dma_fence_put(fence);
> > +   return ret;
> > +}
> > +
> >  /**
> >   * intel_prepare_plane_fb - Prepare fb for usage on plane
> >   * @_plane: drm plane to prepare for
> > @@ -1035,7 +1076,7 @@ intel_prepare_plane_fb(struct drm_plane
> > *_plane,
> > struct intel_atomic_state *state =
> > to_intel_atomic_state(new_plane_state->uapi.state);
> > struct drm_i915_private *dev_priv = to_i915(plane-
> > >base.dev);
> > -   const struct intel_plane_state *old_plane_state =
> > +   struct intel_plane_state *old_plane_state =
> > intel_atomic_get_old_plane_state(state, plane);
> > struct drm_i915_gem_object *obj =
> > intel_fb_obj(new_plane_state->hw.fb);
> > struct drm_i915_gem_object *old_obj =
> > intel_fb_obj(old_plane_state->hw.fb);
> > @@ -1057,56 +1098,30 @@ intel_prepare_plane_fb(struct drm_plane
> > *_plane,
> >  * This should only fail upon a hung GPU, in which
> > case we
> >  * can safely continue.
> >  */
> > -   if (new_crtc_state &&
> > intel_crtc_needs_modeset(new_crtc_state)) {
> > -   ret =
> > 

[Intel-gfx] [PATCH 3/3] drm/i915/hdcp: Add more conditions to enable hdcp

2023-10-26 Thread Suraj Kandpal
When we dock a monitor we end up with a enable and disable connector
cycle but if hdcp content is running we get the userspace in
enabled state and driver maintaining a undesired state which causes
the content to stop playing and we only enabe hdcp if the userspace
state in desired. This patch fixes that.

--v2
-Move code to intel_hdcp [Jani]

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 44c0a93f3af8..39b3f7c0c77c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2409,9 +2409,19 @@ void intel_hdcp_enable(struct intel_atomic_state *state,
   const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state)
 {
-   /* Enable hdcp if it's desired */
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
+   struct intel_hdcp *hdcp = >hdcp;
+
+   /*
+* Enable hdcp if it's desired or if userspace is enabled and
+* driver set its state to undesired
+*/
if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+   (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_ENABLED && hdcp->value ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
_intel_hdcp_enable(state, encoder, crtc_state, conn_state);
 }
 
-- 
2.25.1



[Intel-gfx] [PATCH 2/3] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Suraj Kandpal
Let's create a blanket function which just has some conditions
which need to be checked before connectors enable hdcp.
This cleans up code and avoids code duplication.

--v3
-Keep function name as intel_hdcp_enable() [Jani]

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 21 -
 drivers/gpu/drm/i915/display/intel_hdcp.h   |  8 
 4 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9151d5add960..b644cf981846 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
else
intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+   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 7b4628f4f124..4366da79fe81 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
 
intel_audio_codec_enable(encoder, pipe_config, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
+   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 7c0cfcb48521..44c0a93f3af8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2324,10 +2324,10 @@ intel_hdcp_set_streams(struct intel_digital_port 
*dig_port,
return 0;
 }
 
-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)
+static 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 *i915 = to_i915(encoder->base.dev);
struct intel_connector *connector =
@@ -2404,6 +2404,17 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
return ret;
 }
 
+void intel_hdcp_enable(struct intel_atomic_state *state,
+  struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
+{
+   /* Enable hdcp if it's desired */
+   if (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+}
+
 int intel_hdcp_disable(struct intel_connector *connector)
 {
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
@@ -2491,7 +2502,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state 
*state,
}
 
if (desired_and_not_enabled || content_protection_type_changed)
-   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+   _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
 }
 
 void intel_hdcp_component_fini(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 5997c52a0958..a9c784fd9ba5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -28,10 +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_atomic_state *state,
- struct intel_encoder *encoder,
- const struct intel_crtc_state *pipe_config,
- const struct drm_connector_state *conn_state);
+void intel_hdcp_enable(struct intel_atomic_state *state,
+  struct 

[Intel-gfx] [PATCH 1/3] drm/i915/hdcp: Rename HCDP 1.4 enablement function

2023-10-26 Thread Suraj Kandpal
Rename hdcp 1.4 enablement function from _intel_hdcp_enable to
intel_hdcp1_enable to better represent what version of hdcp is
being enabled

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c89da3568ebd..7c0cfcb48521 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -923,7 +923,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
return 0;
 }
 
-static int _intel_hdcp_enable(struct intel_connector *connector)
+static int intel_hdcp1_enable(struct intel_connector *connector)
 {
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
@@ -1058,7 +1058,7 @@ static int intel_hdcp_check_link(struct intel_connector 
*connector)
goto out;
}
 
-   ret = _intel_hdcp_enable(connector);
+   ret = intel_hdcp1_enable(connector);
if (ret) {
drm_err(>drm, "Failed to enable hdcp (%d)\n", ret);
intel_hdcp_update_value(connector,
@@ -2388,7 +2388,7 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
 */
if (ret && intel_hdcp_capable(connector) &&
hdcp->content_type != DRM_MODE_HDCP_CONTENT_TYPE1) {
-   ret = _intel_hdcp_enable(connector);
+   ret = intel_hdcp1_enable(connector);
}
 
if (!ret) {
-- 
2.25.1



[Intel-gfx] [PATCH 0/3] drm/i915/hdcp: Additional conditions to enable hdcp

2023-10-26 Thread Suraj Kandpal
We are seeing a issue when we close the lid of a laptop or dock a
monitor hdcp content is not being reenabled automatically this is
because when we dock a monitor we end up with a enable and
disable connector cycle but if hdcp content is running we get the
userspace in enabled state and driver maintaining a undesired
state which causes the content to stop playing and we only enabe
hdcp if the userspace state in desired.
This first and second patch refactors the code while the third one adds the
new conditions to enable hdcp.

Signed-off-by: Suraj Kandpal 

Suraj Kandpal (3):
  drm/i915/hdcp: Rename HCDP 1.4 enablement function
  drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function
  drm/i915/hdcp: Add more conditions to enable hdcp

 drivers/gpu/drm/i915/display/intel_ddi.c|  5 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +--
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 37 -
 drivers/gpu/drm/i915/display/intel_hdcp.h   |  8 ++---
 4 files changed, 35 insertions(+), 20 deletions(-)

-- 
2.25.1



[Intel-gfx] [PATCH 2/3] drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function

2023-10-26 Thread Suraj Kandpal
Let's convert intel_hdcp_enable to a blanket function
which just has some conditions which needs to be checked
before connectors enable hdcp.
This cleans up code and avoids code duplication.

--v3
-Keep function name as intel_hdcp_enable() [Jani]

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 21 -
 drivers/gpu/drm/i915/display/intel_hdcp.h   |  8 
 4 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9151d5add960..b644cf981846 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
else
intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+   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 7b4628f4f124..4366da79fe81 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
 
intel_audio_codec_enable(encoder, pipe_config, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
+   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 7c0cfcb48521..44c0a93f3af8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2324,10 +2324,10 @@ intel_hdcp_set_streams(struct intel_digital_port 
*dig_port,
return 0;
 }
 
-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)
+static 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 *i915 = to_i915(encoder->base.dev);
struct intel_connector *connector =
@@ -2404,6 +2404,17 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
return ret;
 }
 
+void intel_hdcp_enable(struct intel_atomic_state *state,
+  struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
+{
+   /* Enable hdcp if it's desired */
+   if (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+}
+
 int intel_hdcp_disable(struct intel_connector *connector)
 {
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
@@ -2491,7 +2502,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state 
*state,
}
 
if (desired_and_not_enabled || content_protection_type_changed)
-   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+   _intel_hdcp_enable(state, encoder, crtc_state, conn_state);
 }
 
 void intel_hdcp_component_fini(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 5997c52a0958..a9c784fd9ba5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -28,10 +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_atomic_state *state,
- struct intel_encoder *encoder,
- const struct intel_crtc_state *pipe_config,
- const struct drm_connector_state *conn_state);
+void intel_hdcp_enable(struct intel_atomic_state *state,
+

Re: [Intel-gfx] [PATCH] file, i915: fix file reference for mmap_singleton()

2023-10-26 Thread Tvrtko Ursulin



On 25/10/2023 16:23, Jann Horn wrote:

On Wed, Oct 25, 2023 at 2:01 PM Christian Brauner  wrote:

Today we got a report at [1] for rcu stalls on the i915 testsuite in [2]
due to the conversion of files to SLAB_TYPSSAFE_BY_RCU. Afaict,
get_file_rcu() goes into an infinite loop trying to carefully verify
that i915->gem.mmap_singleton hasn't changed - see the splat below.

So I stared at this code to figure out what it actually does. It seems
that the i915->gem.mmap_singleton pointer itself never had rcu semantics.

The i915->gem.mmap_singleton is replaced in
file->f_op->release::singleton_release():

 static int singleton_release(struct inode *inode, struct file *file)
 {
 struct drm_i915_private *i915 = file->private_data;

 cmpxchg(>gem.mmap_singleton, file, NULL);
 drm_dev_put(>drm);

 return 0;
 }

The cmpxchg() is ordered against a concurrent update of
i915->gem.mmap_singleton from mmap_singleton(). IOW, when
mmap_singleton() fails to get a reference on i915->gem.mmap_singleton
via mmap_singleton():

 rcu_read_lock();
 file = get_file_rcu(>gem.mmap_singleton);
 rcu_read_unlock();

mmap_singleton() allocates a new file via anon_inode_getfile() and does

 smp_store_mb(i915->gem.mmap_singleton, file);

So, afaiu, then what happens in the case of this bug is that at some
point fput() is called and drops the file->f_count to zero but obviously
leaving the pointer in i915->gem.mmap_singleton in tact until
file->f_op->release::singleton_release() is called.

Now, there might be possibly larger delays until
file->f_op->release::singleton_release() is called and
i915->gem.mmap_singleton is set to NULL?

Say concurrently another task hits mmap_singleton() and does:

 rcu_read_lock();
 file = get_file_rcu(>gem.mmap_singleton);
 rcu_read_unlock();

When get_file_rcu() fails to get a reference via atomic_inc_not_zero()
it will try the reload from i915->gem.mmap_singleton assuming it has
comparable semantics as __fget_files_rcu() that also reloads on
atomic_inc_not_zero() failure.

But since i915->gem.mmap_singleton doesn't have proper rcu semantics it
reloads the same pointer again, trying the same atomic_inc_not_zero()
again and doing so until file->f_op->release::singleton_release() of the
old file has been called.

So, in contrast to __fget_files_rcu() here we want to not retry when
atomic_inc_not_zero() has failed. We only want to retry in case we
managed to get a reference but the pointer did change on reload.

[...]

Link: [1]: 
https://lore.kernel.org/intel-gfx/sj1pr11mb6129cb39eed831784c331bafb9...@sj1pr11mb6129.namprd11.prod.outlook.com
Link: [2]: 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231013/bat-dg2-11/igt@i915_selftest@l...@mman.html#dmesg-warnings10963
Signed-off-by: Christian Brauner 


Patch makes sense to me. I'm not sure why you changed EAGAIN to
EINVAL, and it's obviously a bit ugly, but it looks like a valid fix
for what the SLUB_TYPESAFE_BY_RCU conversion broke.

Reviewed-by: Jann Horn 


But as a side note, I am a bit confused about how the concurrency of
the existing code is supposed to work... it looks like two parallel
calls to mmap_singleton() can end up returning different pointers, and
then the singleton is not actually a singleton anymore? If that part
of the existing code is wrong even before the SLAB_TYPESAFE_BY_RCU
conversion, we might later have to open-code get_file_rcu() in
mmap_singleton(), so that we can do a cmpxchg at the end that checks
whether the i915->gem.mmap_singleton pointer is still the same?

Like:

static struct file *mmap_singleton(struct drm_i915_private *i915)
{
 struct file *file, *new_file;

 rcu_read_lock();
 file = READ_ONCE(i915->gem.mmap_singleton);
 if (file && atomic_long_inc_not_zero(>f_count)) {
 rcu_read_unlock();
 return file;
 }
 rcu_read_unlock();

 new_file = anon_inode_getfile("i915.gem", _fops,
i915, O_RDWR);
 if (IS_ERR(new_file))
 return new_file;

 /* Everyone shares a single global address space */
 new_file->f_mapping = i915->drm.anon_inode->i_mapping;

 if (try_cmpxchg(>gem.mmap_singleton, , new_file)) {
 // something with drm_dev refcount ?
 return new_file;
 }

 // something with drm_dev refcount ?
 fput(new_file);

 return file;
}

It would be nice to get some i915 maintainer's comment on how the
singleton stuff is supposed to work.


I see that the story has mostly been unraveled by now elsewhere in the 
thread, and yes, upon some historical digging and looking at the code I 
agree that the name singleton is confusing/misleading.


And although race can happen and we can end up with more than one 
anonymous inode, I don't think there is any real harm which would 
warrant complicating 

Re: [Intel-gfx] [PATCH v4 00/23] Framework for display parameters

2023-10-26 Thread Hogander, Jouni
On Tue, 2023-10-24 at 15:40 +0300, Jouni Högander wrote:
> Currently all module parameters are handled by i915_param.c/h. This
> is a problem for display parameters when Xe driver is used.
> 
> This patch set adds a mechanism to add parameters specific to the
> display. This is mainly copied from existing i915 parameters
> implementation with some naming changes and taking into account
> varying driver name.
> 
> Also all display specific module parameters are moved under display
> and the
> module parameter are all converted as non-writable. This should be ok
> as we have writable device parameters under debugfs.
> 
> v4:
>   - Change verbose_state_checks device parameter permissions to 0400
> 
> v3:
>   - Change enable_ip as boolean
>   - Fix enable_psr2_sel_fetch description
>   - Add default value into psr_safest_params description
>   - Drop unused predefinition (dentry) from
> intel_display_debugfs_params.h
> v2:
>   - Drop fastboot parameter
>   - Include display parameters into i915_capabilities debugfs
> interface

Thank you Luca, Jani and Tvrtko for checking my patches. These are all
now merged.

BR,

Jouni Högander
> 
> Cc: Jani Nikula 
> Cc: Uma Shankar 
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Vivi 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> Cc: Luca Coelho 
> 
> Jouni Högander (23):
>   drm/i915/display: Add framework to add parameters specific to
> display
>   drm/i915/display: Dump also display parameters
>   drm/i915/display: Move enable_fbc module parameter under display
>   drm/i915/display: Move psr related module parameters under display
>   drm/i915/display: Move vbt_firmware module parameter under display
>   drm/i915/display: Move lvds_channel_mode module parameter under
>     display
>   drm/i915/display: Move panel_use_ssc module parameter under display
>   drm/i915/display: Move vbt_sdvo_panel_type module parameter under
>     display
>   drm/i915/display: Move enable_dc module parameter under display
>   drm/i915/display: Move enable_dpt module parameter under display
>   drm/i915/display: Move enable_sagv module parameter under display
>   drm/i915/display: Move disable_power_well module parameter under
>     display
>   drm/i915/display: Move enable_ips module parameter under display
>   drm/i915/display: Move invert_brightness module parameter under
>     display
>   drm/i915/display: Move edp_vswing module parameter under display
>   drm/i915/display: Move enable_dpcd_backlight module parameter under
>     display
>   drm/i915/display: Move load_detect_test parameter under display
>   drm/i915/display: Move force_reset_modeset_test parameter under
>     display
>   drm/i915/display: Move disable_display parameter under display
>   drm/i915/display: Use device parameters instead of module in
>     I915_STATE_WARN
>   drm/i915/display: Move verbose_state_checks under display
>   drm/i915/display: Move nuclear_pageflip under display
>   drm/i915/display: Move enable_dp_mst under display
> 
>  drivers/gpu/drm/i915/Makefile |   2 +
>  drivers/gpu/drm/i915/display/hsw_ips.c    |   4 +-
>  drivers/gpu/drm/i915/display/i9xx_wm.c    |   2 +-
>  .../gpu/drm/i915/display/intel_backlight.c    |   9 +-
>  drivers/gpu/drm/i915/display/intel_bios.c |   6 +-
>  drivers/gpu/drm/i915/display/intel_crt.c  |   4 +-
>  drivers/gpu/drm/i915/display/intel_display.h  |   2 +-
>  .../gpu/drm/i915/display/intel_display_core.h |   2 +
>  .../drm/i915/display/intel_display_debugfs.c  |   2 +
>  .../display/intel_display_debugfs_params.c    | 176 ++
>  .../display/intel_display_debugfs_params.h    |  13 ++
>  .../drm/i915/display/intel_display_device.c   |  13 +-
>  .../drm/i915/display/intel_display_device.h   |   1 +
>  .../drm/i915/display/intel_display_params.c   | 217
> ++
>  .../drm/i915/display/intel_display_params.h   |  61 +
>  .../drm/i915/display/intel_display_power.c    |  14 +-
>  .../drm/i915/display/intel_display_reset.c    |   2 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   |   6 +-
>  .../drm/i915/display/intel_dp_aux_backlight.c |   4 +-
>  drivers/gpu/drm/i915/display/intel_dpt.c  |   6 +-
>  drivers/gpu/drm/i915/display/intel_fb.c   |   2 +-
>  drivers/gpu/drm/i915/display/intel_fbc.c  |  10 +-
>  drivers/gpu/drm/i915/display/intel_lvds.c |   4 +-
>  drivers/gpu/drm/i915/display/intel_opregion.c |   2 +-
>  drivers/gpu/drm/i915/display/intel_panel.c    |   4 +-
>  drivers/gpu/drm/i915/display/intel_psr.c  |  14 +-
>  .../drm/i915/display/skl_universal_plane.c    |   2 +-
>  drivers/gpu/drm/i915/display/skl_watermark.c  |   5 +-
>  drivers/gpu/drm/i915/i915_debugfs.c   |   3 +
>  drivers/gpu/drm/i915/i915_driver.c    |   2 +
>  drivers/gpu/drm/i915/i915_gpu_error.c |   3 +
>  drivers/gpu/drm/i915/i915_gpu_error.h |   2 +
>  drivers/gpu/drm/i915/i915_params.c    |  89 ---
>  drivers/gpu/drm/i915/i915_params.h    |  22 --
> 

Re: [Intel-gfx] [PATCH v2] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init

2023-10-26 Thread Imre Deak
On Wed, Oct 25, 2023 at 07:08:34PM +0200, Nirmoy Das wrote:
> Fix below compiler warning:
> 
> intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
> writing between 1 and 11 bytes into a region of size 3
> [-Werror=format-truncation=]
> "%c/TC#%d", port_name(port), tc_port + 1);
>^~
> intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
> into a destination of size 8
>   snprintf(tc->port_name, sizeof(tc->port_name),
>   ^~
> "%c/TC#%d", port_name(port), tc_port + 1);
> ~
> 
> v2: use kasprintf(Imre)
> 
> Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new intel_tc_port 
> struct")
> Cc: Mika Kahola 
> Cc: Imre Deak 
> Cc: Jani Nikula 
> Signed-off-by: Nirmoy Das 

Reviewed-by: Imre Deak 

Nit: port_name could be const.

> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 37b0f8529b4f..0fa54450d51b 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -58,7 +58,7 @@ struct intel_tc_port {
>   struct delayed_work link_reset_work;
>   int link_refcount;
>   bool legacy_port:1;
> - char port_name[8];
> + char *port_name;
>   enum tc_port_mode mode;
>   enum tc_port_mode init_mode;
>   enum phy_fia phy_fia;
> @@ -1875,8 +1875,10 @@ int intel_tc_port_init(struct intel_digital_port 
> *dig_port, bool is_legacy)
>   else
>   tc->phy_ops = _tc_phy_ops;
>  
> - snprintf(tc->port_name, sizeof(tc->port_name),
> -  "%c/TC#%d", port_name(port), tc_port + 1);
> + tc->port_name = kasprintf(GFP_KERNEL, "%c/TC#%d", port_name(port),
> +   tc_port + 1);
> + if (!tc->port_name)
> + return -ENOMEM;
>  
>   mutex_init(>lock);
>   /* TODO: Combine the two works */
> @@ -1897,6 +1899,7 @@ void intel_tc_port_cleanup(struct intel_digital_port 
> *dig_port)
>  {
>   intel_tc_port_suspend(dig_port);
>  
> + kfree(dig_port->tc->port_name);
>   kfree(dig_port->tc);
>   dig_port->tc = NULL;
>  }
> -- 
> 2.41.0
> 


Re: [Intel-gfx] [PATCH] drm/i915/gt: Remove {} from if-else

2023-10-26 Thread Andi Shyti
Hi Soumya,

On Wed, Oct 25, 2023 at 09:43:08PM -0700, Soumya Negi wrote:
> In accordance to Linux coding style(Documentation/process/4.Coding.rst),
> remove unneeded braces from if-else block as all arms of this block
> contain single statements.
> 
> Suggested-by: Andi Shyti 
> Signed-off-by: Soumya Negi 

Acked-by: Karolina Stolarek 
Reviewed-by: Andi Shyti 

Thanks,
Andi


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: Additional conditions to enable hdcp (rev2)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: Additional conditions to enable hdcp (rev2)
URL   : https://patchwork.freedesktop.org/series/125550/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13787 -> Patchwork_125550v2


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/index.html

Participating hosts (39 -> 37)
--

  Additional (1): bat-dg1-5 
  Missing(3): bat-dg2-9 bat-jsl-1 fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_125550v2 that come from known issues:

### CI changes ###

 Possible fixes 

  * boot:
- bat-adlp-11:[FAIL][1] ([i915#8293]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13787/bat-adlp-11/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-adlp-11/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][4] ([i915#4083])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][5] ([i915#4077]) +2 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][6] ([i915#4079]) +1 other test skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@gem_tiled_pread_basic.html
- bat-adlp-11:NOTRUN -> [SKIP][7] ([i915#3282])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-adlp-11/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][9] ([i915#4212]) +7 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#4215])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-11:NOTRUN -> [SKIP][11] ([i915#4103] / [i915#5608]) +1 
other test skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-dg1-5:  NOTRUN -> [SKIP][12] ([i915#4103] / [i915#4213]) +1 
other test skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-adlp-11:NOTRUN -> [SKIP][13] ([i915#3555] / [i915#3840])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-adlp-11/igt@kms_...@dsc-basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#3555] / [i915#3840])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([fdo#109285])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-11:NOTRUN -> [SKIP][16] ([i915#4093]) +3 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_hdmi_inject@inject-audio:
- bat-dg1-5:  NOTRUN -> [SKIP][17] ([i915#433])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-dg1-5/igt@kms_hdmi_inj...@inject-audio.html
- bat-adlp-11:NOTRUN -> [SKIP][18] ([i915#4369])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][19] ([i915#3546]) +2 other tests skip
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v2/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_psr@sprite_plane_onoff:
- bat-dg1-5:  NOTRUN -> [SKIP][20] ([i915#1072] / [i915#4078]) +3 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/hdcp: Additional conditions to enable hdcp (rev2)

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: Additional conditions to enable hdcp (rev2)
URL   : https://patchwork.freedesktop.org/series/125550/
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 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Remove {} from if-else

2023-10-26 Thread Karolina Stolarek



On 26.10.2023 06:43, Soumya Negi wrote:

In accordance to Linux coding style(Documentation/process/4.Coding.rst),
remove unneeded braces from if-else block as all arms of this block
contain single statements.


I'd just keep the description simple, and say that braces are not needed
for single line statements.

The patch looks fine to me. Andi, if you decide to merge it, feel free
to add my ack.

While we're here, I wanted briefly discuss how to construct To and CC
when working on i915 code. These are not hard rules (and some developers
might disagree with me), but suggestions on how to get the right people
look at your code and reduce the noise (decided to drop maintainers;
they'll be able to join the conversation from their subscription to ML)

First of all, if you work on something in i915 that only touches this
driver, you should submit it to intel-gfx, and there's no need to
include dri-devel. You can, but that mailing list is mostly used for
changes that are either for DRM or impact other drivers.

Secondly, try to include only people who are directly involved and
potential reviewers. You can CC maintainers for bigger changes that
require their involvement, but here, it's enough to include Andi, myself
and someone who added this piece of code.

So, if it was my patch, I'd have intel-gfx in To: and Andi, Prathap and
myself in Cc:. get_maintainer.pl script might've added a lot more people
there, so I'd move away from using it, and only include developers that
are involved or interested in your work. You can always reach out to
Andi and me before sending your patches, if you have any doubts.

All the best,
Karolina



Suggested-by: Andi Shyti 
Signed-off-by: Soumya Negi 
---
  drivers/gpu/drm/i915/gt/intel_ggtt.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1c93e84278a0..9f6f9e138532 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -226,16 +226,15 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
gen8_ggtt_invalidate(ggtt);
  
  	list_for_each_entry(gt, >gt_list, ggtt_link) {

-   if (intel_guc_tlb_invalidation_is_available(>uc.guc)) {
+   if (intel_guc_tlb_invalidation_is_available(>uc.guc))
guc_ggtt_ct_invalidate(gt);
-   } else if (GRAPHICS_VER(i915) >= 12) {
+   else if (GRAPHICS_VER(i915) >= 12)
intel_uncore_write_fw(gt->uncore,
  GEN12_GUC_TLB_INV_CR,
  GEN12_GUC_TLB_INV_CR_INVALIDATE);
-   } else {
+   else
intel_uncore_write_fw(gt->uncore,
  GEN8_GTCR, GEN8_GTCR_INVALIDATE);
-   }
}
  }
  


Re: [Intel-gfx] [PATCH 1/2] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Jani Nikula
On Thu, 26 Oct 2023, "Kandpal, Suraj"  wrote:
>> -Original Message-
>> From: Jani Nikula 
>> Sent: Thursday, October 26, 2023 1:02 PM
>> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
>> Cc: Shankar, Uma ; Nautiyal, Ankit K
>> ; Kandpal, Suraj 
>> Subject: Re: [PATCH 1/2] drm/i915/hdcp: Create a blanket hdcp enable function
>> 
>> On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
>> > Let's create a blanket function which just has some conditions which
>> > need to be checked before connectors enable hdcp.
>> > This cleans up code and avoids code duplication.
>> 
>> Let's call that function intel_hdcp_enable(), and hide all the details inside
>> intel_hdcp.c. These are the only callers outside of intel_hdcp.c.
>
> Maybe the rename current intel_hdcp_enable() to something else as that also 
> is called in
> Intel_hdcp_update_pipe on which I wouldn't want these conditions to be 
> enforced.
> I thought of renaming the current intel_hdcp_enable() to _intel_hdcp_enable() 
> but that is already
> Being used as a function name to enable hdcp1.4
> So any suggestions what I can rename it to?

Please just call it intel_hdcp_enable(), and deal with the above
problems internally in intel_hdcp.c. Don't leak the problems outside of
intel_hdcp.c.

BR,
Jani.

>
> Regards,
> Suraj Kandpal
>> 
>> BR,
>> Jani.
>> 
>> >
>> > Signed-off-by: Suraj Kandpal 
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
>> >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
>> >  drivers/gpu/drm/i915/display/intel_hdcp.c   | 11 +++
>> >  drivers/gpu/drm/i915/display/intel_hdcp.h   |  4 
>> >  4 files changed, 17 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>> > b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > index 9151d5add960..338049b66e9c 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > @@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct
>> intel_atomic_state *state,
>> >else
>> >intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
>> >
>> > -  /* Enable hdcp if it's desired */
>> > -  if (conn_state->content_protection ==
>> > -  DRM_MODE_CONTENT_PROTECTION_DESIRED)
>> > -  intel_hdcp_enable(state, encoder, crtc_state, conn_state);
>> > +  intel_hdcp_try_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 7b4628f4f124..cfcaf54a4a72 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> > @@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct
>> > intel_atomic_state *state,
>> >
>> >intel_audio_codec_enable(encoder, pipe_config, conn_state);
>> >
>> > -  /* Enable hdcp if it's desired */
>> > -  if (conn_state->content_protection ==
>> > -  DRM_MODE_CONTENT_PROTECTION_DESIRED)
>> > -  intel_hdcp_enable(state, encoder, pipe_config, conn_state);
>> > +  intel_hdcp_try_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 c89da3568ebd..9d632a85309d 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
>> > @@ -2324,6 +2324,17 @@ intel_hdcp_set_streams(struct intel_digital_port
>> *dig_port,
>> >return 0;
>> >  }
>> >
>> > +void intel_hdcp_try_enable(struct intel_atomic_state *state,
>> > + struct intel_encoder *encoder,
>> > + const struct intel_crtc_state *crtc_state,
>> > + const struct drm_connector_state *conn_state) {
>> > +  /* Enable hdcp if it's desired */
>> > +  if (conn_state->content_protection ==
>> > +  DRM_MODE_CONTENT_PROTECTION_DESIRED)
>> > +  intel_hdcp_enable(state, encoder, crtc_state, conn_state); }
>> > +
>> >  int intel_hdcp_enable(struct intel_atomic_state *state,
>> >  struct intel_encoder *encoder,
>> >  const struct intel_crtc_state *pipe_config, diff --git
>> > a/drivers/gpu/drm/i915/display/intel_hdcp.h
>> > b/drivers/gpu/drm/i915/display/intel_hdcp.h
>> > index 5997c52a0958..280eaa4d1010 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
>> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
>> > @@ -44,5 +44,9 @@ void intel_hdcp_component_init(struct
>> > drm_i915_private *i915);  void intel_hdcp_component_fini(struct
>> > drm_i915_private *i915);  void intel_hdcp_cleanup(struct
>> > intel_connector *connector);  void intel_hdcp_handle_cp_irq(struct
>> > intel_connector *connector);
>> > +void intel_hdcp_try_enable(struct intel_atomic_state *state,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Remove {} from if-else

2023-10-26 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Remove {} from if-else
URL   : https://patchwork.freedesktop.org/series/125614/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13787 -> Patchwork_125614v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/index.html

Participating hosts (39 -> 37)
--

  Additional (1): bat-dg1-5 
  Missing(3): bat-dg2-9 fi-snb-2520m fi-pnv-d510 

Known issues


  Here are the changes found in Patchwork_125614v1 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13787/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-jsl-1/boot.html

  
 Possible fixes 

  * boot:
- bat-adlp-11:[FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13787/bat-adlp-11/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-adlp-11/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][5] ([i915#9318])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][6] ([i915#4083])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][7] ([i915#4077]) +2 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][8] ([i915#4079]) +1 other test skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
- bat-adlp-11:NOTRUN -> [SKIP][9] ([i915#3282])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-adlp-11/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#6621])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][11] ([i915#4212]) +7 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][12] ([i915#4215])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-11:NOTRUN -> [SKIP][13] ([i915#4103] / [i915#5608]) +1 
other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#4103] / [i915#4213]) +1 
other test skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-adlp-11:NOTRUN -> [SKIP][15] ([i915#3555] / [i915#3840])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-adlp-11/igt@kms_...@dsc-basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][16] ([i915#3555] / [i915#3840])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5:  NOTRUN -> [SKIP][17] ([fdo#109285])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-11:NOTRUN -> [SKIP][18] ([i915#4093]) +3 other tests skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_hdmi_inject@inject-audio:
- bat-dg1-5:  NOTRUN -> [SKIP][19] ([i915#433])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-dg1-5/igt@kms_hdmi_inj...@inject-audio.html
- bat-adlp-11:NOTRUN -> [SKIP][20] ([i915#4369])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125614v1/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][21] ([i915#3546]) +2 other tests skip
 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Kandpal, Suraj



> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, October 26, 2023 1:02 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj 
> Subject: Re: [PATCH 1/2] drm/i915/hdcp: Create a blanket hdcp enable function
> 
> On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
> > Let's create a blanket function which just has some conditions which
> > need to be checked before connectors enable hdcp.
> > This cleans up code and avoids code duplication.
> 
> Let's call that function intel_hdcp_enable(), and hide all the details inside
> intel_hdcp.c. These are the only callers outside of intel_hdcp.c.

Maybe the rename current intel_hdcp_enable() to something else as that also is 
called in
Intel_hdcp_update_pipe on which I wouldn't want these conditions to be enforced.
I thought of renaming the current intel_hdcp_enable() to _intel_hdcp_enable() 
but that is already
Being used as a function name to enable hdcp1.4
So any suggestions what I can rename it to?

Regards,
Suraj Kandpal
> 
> BR,
> Jani.
> 
> >
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
> >  drivers/gpu/drm/i915/display/intel_hdcp.c   | 11 +++
> >  drivers/gpu/drm/i915/display/intel_hdcp.h   |  4 
> >  4 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 9151d5add960..338049b66e9c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> > else
> > intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
> >
> > -   /* Enable hdcp if it's desired */
> > -   if (conn_state->content_protection ==
> > -   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > -   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> > +   intel_hdcp_try_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 7b4628f4f124..cfcaf54a4a72 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct
> > intel_atomic_state *state,
> >
> > intel_audio_codec_enable(encoder, pipe_config, conn_state);
> >
> > -   /* Enable hdcp if it's desired */
> > -   if (conn_state->content_protection ==
> > -   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > -   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
> > +   intel_hdcp_try_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 c89da3568ebd..9d632a85309d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2324,6 +2324,17 @@ intel_hdcp_set_streams(struct intel_digital_port
> *dig_port,
> > return 0;
> >  }
> >
> > +void intel_hdcp_try_enable(struct intel_atomic_state *state,
> > +  struct intel_encoder *encoder,
> > +  const struct intel_crtc_state *crtc_state,
> > +  const struct drm_connector_state *conn_state) {
> > +   /* Enable hdcp if it's desired */
> > +   if (conn_state->content_protection ==
> > +   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > +   intel_hdcp_enable(state, encoder, crtc_state, conn_state); }
> > +
> >  int intel_hdcp_enable(struct intel_atomic_state *state,
> >   struct intel_encoder *encoder,
> >   const struct intel_crtc_state *pipe_config, diff --git
> > a/drivers/gpu/drm/i915/display/intel_hdcp.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp.h
> > index 5997c52a0958..280eaa4d1010 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> > @@ -44,5 +44,9 @@ void intel_hdcp_component_init(struct
> > drm_i915_private *i915);  void intel_hdcp_component_fini(struct
> > drm_i915_private *i915);  void intel_hdcp_cleanup(struct
> > intel_connector *connector);  void intel_hdcp_handle_cp_irq(struct
> > intel_connector *connector);
> > +void intel_hdcp_try_enable(struct intel_atomic_state *state,
> > +  struct intel_encoder *encoder,
> > +  const struct intel_crtc_state *crtc_state,
> > +  const struct drm_connector_state *conn_state);
> >
> >  #endif /* __INTEL_HDCP_H__ */
> 
> --
> Jani Nikula, Intel


Re: [Intel-gfx] [PATCH v3] drm/i915/dsb: DSB code refactoring

2023-10-26 Thread Luca Coelho
On Sun, 2023-10-08 at 15:42 +0530, Animesh Manna wrote:
> Refactor DSB implementation to be compatible with Xe driver.
> 
> v1: RFC version.
> v2: Make intel_dsb structure opaque from external usage. [Jani]
> v3: Rebased on latest.
> 
> Cc: Jani Nikula 
> Signed-off-by: Animesh Manna 
> ---

Looks great overall! Just a couple of small comments below.


[...]
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 3e32aa49b8eb..ec89d968a873 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -13,12 +13,13 @@
>  #include "intel_de.h"
>  #include "intel_display_types.h"
>  #include "intel_dsb.h"
> +#include "intel_dsb_buffer.h"
>  #include "intel_dsb_regs.h"
>  #include "intel_vblank.h"
>  #include "intel_vrr.h"
>  #include "skl_watermark.h"
>  
> -struct i915_vma;
> +#define CACHELINE_BYTES 64

I see that this macro is defined in GT and you want to avoid depending
on the definition from GT, but you don't make any other changes related
to the cacheline size here, so maybe this change should be a separate
patch? Also, it looks a bit magic without an explanation on where the
number is coming from.

 
[...]
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb_buffer.c 
> b/drivers/gpu/drm/i915/display/intel_dsb_buffer.c
> new file mode 100644
> index ..723937591831
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_dsb_buffer.c
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright 2023, Intel Corporation.
> + */
> +
> +#include "gem/i915_gem_internal.h"
> +#include "i915_drv.h"
> +#include "i915_vma.h"
> +#include "intel_display_types.h"
> +#include "intel_dsb_buffer.h"
> +
> +u32 intel_dsb_buffer_ggtt_offset(struct intel_dsb_buffer *dsb_buf)
> +{
> + return i915_ggtt_offset(dsb_buf->vma);
> +}
> +
> +void intel_dsb_buffer_write(struct intel_dsb_buffer *dsb_buf, u32 idx, u32 
> val)
> +{
> + dsb_buf->cmd_buf[idx] = val;
> +}
> +
> +u32 intel_dsb_buffer_read(struct intel_dsb_buffer *dsb_buf, u32 idx)
> +{
> + return dsb_buf->cmd_buf[idx];
> +}
> +
> +void intel_dsb_buffer_memset(struct intel_dsb_buffer *dsb_buf, u32 idx, u32 
> val, u32 sz)
> +{
> + memset(_buf->cmd_buf[idx], val, sz);

I think you should check the array boundaries here, to be sure. 
Probably a good idea to do with the other functions as well, but I
think this is the most critical and easiest to make mistakes with.

--
Cheers,
Luca.



Re: [Intel-gfx] [PATCH 1/2] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Jani Nikula
On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
> Let's create a blanket function which just has some conditions
> which need to be checked before connectors enable hdcp.
> This cleans up code and avoids code duplication.

Let's call that function intel_hdcp_enable(), and hide all the details
inside intel_hdcp.c. These are the only callers outside of intel_hdcp.c.

BR,
Jani.

>
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
>  drivers/gpu/drm/i915/display/intel_hdcp.c   | 11 +++
>  drivers/gpu/drm/i915/display/intel_hdcp.h   |  4 
>  4 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 9151d5add960..338049b66e9c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
> *state,
>   else
>   intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
>  
> - /* Enable hdcp if it's desired */
> - if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> + intel_hdcp_try_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 7b4628f4f124..cfcaf54a4a72 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct 
> intel_atomic_state *state,
>  
>   intel_audio_codec_enable(encoder, pipe_config, conn_state);
>  
> - /* Enable hdcp if it's desired */
> - if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(state, encoder, pipe_config, conn_state);
> + intel_hdcp_try_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 c89da3568ebd..9d632a85309d 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -2324,6 +2324,17 @@ intel_hdcp_set_streams(struct intel_digital_port 
> *dig_port,
>   return 0;
>  }
>  
> +void intel_hdcp_try_enable(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +const struct drm_connector_state *conn_state)
> +{
> + /* Enable hdcp if it's desired */
> + if (conn_state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_DESIRED)
> + intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> +}
> +
>  int intel_hdcp_enable(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config,
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
> b/drivers/gpu/drm/i915/display/intel_hdcp.h
> index 5997c52a0958..280eaa4d1010 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> @@ -44,5 +44,9 @@ void intel_hdcp_component_init(struct drm_i915_private 
> *i915);
>  void intel_hdcp_component_fini(struct drm_i915_private *i915);
>  void intel_hdcp_cleanup(struct intel_connector *connector);
>  void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
> +void intel_hdcp_try_enable(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +const struct drm_connector_state *conn_state);
>  
>  #endif /* __INTEL_HDCP_H__ */

-- 
Jani Nikula, Intel


[Intel-gfx] [PATCH 1/2] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Suraj Kandpal
Let's create a blanket function which just has some conditions
which need to be checked before connectors enable hdcp.
This cleans up code and avoids code duplication.

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 11 +++
 drivers/gpu/drm/i915/display/intel_hdcp.h   |  4 
 4 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9151d5add960..338049b66e9c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
else
intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+   intel_hdcp_try_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 7b4628f4f124..cfcaf54a4a72 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
 
intel_audio_codec_enable(encoder, pipe_config, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
+   intel_hdcp_try_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 c89da3568ebd..9d632a85309d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2324,6 +2324,17 @@ intel_hdcp_set_streams(struct intel_digital_port 
*dig_port,
return 0;
 }
 
+void intel_hdcp_try_enable(struct intel_atomic_state *state,
+  struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
+{
+   /* Enable hdcp if it's desired */
+   if (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
+}
+
 int intel_hdcp_enable(struct intel_atomic_state *state,
  struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 5997c52a0958..280eaa4d1010 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -44,5 +44,9 @@ void intel_hdcp_component_init(struct drm_i915_private *i915);
 void intel_hdcp_component_fini(struct drm_i915_private *i915);
 void intel_hdcp_cleanup(struct intel_connector *connector);
 void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
+void intel_hdcp_try_enable(struct intel_atomic_state *state,
+  struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state);
 
 #endif /* __INTEL_HDCP_H__ */
-- 
2.25.1



[Intel-gfx] [PATCH 2/2] drm/i915/hdcp: Add more conditions to enable hdcp

2023-10-26 Thread Suraj Kandpal
When we dock a monitor we end up with a enable and disable connector
cycle but if hdcp content is running we get the userspace in
enabled state and driver maintaining a undesired state which causes
the content to stop playing and we only enabe hdcp if the userspace
state in desired. This patch fixes that.

--v2
-Move code to intel_hdcp [Jani]

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 9d632a85309d..d67368b63c9f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2329,9 +2329,19 @@ void intel_hdcp_try_enable(struct intel_atomic_state 
*state,
   const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state)
 {
-   /* Enable hdcp if it's desired */
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
+   struct intel_hdcp *hdcp = >hdcp;
+
+   /*
+* Enable hdcp if it's desired or if userspace is enabled and
+* driver set its state to undesired
+*/
if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+   (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_ENABLED && hdcp->value ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
intel_hdcp_enable(state, encoder, crtc_state, conn_state);
 }
 
-- 
2.25.1



[Intel-gfx] [PATCH 0/2] drm/i915/hdcp: Additional conditions to enable hdcp

2023-10-26 Thread Suraj Kandpal
We are seeing a issue when we close the lid of a laptop or dock a
monitor hdcp content is not being reenabled automatically this is
because when we dock a monitor we end up with a enable and
disable connector cycle but if hdcp content is running we get the
userspace in enabled state and driver maintaining a undesired
state which causes the content to stop playing and we only enabe
hdcp if the userspace state in desired.
This first patch refactors the code while the second one adds the
new conditions to enable hdcp.

Signed-off-by: Suraj Kandpal 

Suraj Kandpal (2):
  drm/i915/hdcp: Create a blanket hdcp enable function
  drm/i915/hdcp: Add more conditions to enable hdcp

 drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 21 +
 drivers/gpu/drm/i915/display/intel_hdcp.h   |  4 
 4 files changed, 27 insertions(+), 8 deletions(-)

-- 
2.25.1