[Intel-gfx] [RFC PATCH 2/2] drm/i915/dp: Retry AUX requests 7 times.

[Khaled Almahallawy]

Given that intel_dp_aux_xfer retries 5 times, so configure drm_dpcd_access to 
retry only 7 times,
which means the max number of retries for i915 = 7 * 5 = 35 times.

Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index eaebf123310a..73d711a94000 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -688,5 +688,7 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
   encoder->base.name);
 
intel_dp->aux.transfer = intel_dp_aux_transfer;
+   /* Follow DP specs*/
+   intel_dp->aux.num_retries = 7;
cpu_latency_qos_add_request(&intel_dp->pm_qos, PM_QOS_DEFAULT_VALUE);
 }
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Khaled Almahallawy]

The number of AUX retries specified in the DP specs is 7. Currently, to make 
Dell 4k monitors happier, the number of retries are 32.
i915 also retries 5 times (intel_dp_aux_xfer) which means in the case of AUX 
timeout we actually retries 32 * 5 = 160 times.

So making the number of aux retires a variable to allow for fine tuning and 
optimization of aux timing.

Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 10 +++---
 include/drm/drm_dp_helper.h |  1 +
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..8fdf57b4a06c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -249,13 +249,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
 
mutex_lock(&aux->hw_mutex);
 
-   /*
-* The specification doesn't give any recommendation on how often to
-* retry native transactions. We used to retry 7 times like for
-* aux i2c transactions but real world devices this wasn't
-* sufficient, bump to 32 which makes Dell 4k monitors happier.
-*/
-   for (retry = 0; retry < 32; retry++) {
+   for (retry = 0; retry < aux->num_retries; retry++) {
if (ret != 0 && ret != -ETIMEDOUT) {
usleep_range(AUX_RETRY_INTERVAL,
 AUX_RETRY_INTERVAL + 100);
@@ -1744,6 +1738,8 @@ void drm_dp_aux_init(struct drm_dp_aux *aux)
aux->ddc.retries = 3;
 
aux->ddc.lock_ops = &drm_dp_i2c_lock_ops;
+   /*Still making the Dell 4k monitors happier*/
+   aux->num_retries = 32;
 }
 EXPORT_SYMBOL(drm_dp_aux_init);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index edffd1dcca3e..16cbfc8f5e66 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1876,6 +1876,7 @@ struct drm_dp_aux {
struct mutex hw_mutex;
struct work_struct crc_work;
u8 crc_count;
+   int num_retries;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
/**
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Add a check for object size for corner cases

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Add a check for object size for corner cases
URL   : https://patchwork.freedesktop.org/series/86934/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9755 -> Patchwork_19648


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  
 Possible fixes 

  * igt@gem_tiled_blits@basic:
- fi-tgl-y:   [DMESG-WARN][3] ([i915#402]) -> [PASS][4] +2 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/fi-tgl-y/igt@gem_tiled_bl...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/fi-tgl-y/igt@gem_tiled_bl...@basic.html

  
 Warnings 

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

  
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 38)
--

  Missing(6): fi-jsl-1 fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9755 -> Patchwork_19648

  CI-20190529: 20190529
  CI_DRM_9755: 4bf39002081ca59826f350c446106d2b2bef7e3a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19648: 881079e442266ac28a2bbd86e1c4e5bc008ab773 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

881079e44226 drm/i915/gem: Add a check for object size for corner cases

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/2] drm/dp: Make number of AUX retries 
configurable by display drivers.
URL   : https://patchwork.freedesktop.org/series/86937/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
9b605e7f6e6f drm/dp: Make number of AUX retries configurable by display drivers.
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
The number of AUX retries specified in the DP specs is 7. Currently, to make 
Dell 4k monitors happier, the number of retries are 32.

total: 0 errors, 1 warnings, 0 checks, 29 lines checked
011a4bcefd9a drm/i915/dp: Retry AUX requests 7 times.
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#6: 
Given that intel_dp_aux_xfer retries 5 times, so configure drm_dpcd_access to 
retry only 7 times,

total: 0 errors, 1 warnings, 0 checks, 7 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Thomas Zimmermann]

Hi

Am 10.02.21 um 09:33 schrieb Khaled Almahallawy:

The number of AUX retries specified in the DP specs is 7. Currently, to make 
Dell 4k monitors happier, the number of retries are 32.
i915 also retries 5 times (intel_dp_aux_xfer) which means in the case of AUX 
timeout we actually retries 32 * 5 = 160 times.

So making the number of aux retires a variable to allow for fine tuning and 
optimization of aux timing.

Signed-off-by: Khaled Almahallawy 
---
  drivers/gpu/drm/drm_dp_helper.c | 10 +++---
  include/drm/drm_dp_helper.h |  1 +
  2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..8fdf57b4a06c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -249,13 +249,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
  
  	mutex_lock(&aux->hw_mutex);
  
-	/*

-* The specification doesn't give any recommendation on how often to
-* retry native transactions. We used to retry 7 times like for
-* aux i2c transactions but real world devices this wasn't
-* sufficient, bump to 32 which makes Dell 4k monitors happier.
-*/
-   for (retry = 0; retry < 32; retry++) {
+   for (retry = 0; retry < aux->num_retries; retry++) {
if (ret != 0 && ret != -ETIMEDOUT) {
usleep_range(AUX_RETRY_INTERVAL,
 AUX_RETRY_INTERVAL + 100);
@@ -1744,6 +1738,8 @@ void drm_dp_aux_init(struct drm_dp_aux *aux)
aux->ddc.retries = 3;
  
  	aux->ddc.lock_ops = &drm_dp_i2c_lock_ops;

+   /*Still making the Dell 4k monitors happier*/


The original comment was helpful; this one isn't.

Besides that, what problem does this patchset address? Too much probing? 
If I connect a Dell monitor to an Intel card, how often does it have to 
probe?


Best regards
Thomas


+   aux->num_retries = 32;
  }
  EXPORT_SYMBOL(drm_dp_aux_init);
  
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h

index edffd1dcca3e..16cbfc8f5e66 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1876,6 +1876,7 @@ struct drm_dp_aux {
struct mutex hw_mutex;
struct work_struct crc_work;
u8 crc_count;
+   int num_retries;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
/**



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [RFC,1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/2] drm/dp: Make number of AUX retries 
configurable by display drivers.
URL   : https://patchwork.freedesktop.org/series/86937/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_m

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RFC,1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/2] drm/dp: Make number of AUX retries 
configurable by display drivers.
URL   : https://patchwork.freedesktop.org/series/86937/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9755 -> Patchwork_19649


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/fi-hsw-4770/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19649/fi-hsw-4770/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_flip@basic-flip-vs-dpms@a-dp2:
- fi-kbl-7500u:   [PASS][3] -> [DMESG-WARN][4] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/fi-kbl-7500u/igt@kms_flip@basic-flip-vs-d...@a-dp2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19649/fi-kbl-7500u/igt@kms_flip@basic-flip-vs-d...@a-dp2.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19649/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  
 Possible fixes 

  * igt@gem_tiled_blits@basic:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/fi-tgl-y/igt@gem_tiled_bl...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19649/fi-tgl-y/igt@gem_tiled_bl...@basic.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][9] ([i915#1372]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19649/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
 Warnings 

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

  
  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 40)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9755 -> Patchwork_19649

  CI-20190529: 20190529
  CI_DRM_9755: 4bf39002081ca59826f350c446106d2b2bef7e3a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19649: 011a4bcefd9a01da9d2488e946ada9d8bd53e6f0 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

011a4bcefd9a drm/i915/dp: Retry AUX requests 7 times.
9b605e7f6e6f drm/dp: Make number of AUX retries configurable by display drivers.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19649/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate clients by PID by default

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Implement a default view where clients are aggregated by their PID.

Toggled by pressing 'H' similar to top(1).

Signed-off-by: Tvrtko Ursulin 
---
 man/intel_gpu_top.rst |   1 +
 tools/intel_gpu_top.c | 109 +-
 2 files changed, 97 insertions(+), 13 deletions(-)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index b145d85c0440..20658e291db0 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -58,6 +58,7 @@ Supported keys:
 'n'Toggle display of numeric client busyness overlay.
 's'Toggle between sort modes (runtime, total runtime, pid, client id).
 'i'Toggle display of clients which used no GPU time.
+'H'Toggle between per PID aggregation and individual clients.
 
 DEVICE SELECTION
 
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 63ef77056341..018e28a66c10 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -979,17 +979,18 @@ static int client_pid_cmp(const void *_a, const void *_b)
 
 static int (*client_cmp)(const void *, const void *) = client_last_cmp;
 
-static void sort_clients(struct clients *clients)
+static struct clients *sort_clients(struct clients *clients,
+   int (*cmp)(const void *, const void *))
 {
unsigned int active, free;
struct client *c;
int tmp;
 
if (!clients)
-   return;
+   return clients;
 
qsort(clients->client, clients->num_clients, sizeof(*clients->client),
- client_cmp);
+ cmp);
 
/* Trim excessive array space. */
active = 0;
@@ -1011,9 +1012,76 @@ static void sort_clients(struct clients *clients)
  sizeof(*c));
}
}
+
+   return clients;
+}
+
+static struct clients *aggregated_clients(struct clients *clients)
+{
+   struct client *ac, *c, *cp = NULL;
+   struct clients *aggregated;
+   int tmp, num = 0;
+
+   /* Sort by pid first to make it easy to aggregate while walking. */
+   sort_clients(clients, client_pid_cmp);
+
+   aggregated = calloc(1, sizeof(*clients));
+   assert(aggregated);
+
+   ac = calloc(clients->num_clients, sizeof(*c));
+   assert(ac);
+
+   aggregated->num_classes = clients->num_classes;
+   aggregated->class = clients->class;
+   aggregated->client = ac;
+
+   for_each_client(clients, c, tmp) {
+   unsigned int i;
+
+   if (c->status == FREE)
+   break;
+
+   assert(c->status == ALIVE);
+
+   if ((cp && c->pid != cp->pid) || !cp) {
+   ac = &aggregated->client[num];
+
+   /* New pid. */
+   ac->clients = aggregated;
+   ac->status = ALIVE;
+   ac->id = ++num;
+   ac->pid = c->pid;
+   strcpy(ac->name, c->name);
+   strcpy(ac->print_name, c->print_name);
+   ac->engines = c->engines;
+   ac->val = calloc(clients->num_classes,
+sizeof(ac->val[0]));
+   assert(ac->val);
+   ac->samples = 1;
+   }
+
+   cp = c;
+
+   if (c->samples < 2)
+   continue;
+
+   ac->samples = 2; /* All what matters for display. */
+   ac->total_runtime += c->total_runtime;
+   ac->last_runtime += c->last_runtime;
+
+   for (i = 0; i < clients->num_classes; i++)
+   ac->val[i] += c->val[i];
+   }
+
+   aggregated->num_clients = num;
+   aggregated->active_clients = num;
+
+   return sort_clients(aggregated, client_cmp);
 }
 
-static void scan_clients(struct clients *clients)
+static bool aggregate_pids = true;
+
+static struct clients *scan_clients(struct clients *clients)
 {
struct dirent *dent;
struct client *c;
@@ -1022,7 +1090,7 @@ static void scan_clients(struct clients *clients)
DIR *d;
 
if (!clients)
-   return;
+   return clients;
 
for_each_client(clients, c, tmp) {
assert(c->status != PROBE);
@@ -1034,7 +1102,7 @@ static void scan_clients(struct clients *clients)
 
d = opendir(clients->sysfs_root);
if (!d)
-   return;
+   return clients;
 
while ((dent = readdir(d)) != NULL) {
char name[24], pid[24];
@@ -1077,7 +1145,10 @@ static void scan_clients(struct clients *clients)
break;
}
 
-   sort_clients(clients);
+   if (aggregate_pids)
+   return aggregated_clients(clients);
+   else
+   return sort_clients(clients, client_cmp);
 }
 
 static const char *bars[] =

[Intel-gfx] [PATCH i-g-t 1/3] intel_gpu_top: Wrap interactive header

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Slight improvement with regards to wrapping header components to fit
console width. If a single element is wider than max it can still
overflow but it should now work better for practical console widths.

Signed-off-by: Tvrtko Ursulin 
---
 tools/intel_gpu_top.c | 81 ---
 1 file changed, 68 insertions(+), 13 deletions(-)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 21084185d896..63ef77056341 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1461,6 +1461,41 @@ static bool print_groups(struct cnt_group **groups)
return print_data;
 }
 
+static int __attribute__ ((format(__printf__, 6, 7)))
+print_header_token(const char *cont, int lines, int con_w, int con_h, int *rem,
+  const char *fmt, ...)
+{
+   const char *indent = "\n   ";
+   char buf[256];
+   va_list args;
+   int ret;
+
+   if (lines >= con_h)
+   return lines;
+
+   va_start(args, fmt);
+   ret = vsnprintf(buf, sizeof(buf), fmt, args);
+   assert(ret < sizeof(buf));
+   va_end(args);
+
+   ret = (cont ? strlen(cont) : 0) + strlen(buf);
+   *rem -= ret;
+   if (*rem < 0) {
+   if (++lines >= con_h)
+   return lines;
+
+   *rem = con_w - ret - strlen(indent);
+   cont = indent;
+   }
+
+   if (cont)
+   ret = printf("%s%s", cont, buf);
+   else
+   ret = printf("%s", buf);
+
+   return lines;
+}
+
 static const char *header_msg;
 
 static int
@@ -1540,23 +1575,43 @@ print_header(const struct igt_device_card *card,
*consumed = print_groups(groups);
 
if (output_mode == INTERACTIVE) {
+   int rem = con_w;
+
printf("\033[H\033[J");
 
-   if (lines++ < con_h)
-   printf("intel-gpu-top: %s @ %s\n",
-  codename, card->card);
-   if (lines++ < con_h) {
-   printf("%s/%s MHz; %s%% RC6; ",
-  freq_items[1].buf, freq_items[0].buf,
-  rc6_items[0].buf);
-   if (engines->r_gpu.present) {
-   printf("%s/%s W; ",
-  power_items[0].buf,
-  power_items[1].buf);
-   }
-   printf("%s irqs/s\n", irq_items[0].buf);
+   lines = print_header_token(NULL, lines, con_w, con_h, &rem,
+  "intel-gpu-top:");
+
+   lines = print_header_token(" ", lines, con_w, con_h, &rem,
+  "%s", codename);
+
+   lines = print_header_token(" @ ", lines, con_w, con_h, &rem,
+  "%s", card->card);
+
+   lines = print_header_token(" - ", lines, con_w, con_h, &rem,
+  "%s/%s MHz",
+  freq_items[1].buf,
+  freq_items[0].buf);
+
+   lines = print_header_token("; ", lines, con_w, con_h, &rem,
+  "%s%% RC6",
+  rc6_items[0].buf);
+
+   if (engines->r_gpu.present) {
+   lines = print_header_token("; ", lines, con_w, con_h,
+  &rem,
+  "%s/%s W",
+  power_items[0].buf,
+  power_items[1].buf);
}
 
+   lines = print_header_token("; ", lines, con_w, con_h, &rem,
+  "%s irqs/s",
+  irq_items[0].buf);
+
+   if (lines++ < con_h)
+   printf("\n");
+
if (lines++ < con_h) {
if (header_msg) {
printf(" >>> %s\n", header_msg);
-- 
2.27.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 3/3] intel_gpu_top: Interactive help screen

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Show a list of supported interactive commands when pressing 'h'.

Signed-off-by: Tvrtko Ursulin 
---
 man/intel_gpu_top.rst |  1 +
 tools/intel_gpu_top.c | 68 ++-
 2 files changed, 61 insertions(+), 8 deletions(-)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index 20658e291db0..f6d74852558b 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -54,6 +54,7 @@ RUNTIME CONTROL
 Supported keys:
 
 'q'Exit from the tool.
+'h'Show interactive help.
 '1'Toggle between aggregated engine class and physical engine mode.
 'n'Toggle display of numeric client busyness overlay.
 's'Toggle between sort modes (runtime, total runtime, pid, client id).
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 018e28a66c10..c0e45ddb24e1 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -2255,19 +2255,31 @@ static void select_client_sort(void)
header_msg = cmp[client_sort].msg;
 }
 
-static void process_stdin(unsigned int timeout_us)
+static bool in_help;
+
+static void process_help_stdin(void)
 {
-   struct pollfd p = { .fd = 0, .events = POLLIN };
-   int ret;
+   for (;;) {
+   int ret;
+   char c;
 
-   ret = poll(&p, 1, timeout_us / 1000);
-   if (ret <= 0) {
-   if (ret < 0)
-   stop_top = true;
-   return;
+   ret = read(0, &c, 1);
+   if (ret <= 0)
+   break;
+
+   switch (c) {
+   case 'q':
+   case 'h':
+   in_help = false;
+   break;
+   };
}
+}
 
+static void process_normal_stdin(void)
+{
for (;;) {
+   int ret;
char c;
 
ret = read(0, &c, 1);
@@ -2298,6 +2310,9 @@ static void process_stdin(unsigned int timeout_us)
case 's':
select_client_sort();
break;
+   case 'h':
+   in_help = true;
+   break;
case 'H':
aggregate_pids ^= true;
if (aggregate_pids)
@@ -2309,6 +2324,38 @@ static void process_stdin(unsigned int timeout_us)
}
 }
 
+static void process_stdin(unsigned int timeout_us)
+{
+   struct pollfd p = { .fd = 0, .events = POLLIN };
+   int ret;
+
+   ret = poll(&p, 1, timeout_us / 1000);
+   if (ret <= 0) {
+   if (ret < 0)
+   stop_top = true;
+   return;
+   }
+
+   if (in_help)
+   process_help_stdin();
+   else
+   process_normal_stdin();
+}
+
+static void show_help_screen(void)
+{
+   printf(
+"Help for interactive commands:\n\n"
+"'1'Toggle between aggregated engine class and physical engine mode.\n"
+"'n'Toggle display of numeric client busyness overlay.\n"
+"'s'Toggle between sort modes (runtime, total runtime, pid, client 
id).\n"
+"'i'Toggle display of clients which used no GPU time.\n"
+"'H'Toggle between per PID aggregation and individual clients.\n"
+"\n"
+"'h' or 'q'Exit interactive help.\n"
+"\n");
+}
+
 int main(int argc, char **argv)
 {
unsigned int period_us = DEFAULT_PERIOD_MS * 1000;
@@ -2491,6 +2538,11 @@ int main(int argc, char **argv)
 t, lines, con_w, con_h,
 &consumed);
 
+   if (in_help) {
+   show_help_screen();
+   break;
+   }
+
lines = print_imc(engines, t, lines, con_w, con_h);
 
lines = print_engines(engines, t, lines, con_w, con_h);
-- 
2.27.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate clients by PID by default

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Implement a default view where clients are aggregated by their PID.

Toggled by pressing 'H' similar to top(1).

v2:
 * Fix memory leak.

Signed-off-by: Tvrtko Ursulin 
---
 man/intel_gpu_top.rst |   1 +
 tools/intel_gpu_top.c | 121 +-
 2 files changed, 109 insertions(+), 13 deletions(-)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index b145d85c0440..20658e291db0 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -58,6 +58,7 @@ Supported keys:
 'n'Toggle display of numeric client busyness overlay.
 's'Toggle between sort modes (runtime, total runtime, pid, client id).
 'i'Toggle display of clients which used no GPU time.
+'H'Toggle between per PID aggregation and individual clients.
 
 DEVICE SELECTION
 
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 63ef77056341..525fb2cd539b 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -979,17 +979,18 @@ static int client_pid_cmp(const void *_a, const void *_b)
 
 static int (*client_cmp)(const void *, const void *) = client_last_cmp;
 
-static void sort_clients(struct clients *clients)
+static struct clients *sort_clients(struct clients *clients,
+   int (*cmp)(const void *, const void *))
 {
unsigned int active, free;
struct client *c;
int tmp;
 
if (!clients)
-   return;
+   return clients;
 
qsort(clients->client, clients->num_clients, sizeof(*clients->client),
- client_cmp);
+ cmp);
 
/* Trim excessive array space. */
active = 0;
@@ -1011,9 +1012,88 @@ static void sort_clients(struct clients *clients)
  sizeof(*c));
}
}
+
+   return clients;
+}
+
+static struct clients *aggregated_clients(struct clients *clients)
+{
+   struct client *ac, *c, *cp = NULL;
+   struct clients *aggregated;
+   int tmp, num = 0;
+
+   /* Sort by pid first to make it easy to aggregate while walking. */
+   sort_clients(clients, client_pid_cmp);
+
+   aggregated = calloc(1, sizeof(*clients));
+   assert(aggregated);
+
+   ac = calloc(clients->num_clients, sizeof(*c));
+   assert(ac);
+
+   aggregated->num_classes = clients->num_classes;
+   aggregated->class = clients->class;
+   aggregated->client = ac;
+
+   for_each_client(clients, c, tmp) {
+   unsigned int i;
+
+   if (c->status == FREE)
+   break;
+
+   assert(c->status == ALIVE);
+
+   if ((cp && c->pid != cp->pid) || !cp) {
+   ac = &aggregated->client[num];
+
+   /* New pid. */
+   ac->clients = aggregated;
+   ac->status = ALIVE;
+   ac->id = ++num;
+   ac->pid = c->pid;
+   strcpy(ac->name, c->name);
+   strcpy(ac->print_name, c->print_name);
+   ac->engines = c->engines;
+   ac->val = calloc(clients->num_classes,
+sizeof(ac->val[0]));
+   assert(ac->val);
+   ac->samples = 1;
+   }
+
+   cp = c;
+
+   if (c->samples < 2)
+   continue;
+
+   ac->samples = 2; /* All what matters for display. */
+   ac->total_runtime += c->total_runtime;
+   ac->last_runtime += c->last_runtime;
+
+   for (i = 0; i < clients->num_classes; i++)
+   ac->val[i] += c->val[i];
+   }
+
+   aggregated->num_clients = num;
+   aggregated->active_clients = num;
+
+   return sort_clients(aggregated, client_cmp);
 }
 
-static void scan_clients(struct clients *clients)
+static void free_clients(struct clients *clients)
+{
+   struct client *c;
+   unsigned int tmp;
+
+   for_each_client(clients, c, tmp)
+   free(c->val);
+
+   free(clients->client);
+   free(clients);
+}
+
+static bool aggregate_pids = true;
+
+static struct clients *scan_clients(struct clients *clients)
 {
struct dirent *dent;
struct client *c;
@@ -1022,7 +1102,7 @@ static void scan_clients(struct clients *clients)
DIR *d;
 
if (!clients)
-   return;
+   return clients;
 
for_each_client(clients, c, tmp) {
assert(c->status != PROBE);
@@ -1034,7 +1114,7 @@ static void scan_clients(struct clients *clients)
 
d = opendir(clients->sysfs_root);
if (!d)
-   return;
+   return clients;
 
while ((dent = readdir(d)) != NULL) {
char name[24], pid[24];
@@ -1077,7 +1157,10 @@ static void scan_clients(struct clients *c

[Intel-gfx] [PATCH] drm/i915: Check for scratch page scribbling

[Chris Wilson]

Periodically check, for example when idling and upon closing user
contexts, whether or not some client has written into unallocated PTE in
their ppGTT.

Signed-off-by: Chris Wilson 
---
 .../drm/i915/gem/selftests/i915_gem_context.c | 19 +++--
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 31 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |  4 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 41 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  1 +
 drivers/gpu/drm/i915/i915_scheduler.c | 33 +--
 drivers/gpu/drm/i915/i915_utils.c | 29 +
 drivers/gpu/drm/i915/i915_utils.h |  3 ++
 8 files changed, 97 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index df949320f2b5..b0c349a46e6a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1737,7 +1737,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
return err;
 }
 
-static int check_scratch_page(struct i915_gem_context *ctx, u32 *out)
+static int check_ctx_scratch(struct i915_gem_context *ctx, u32 *out)
 {
struct i915_address_space *vm;
struct page *page;
@@ -1770,6 +1770,17 @@ static int check_scratch_page(struct i915_gem_context 
*ctx, u32 *out)
return err;
 }
 
+static void reset_ctx_scratch(struct i915_gem_context *ctx, u32 value)
+{
+   struct i915_address_space *vm = ctx_vm(ctx);
+   struct page *page = __px_page(vm->scratch[0]);
+   u32 *vaddr;
+
+   vaddr = kmap(page);
+   memset32(vaddr, value, PAGE_SIZE / sizeof(value));
+   kunmap(page);
+}
+
 static int igt_vm_isolation(void *arg)
 {
struct drm_i915_private *i915 = arg;
@@ -1816,11 +1827,11 @@ static int igt_vm_isolation(void *arg)
goto out_file;
 
/* Read the initial state of the scratch page */
-   err = check_scratch_page(ctx_a, &expected);
+   err = check_ctx_scratch(ctx_a, &expected);
if (err)
goto out_file;
 
-   err = check_scratch_page(ctx_b, &expected);
+   err = check_ctx_scratch(ctx_b, &expected);
if (err)
goto out_file;
 
@@ -1876,6 +1887,8 @@ static int igt_vm_isolation(void *arg)
count, num_engines);
 
 out_file:
+   /* As we deliberately write into scratch, cover up our tracks */
+   reset_ctx_scratch(ctx_a, expected);
if (igt_live_test_end(&t))
err = -EIO;
fput(file);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 577ebd4a324f..8443794df3ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1265,35 +1265,6 @@ bool intel_engine_can_store_dword(struct intel_engine_cs 
*engine)
}
 }
 
-static void hexdump(struct drm_printer *m, const void *buf, size_t len)
-{
-   const size_t rowsize = 8 * sizeof(u32);
-   const void *prev = NULL;
-   bool skip = false;
-   size_t pos;
-
-   for (pos = 0; pos < len; pos += rowsize) {
-   char line[128];
-
-   if (prev && !memcmp(prev, buf + pos, rowsize)) {
-   if (!skip) {
-   drm_printf(m, "*\n");
-   skip = true;
-   }
-   continue;
-   }
-
-   WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
-   rowsize, sizeof(u32),
-   line, sizeof(line),
-   false) >= sizeof(line));
-   drm_printf(m, "[%04zx] %s\n", pos, line);
-
-   prev = buf + pos;
-   skip = false;
-   }
-}
-
 static void intel_engine_print_registers(struct intel_engine_cs *engine,
 struct drm_printer *m)
 {
@@ -1450,7 +1421,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
}
 
drm_printf(m, "HWSP:\n");
-   hexdump(m, engine->status_page.addr, PAGE_SIZE);
+   i915_hexdump(m, engine->status_page.addr, PAGE_SIZE);
 
drm_printf(m, "Idle? %s\n", yesno(intel_engine_is_idle(engine)));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 0bd303d2823e..38375a006a99 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -11,6 +11,7 @@
 #include "intel_context.h"
 #include "intel_engine_pm.h"
 #include "intel_gt.h"
+#include "intel_gtt.h"
 #include "intel_gt_clock_utils.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -100,6 +101,9 @@ static int __gt_park(struct intel_wakeref *wf)
runtime_end(gt);
intel_gt_park_requests(gt);
 
+

[Intel-gfx] [PATCH] drm/i915: Check for scratch page scribbling

[Chris Wilson]

Periodically check, for example when idling and upon closing user
contexts, whether or not some client has written into unallocated PTE in
their ppGTT.

Signed-off-by: Chris Wilson 
---
 .../drm/i915/gem/selftests/i915_gem_context.c | 19 +++--
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 31 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |  4 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 42 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  1 +
 drivers/gpu/drm/i915/i915_scheduler.c | 33 +--
 drivers/gpu/drm/i915/i915_utils.c | 29 +
 drivers/gpu/drm/i915/i915_utils.h |  3 ++
 8 files changed, 98 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index df949320f2b5..b0c349a46e6a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1737,7 +1737,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
return err;
 }
 
-static int check_scratch_page(struct i915_gem_context *ctx, u32 *out)
+static int check_ctx_scratch(struct i915_gem_context *ctx, u32 *out)
 {
struct i915_address_space *vm;
struct page *page;
@@ -1770,6 +1770,17 @@ static int check_scratch_page(struct i915_gem_context 
*ctx, u32 *out)
return err;
 }
 
+static void reset_ctx_scratch(struct i915_gem_context *ctx, u32 value)
+{
+   struct i915_address_space *vm = ctx_vm(ctx);
+   struct page *page = __px_page(vm->scratch[0]);
+   u32 *vaddr;
+
+   vaddr = kmap(page);
+   memset32(vaddr, value, PAGE_SIZE / sizeof(value));
+   kunmap(page);
+}
+
 static int igt_vm_isolation(void *arg)
 {
struct drm_i915_private *i915 = arg;
@@ -1816,11 +1827,11 @@ static int igt_vm_isolation(void *arg)
goto out_file;
 
/* Read the initial state of the scratch page */
-   err = check_scratch_page(ctx_a, &expected);
+   err = check_ctx_scratch(ctx_a, &expected);
if (err)
goto out_file;
 
-   err = check_scratch_page(ctx_b, &expected);
+   err = check_ctx_scratch(ctx_b, &expected);
if (err)
goto out_file;
 
@@ -1876,6 +1887,8 @@ static int igt_vm_isolation(void *arg)
count, num_engines);
 
 out_file:
+   /* As we deliberately write into scratch, cover up our tracks */
+   reset_ctx_scratch(ctx_a, expected);
if (igt_live_test_end(&t))
err = -EIO;
fput(file);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 577ebd4a324f..8443794df3ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1265,35 +1265,6 @@ bool intel_engine_can_store_dword(struct intel_engine_cs 
*engine)
}
 }
 
-static void hexdump(struct drm_printer *m, const void *buf, size_t len)
-{
-   const size_t rowsize = 8 * sizeof(u32);
-   const void *prev = NULL;
-   bool skip = false;
-   size_t pos;
-
-   for (pos = 0; pos < len; pos += rowsize) {
-   char line[128];
-
-   if (prev && !memcmp(prev, buf + pos, rowsize)) {
-   if (!skip) {
-   drm_printf(m, "*\n");
-   skip = true;
-   }
-   continue;
-   }
-
-   WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
-   rowsize, sizeof(u32),
-   line, sizeof(line),
-   false) >= sizeof(line));
-   drm_printf(m, "[%04zx] %s\n", pos, line);
-
-   prev = buf + pos;
-   skip = false;
-   }
-}
-
 static void intel_engine_print_registers(struct intel_engine_cs *engine,
 struct drm_printer *m)
 {
@@ -1450,7 +1421,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
}
 
drm_printf(m, "HWSP:\n");
-   hexdump(m, engine->status_page.addr, PAGE_SIZE);
+   i915_hexdump(m, engine->status_page.addr, PAGE_SIZE);
 
drm_printf(m, "Idle? %s\n", yesno(intel_engine_is_idle(engine)));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 0bd303d2823e..38375a006a99 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -11,6 +11,7 @@
 #include "intel_context.h"
 #include "intel_engine_pm.h"
 #include "intel_gt.h"
+#include "intel_gtt.h"
 #include "intel_gt_clock_utils.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -100,6 +101,9 @@ static int __gt_park(struct intel_wakeref *wf)
runtime_end(gt);
intel_gt_park_requests(gt);
 
+

Re: [Intel-gfx] [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Almahallawy, Khaled]

On Wed, 2021-02-10 at 09:55 +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 10.02.21 um 09:33 schrieb Khaled Almahallawy:
> > The number of AUX retries specified in the DP specs is 7.
> > Currently, to make Dell 4k monitors happier, the number of retries
> > are 32.
> > i915 also retries 5 times (intel_dp_aux_xfer) which means in the
> > case of AUX timeout we actually retries 32 * 5 = 160 times.
> > 
> > So making the number of aux retires a variable to allow for fine
> > tuning and optimization of aux timing.
> > 
> > Signed-off-by: Khaled Almahallawy 
> > ---
> >   drivers/gpu/drm/drm_dp_helper.c | 10 +++---
> >   include/drm/drm_dp_helper.h |  1 +
> >   2 files changed, 4 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index eedbb48815b7..8fdf57b4a06c 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -249,13 +249,7 @@ static int drm_dp_dpcd_access(struct
> > drm_dp_aux *aux, u8 request,
> >   
> > mutex_lock(&aux->hw_mutex);
> >   
> > -   /*
> > -* The specification doesn't give any recommendation on how
> > often to
> > -* retry native transactions. We used to retry 7 times like for
> > -* aux i2c transactions but real world devices this wasn't
> > -* sufficient, bump to 32 which makes Dell 4k monitors happier.
> > -*/
> > -   for (retry = 0; retry < 32; retry++) {
> > +   for (retry = 0; retry < aux->num_retries; retry++) {
> > if (ret != 0 && ret != -ETIMEDOUT) {
> > usleep_range(AUX_RETRY_INTERVAL,
> >  AUX_RETRY_INTERVAL + 100);
> > @@ -1744,6 +1738,8 @@ void drm_dp_aux_init(struct drm_dp_aux *aux)
> > aux->ddc.retries = 3;
> >   
> > aux->ddc.lock_ops = &drm_dp_i2c_lock_ops;
> > +   /*Still making the Dell 4k monitors happier*/
> 
> The original comment was helpful; this one isn't.

Noted and I apologize for the comment. Was just copy/past original
comment. 
> 

> Besides that, what problem does this patchset address? Too much
> probing? 

The problem mainly with disconnect. When disconnecting, AUX read will
fail because of timing out. The 32 retries cause the disconnect flow
especially for Type-C/TBT Docks with MST hubs taking a long time.
Just trying to reduce this disconnect time. In addition as I noted,
i915 does retry in addition to retries by this function. 

Currently this function retry for 4 AUX situations:
AUX_NAK, AUX_DEFER, I/O error reported by driver and AUX timeout.

> If I connect a Dell monitor to an Intel card, how often does it have
> to 
> probe?

I guess it depends on how you connect (direct, behind MST hub, behind DOCK with 
MST). But I believe the most time consuming is the disconnect flow. 

Thanks
Khaled
> 
> Best regards
> Thomas
> 
> > +   aux->num_retries = 32;
> >   }
> >   EXPORT_SYMBOL(drm_dp_aux_init);
> >   
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index edffd1dcca3e..16cbfc8f5e66 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1876,6 +1876,7 @@ struct drm_dp_aux {
> > struct mutex hw_mutex;
> > struct work_struct crc_work;
> > u8 crc_count;
> > +   int num_retries;
> > ssize_t (*transfer)(struct drm_dp_aux *aux,
> > struct drm_dp_aux_msg *msg);
> > /**
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Check for scratch page scribbling

[Chris Wilson]

Periodically check, for example when idling and upon closing user
contexts, whether or not some client has written into unallocated PTE in
their ppGTT.

Signed-off-by: Chris Wilson 
---
 .../drm/i915/gem/selftests/i915_gem_context.c | 19 +++--
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 31 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |  4 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 42 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  1 +
 drivers/gpu/drm/i915/i915_scheduler.c | 33 +--
 drivers/gpu/drm/i915/i915_utils.c | 29 +
 drivers/gpu/drm/i915/i915_utils.h |  3 ++
 8 files changed, 98 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index df949320f2b5..b0c349a46e6a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1737,7 +1737,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
return err;
 }
 
-static int check_scratch_page(struct i915_gem_context *ctx, u32 *out)
+static int check_ctx_scratch(struct i915_gem_context *ctx, u32 *out)
 {
struct i915_address_space *vm;
struct page *page;
@@ -1770,6 +1770,17 @@ static int check_scratch_page(struct i915_gem_context 
*ctx, u32 *out)
return err;
 }
 
+static void reset_ctx_scratch(struct i915_gem_context *ctx, u32 value)
+{
+   struct i915_address_space *vm = ctx_vm(ctx);
+   struct page *page = __px_page(vm->scratch[0]);
+   u32 *vaddr;
+
+   vaddr = kmap(page);
+   memset32(vaddr, value, PAGE_SIZE / sizeof(value));
+   kunmap(page);
+}
+
 static int igt_vm_isolation(void *arg)
 {
struct drm_i915_private *i915 = arg;
@@ -1816,11 +1827,11 @@ static int igt_vm_isolation(void *arg)
goto out_file;
 
/* Read the initial state of the scratch page */
-   err = check_scratch_page(ctx_a, &expected);
+   err = check_ctx_scratch(ctx_a, &expected);
if (err)
goto out_file;
 
-   err = check_scratch_page(ctx_b, &expected);
+   err = check_ctx_scratch(ctx_b, &expected);
if (err)
goto out_file;
 
@@ -1876,6 +1887,8 @@ static int igt_vm_isolation(void *arg)
count, num_engines);
 
 out_file:
+   /* As we deliberately write into scratch, cover up our tracks */
+   reset_ctx_scratch(ctx_a, expected);
if (igt_live_test_end(&t))
err = -EIO;
fput(file);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 577ebd4a324f..8443794df3ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1265,35 +1265,6 @@ bool intel_engine_can_store_dword(struct intel_engine_cs 
*engine)
}
 }
 
-static void hexdump(struct drm_printer *m, const void *buf, size_t len)
-{
-   const size_t rowsize = 8 * sizeof(u32);
-   const void *prev = NULL;
-   bool skip = false;
-   size_t pos;
-
-   for (pos = 0; pos < len; pos += rowsize) {
-   char line[128];
-
-   if (prev && !memcmp(prev, buf + pos, rowsize)) {
-   if (!skip) {
-   drm_printf(m, "*\n");
-   skip = true;
-   }
-   continue;
-   }
-
-   WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
-   rowsize, sizeof(u32),
-   line, sizeof(line),
-   false) >= sizeof(line));
-   drm_printf(m, "[%04zx] %s\n", pos, line);
-
-   prev = buf + pos;
-   skip = false;
-   }
-}
-
 static void intel_engine_print_registers(struct intel_engine_cs *engine,
 struct drm_printer *m)
 {
@@ -1450,7 +1421,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
}
 
drm_printf(m, "HWSP:\n");
-   hexdump(m, engine->status_page.addr, PAGE_SIZE);
+   i915_hexdump(m, engine->status_page.addr, PAGE_SIZE);
 
drm_printf(m, "Idle? %s\n", yesno(intel_engine_is_idle(engine)));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 0bd303d2823e..38375a006a99 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -11,6 +11,7 @@
 #include "intel_context.h"
 #include "intel_engine_pm.h"
 #include "intel_gt.h"
+#include "intel_gtt.h"
 #include "intel_gt_clock_utils.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -100,6 +101,9 @@ static int __gt_park(struct intel_wakeref *wf)
runtime_end(gt);
intel_gt_park_requests(gt);
 
+

[Intel-gfx] [PATCH 2/2] drm/i915/gt: Correct surface base address

[Chris Wilson]

The surface_state_base is an offset into the batch, so we need to pass
the correct batch address for STATE_BASE_ADDRESS.

Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Prathap Kumar Valsan 
Cc: Akeem G Abodunrin 
---
 drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
index e403eb046a43..de575fdb033f 100644
--- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -240,7 +240,7 @@ gen7_emit_state_base_address(struct batch_chunk *batch,
/* general */
*cs++ = batch_addr(batch) | BASE_ADDRESS_MODIFY;
/* surface */
-   *cs++ = batch_addr(batch) | surface_state_base | BASE_ADDRESS_MODIFY;
+   *cs++ = (batch_addr(batch) + surface_state_base) | BASE_ADDRESS_MODIFY;
/* dynamic */
*cs++ = batch_addr(batch) | BASE_ADDRESS_MODIFY;
/* indirect */
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate clients by PID by default

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-02-10 09:37:55)
> +static struct clients *aggregated_clients(struct clients *clients)
> +{
> +   struct client *ac, *c, *cp = NULL;
> +   struct clients *aggregated;
> +   int tmp, num = 0;
> +
> +   /* Sort by pid first to make it easy to aggregate while walking. */
> +   sort_clients(clients, client_pid_cmp);

You could eliminate this tiny bit of duplication by always calling
aggregated_clients() and returning here for !aggregate_pids.

> +   aggregated = calloc(1, sizeof(*clients));
> +   assert(aggregated);
> +
> +   ac = calloc(clients->num_clients, sizeof(*c));
> +   assert(ac);
> +
> +   aggregated->num_classes = clients->num_classes;
> +   aggregated->class = clients->class;
> +   aggregated->client = ac;
> +
> +   for_each_client(clients, c, tmp) {
> +   unsigned int i;
> +
> +   if (c->status == FREE)
> +   break;
> +
> +   assert(c->status == ALIVE);
> +
> +   if ((cp && c->pid != cp->pid) || !cp) {
> +   ac = &aggregated->client[num];
> +
> +   /* New pid. */
> +   ac->clients = aggregated;
> +   ac->status = ALIVE;
> +   ac->id = ++num;
> +   ac->pid = c->pid;
> +   strcpy(ac->name, c->name);
> +   strcpy(ac->print_name, c->print_name);
> +   ac->engines = c->engines;
> +   ac->val = calloc(clients->num_classes,
> +sizeof(ac->val[0]));
> +   assert(ac->val);
> +   ac->samples = 1;
> +   }
> +
> +   cp = c;
> +
> +   if (c->samples < 2)
> +   continue;
> +
> +   ac->samples = 2; /* All what matters for display. */
> +   ac->total_runtime += c->total_runtime;
> +   ac->last_runtime += c->last_runtime;
> +
> +   for (i = 0; i < clients->num_classes; i++)
> +   ac->val[i] += c->val[i];
> +   }
> +
> +   aggregated->num_clients = num;
> +   aggregated->active_clients = num;
> +
> +   return sort_clients(aggregated, client_cmp);
>  }

Ok, that works very well. Hmm. The sort order does seem a little jumpy
though. May I suggest ac->id = -c->pid; instead of num;
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] intel_gpu_top: Interactive help screen

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-02-10 09:37:56)
> From: Tvrtko Ursulin 
> 
> Show a list of supported interactive commands when pressing 'h'.
> 
> Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues

[Hans de Goede]

Hi,

On 2/10/21 12:07 AM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-09 11:46:46)
>> Hi,
>>
>> On 2/9/21 12:27 AM, Chris Wilson wrote:
>>> Quoting Hans de Goede (2021-02-08 20:38:58)
 Hi All,

 We (Fedora) have been receiving reports from multiple users about gfx 
 issues / glitches
 stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell iGPUs 
 and all
 reporters report that adding i915.mitigations=off to the cmdline fixes 
 things, see:
>>>
>>> I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
>>> did not report any differences with and without mitigations. I have yet
>>> to test other platforms. So I don't yet have an alternative.
>>
>> Note the original / first reporter of:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1925346
>>
>> Is using hsw-gt2, so it seems that the problem is not just the enabling of
>> the mitigations on ivy-bridge / bay-trail but that there actually is
>> a regression on devices where the WA worked fine before...
> 
> There have been 3 crashes uploaded related to v5.10.9, and in all 3
> cases the ACTHD has been in the first page. This strongly suggests that
> the w/a is scribbling over address 0. And there's then a very good
> chance that
> 
> commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6
> Author: Chris Wilson 
> Date:   Mon Jan 25 12:50:33 2021 +
> 
> drm/i915/gt: Always try to reserve GGTT address 0x0
> 
> commit 489140b5ba2e7cc4b853c29e0591895ddb462a82 upstream.
> 
> in v5.10.14 is sufficient to hide the issue.

That one actually is already in v5.10.13 and the various reportes of these
issues have already tested 5.10.13. They did mention that it took longer
to reproduce with 5.10.13 then with 5.10.10, but that could also be due to:

"drm/i915/gt: Clear CACHE_MODE prior to clearing residuals"
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=520d05a77b2866eb4cb9e548e1d8c8abcfe60ec5

Regards,

Hans

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/3] intel_gpu_top: Wrap interactive header

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-02-10 09:37:54)
> From: Tvrtko Ursulin 
> 
> Slight improvement with regards to wrapping header components to fit
> console width. If a single element is wider than max it can still
> overflow but it should now work better for practical console widths.

I'm not fond of this layout, but that's just a personal preference.
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Add a check for object size for corner cases

[Chris Wilson]

Quoting Anand Moon (2021-02-10 07:59:29)
> Add check for object size to return appropriate error -E2BIG or -EINVAL
> to avoid WARM_ON and sucessfull return for some testcase.

No. You miss the point of having those warnings. We need to inspect the
code to remove the last remaining "int pagenum", and then we can remove
the GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX). These are not emitted for
users, only for us to motivate us into finally fixing the code.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check for scratch page scribbling

[Mika Kuoppala]

Chris Wilson  writes:

> Periodically check, for example when idling and upon closing user
> contexts, whether or not some client has written into unallocated PTE in
> their ppGTT.
>
> Signed-off-by: Chris Wilson 
> ---
>  .../drm/i915/gem/selftests/i915_gem_context.c | 19 +++--
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 31 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c |  4 ++
>  drivers/gpu/drm/i915/gt/intel_gtt.c   | 42 +++
>  drivers/gpu/drm/i915/gt/intel_gtt.h   |  1 +
>  drivers/gpu/drm/i915/i915_scheduler.c | 33 +--
>  drivers/gpu/drm/i915/i915_utils.c | 29 +
>  drivers/gpu/drm/i915/i915_utils.h |  3 ++
>  8 files changed, 98 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> index df949320f2b5..b0c349a46e6a 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> @@ -1737,7 +1737,7 @@ static int read_from_scratch(struct i915_gem_context 
> *ctx,
>   return err;
>  }
>  
> -static int check_scratch_page(struct i915_gem_context *ctx, u32 *out)
> +static int check_ctx_scratch(struct i915_gem_context *ctx, u32 *out)
>  {
>   struct i915_address_space *vm;
>   struct page *page;
> @@ -1770,6 +1770,17 @@ static int check_scratch_page(struct i915_gem_context 
> *ctx, u32 *out)
>   return err;
>  }
>  
> +static void reset_ctx_scratch(struct i915_gem_context *ctx, u32 value)
> +{
> + struct i915_address_space *vm = ctx_vm(ctx);
> + struct page *page = __px_page(vm->scratch[0]);
> + u32 *vaddr;
> +
> + vaddr = kmap(page);
> + memset32(vaddr, value, PAGE_SIZE / sizeof(value));
> + kunmap(page);
> +}
> +
>  static int igt_vm_isolation(void *arg)
>  {
>   struct drm_i915_private *i915 = arg;
> @@ -1816,11 +1827,11 @@ static int igt_vm_isolation(void *arg)
>   goto out_file;
>  
>   /* Read the initial state of the scratch page */
> - err = check_scratch_page(ctx_a, &expected);
> + err = check_ctx_scratch(ctx_a, &expected);
>   if (err)
>   goto out_file;
>  
> - err = check_scratch_page(ctx_b, &expected);
> + err = check_ctx_scratch(ctx_b, &expected);
>   if (err)
>   goto out_file;
>  
> @@ -1876,6 +1887,8 @@ static int igt_vm_isolation(void *arg)
>   count, num_engines);
>  
>  out_file:
> + /* As we deliberately write into scratch, cover up our tracks */
> + reset_ctx_scratch(ctx_a, expected);
>   if (igt_live_test_end(&t))
>   err = -EIO;
>   fput(file);
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 577ebd4a324f..8443794df3ee 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1265,35 +1265,6 @@ bool intel_engine_can_store_dword(struct 
> intel_engine_cs *engine)
>   }
>  }
>  
> -static void hexdump(struct drm_printer *m, const void *buf, size_t len)
> -{
> - const size_t rowsize = 8 * sizeof(u32);
> - const void *prev = NULL;
> - bool skip = false;
> - size_t pos;
> -
> - for (pos = 0; pos < len; pos += rowsize) {
> - char line[128];
> -
> - if (prev && !memcmp(prev, buf + pos, rowsize)) {
> - if (!skip) {
> - drm_printf(m, "*\n");
> - skip = true;
> - }
> - continue;
> - }
> -
> - WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
> - rowsize, sizeof(u32),
> - line, sizeof(line),
> - false) >= sizeof(line));
> - drm_printf(m, "[%04zx] %s\n", pos, line);
> -
> - prev = buf + pos;
> - skip = false;
> - }
> -}
> -
>  static void intel_engine_print_registers(struct intel_engine_cs *engine,
>struct drm_printer *m)
>  {
> @@ -1450,7 +1421,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
>   }
>  
>   drm_printf(m, "HWSP:\n");
> - hexdump(m, engine->status_page.addr, PAGE_SIZE);
> + i915_hexdump(m, engine->status_page.addr, PAGE_SIZE);
>  
>   drm_printf(m, "Idle? %s\n", yesno(intel_engine_is_idle(engine)));
>  
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index 0bd303d2823e..38375a006a99 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -11,6 +11,7 @@
>  #include "intel_context.h"
>  #include "intel_engine_pm.h"
>  #include "intel_gt.h"
> +#include "intel_gtt.h"
>  #include "intel_gt_clock_utils.h"
>  #include

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Correct surface base address

[Mika Kuoppala]

Chris Wilson  writes:

> The surface_state_base is an offset into the batch, so we need to pass
> the correct batch address for STATE_BASE_ADDRESS.
>
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Prathap Kumar Valsan 
> Cc: Akeem G Abodunrin 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
> b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> index e403eb046a43..de575fdb033f 100644
> --- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> @@ -240,7 +240,7 @@ gen7_emit_state_base_address(struct batch_chunk *batch,
>   /* general */
>   *cs++ = batch_addr(batch) | BASE_ADDRESS_MODIFY;
>   /* surface */
> - *cs++ = batch_addr(batch) | surface_state_base | BASE_ADDRESS_MODIFY;
> + *cs++ = (batch_addr(batch) + surface_state_base) | BASE_ADDRESS_MODIFY;
>   /* dynamic */
>   *cs++ = batch_addr(batch) | BASE_ADDRESS_MODIFY;
>   /* indirect */
> -- 
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate clients by PID by default

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Implement a default view where clients are aggregated by their PID.

Toggled by pressing 'H' similar to top(1).

v2:
 * Fix memory leak.

v3:
 * Do not allow sort by client id in aggregated mode.
 * Tweak sort criteria and sorting decisions. (Chris)

Signed-off-by: Tvrtko Ursulin 
---
 man/intel_gpu_top.rst |   1 +
 tools/intel_gpu_top.c | 130 +-
 2 files changed, 118 insertions(+), 13 deletions(-)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index b145d85c0440..20658e291db0 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -58,6 +58,7 @@ Supported keys:
 'n'Toggle display of numeric client busyness overlay.
 's'Toggle between sort modes (runtime, total runtime, pid, client id).
 'i'Toggle display of clients which used no GPU time.
+'H'Toggle between per PID aggregation and individual clients.
 
 DEVICE SELECTION
 
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 63ef77056341..695a8cb397ae 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -979,17 +979,18 @@ static int client_pid_cmp(const void *_a, const void *_b)
 
 static int (*client_cmp)(const void *, const void *) = client_last_cmp;
 
-static void sort_clients(struct clients *clients)
+static struct clients *sort_clients(struct clients *clients,
+   int (*cmp)(const void *, const void *))
 {
unsigned int active, free;
struct client *c;
int tmp;
 
if (!clients)
-   return;
+   return clients;
 
qsort(clients->client, clients->num_clients, sizeof(*clients->client),
- client_cmp);
+ cmp);
 
/* Trim excessive array space. */
active = 0;
@@ -1011,9 +1012,95 @@ static void sort_clients(struct clients *clients)
  sizeof(*c));
}
}
+
+   return clients;
 }
 
-static void scan_clients(struct clients *clients)
+static bool aggregate_pids = true;
+
+static struct clients *display_clients(struct clients *clients)
+{
+   struct client *ac, *c, *cp = NULL;
+   struct clients *aggregated;
+   int tmp, num = 0;
+
+   if (!aggregate_pids)
+   return sort_clients(clients, client_cmp);
+
+   /* Sort by pid first to make it easy to aggregate while walking. */
+   sort_clients(clients, client_pid_cmp);
+
+   aggregated = calloc(1, sizeof(*clients));
+   assert(aggregated);
+
+   ac = calloc(clients->num_clients, sizeof(*c));
+   assert(ac);
+
+   aggregated->num_classes = clients->num_classes;
+   aggregated->class = clients->class;
+   aggregated->client = ac;
+
+   for_each_client(clients, c, tmp) {
+   unsigned int i;
+
+   if (c->status == FREE)
+   break;
+
+   assert(c->status == ALIVE);
+
+   if ((cp && c->pid != cp->pid) || !cp) {
+   ac = &aggregated->client[num++];
+
+   /* New pid. */
+   ac->clients = aggregated;
+   ac->status = ALIVE;
+   ac->id = -c->pid;
+   ac->pid = c->pid;
+   ac->busy_root = -1;
+   ac->sysfs_root = -1;
+   strcpy(ac->name, c->name);
+   strcpy(ac->print_name, c->print_name);
+   ac->engines = c->engines;
+   ac->val = calloc(clients->num_classes,
+sizeof(ac->val[0]));
+   assert(ac->val);
+   ac->samples = 1;
+   }
+
+   cp = c;
+
+   if (c->samples < 2)
+   continue;
+
+   ac->samples = 2; /* All what matters for display. */
+   ac->total_runtime += c->total_runtime;
+   ac->last_runtime += c->last_runtime;
+
+   for (i = 0; i < clients->num_classes; i++)
+   ac->val[i] += c->val[i];
+   }
+
+   aggregated->num_clients = num;
+   aggregated->active_clients = num;
+
+   return sort_clients(aggregated, client_cmp);
+}
+
+static void free_clients(struct clients *clients)
+{
+   struct client *c;
+   unsigned int tmp;
+
+   for_each_client(clients, c, tmp) {
+   free(c->val);
+   free(c->last);
+   }
+
+   free(clients->client);
+   free(clients);
+}
+
+static struct clients *scan_clients(struct clients *clients)
 {
struct dirent *dent;
struct client *c;
@@ -1022,7 +1109,7 @@ static void scan_clients(struct clients *clients)
DIR *d;
 
if (!clients)
-   return;
+   return clients;
 
for_each_client(clients, c, tmp) {
assert(c->status != PROBE);
@@ -10

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate clients by PID by default

[Tvrtko Ursulin]

On 10/02/2021 10:35, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2021-02-10 09:37:55)

+static struct clients *aggregated_clients(struct clients *clients)
+{
+   struct client *ac, *c, *cp = NULL;
+   struct clients *aggregated;
+   int tmp, num = 0;
+
+   /* Sort by pid first to make it easy to aggregate while walking. */
+   sort_clients(clients, client_pid_cmp);


You could eliminate this tiny bit of duplication by always calling
aggregated_clients() and returning here for !aggregate_pids.


Okay, I did something like that.


+   aggregated = calloc(1, sizeof(*clients));
+   assert(aggregated);
+
+   ac = calloc(clients->num_clients, sizeof(*c));
+   assert(ac);
+
+   aggregated->num_classes = clients->num_classes;
+   aggregated->class = clients->class;
+   aggregated->client = ac;
+
+   for_each_client(clients, c, tmp) {
+   unsigned int i;
+
+   if (c->status == FREE)
+   break;
+
+   assert(c->status == ALIVE);
+
+   if ((cp && c->pid != cp->pid) || !cp) {
+   ac = &aggregated->client[num];
+
+   /* New pid. */
+   ac->clients = aggregated;
+   ac->status = ALIVE;
+   ac->id = ++num;
+   ac->pid = c->pid;
+   strcpy(ac->name, c->name);
+   strcpy(ac->print_name, c->print_name);
+   ac->engines = c->engines;
+   ac->val = calloc(clients->num_classes,
+sizeof(ac->val[0]));
+   assert(ac->val);
+   ac->samples = 1;
+   }
+
+   cp = c;
+
+   if (c->samples < 2)
+   continue;
+
+   ac->samples = 2; /* All what matters for display. */
+   ac->total_runtime += c->total_runtime;
+   ac->last_runtime += c->last_runtime;
+
+   for (i = 0; i < clients->num_classes; i++)
+   ac->val[i] += c->val[i];
+   }
+
+   aggregated->num_clients = num;
+   aggregated->active_clients = num;
+
+   return sort_clients(aggregated, client_cmp);
  }


Ok, that works very well. Hmm. The sort order does seem a little jumpy
though. May I suggest ac->id = -c->pid; instead of num;


Done it although I thought 1st pass being sort by pid already, num as id 
would follow a stable order. I guess your point was inversion to 
preserve order when cycling sort modes?


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate clients by PID by default

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-02-10 10:55:44)
> 
> On 10/02/2021 10:35, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2021-02-10 09:37:55)
> > Ok, that works very well. Hmm. The sort order does seem a little jumpy
> > though. May I suggest ac->id = -c->pid; instead of num;
> 
> Done it although I thought 1st pass being sort by pid already, num as id 
> would follow a stable order. I guess your point was inversion to 
> preserve order when cycling sort modes?

I thought that makes more sense for 'aggregate-by-pid', that it should
either be in ascending/descending pid order for idle.

It just felt very jumpy; it may have been tiny amount of %busy, but I
suspected it may have been slightly unstable sorting with changing
clients.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Add a check for object size for corner cases

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Add a check for object size for corner cases
URL   : https://patchwork.freedesktop.org/series/86934/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9755_full -> Patchwork_19648_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][1] ([fdo#111827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-iclb4/igt@feature_discov...@chamelium.html

  * igt@gem_ctx_persistence@legacy-engines-hostile-preempt:
- shard-snb:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-kbl:  [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/shard-kbl7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-kbl6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-glk1/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace:
- shard-hsw:  NOTRUN -> [SKIP][10] ([fdo#109271]) +85 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-hsw4/igt@gem_exec_f...@basic-pace.html

  * igt@gem_exec_fence@basic-wait@bcs0:
- shard-kbl:  NOTRUN -> [SKIP][11] ([fdo#109271]) +77 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-kbl4/igt@gem_exec_fence@basic-w...@bcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][12] ([i915#2389]) +4 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-kbl1/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#2803])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/shard-tglb5/igt@gem_exec_schedule@u-fairsl...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-tglb2/igt@gem_exec_schedule@u-fairsl...@rcs0.html
- shard-skl:  [PASS][15] -> [DMESG-WARN][16] ([i915#1610] / 
[i915#2803])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/shard-skl4/igt@gem_exec_schedule@u-fairsl...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-skl10/igt@gem_exec_schedule@u-fairsl...@rcs0.html

  * igt@gem_render_copy@y-tiled-mc-ccs-to-y-tiled-ccs:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-iclb4/igt@gem_render_c...@y-tiled-mc-ccs-to-y-tiled-ccs.html

  * igt@gem_userptr_blits@huge-split:
- shard-glk:  [PASS][18] -> [INCOMPLETE][19] ([i915#2502])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/shard-glk7/igt@gem_userptr_bl...@huge-split.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-glk2/igt@gem_userptr_bl...@huge-split.html

  * igt@gem_workarounds@suspend-resume:
- shard-glk:  [PASS][20] -> [INCOMPLETE][21] ([i915#2199])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9755/shard-glk7/igt@gem_workarou...@suspend-resume.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-glk9/igt@gem_workarou...@suspend-resume.html

  * igt@gen7_exec_parse@basic-allocation:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109289]) +1 similar issue
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19648/shard-tglb8/igt@gen7_exec_pa...@basic-allocation.html

  * igt@gen7_exec_parse@bitmasks:
- shard-iclb: NOTRUN -> [SKIP][23] ([fdo#109289]) +2 similar issues
   [23]: 
https://intel

Re: [Intel-gfx] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate clients by PID by default

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-02-10 10:53:43)
> +static struct clients *display_clients(struct clients *clients)
> +{
> +   struct client *ac, *c, *cp = NULL;
> +   struct clients *aggregated;
> +   int tmp, num = 0;
> +
> +   if (!aggregate_pids)
> +   return sort_clients(clients, client_cmp);

Still two calls to return sort_clients(foo, client_cmp) in this function
:) [a clients = aggregated; after processing would merge the two paths].

Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check for scratch page scribbling

[Chris Wilson]

Quoting Mika Kuoppala (2021-02-10 10:49:55)
> Chris Wilson  writes:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
> > b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > index d34770ae4c9a..5ac9eb4a3a92 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > @@ -158,10 +158,49 @@ static void poison_scratch_page(struct 
> > drm_i915_gem_object *scratch)
> >  
> >   vaddr = kmap(page);
> >   memset(vaddr, val, PAGE_SIZE);
> > + set_page_dirty(page); /* keep the poisoned contents */
> 
> Should we use locked version in here?

We don't hold the page-lock here, so no. If this is not an anonymous
page, something is very wrong :p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate clients by PID by default

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Implement a default view where clients are aggregated by their PID.

Toggled by pressing 'H' similar to top(1).

v2:
 * Fix memory leak.

v3:
 * Do not allow sort by client id in aggregated mode.
 * Tweak sort criteria and sorting decisions. (Chris)

v4:
 * More tweaks to code flow. (Chris)

Signed-off-by: Tvrtko Ursulin 
---
 man/intel_gpu_top.rst |   1 +
 tools/intel_gpu_top.c | 133 +-
 2 files changed, 121 insertions(+), 13 deletions(-)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index b145d85c0440..20658e291db0 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -58,6 +58,7 @@ Supported keys:
 'n'Toggle display of numeric client busyness overlay.
 's'Toggle between sort modes (runtime, total runtime, pid, client id).
 'i'Toggle display of clients which used no GPU time.
+'H'Toggle between per PID aggregation and individual clients.
 
 DEVICE SELECTION
 
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 63ef77056341..e7f696110be8 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -979,17 +979,18 @@ static int client_pid_cmp(const void *_a, const void *_b)
 
 static int (*client_cmp)(const void *, const void *) = client_last_cmp;
 
-static void sort_clients(struct clients *clients)
+static struct clients *sort_clients(struct clients *clients,
+   int (*cmp)(const void *, const void *))
 {
unsigned int active, free;
struct client *c;
int tmp;
 
if (!clients)
-   return;
+   return clients;
 
qsort(clients->client, clients->num_clients, sizeof(*clients->client),
- client_cmp);
+ cmp);
 
/* Trim excessive array space. */
active = 0;
@@ -1011,9 +1012,98 @@ static void sort_clients(struct clients *clients)
  sizeof(*c));
}
}
+
+   return clients;
+}
+
+static bool aggregate_pids = true;
+
+static struct clients *display_clients(struct clients *clients)
+{
+   struct client *ac, *c, *cp = NULL;
+   struct clients *aggregated;
+   int tmp, num = 0;
+
+   if (!aggregate_pids)
+   goto out;
+
+   /* Sort by pid first to make it easy to aggregate while walking. */
+   sort_clients(clients, client_pid_cmp);
+
+   aggregated = calloc(1, sizeof(*clients));
+   assert(aggregated);
+
+   ac = calloc(clients->num_clients, sizeof(*c));
+   assert(ac);
+
+   aggregated->num_classes = clients->num_classes;
+   aggregated->class = clients->class;
+   aggregated->client = ac;
+
+   for_each_client(clients, c, tmp) {
+   unsigned int i;
+
+   if (c->status == FREE)
+   break;
+
+   assert(c->status == ALIVE);
+
+   if ((cp && c->pid != cp->pid) || !cp) {
+   ac = &aggregated->client[num++];
+
+   /* New pid. */
+   ac->clients = aggregated;
+   ac->status = ALIVE;
+   ac->id = -c->pid;
+   ac->pid = c->pid;
+   ac->busy_root = -1;
+   ac->sysfs_root = -1;
+   strcpy(ac->name, c->name);
+   strcpy(ac->print_name, c->print_name);
+   ac->engines = c->engines;
+   ac->val = calloc(clients->num_classes,
+sizeof(ac->val[0]));
+   assert(ac->val);
+   ac->samples = 1;
+   }
+
+   cp = c;
+
+   if (c->samples < 2)
+   continue;
+
+   ac->samples = 2; /* All what matters for display. */
+   ac->total_runtime += c->total_runtime;
+   ac->last_runtime += c->last_runtime;
+
+   for (i = 0; i < clients->num_classes; i++)
+   ac->val[i] += c->val[i];
+   }
+
+   aggregated->num_clients = num;
+   aggregated->active_clients = num;
+
+   clients = aggregated;
+
+out:
+   return sort_clients(clients, client_cmp);
 }
 
-static void scan_clients(struct clients *clients)
+static void free_clients(struct clients *clients)
+{
+   struct client *c;
+   unsigned int tmp;
+
+   for_each_client(clients, c, tmp) {
+   free(c->val);
+   free(c->last);
+   }
+
+   free(clients->client);
+   free(clients);
+}
+
+static struct clients *scan_clients(struct clients *clients)
 {
struct dirent *dent;
struct client *c;
@@ -1022,7 +1112,7 @@ static void scan_clients(struct clients *clients)
DIR *d;
 
if (!clients)
-   return;
+   return clients;
 
for_each_client(clients, c, tmp) {
 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Check for scratch page scribbling (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Check for scratch page scribbling (rev2)
URL   : https://patchwork.freedesktop.org/series/86939/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/gt/intel_gtt.o
drivers/gpu/drm/i915/gt/intel_gtt.c: In function ‘poison_scratch_page’:
drivers/gpu/drm/i915/gt/intel_gtt.c:161:18: error: ‘pages’ undeclared (first 
use in this function); did you mean ‘page’?
   set_page_dirty(pages); /* keep the poisoned contents */
  ^
  page
drivers/gpu/drm/i915/gt/intel_gtt.c:161:18: note: each undeclared identifier is 
reported only once for each function it appears in
scripts/Makefile.build:279: recipe for target 
'drivers/gpu/drm/i915/gt/intel_gtt.o' failed
make[4]: *** [drivers/gpu/drm/i915/gt/intel_gtt.o] Error 1
scripts/Makefile.build:496: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:496: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:496: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1800: recipe for target 'drivers' failed
make: *** [drivers] Error 2


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/vblank: Document drm_crtc_vblank_restore constraints

[Daniel Vetter]

On Tue, Feb 09, 2021 at 05:36:07PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 09, 2021 at 11:15:23AM +0100, Daniel Vetter wrote:
> > I got real badly confused when trying to review a fix from Ville for
> > this. Let's try to document better what's required for this, and check
> > the minimal settings at runtime - we can't check ofc that there's
> > indeed no races in the driver callback.
> > 
> > Also noticed that the drm_vblank_restore version is unused, so lets
> > unexport that while at it.
> > 
> > Cc: Ville Syrjala 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_vblank.c | 25 ++---
> >  include/drm/drm_vblank.h |  1 -
> >  2 files changed, 10 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index c914b14cfb43..05f4d4c078fd 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -1471,20 +1471,7 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
> >  }
> >  EXPORT_SYMBOL(drm_crtc_vblank_on);
> >  
> > -/**
> > - * drm_vblank_restore - estimate missed vblanks and update vblank count.
> > - * @dev: DRM device
> > - * @pipe: CRTC index
> > - *
> > - * Power manamement features can cause frame counter resets between vblank
> > - * disable and enable. Drivers can use this function in their
> > - * &drm_crtc_funcs.enable_vblank implementation to estimate missed vblanks 
> > since
> > - * the last &drm_crtc_funcs.disable_vblank using timestamps and update the
> > - * vblank counter.
> > - *
> > - * This function is the legacy version of drm_crtc_vblank_restore().
> > - */
> > -void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
> > +static void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
> >  {
> > ktime_t t_vblank;
> > struct drm_vblank_crtc *vblank;
> > @@ -1520,7 +1507,6 @@ void drm_vblank_restore(struct drm_device *dev, 
> > unsigned int pipe)
> > diff, diff_ns, framedur_ns, cur_vblank - vblank->last);
> > store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
> >  }
> > -EXPORT_SYMBOL(drm_vblank_restore);
> >  
> >  /**
> >   * drm_crtc_vblank_restore - estimate missed vblanks and update vblank 
> > count.
> > @@ -1531,9 +1517,18 @@ EXPORT_SYMBOL(drm_vblank_restore);
> >   * &drm_crtc_funcs.enable_vblank implementation to estimate missed vblanks 
> > since
> >   * the last &drm_crtc_funcs.disable_vblank using timestamps and update the
> >   * vblank counter.
> > + *
> > + * Note that drivers must have race-free high-precision timestamping 
> > support,
> > + * i.e.  &drm_crtc_funcs.get_vblank_timestamp must be hooked up and
> > + * &drm_driver.vblank_disable_immediate must be set to indicate the
> > + * time-stamping functions are race-free against vblank hardware counter
> > + * increments.
> 
> Looks good. Might prevent someone from shooting themselves in
> the foot.

Yeah hopefully, maybe even me :-)


> 
> Reviewed-by: Ville Syrjälä 

Thanks for your review, I pushed to drm-misc-next.
-Daniel

> 
> >   */
> >  void drm_crtc_vblank_restore(struct drm_crtc *crtc)
> >  {
> > +   WARN_ON_ONCE(!crtc->funcs->get_vblank_timestamp);
> > +   WARN_ON_ONCE(!crtc->dev->vblank_disable_immediate);
> > +
> > drm_vblank_restore(crtc->dev, drm_crtc_index(crtc));
> >  }
> >  EXPORT_SYMBOL(drm_crtc_vblank_restore);
> > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> > index dd125f8c766c..733a3e2d1d10 100644
> > --- a/include/drm/drm_vblank.h
> > +++ b/include/drm/drm_vblank.h
> > @@ -247,7 +247,6 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc);
> >  void drm_crtc_vblank_reset(struct drm_crtc *crtc);
> >  void drm_crtc_vblank_on(struct drm_crtc *crtc);
> >  u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
> > -void drm_vblank_restore(struct drm_device *dev, unsigned int pipe);
> >  void drm_crtc_vblank_restore(struct drm_crtc *crtc);
> >  
> >  void drm_calc_timestamping_constants(struct drm_crtc *crtc,
> > -- 
> > 2.30.0
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Check for scratch page scribbling

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Check for scratch page scribbling
URL   : https://patchwork.freedesktop.org/series/86940/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/in

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check for scratch page scribbling

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2021-02-10 10:49:55)
>> Chris Wilson  writes:
>> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
>> > b/drivers/gpu/drm/i915/gt/intel_gtt.c
>> > index d34770ae4c9a..5ac9eb4a3a92 100644
>> > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
>> > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
>> > @@ -158,10 +158,49 @@ static void poison_scratch_page(struct 
>> > drm_i915_gem_object *scratch)
>> >  
>> >   vaddr = kmap(page);
>> >   memset(vaddr, val, PAGE_SIZE);
>> > + set_page_dirty(page); /* keep the poisoned contents */
>> 
>> Should we use locked version in here?
>
> We don't hold the page-lock here, so no. If this is not an anonymous
> page, something is very wrong :p

Cleared confusion in irc. We dont hold the lock and set_page_dirty dont
take it.

But this is anonymous page and we are sole user during poisoning.

Reviewed-by: Mika Kuoppala 

> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/adl_s: Add gmbus pin mapping

[Anand Moon]

Add table to map the GMBUS pin pairs to GPIO registers and port to DDC
mapping for ADL_S as per below Bspec.

Bspec:20124, 53597.

Cc: Aditya Swarup 
Cc: Matt Roper 
Cc: Lucas De Marchi 
Signed-off-by: Anand Moon 
---
 drivers/gpu/drm/i915/display/intel_gmbus.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 0c952e1d720e..58b8e42d4f90 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -52,6 +52,14 @@ static const struct gmbus_pin gmbus_pins[] = {
[GMBUS_PIN_DPD] = { "dpd", GPIOF },
 };
 
+static const struct gmbus_pin gmbus_pins_adls[] = {
+   [GMBUS_PIN_1_BXT] = { "edp", GPIOA },
+   [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOD },
+   [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOE },
+   [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOF },
+   [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOG },
+};
+
 static const struct gmbus_pin gmbus_pins_bdw[] = {
[GMBUS_PIN_VGADDC] = { "vga", GPIOA },
[GMBUS_PIN_DPC] = { "dpc", GPIOD },
@@ -101,7 +109,9 @@ static const struct gmbus_pin gmbus_pins_dg1[] = {
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
+   if (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)
+   return &gmbus_pins_adls[pin];
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
return &gmbus_pins_dg1[pin];
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
return &gmbus_pins_icp[pin];
@@ -122,7 +132,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
+   if (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)
+   size = ARRAY_SIZE(gmbus_pins_adls);
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
size = ARRAY_SIZE(gmbus_pins_dg1);
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
size = ARRAY_SIZE(gmbus_pins_icp);
-- 
2.30.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling

[Juha-Pekka Heikkila]

On 9.2.2021 17.21, Ville Syrjälä wrote:

On Tue, Feb 09, 2021 at 09:22:09AM +, Chris Wilson wrote:

Quoting Ville Syrjala (2021-02-09 02:19:16)

From: Ville Syrjälä 

ilk+ planes get notably unhappy when the plane x+w exceeds
the stride. This wasn't a problem previously because we
always aligned SURF to the closest tile boundary so the
x offset never got particularly large. But now with async
flips we have to align to 256KiB instead and thus this
becomes a real issue.

On ilk/snb/ivb it looks like the accesses just just wrap
early to the next tile row when scanout goes past the
SURF+n*stride boundary, hsw/bdw suffer more heavily and
start to underrun constantly. i965/g4x appear to be immune.
vlv/chv I've not yet checked.

Let's borrow another trick from the skl+ code and search
backwards for a better SURF offset in the hopes of getting the
x offset below the limit. IIRC when I ran into a similar issue
on skl years ago it was causing the hardware to fall over
pretty hard as well.

And let's be consistent and include i965/g4x in the check
as well, just in case I just got super lucky somehow when
I wasn't able to reproduce the issue. Not that it really
matters since we still use 4k SURF alignment for i965/g4x
anyway.

Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv")
Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb")
Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw")
Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw")
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/i9xx_plane.c | 27 +++
  1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 0523e2c79d16..8a52beaed2da 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -255,6 +255,33 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
 else
 offset = 0;
  
+   /*

+* When using an X-tiled surface the plane starts to
+* misbehave if the x offset + width exceeds the stride.
+* hsw/bdw: underrun galore
+* ilk/snb/ivb: wrap to the next tile row mid scanout
+* i965/g4x: so far appear immune to this
+* vlv/chv: TODO check
+*
+* Linear surfaces seem to work just fine, even on hsw/bdw
+* despite them not using the linear offset anymore.
+*/
+   if (INTEL_GEN(dev_priv) >= 4 && fb->modifier == 
I915_FORMAT_MOD_X_TILED) {
+   u32 alignment = intel_surf_alignment(fb, 0);
+   int cpp = fb->format->cpp[0];
+
+   while ((src_x + src_w) * cpp > 
plane_state->color_plane[0].stride) {
+   if (offset == 0) {
+   drm_dbg_kms(&dev_priv->drm,
+   "Unable to find suitable display surface 
offset due to X-tiling\n");
+   return -EINVAL;
+   }
+
+   offset = intel_plane_adjust_aligned_offset(&src_x, 
&src_y, plane_state, 0,
+  offset, 
offset - alignment);


As offset decreases, src_x goes up; but modulus the pitch. So long as
the alignment is not a multiple of the pitch, src_x will change on each
iteration. And after the adjustment, the offset is stored in
plane_state.

So this loop would fail for any power-of-two stride, but at the same
time that would put the src_x + src_w out-of-bounds in the supplied
coordinates. The only way src_x + src_w would exceed stride legally is
if we have chosen an aligned offset that causes that, thus there should
exist an offset where src_x + src_w does not exceed the stride.

The reason for choosing a nearby tile offset was to reduce src_x/src_y
to fit within the crtc limits. While remapping could be used to solve
that, the aligned_offset computation allows reuse of a single view.

Since offset, src_x are a function of the plane input parameters, this
should be possible to exercise with carefully selected framebuffers and
modesetting. Right? Is there a test case for this?


My idea was to extend kms_big_fb for these sort of things.
While I originally made it purely to test remapping it should
be possible to extend it for non-remapped fbs as well. IIRC
J-P did at least some work towards that goal, but I guess
it's only in the internal copy for whatever reason.


There are those max-hw-stride subtests in kms_big_fb which would go for 
this but it's all in internal trees.


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Check for scratch page scribbling

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Check for scratch page scribbling
URL   : https://patchwork.freedesktop.org/series/86940/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9757 -> Patchwork_19651


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- fi-skl-guc: [PASS][1] -> [DMESG-WARN][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-skl-guc/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-skl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@gem:
- fi-kbl-guc: [PASS][3] -> [DMESG-WARN][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-kbl-guc/igt@i915_selftest@l...@gem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-kbl-guc/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@gem_contexts:
- fi-byt-j1900:   [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-byt-j1900/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-byt-j1900/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@mman:
- fi-kbl-r:   [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-kbl-r/igt@i915_selftest@l...@mman.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-kbl-r/igt@i915_selftest@l...@mman.html
- fi-skl-6700k2:  [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-skl-6700k2/igt@i915_selftest@l...@mman.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-skl-6700k2/igt@i915_selftest@l...@mman.html
- fi-ivb-3770:[PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-ivb-3770/igt@i915_selftest@l...@mman.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-ivb-3770/igt@i915_selftest@l...@mman.html
- fi-kbl-x1275:   [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-kbl-x1275/igt@i915_selftest@l...@mman.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-kbl-x1275/igt@i915_selftest@l...@mman.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-hsw-4770:[PASS][15] -> [DMESG-WARN][16] +4 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-hsw-4770/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-hsw-4770/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_suspend@basic-s0:
- {fi-hsw-gt1}:   [PASS][17] -> [DMESG-WARN][18] +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-hsw-gt1/igt@gem_exec_susp...@basic-s0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-hsw-gt1/igt@gem_exec_susp...@basic-s0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][19] ([fdo#109315] / [i915#2575])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@fbdev@write:
- fi-tgl-y:   [PASS][20] -> [DMESG-WARN][21] ([i915#402]) +2 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-tgl-y/igt@fb...@write.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-tgl-y/igt@fb...@write.html

  * igt@i915_selftest@live@gem_contexts:
- fi-ivb-3770:[PASS][22] -> [INCOMPLETE][23] ([i915#2782])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-ivb-3770/igt@i915_selftest@live@gem_contexts.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19651/fi-ivb-3770/igt@i915_selftest@live@gem_contexts.html
- fi-hsw-4770:[PASS][24] -> [INCOMPLETE][25] ([i915#278

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Correct surface base address

[Chris Wilson]

Quoting Mika Kuoppala (2021-02-10 10:50:18)
> Chris Wilson  writes:
> 
> > The surface_state_base is an offset into the batch, so we need to pass
> > the correct batch address for STATE_BASE_ADDRESS.
> >
> > Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Prathap Kumar Valsan 
> > Cc: Akeem G Abodunrin 
> 
> Reviewed-by: Mika Kuoppala 

Compared against https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7571/index.html
I think we've found our suspect.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI] drm/i915/gt: Correct surface base address for renderclear

[Chris Wilson]

The surface_state_base is an offset into the batch, so we need to pass
the correct batch address for STATE_BASE_ADDRESS.

Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Prathap Kumar Valsan 
Cc: Akeem G Abodunrin 
Cc: Hans de Goede 
Reviewed-by: Mika Kuoppala 
Cc:  # v5.7+
---
 drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
index e403eb046a43..de575fdb033f 100644
--- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -240,7 +240,7 @@ gen7_emit_state_base_address(struct batch_chunk *batch,
/* general */
*cs++ = batch_addr(batch) | BASE_ADDRESS_MODIFY;
/* surface */
-   *cs++ = batch_addr(batch) | surface_state_base | BASE_ADDRESS_MODIFY;
+   *cs++ = (batch_addr(batch) + surface_state_base) | BASE_ADDRESS_MODIFY;
/* dynamic */
*cs++ = batch_addr(batch) | BASE_ADDRESS_MODIFY;
/* indirect */
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup

[Daniel Vetter]

On Wed, Feb 10, 2021 at 08:52:29AM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 09.02.21 um 11:54 schrieb Daniel Vetter:
> > *: vmwgfx is the only non-gem driver, but there's plans to move at least
> > vmwgfx internals (maybe not the uapi, we'll see) over to gem. Once that's
> > done it's truly all gpu memory.
> 
> Do you have a URL to the discussion?
> 
> While I recent worked on GEM, I thought that vmwgfx could easily switch to
> the GEM internals without adopting the interface.

Zack Rusin pinged me on irc I think, not sure there's anything on
dri-devel. zackr on freenode. I think he's working on this already.

> Personally, I think we should consider renaming struct drm_gem_object et al.
> It's not strictly GEM UAPI, but nowadays anything memory-related. Maybe
> drm_mem_object would fit.

I think abbrevations we've created that have been around for long enough
can stay. Otherwise we'd need to rename drm into something less confusing
too :-)

So gem just becomes the buffer based memory management thing in drm, which
is the accelerator and display framework in upstream. And ttm is our
memory manager for discrete gpus - ttm means translation table manager,
and that part just got moved out as a helper so drivers call we needed :-)

I mean we haven't even managed to rename the cma helpers to dma helpers.
The one thing we did manage is rename struct fence to struct dma_fence,
because no prefix was just really bad naming accident.

Cheers, Daniel

> 
> Best regards
> Thomas
> 
> > > ---
> > >   drivers/gpu/drm/drm_gem.c | 89 +++
> > >   include/drm/drm_gem.h | 17 
> > >   2 files changed, 106 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > index c2ce78c4edc3..a12da41eaafe 100644
> > > --- a/drivers/gpu/drm/drm_gem.c
> > > +++ b/drivers/gpu/drm/drm_gem.c
> > > @@ -29,6 +29,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -112,6 +113,89 @@ drm_gem_init(struct drm_device *dev)
> > >   return drmm_add_action(dev, drm_gem_init_release, NULL);
> > >   }
> > > +/**
> > > + * drm_gem_object_set_cgroup - associate GEM object with a cgroup
> > > + * @obj: GEM object which is being associated with a cgroup
> > > + * @task: task associated with process control group to use
> > > + *
> > > + * This will acquire a reference on cgroup and use for charging GEM
> > > + * memory allocations.
> > > + * This helper could be extended in future to migrate charges to another
> > > + * cgroup, print warning if this usage occurs.
> > > + */
> > > +void drm_gem_object_set_cgroup(struct drm_gem_object *obj,
> > > +struct task_struct *task)
> > > +{
> > > + /* if object has existing cgroup, we migrate the charge... */
> > > + if (obj->drmcg) {
> > > + pr_warn("DRM: need to migrate cgroup charge of %lld\n",
> > > + atomic64_read(&obj->drmcg_bytes_charged));
> > > + }
> > > + obj->drmcg = drmcg_get(task);
> > > +}
> > > +EXPORT_SYMBOL(drm_gem_object_set_cgroup);
> > > +
> > > +/**
> > > + * drm_gem_object_unset_cgroup - clear GEM object's associated cgroup
> > > + * @obj: GEM object
> > > + *
> > > + * This will release a reference on cgroup.
> > > + */
> > > +void drm_gem_object_unset_cgroup(struct drm_gem_object *obj)
> > > +{
> > > + WARN_ON(atomic64_read(&obj->drmcg_bytes_charged));
> > > + drmcg_put(obj->drmcg);
> > > +}
> > > +EXPORT_SYMBOL(drm_gem_object_unset_cgroup);
> > > +
> > > +/**
> > > + * drm_gem_object_charge_mem - try charging size bytes to DRM cgroup
> > > + * @obj: GEM object which is being charged
> > > + * @size: number of bytes to charge
> > > + *
> > > + * Try to charge @size bytes to GEM object's associated DRM cgroup.  This
> > > + * will fail if a successful charge would cause the current device memory
> > > + * usage to go above the cgroup's GPU memory maximum limit.
> > > + *
> > > + * Returns 0 on success.  Otherwise, an error code is returned.
> > > + */
> > > +int drm_gem_object_charge_mem(struct drm_gem_object *obj, u64 size)
> > > +{
> > > + int ret;
> > > +
> > > + ret = drm_cgroup_try_charge(obj->drmcg, obj->dev,
> > > + DRMCG_TYPE_MEM_CURRENT, size);
> > > + if (!ret)
> > > + atomic64_add(size, &obj->drmcg_bytes_charged);
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(drm_gem_object_charge_mem);
> > > +
> > > +/**
> > > + * drm_gem_object_uncharge_mem - uncharge size bytes from DRM cgroup
> > > + * @obj: GEM object which is being uncharged
> > > + * @size: number of bytes to uncharge
> > > + *
> > > + * Uncharge @size bytes from the DRM cgroup associated with specified
> > > + * GEM object.
> > > + *
> > > + * Returns 0 on success.  Otherwise, an error code is returned.
> > > + */
> > > +void drm_gem_object_uncharge_mem(struct drm_gem_object *obj, u64 size)
> > > +{
> > > + u64 charged = atomic64_read(&obj->drmcg_bytes_cha

Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues

[Chris Wilson]

Quoting Hans de Goede (2021-02-10 10:37:19)
> Hi,
> 
> On 2/10/21 12:07 AM, Chris Wilson wrote:
> > Quoting Hans de Goede (2021-02-09 11:46:46)
> >> Hi,
> >>
> >> On 2/9/21 12:27 AM, Chris Wilson wrote:
> >>> Quoting Hans de Goede (2021-02-08 20:38:58)
>  Hi All,
> 
>  We (Fedora) have been receiving reports from multiple users about gfx 
>  issues / glitches
>  stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell 
>  iGPUs and all
>  reporters report that adding i915.mitigations=off to the cmdline fixes 
>  things, see:
> >>>
> >>> I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
> >>> did not report any differences with and without mitigations. I have yet
> >>> to test other platforms. So I don't yet have an alternative.
> >>
> >> Note the original / first reporter of:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1925346
> >>
> >> Is using hsw-gt2, so it seems that the problem is not just the enabling of
> >> the mitigations on ivy-bridge / bay-trail but that there actually is
> >> a regression on devices where the WA worked fine before...
> > 
> > There have been 3 crashes uploaded related to v5.10.9, and in all 3
> > cases the ACTHD has been in the first page. This strongly suggests that
> > the w/a is scribbling over address 0. And there's then a very good
> > chance that
> > 
> > commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6
> > Author: Chris Wilson 
> > Date:   Mon Jan 25 12:50:33 2021 +
> > 
> > drm/i915/gt: Always try to reserve GGTT address 0x0
> > 
> > commit 489140b5ba2e7cc4b853c29e0591895ddb462a82 upstream.
> > 
> > in v5.10.14 is sufficient to hide the issue.
> 
> That one actually is already in v5.10.13 and the various reportes of these
> issues have already tested 5.10.13. They did mention that it took longer
> to reproduce with 5.10.13 then with 5.10.10, but that could also be due to:
> 
> "drm/i915/gt: Clear CACHE_MODE prior to clearing residuals"
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=520d05a77b2866eb4cb9e548e1d8c8abcfe60ec5

Started looking for scratch page overwrites, and found this little gem:
https://patchwork.freedesktop.org/patch/420436/?series=86947&rev=1

Looks promising wrt the cause of overwriting random addresses -- and
I hope that is the explanation for the glitches/hangs. I have a hsw gt2
with gnome shell, piglit is happy, but I suspect it is all due to
placement and so will only occur at random.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_s: Add gmbus pin mapping

[Patchwork]

== Series Details ==

Series: drm/i915/adl_s: Add gmbus pin mapping
URL   : https://patchwork.freedesktop.org/series/86944/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9757 -> Patchwork_19652


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [DMESG-WARN][1] ([i915#2411] / [i915#402]) -> 
[PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: [DMESG-FAIL][3] ([i915#3047]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-glk-dsi/igt@i915_selftest@l...@client.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/fi-glk-dsi/igt@i915_selftest@l...@client.html

  
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-apl-guc fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9757 -> Patchwork_19652

  CI-20190529: 20190529
  CI_DRM_9757: fbcc37cd0591950c13a233a364342d873539d12f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6000: 72fcf1364781a401374dcff43b00db8e722cd47b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19652: ce88e6504d0f01c482977ec879466d00e4636265 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ce88e6504d0f drm/i915/adl_s: Add gmbus pin mapping

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"

[Daniel Vetter]

On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> This reverts commit fb6473a48b635c55d04eb94e579eede52ef39550.
> 
> These additional checks added to avoid EBUSY give unnecessary WARN_ON
> in case of big joiner used in i915 in which case even if the modeset
> is requested on a single pipe, internally another consecutive
> pipe is stolen and used to drive half of the transcoder timings.
> So in this case it is expected that requested crtc and affected crtcs
> do not match. Hence the added WARN ON becomes irrelevant.
> But there is no easy solution to get the bigjoiner information
> here at drm level. So for now revert this until we work out
> a better solution.
> 
> Cc: Ville Syrjala 
> Cc: Daniel Vetter 
> Signed-off-by: Manasi Navare 

Nope. We can maybe rework this so that i915 can do stuff under the hood,
but wrt uapi this was the thing we discussed with compositors. Without
such a guarantee atomic is defacto broken from a compositor pov.

This WARN_ON is not unecessary, compositor people really do not want the
kernel to throw around spurious EBUSY they have no visibility into.

Please also cc all the compositor people from my original patch if you
change anything in this area.
-Daniel


> ---
>  drivers/gpu/drm/drm_atomic.c | 29 -
>  1 file changed, 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index b1efa9322be2..48b2262d69f6 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -320,10 +320,6 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
>   * needed. It will also grab the relevant CRTC lock to make sure that the 
> state
>   * is consistent.
>   *
> - * WARNING: Drivers may only add new CRTC states to a @state if
> - * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
> - * not created by userspace through an IOCTL call.
> - *
>   * Returns:
>   *
>   * Either the allocated state or the error code encoded into the pointer. 
> When
> @@ -1306,15 +1302,10 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   struct drm_crtc_state *new_crtc_state;
>   struct drm_connector *conn;
>   struct drm_connector_state *conn_state;
> - unsigned requested_crtc = 0;
> - unsigned affected_crtc = 0;
>   int i, ret = 0;
>  
>   DRM_DEBUG_ATOMIC("checking %p\n", state);
>  
> - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> - requested_crtc |= drm_crtc_mask(crtc);
> -
>   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
> new_plane_state, i) {
>   ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
>   if (ret) {
> @@ -1362,26 +1353,6 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   }
>   }
>  
> - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> - affected_crtc |= drm_crtc_mask(crtc);
> -
> - /*
> -  * For commits that allow modesets drivers can add other CRTCs to the
> -  * atomic commit, e.g. when they need to reallocate global resources.
> -  * This can cause spurious EBUSY, which robs compositors of a very
> -  * effective sanity check for their drawing loop. Therefor only allow
> -  * drivers to add unrelated CRTC states for modeset commits.
> -  *
> -  * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> -  * so compositors know what's going on.
> -  */
> - if (affected_crtc != requested_crtc) {
> - DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x, 
> affected 0x%0x\n",
> -  requested_crtc, affected_crtc);
> - WARN(!state->allow_modeset, "adding CRTC not allowed without 
> modesets: requested 0x%x, affected 0x%0x\n",
> -  requested_crtc, affected_crtc);
> - }
> -
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_check_only);
> -- 
> 2.19.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"

[Simon Ser]

On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter  
wrote:

> On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
>
> > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > in case of big joiner used in i915 in which case even if the modeset
> > is requested on a single pipe, internally another consecutive
> > pipe is stolen and used to drive half of the transcoder timings.
> > So in this case it is expected that requested crtc and affected crtcs
> > do not match. Hence the added WARN ON becomes irrelevant.

The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
then the driver is allowed to steal an unrelated pipe.

Maybe i915 is stealing a pipe without allow_modeset?

> Nope. We can maybe rework this so that i915 can do stuff under the hood,
> but wrt uapi this was the thing we discussed with compositors. Without
> such a guarantee atomic is defacto broken from a compositor pov.

Agreed.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Correct surface base address for renderclear

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Correct surface base address for renderclear
URL   : https://patchwork.freedesktop.org/series/86947/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9757 -> Patchwork_19653


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][3] -> [INCOMPLETE][4] ([i915#142] / 
[i915#2405])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@runner@aborted:
- fi-kbl-r:   NOTRUN -> [FAIL][5] ([i915#1569] / [i915#192] / 
[i915#193] / [i915#194] / [i915#2295])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/fi-kbl-r/igt@run...@aborted.html
- fi-byt-j1900:   NOTRUN -> [FAIL][6] ([i915#1814] / [i915#2505])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/fi-byt-j1900/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#2411] / [i915#402]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_flink_basic@bad-flink:
- fi-tgl-y:   [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: [DMESG-FAIL][11] ([i915#3047]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/fi-glk-dsi/igt@i915_selftest@l...@client.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/fi-glk-dsi/igt@i915_selftest@l...@client.html

  
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 40)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9757 -> Patchwork_19653

  CI-20190529: 20190529
  CI_DRM_9757: fbcc37cd0591950c13a233a364342d873539d12f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6000: 72fcf1364781a401374dcff43b00db8e722cd47b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19653: 68013951f2c3c244d94c3ab05c4f14a3418ff7df @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

68013951f2c3 drm/i915/gt: Correct surface base address for renderclear

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Thomas Zimmermann]

Hi Dave and Daniel,

here's this week's PR for drm-misc-fixes. There's a buffer overflow in vc4
and a memory leak in xlnx. The rest appear to be mere bug fixes.

Best regards
Thomas

drm-misc-fixes-2021-02-10:
 * dp_mst: Don't report un-attached ports as connected
 * sun4i: tcon1 sync polarity fix; Always set HDMI clock rate; Fix
  H6 HDMI PHY config; Fix H6 max frequency
 * vc4: Fix buffer overflow
 * xlnx: Fix memory leak
The following changes since commit 2b1b3e544f65f40df5eef99753e460a127910479:

  drm/ttm: Use __GFP_NOWARN for huge pages in ttm_pool_alloc_page (2021-01-28 
13:01:52 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-02-10

for you to fetch changes up to 1926a0508d8947cf081280d85ff035300dc71da7:

  drm/sun4i: dw-hdmi: Fix max. frequency for H6 (2021-02-10 11:20:38 +0100)


 * dp_mst: Don't report un-attached ports as connected
 * sun4i: tcon1 sync polarity fix; Always set HDMI clock rate; Fix
  H6 HDMI PHY config; Fix H6 max frequency
 * vc4: Fix buffer overflow
 * xlnx: Fix memory leak


Imre Deak (1):
  drm/dp_mst: Don't report ports connected if nothing is attached to them

Jernej Skrabec (4):
  drm/sun4i: tcon: set sync polarity for tcon1 channel
  drm/sun4i: dw-hdmi: always set clock rate
  drm/sun4i: Fix H6 HDMI PHY configuration
  drm/sun4i: dw-hdmi: Fix max. frequency for H6

Maxime Ripard (1):
  drm/vc4: hvs: Fix buffer overflow with the dlist handling

Quanyang Wang (1):
  drm/xlnx: fix kmemleak by sending vblank_event in atomic_disable

 drivers/gpu/drm/drm_dp_mst_topology.c  |  1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 +
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  6 ++
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c  | 10 +++---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  |  1 -
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 26 +-
 drivers/gpu/drm/vc4/vc4_plane.c| 18 ++
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 15 +++
 8 files changed, 65 insertions(+), 37 deletions(-)

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Maarten Lankhorst]

Op 2021-02-10 om 04:11 schreef Stephen Rothwell:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/v3d/v3d_sched.c:263:1: error: return type is an incomplete 
> type
>   263 | v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job 
> *sched_job)
>   | ^
> drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_gpu_reset_for_timeout':
> drivers/gpu/drm/v3d/v3d_sched.c:289:9: error: 'return' with a value, in 
> function returning void [-Werror=return-type]
>   289 |  return DRM_GPU_SCHED_STAT_NOMINAL;
>   | ^~
> drivers/gpu/drm/v3d/v3d_sched.c:263:1: note: declared here
>   263 | v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job 
> *sched_job)
>   | ^
> drivers/gpu/drm/v3d/v3d_sched.c: At top level:
> drivers/gpu/drm/v3d/v3d_sched.c:298:1: error: return type is an incomplete 
> type
>   298 | v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
>   | ^~~
> drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_cl_job_timedout':
> drivers/gpu/drm/v3d/v3d_sched.c:309:10: error: 'return' with a value, in 
> function returning void [-Werror=return-type]
>   309 |   return DRM_GPU_SCHED_STAT_NOMINAL;
>   |  ^~
> drivers/gpu/drm/v3d/v3d_sched.c:298:1: note: declared here
>   298 | v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
>   | ^~~
> drivers/gpu/drm/v3d/v3d_sched.c: At top level:
> drivers/gpu/drm/v3d/v3d_sched.c:316:1: error: return type is an incomplete 
> type
>   316 | v3d_bin_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:325:1: error: return type is an incomplete 
> type
>   325 | v3d_render_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~
> drivers/gpu/drm/v3d/v3d_sched.c:334:1: error: return type is an incomplete 
> type
>   334 | v3d_generic_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:342:1: error: return type is an incomplete 
> type
>   342 | v3d_csd_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_csd_job_timedout':
> drivers/gpu/drm/v3d/v3d_sched.c:353:10: error: 'return' with a value, in 
> function returning void [-Werror=return-type]
>   353 |   return DRM_GPU_SCHED_STAT_NOMINAL;
>   |  ^~
> drivers/gpu/drm/v3d/v3d_sched.c:342:1: note: declared here
>   342 | v3d_csd_job_timedout(struct drm_sched_job *sched_job)
>   | ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c: At top level:
> drivers/gpu/drm/v3d/v3d_sched.c:362:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   362 |  .timedout_job = v3d_bin_job_timedout,
>   |  ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:362:18: note: (near initialization for 
> 'v3d_bin_sched_ops.timedout_job')
> drivers/gpu/drm/v3d/v3d_sched.c:369:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   369 |  .timedout_job = v3d_render_job_timedout,
>   |  ^~~
> drivers/gpu/drm/v3d/v3d_sched.c:369:18: note: (near initialization for 
> 'v3d_render_sched_ops.timedout_job')
> drivers/gpu/drm/v3d/v3d_sched.c:376:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   376 |  .timedout_job = v3d_generic_job_timedout,
>   |  ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:376:18: note: (near initialization for 
> 'v3d_tfu_sched_ops.timedout_job')
> drivers/gpu/drm/v3d/v3d_sched.c:383:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   383 |  .timedout_job = v3d_csd_job_timedout,
>   |  ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:383:18: note: (near initialization for 
> 'v3d_csd_sched_ops.timedout_job')
> drivers/gpu/drm/v3d/v3d_sched.c:390:18: error: initialization of 'enum 
> drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer 
> type 'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
>   390 |  .timedout_job = v3d_generic_job_timedout,
>   |  ^~~~
> drivers/gpu/drm/v3d/v3d_sched.c:390:18: note: (near initia

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries

[Souza, Jose]

On Tue, 2021-02-09 at 22:22 +, Patchwork wrote:
Patch Details
Series: drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries
URL:https://patchwork.freedesktop.org/series/86908/
State:  success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/index.html
CI Bug Log - changes from CI_DRM_9752_full -> Patchwork_19643_full
Summary

SUCCESS

No regressions found.

Pushed, thanks for the review Matt.

Known issues

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

IGT changes
Issues hit

  *   igt@gem_ctx_isolation@preservation-s3@bcs0:

 *   shard-kbl: 
PASS
 -> 
DMESG-WARN
 ([i915#180]) +3 similar issues
  *   igt@gem_ctx_persistence@legacy-engines-persistence:

 *   shard-hsw: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#1099]) +1 similar issue
  *   igt@gem_eio@in-flight-suspend:

 *   shard-apl: 
PASS
 -> 
DMESG-WARN
 ([i915#1037] / [i915#180])
  *   igt@gem_eio@unwedge-stress:

 *   shard-tglb: 
PASS
 -> 
TIMEOUT
 ([i915#1037] / [i915#3063])
  *   igt@gem_exec_fair@basic-none-solo@rcs0:

 *   shard-kbl: 
PASS
 -> 
FAIL
 ([i915#2842])
  *   igt@gem_exec_fair@basic-pace-share@rcs0:

 *   shard-glk: 
PASS
 -> 
FAIL
 ([i915#2842])
  *   igt@gem_exec_fair@basic-sync@rcs0:

 *   shard-kbl: 
PASS
 -> 
SKIP
 ([fdo#109271])
  *   igt@gem_exec_reloc@basic-wide-active@rcs0:

 *   shard-kbl: NOTRUN -> 
FAIL
 ([i915#2389]) +4 similar issues
  *   igt@gem_exec_reloc@basic-wide-active@vcs1:

 *   shard-iclb: NOTRUN -> 
FAIL
 ([i915#2389])
  *   igt@gem_exec_schedule@u-fairslice@rcs0:

 *   shard-apl: 
PASS
 -> 
DMESG-WARN
 ([i915#1610])
  *   igt@gem_exec_schedule@u-fairslice@vcs0:

 *   shard-skl: 
PASS
 -> 
DMESG-WARN
 ([i915#1610] / [i915#2803])
  *   igt@gem_exec_whisper@basic-queues:

 *   shard-glk: 
PASS
 -> 
DMESG-WARN
 ([i915#118] / [i915#95])
  *   igt@gem_huc_copy@huc-copy:

 *   shard-apl: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#2190])
  *   igt@gem_pread@exhaustion:

 *   shard-kbl: NOTRUN -> 
WARN
 ([i915#2658])
  *   igt@gem_userptr_blits@process-exit-mmap-busy@wc:

 *   shard-apl: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#1699]) +3 similar issues
  *   igt@i915_pm_backlight@fade_with_suspend:

 *   shard-skl: 
PASS

Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"

[Ville Syrjälä]

On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote:
> On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter  
> wrote:
> 
> > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> >
> > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > in case of big joiner used in i915 in which case even if the modeset
> > > is requested on a single pipe, internally another consecutive
> > > pipe is stolen and used to drive half of the transcoder timings.
> > > So in this case it is expected that requested crtc and affected crtcs
> > > do not match. Hence the added WARN ON becomes irrelevant.
> 
> The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> then the driver is allowed to steal an unrelated pipe.
> 
> Maybe i915 is stealing a pipe without allow_modeset?

No. All page flips etc. will have to get split up internally
between multiple crtcs.

So I think there's basically three options:
a) massive rewrite of i915 to bypass even more of drm_atomic stuff
b) allow i915 to silence that warning, which opens up the question
   whether the warn is doing any good if it can just be bypassed
c) nuke the warning entirely

a) is not going to happen, and it would any way allow i915 to
do things any which way it wants without tripping the warn,
rendering the warn entirely toothless.

Hmm. Maybe there is a d) which would be to ignore all crtcs
that are not logically enabled in the warn? Not sure if that
could allow something to slit through that people want it to
catch?

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/adl_s: Add gmbus pin mapping

[Aditya Swarup]

On 2/10/21 3:54 AM, Anand Moon wrote:
> Add table to map the GMBUS pin pairs to GPIO registers and port to DDC
> mapping for ADL_S as per below Bspec.

Has this patch been tested on an ADLS system? Upstream CI AFAIK doesn't have
support for ADL-S. Also comments below..

> 
> Bspec:20124, 53597.
> 
> Cc: Aditya Swarup 
> Cc: Matt Roper 
> Cc: Lucas De Marchi 
> Signed-off-by: Anand Moon 
> ---
>  drivers/gpu/drm/i915/display/intel_gmbus.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index 0c952e1d720e..58b8e42d4f90 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -52,6 +52,14 @@ static const struct gmbus_pin gmbus_pins[] = {
>   [GMBUS_PIN_DPD] = { "dpd", GPIOF },
>  };
>  
> +static const struct gmbus_pin gmbus_pins_adls[] = {
> + [GMBUS_PIN_1_BXT] = { "edp", GPIOA },

I am pretty sure that GMBUS_PIN_1_BXT should map to GPIOB(1) and not GPIOA(0) 
like what we have for ICP.

> + [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOD },
> + [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOE },
> + [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOF },
> + [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOG },
> +};
> +
>  static const struct gmbus_pin gmbus_pins_bdw[] = {
>   [GMBUS_PIN_VGADDC] = { "vga", GPIOA },
>   [GMBUS_PIN_DPC] = { "dpc", GPIOD },
> @@ -101,7 +109,9 @@ static const struct gmbus_pin gmbus_pins_dg1[] = {
>  static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private 
> *dev_priv,
>unsigned int pin)
>  {
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)

This check should be converted to IS_ALDERLAKE_S(dev_priv) instead of PCH check 
for PCH_ADP.
Unfortunately, we are reusing PCH_ADP for ADLS and ADLP which have different 
mappings but the same ADP PCH.
This will break ADLP. 

The PCH_ADP check for ADLS in intel_bios.c will also be changed in the ADLP 
patches
that are going to be submitted upstream.

So might as well do the correct thing now and change this to 
IS_ALDERLAKE_S(dev_priv).

> + return &gmbus_pins_adls[pin];
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
>   return &gmbus_pins_dg1[pin];
>   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>   return &gmbus_pins_icp[pin];
> @@ -122,7 +132,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
> *dev_priv,
>  {
>   unsigned int size;
>  
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)

See comment above. Change to IS_ALDERLAKE_S(dev_priv)

Aditya Swarup

> + size = ARRAY_SIZE(gmbus_pins_adls);
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
>   size = ARRAY_SIZE(gmbus_pins_dg1);
>   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>   size = ARRAY_SIZE(gmbus_pins_icp);
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vbt: update DP max link rate table

[Ville Syrjälä]

On Mon, Feb 08, 2021 at 01:31:57PM +, Lee, Shawn C wrote:
> On Fri, Feb 05, 2021, at 8:26 p.m, Ville Syrjälä wrote:
> >On Mon, Feb 01, 2021 at 11:02:28PM +0800, Lee Shawn C wrote:
> >> According to Bspec #20124, max link rate table for DP was updated at 
> >> BDB version 230. Max link rate can support upto UHBR.
> >> 
> >> After migrate to BDB v230, the definition for LBR, HBR2 and HBR3 were 
> >> changed. For backward compatibility. If BDB version was from 216 to 
> >> 229. Driver have to follow original rule to configure DP max link rate 
> >> value from VBT.
> >> 
> >> Cc: Ville Syrjala 
> >> Cc: Imre Deak 
> >> Cc: Jani Nikula 
> >> Cc: Cooper Chiou 
> >> Cc: William Tseng 
> >> Signed-off-by: Lee Shawn C 
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_bios.c | 24 ++-
> >>  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 14 +++
> >>  2 files changed, 32 insertions(+), 6 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> >> b/drivers/gpu/drm/i915/display/intel_bios.c
> >> index 04337ac6f8c4..be1f732e6550 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> >> @@ -1876,7 +1876,15 @@ static void parse_ddi_port(struct drm_i915_private 
> >> *dev_priv,
> >>/* DP max link rate for CNL+ */
> >>if (bdb_version >= 216) {
> >>switch (child->dp_max_link_rate) {
> >> -  default:
> >> +  case VBT_DP_MAX_LINK_RATE_UHBR20:
> >> +  info->dp_max_link_rate = 200;
> >> +  break;
> >> +  case VBT_DP_MAX_LINK_RATE_UHBR13P5:
> >> +  info->dp_max_link_rate = 135;
> >> +  break;
> >> +  case VBT_DP_MAX_LINK_RATE_UHBR10:
> >> +  info->dp_max_link_rate = 100;
> >> +  break;
> >>case VBT_DP_MAX_LINK_RATE_HBR3:
> >>info->dp_max_link_rate = 81;
> >>break;
> >> @@ -1889,7 +1897,21 @@ static void parse_ddi_port(struct drm_i915_private 
> >> *dev_priv,
> >>case VBT_DP_MAX_LINK_RATE_LBR:
> >>info->dp_max_link_rate = 162000;
> >>break;
> >> +  case VBT_DP_MAX_LINK_RATE_DEFAULT:
> >> +  default:
> >> +  info->dp_max_link_rate = 0;
> >> +  break;
> >> +  }
> >> +
> >> +  if (bdb_version < 230) {
> >> +  if (child->dp_max_link_rate == 
> >> VBT_DP_MAX_LINK_RATE_DEFAULT)
> >> +  info->dp_max_link_rate = 81;
> >> +  else if (child->dp_max_link_rate == 
> >> VBT_DP_MAX_LINK_RATE_LBR)
> >> +  info->dp_max_link_rate = 54;
> >> +  else if (child->dp_max_link_rate == 
> >> VBT_DP_MAX_LINK_RATE_HBR2)
> >> +  info->dp_max_link_rate = 162000;
> >>}
> >
> >I would split this into two separate functions, one does the new mapping, 
> >the other the old mapping. 
> >
> 
> I will split this into two separate functions in patch v2.

Actually looking through the VBT history this seems to have been
retroactively changed for already rev 216+ to follow the new
definitions. And naturally no actual explanation given. So it's
the same old VBT==snafu as always.

I guess the real question is whether any machines migth have shipped
that depened on the old defitions? Unless someone manages to
find that out I think we might just have to change this to follow
only the new style and hope we don't regress a lot of machines.

I was a bit hopeful that this might have fixed [1], but looks
like that just has this set to 0 which doesn't give us the desired
2.7Gbps with either the old or new definition :(

[1] https://gitlab.freedesktop.org/drm/intel/-/issues/3034

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Lyude Paul]

On Wed, 2021-02-10 at 00:33 -0800, Khaled Almahallawy wrote:
> The number of AUX retries specified in the DP specs is 7. Currently, to make
> Dell 4k monitors happier, the number of retries are 32.
> i915 also retries 5 times (intel_dp_aux_xfer) which means in the case of AUX
> timeout we actually retries 32 * 5 = 160 times.

Is there any good reason for i915 to actually be doing retries itself? It seems
like an easier solution here might just to be to fix i915 so it doesn't retry,
and just rely on DRM to do the retries as appropriate.

That being said though, I'm open to this if there is a legitimate reason for
i915 to be handling retries on its own

> 
> So making the number of aux retires a variable to allow for fine tuning and
> optimization of aux timing.
> 
> Signed-off-by: Khaled Almahallawy 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 10 +++---
>  include/drm/drm_dp_helper.h |  1 +
>  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index eedbb48815b7..8fdf57b4a06c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -249,13 +249,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>  
> mutex_lock(&aux->hw_mutex);
>  
> -   /*
> -    * The specification doesn't give any recommendation on how often to
> -    * retry native transactions. We used to retry 7 times like for
> -    * aux i2c transactions but real world devices this wasn't
> -    * sufficient, bump to 32 which makes Dell 4k monitors happier.
> -    */
> -   for (retry = 0; retry < 32; retry++) {
> +   for (retry = 0; retry < aux->num_retries; retry++) {
> if (ret != 0 && ret != -ETIMEDOUT) {
> usleep_range(AUX_RETRY_INTERVAL,
>  AUX_RETRY_INTERVAL + 100);
> @@ -1744,6 +1738,8 @@ void drm_dp_aux_init(struct drm_dp_aux *aux)
> aux->ddc.retries = 3;
>  
> aux->ddc.lock_ops = &drm_dp_i2c_lock_ops;
> +   /*Still making the Dell 4k monitors happier*/
> +   aux->num_retries = 32;
>  }
>  EXPORT_SYMBOL(drm_dp_aux_init);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index edffd1dcca3e..16cbfc8f5e66 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1876,6 +1876,7 @@ struct drm_dp_aux {
> struct mutex hw_mutex;
> struct work_struct crc_work;
> u8 crc_count;
> +   int num_retries;
> ssize_t (*transfer)(struct drm_dp_aux *aux,
>     struct drm_dp_aux_msg *msg);
> /**

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] i915/perf: Drop the check for report reason in OA

[Umesh Nerlige Ramappa]

After fixing the OA_TAIL_PTR corruption, there are no more reports with
reason field of zero. Drop the check for report reason.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 93f3e2c5c89a..c15bead2dac7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -725,11 +725,6 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
  (IS_GEN(stream->perf->i915, 12) ?
   OAREPORT_REASON_MASK_EXTENDED :
   OAREPORT_REASON_MASK));
-   if (reason == 0) {
-   if (__ratelimit(&stream->perf->spurious_report_rs))
-   DRM_NOTE("Skipping spurious, invalid OA 
report\n");
-   continue;
-   }
 
ctx_id = report32[2] & stream->specific_ctx_id_mask;
 
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for i915/perf: Drop the check for report reason in OA (rev2)

[Patchwork]

== Series Details ==

Series: i915/perf: Drop the check for report reason in OA (rev2)
URL   : https://patchwork.freedesktop.org/series/84478/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9760 -> Patchwork_19654


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-byt-j1900:   NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][2] -> [INCOMPLETE][3] ([i915#2940])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [PASS][5] -> [DMESG-FAIL][6] ([i915#165])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-y:   [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/fi-tgl-y/igt@prime_v...@basic-userptr.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/fi-tgl-y/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-bsw-n3050:   NOTRUN -> [FAIL][9] ([i915#1436])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_flink_basic@bad-flink:
- fi-tgl-y:   [DMESG-WARN][10] ([i915#402]) -> [PASS][11] +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (43 -> 40)
--

  Additional (1): fi-byt-j1900 
  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9760 -> Patchwork_19654

  CI-20190529: 20190529
  CI_DRM_9760: eaeb42cad669bf4d427c416414d107e6b44f490e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19654: fa2658cd3a26e48ba79c19d11493a231db86d365 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fa2658cd3a26 i915/perf: Drop the check for report reason in OA

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adl_s: Add gmbus pin mapping

[Patchwork]

== Series Details ==

Series: drm/i915/adl_s: Add gmbus pin mapping
URL   : https://patchwork.freedesktop.org/series/86944/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9757_full -> Patchwork_19652_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_engines@execute-one:
- shard-snb:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-snb5/igt@gem_ctx_engi...@execute-one.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-snb6/igt@gem_ctx_engi...@execute-one.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-hostile:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-snb2/igt@gem_ctx_persiste...@engines-hostile.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#1037] / [i915#3063])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-tglb8/igt@gem_...@unwedge-stress.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-tglb6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-kbl2/igt@gem_exec_f...@basic-deadline.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-apl3/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][16] ([fdo#112283])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-iclb4/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_exec_reloc@basic-many-active@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][17] ([i915#2389]) +4 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-kbl2/igt@gem_exec_reloc@basic-many-act...@vcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][18] ([i915#2389]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-snb7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#2803])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-tglb2/igt@gem_exec_schedule@u-fairsl...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2190])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19652/shard-apl1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_workarounds@suspend-resume:
- shard-apl:  [PASS][22] 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Correct surface base address for renderclear

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Correct surface base address for renderclear
URL   : https://patchwork.freedesktop.org/series/86947/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9757_full -> Patchwork_19653_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@in-flight-contexts-1us:
- shard-skl:  [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-skl7/igt@gem_...@in-flight-contexts-1us.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-skl2/igt@gem_...@in-flight-contexts-1us.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@close-replace-race:
- shard-kbl:  NOTRUN -> [TIMEOUT][3] ([i915#2918])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-kbl7/igt@gem_ctx_persiste...@close-replace-race.html

  * igt@gem_ctx_persistence@engines-hostile:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-snb4/igt@gem_ctx_persiste...@engines-hostile.html

  * igt@gem_exec_balancer@hang:
- shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([i915#1895] / 
[i915#2295] / [i915#3031])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-iclb3/igt@gem_exec_balan...@hang.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-iclb4/igt@gem_exec_balan...@hang.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-kbl2/igt@gem_exec_f...@basic-deadline.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-kbl4/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][16] ([fdo#112283])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-iclb3/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_exec_reloc@basic-many-active@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][17] ([i915#2389]) +4 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-kbl7/igt@gem_exec_reloc@basic-many-act...@vcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][18] ([i915#2389]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#2803])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9757/shard-tglb2/igt@gem_exec_schedule@u-fairsl...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19653/shard-tglb5/igt@gem_exec_schedule@u-fairsl...@rcs0.html

  * igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk:  [PASS][21] -> [DMESG-WARN][22] ([i915#118] / 
[i915#95])
   [21]: 
https://intel-gfx-ci.01.org/tr

Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup

[Brian Welty]

On 2/9/2021 2:54 AM, Daniel Vetter wrote:
> On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote:
>> This patch adds tracking of which cgroup to make charges against for a
>> given GEM object.  We associate the current task's cgroup with GEM objects
>> as they are created.  First user of this is for charging DRM cgroup for
>> device memory allocations.  The intended behavior is for device drivers to
>> make the cgroup charging calls at the time that backing store is allocated
>> or deallocated for the object.
>>
>> Exported functions are provided for charging memory allocations for a
>> GEM object to DRM cgroup. To aid in debugging, we store how many bytes
>> have been charged inside the GEM object.  Add helpers for setting and
>> clearing the object's associated cgroup which will check that charges are
>> not being leaked.
>>
>> For shared objects, this may make the charge against a cgroup that is
>> potentially not the same cgroup as the process using the memory.  Based
>> on the memory cgroup's discussion of "memory ownership", this seems
>> acceptable [1].
>>
>> [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory 
>> Ownership"
>>
>> Signed-off-by: Brian Welty 
> 
> Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that
> counts everything, why don't we also charge in these gem functions?

I'm not sure what you mean exactly.  You want to merge/move the charging logic
proposed in patch #5 (drm_cgroup_try_charge in kernel/cgroup/drm.c) into
drm_gem_object_charge_mem() ?

Or reading below, I think you are okay keeping the logic separated as is, but
you want much of the code in kernel/cgroup/drm.c moved to drivers/gpu/cgroup ?
Yes, I see that should allow to reduce number of exported functions.

> 
> Also, that would remove the need for all these functions exported to
> drivers. Plus the cgroups setup could also move fully into drm core code,
> since all drivers (*) support it
> That way this would really be a fully
> generic cgroups controller, and we could land it.


Patch #2 proposed to have a few setup functions called during drm device
registration.
You are suggesting to have this more tightly integrated?
Okay, can see what that looks like.  It's true most of the exported functions 
from
kernel/cgroup/drm.c were taking a struct drm_device pointer, so seems it can be
restructured as you suggest.  But I guess we will always need some logic in
kernel/cgroup/drm.c to encapsulate the allocation of the 'struct 
cgroup_subsys_state'
for this new controller.
But I'm not sure I see how this makes the controller 'fully generic' as you 
describe.


> 
> The other things I'd do:
> - drop gpu scheduling controller from the initial patch series. Yes we'll
>   need it, but we also need vram limits and all these things for full
>   featured controller. Having the minimal viable cgroup controller in
>   upstream would unblock all these other things, and we could discuss them
>   in separate patch series, instead of one big bikeshed that never reaches
>   full consensus.
> 
> - the xpu thing is probably real, I just chatted with Android people for
>   their gpu memory accounting needs, and cgroups sounds like a solution
>   for them too. But unlike on desktop/server linux, on Android all shared
>   buffers are allocated from dma-buf heaps, so outside of drm, and hence a
>   cgroup controller that's tightly tied to drm isn't that useful. So I
>   think we should move the controller/charge functions up one level into
>   drivers/gpu/cgroups.

Hmm, so for this, you are asking for the cgroup logic to not directly use
DRM data structures?  Okay, that's why you suggest drivers/gpu/cgroups and
not drivers/gpu/drm/cgroups.  So this is your angle to make it 'fully
generic' then.

> 
>   On the naming bikeshed I think gpu is perfectly fine, just explain in
>   the docs that the G stands for "general" :-) Otherwise we might need to
>   rename drivers/gpu to drivers/xpu too, and that's maybe one bikeshed too
>   far. Plus, right now it really is the controller for gpu related memory,
>   even if we extend it to Android (where it would also include
>   video/camera allocatioons). Extending this cgroup controller to
>   accelerators in general is maybe a bit too much.
>  
> - The other disambiguation is how we account dma-buf (well, buffer based)
>   gpu allocations vs HMM gpu memory allocations, that might be worth
>   clarifying in the docs.
> 
> - Finally to accelerate this further, I think it'd be good to pull out the
>   cgroup spec for this more minimized series into patch 1, as a draft.
>   That way we could get all stakeholders to ack on that ack, so hopefully
>   we're building something that will work for everyone. That way we can
>   hopefully untangle the controller design discussions from the
>   implementation bikeshedding as much as possible.

Okay, thanks for all the inputs.
I agree the 'cgroup spec' should be in first patch.  Can redo this way as well.

As much of the

[Intel-gfx] [PATCH 1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend

[Chris Wilson]

After calling intel_gt_suspend_prepare(), the driver starts to turn off
various subsystems, such as clearing the GGTT, before calling
intel_gt_suspend_late() to relinquish control over the GT. However, if
we still have internal GPU state active as we clear the GGTT, the GPU
may write back its internal state to the residual GGTT addresses that
are now pointing into scratch. Let's reset the GPU to clear that
internal state as soon we have idled the GPU in prepare-to-suspend.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 0bd303d2823e..f41612faa269 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -295,6 +295,9 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
wait_for_suspend(gt);
 
intel_uc_suspend(>->uc);
+
+   /* Flush all the contexts and internal state before turning off GGTT */
+   gt_sanitize(gt, false);
 }
 
 static suspend_state_t pm_suspend_target(void)
@@ -337,7 +340,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)
intel_llc_disable(>->llc);
}
 
-   gt_sanitize(gt, false);
+   gt_sanitize(gt, false); /* Be paranoid, remove all residual GPU state */
 
GT_TRACE(gt, "\n");
 }
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/6] drm/i915: Clear internal GT state on hibernate

[Chris Wilson]

Call intel_gt_suspend_late() to disable the GT before hibernation.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 000e1cd8e920..da0ef483ad6b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -115,6 +115,8 @@ int i915_gem_freeze_late(struct drm_i915_private *i915)
 * the objects as well, see i915_gem_freeze()
 */
 
+   intel_gt_suspend_late(&i915->gt);
+
with_intel_runtime_pm(&i915->runtime_pm, wakeref)
i915_gem_shrink(i915, -1UL, NULL, ~0);
i915_gem_drain_freed_objects(i915);
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/6] drm/i915: Remove unused debug functions

[Chris Wilson]

Remove or hide unused debug functions from clang, or else it moans.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_sw_fence.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index dfabf291e5cd..566bc48e5b0c 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -49,10 +49,12 @@ static inline void debug_fence_init(struct i915_sw_fence 
*fence)
debug_object_init(fence, &i915_sw_fence_debug_descr);
 }
 
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 static inline void debug_fence_init_onstack(struct i915_sw_fence *fence)
 {
debug_object_init_on_stack(fence, &i915_sw_fence_debug_descr);
 }
+#endif
 
 static inline void debug_fence_activate(struct i915_sw_fence *fence)
 {
@@ -92,9 +94,11 @@ static inline void debug_fence_init(struct i915_sw_fence 
*fence)
 {
 }
 
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 static inline void debug_fence_init_onstack(struct i915_sw_fence *fence)
 {
 }
+#endif
 
 static inline void debug_fence_activate(struct i915_sw_fence *fence)
 {
@@ -113,10 +117,6 @@ static inline void debug_fence_destroy(struct 
i915_sw_fence *fence)
 {
 }
 
-static inline void debug_fence_free(struct i915_sw_fence *fence)
-{
-}
-
 static inline void debug_fence_assert(struct i915_sw_fence *fence)
 {
 }
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/6] drm/i915: Check for scratch page scribbling

[Chris Wilson]

Periodically check, for example when idling and upon closing user
contexts, whether or not some client has written into unallocated PTE in
their ppGTT.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 .../drm/i915/gem/selftests/i915_gem_context.c | 24 +++---
 .../drm/i915/gem/selftests/i915_gem_mman.c| 32 -
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 31 +
 drivers/gpu/drm/i915/gt/intel_gt_pm.c | 10 +
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 45 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  1 +
 drivers/gpu/drm/i915/i915_scheduler.c | 33 +-
 drivers/gpu/drm/i915/i915_utils.c | 29 
 drivers/gpu/drm/i915/i915_utils.h |  3 ++
 9 files changed, 141 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index df949320f2b5..5a9128dd3979 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1737,7 +1737,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
return err;
 }
 
-static int check_scratch_page(struct i915_gem_context *ctx, u32 *out)
+static int check_ctx_scratch(struct i915_gem_context *ctx, u32 *out)
 {
struct i915_address_space *vm;
struct page *page;
@@ -1770,6 +1770,17 @@ static int check_scratch_page(struct i915_gem_context 
*ctx, u32 *out)
return err;
 }
 
+static void reset_ctx_scratch(struct i915_gem_context *ctx, u32 value)
+{
+   struct i915_address_space *vm = ctx_vm(ctx);
+   struct page *page = __px_page(vm->scratch[0]);
+   u32 *vaddr;
+
+   vaddr = kmap(page);
+   memset32(vaddr, value, PAGE_SIZE / sizeof(value));
+   kunmap(page);
+}
+
 static int igt_vm_isolation(void *arg)
 {
struct drm_i915_private *i915 = arg;
@@ -1816,11 +1827,11 @@ static int igt_vm_isolation(void *arg)
goto out_file;
 
/* Read the initial state of the scratch page */
-   err = check_scratch_page(ctx_a, &expected);
+   err = check_ctx_scratch(ctx_a, &expected);
if (err)
goto out_file;
 
-   err = check_scratch_page(ctx_b, &expected);
+   err = check_ctx_scratch(ctx_b, &expected);
if (err)
goto out_file;
 
@@ -1855,7 +1866,7 @@ static int igt_vm_isolation(void *arg)
err = read_from_scratch(ctx_b, engine,
offset, &value);
if (err)
-   goto out_file;
+   goto out_scratch;
 
if (value != expected) {
pr_err("%s: Read %08x from scratch (offset 
0x%08x_%08x), after %lu reads!\n",
@@ -1864,7 +1875,7 @@ static int igt_vm_isolation(void *arg)
   lower_32_bits(offset),
   this);
err = -EINVAL;
-   goto out_file;
+   goto out_scratch;
}
 
this++;
@@ -1875,6 +1886,9 @@ static int igt_vm_isolation(void *arg)
pr_info("Checked %lu scratch offsets across %lu engines\n",
count, num_engines);
 
+out_scratch:
+   /* As we deliberately write into scratch, cover up our tracks */
+   reset_ctx_scratch(ctx_a, expected);
 out_file:
if (igt_live_test_end(&t))
err = -EIO;
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index df558ce95a94..b7f41f230c8f 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -155,6 +155,18 @@ static int check_partial_mapping(struct 
drm_i915_gem_object *obj,
drm_clflush_virt_range(cpu, sizeof(*cpu));
kunmap(p);
 
+   if (check_scratch_page(vma->vm)) {
+   pr_err("Partial view for %lu [%u] (offset=%llu, size=%u [%llu, 
row size %u], fence=%d, tiling=%d, stride=%d) overwrote scratch\n",
+  page, n,
+  view.partial.offset,
+  view.partial.size,
+  vma->size >> PAGE_SHIFT,
+  tile->tiling ? tile_row_pages(obj) : 0,
+  vma->fence ? vma->fence->id : -1,
+  tile->tiling, tile->stride);
+   err = -EIO;
+   }
+
 out:
__i915_vma_put(vma);
return err;
@@ -250,6 +262,9 @@ static int check_partial_mappings(struct 
drm_i915_gem_object *obj,
return -EINTR;
}
 
+   if (check_scratch_page(&to_i915(obj->base.dev)->ggtt.vm))
+   return -EIO;
+
return 0;
 }
 
@@ -399,7 +414,11 @@ s

[Intel-gfx] [PATCH 3/6] drm/i915/selftests: Declare suspend_state before testing suspend

[Chris Wilson]

As we mock the suspend routines to exercise suspending driver and
manipulating backing storage across the suspend, declare the suspend
target as we do.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/i915_gem.c | 40 +--
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c 
b/drivers/gpu/drm/i915/selftests/i915_gem.c
index dc394fb7ccfa..6c764bcfe512 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 
 #include "gem/selftests/igt_gem_utils.h"
 #include "gem/selftests/mock_context.h"
@@ -87,25 +88,38 @@ static void simulate_hibernate(struct drm_i915_private 
*i915)
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
 }
 
-static int pm_prepare(struct drm_i915_private *i915)
+static int do_prepare(struct drm_i915_private *i915)
 {
i915_gem_suspend(i915);
 
return 0;
 }
 
-static void pm_suspend(struct drm_i915_private *i915)
+static suspend_state_t set_pm_target(suspend_state_t target)
 {
+#ifdef CONFIG_PM_SLEEP
+   return xchg(&pm_suspend_target_state, target);
+#else
+   return PM_SUSPEND_ON;
+#endif
+}
+
+static suspend_state_t do_suspend(struct drm_i915_private *i915)
+{
+   suspend_state_t old = set_pm_target(PM_SUSPEND_MEM);
intel_wakeref_t wakeref;
 
with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
i915_ggtt_suspend(&i915->ggtt);
i915_gem_suspend_late(i915);
}
+
+   return old;
 }
 
-static void pm_hibernate(struct drm_i915_private *i915)
+static suspend_state_t do_hibernate(struct drm_i915_private *i915)
 {
+   suspend_state_t old = set_pm_target(PM_SUSPEND_MAX);
intel_wakeref_t wakeref;
 
with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
@@ -114,9 +128,11 @@ static void pm_hibernate(struct drm_i915_private *i915)
i915_gem_freeze(i915);
i915_gem_freeze_late(i915);
}
+
+   return old;
 }
 
-static void pm_resume(struct drm_i915_private *i915)
+static void do_resume(struct drm_i915_private *i915, suspend_state_t saved)
 {
intel_wakeref_t wakeref;
 
@@ -128,12 +144,15 @@ static void pm_resume(struct drm_i915_private *i915)
i915_ggtt_resume(&i915->ggtt);
i915_gem_resume(i915);
}
+
+   set_pm_target(saved);
 }
 
 static int igt_gem_suspend(void *arg)
 {
struct drm_i915_private *i915 = arg;
struct i915_gem_context *ctx;
+   suspend_state_t saved;
struct file *file;
int err;
 
@@ -148,16 +167,16 @@ static int igt_gem_suspend(void *arg)
if (err)
goto out;
 
-   err = pm_prepare(i915);
+   err = do_prepare(i915);
if (err)
goto out;
 
-   pm_suspend(i915);
+   saved = do_suspend(i915);
 
/* Here be dragons! Note that with S3RST any S3 may become S4! */
simulate_hibernate(i915);
 
-   pm_resume(i915);
+   do_resume(i915, saved);
 
err = switch_to_context(ctx);
 out:
@@ -169,6 +188,7 @@ static int igt_gem_hibernate(void *arg)
 {
struct drm_i915_private *i915 = arg;
struct i915_gem_context *ctx;
+   suspend_state_t saved;
struct file *file;
int err;
 
@@ -183,16 +203,16 @@ static int igt_gem_hibernate(void *arg)
if (err)
goto out;
 
-   err = pm_prepare(i915);
+   err = do_prepare(i915);
if (err)
goto out;
 
-   pm_hibernate(i915);
+   saved = do_hibernate(i915);
 
/* Here be dragons! */
simulate_hibernate(i915);
 
-   pm_resume(i915);
+   do_resume(i915, saved);
 
err = switch_to_context(ctx);
 out:
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/6] drm/i915/selftests: Restrict partial-tiling to write into the object

[Chris Wilson]

Check that the address we are about to write into maps into the object
to avoid stray writes into the scratch page.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 39293d98f34d..df558ce95a94 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -104,9 +104,12 @@ static int check_partial_mapping(struct 
drm_i915_gem_object *obj,
GEM_BUG_ON(i915_gem_object_get_tiling(obj) != tile->tiling);
GEM_BUG_ON(i915_gem_object_get_stride(obj) != tile->stride);
 
-   page = i915_prandom_u32_max_state(npages, prng);
-   view = compute_partial_view(obj, page, MIN_CHUNK_PAGES);
+   do {
+   page = i915_prandom_u32_max_state(npages, prng);
+   offset = tiled_offset(tile, page << PAGE_SHIFT);
+   } while (offset >= obj->base.size);
 
+   view = compute_partial_view(obj, page, MIN_CHUNK_PAGES);
vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, PIN_MAPPABLE);
if (IS_ERR(vma)) {
pr_err("Failed to pin partial view: offset=%lu; err=%d\n",
@@ -129,10 +132,6 @@ static int check_partial_mapping(struct 
drm_i915_gem_object *obj,
iowrite32(page, io + n * PAGE_SIZE / sizeof(*io));
i915_vma_unpin_iomap(vma);
 
-   offset = tiled_offset(tile, page << PAGE_SHIFT);
-   if (offset >= obj->base.size)
-   goto out;
-
intel_gt_flush_ggtt_writes(&to_i915(obj->base.dev)->gt);
 
p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT);
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 17/18] drm/i915/display13: Add rc_qp_table for rcparams calculation

[Lucas De Marchi]

On Fri, Jan 29, 2021 at 02:01:32PM +0200, Jani Nikula wrote:

On Fri, 29 Jan 2021, Chris Wilson  wrote:

Quoting Jani Nikula (2021-01-29 11:12:02)

On Thu, 28 Jan 2021, Matt Roper  wrote:
> From: Vandita Kulkarni 
>
> Add the qp table for 444 formats, for 8bpc, 10bpc and 12bpc, as given by
> the VESA C model for DSC 1.1
>
> Cc: Manasi Navare 
> Signed-off-by: Vandita Kulkarni 
> Signed-off-by: Matt Roper 
> ---
>  .../gpu/drm/i915/display/intel_qp_tables.h| 294 ++
>  drivers/gpu/drm/i915/display/intel_vdsc.c |  22 +-
>  2 files changed, 315 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_qp_tables.h
>
> diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.h 
b/drivers/gpu/drm/i915/display/intel_qp_tables.h
> new file mode 100644
> index ..13694d5220d4
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_qp_tables.h
> @@ -0,0 +1,294 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +

The include guard is missing.


Should we even be putting large tables into a header?

Would this be better as a .c?


Agreed.


ugh... that huge table on a header and even marked as __maybe_unused is
very ugly. We should really not do that.

Lucas De Marchi



BR,
Jani.

--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gt: Ratelimit heartbeat completion probing

[Tang, CQ]

Chris,
I applied this patch to DII.  I could not apply automatically, so I do it 
manually. The only problem is following in selftest code:
Dii code:
+err_reset:
intel_engine_set_heartbeat(engine, CONFIG_DRM_I915_HEARTBEAT_INTERVAL);
your code:
 +err_reset:
reset_heartbeat(engine);

Anyway, I run the patch on PVC simics with selftest gt_hearbeat, but I catch 
following error:
[   64.836061] i915: Running intel_heartbeat_live_selftests/live_heartbeat_fast
[   64.838307] heartbeat bcs0 heartbeat {seqno:1:5, prio:2147483646} not ticking
[   64.840308] heartbeatAwake? 3
[   64.841262] heartbeatBarriers?: no
[   64.842311] heartbeatLatency: 2260us
[   64.843422] heartbeatForcewake: 0 domains, 0 active
[   64.844857] heartbeatHeartbeat: 7 ms ago
[   64.846071] heartbeatReset count: -1 (global 0)
..

It detects GPU hang.

What is the problem? Do you have the patch for DII for me to try?

--CQ

> -Original Message-
> From: Chris Wilson 
> Sent: Friday, February 5, 2021 6:32 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Tang, CQ 
> Subject: [PATCH] drm/i915/gt: Ratelimit heartbeat completion probing
> 
> The heartbeat runs through a few phases that we expect to complete within
> a certain number of heartbeat intervals. First we must submit the heartbeat
> to the queue, and if the queue is occupied it may take a couple of intervals
> before the heartbeat preempts the workload and is submitted to HW. Once
> running on HW, completion is not instantaneous as it may have to first reset
> the current workload before it itself runs through the empty request and
> signals completion. As such, we know that the heartbeat must take at least
> the preempt reset timeout and before we have had a chance to reset the
> engine, we do not want to issue a global reset ourselves (simply so that we
> only try to do one reset at a time and not confuse ourselves by resetting
> twice and hitting an innocent.)
> 
> So by taking into consideration that once running the request must take a
> finite amount of time, we can delay the final completion check to
> accommodate that and avoid checking too early (before we've had a chance
> to handle any engine resets required).
> 
> v2: Attach a callback to flush the work immediately upon the heartbeat
> completion and insert the delay before the next.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
> Suggested-by: CQ Tang 
> Signed-off-by: Chris Wilson 
> ---
>  .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 93 +--
> drivers/gpu/drm/i915/gt/intel_engine_types.h  |  1 +
>  .../drm/i915/gt/selftest_engine_heartbeat.c   | 65 ++---
>  drivers/gpu/drm/i915/gt/selftest_execlists.c  |  5 +-
>  4 files changed, 119 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 93741a65924a..01d8a04f77b6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -20,6 +20,18 @@
>   * issue a reset -- in the hope that restores progress.
>   */
> 
> +#define HEARTBEAT_COMPLETION 50u /* milliseconds */
> +
> +static long completion_timeout(const struct intel_engine_cs *engine) {
> + long timeout = HEARTBEAT_COMPLETION;
> +
> + if (intel_engine_has_preempt_reset(engine))
> + timeout += READ_ONCE(engine-
> >props.preempt_timeout_ms);
> +
> + return msecs_to_jiffies(timeout);
> +}
> +
>  static bool next_heartbeat(struct intel_engine_cs *engine)  {
>   long delay;
> @@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs
> *engine)
>   return false;
> 
>   delay = msecs_to_jiffies_timeout(delay);
> +
> + /*
> +  * Once we submit a heartbeat to the HW, we know that it will take
> +  * at least a certain amount of time to complete. On a hanging system
> +  * it will first have to wait for the preempt reset timeout, and
> +  * then it will take some time for the reset to resume with the
> +  * heartbeat and for it to complete. So once we have submitted the
> +  * heartbeat to HW, we can wait a while longer before declaring the
> +  * engine stuck and forcing a reset ourselves. If we do a reset
> +  * and the engine is also doing a reset, it is possible that we
> +  * reset the engine twice, harming an innocent.
> +  *
> +  * Before we have sumitted the heartbeat, we do not want to
> change
> +  * the interval as we to promote the heartbeat and trigger
> preemption
> +  * in a deterministic time frame.
> +  */
> + if (engine->heartbeat.systole &&
> + i915_request_is_active(engine->heartbeat.systole))
> + delay = max(delay, completion_timeout(engine));
> +
>   if (delay >= HZ)
>   delay = round_jiffies_up_relative(delay);
>   mod_delayed_work(system_highpri_wq, 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915/gt: Sanitize GPU during 
prepare-to-suspend
URL   : https://patchwork.freedesktop.org/series/86962/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li

Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"

[Navare, Manasi]

On Wed, Feb 10, 2021 at 05:07:03PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote:
> > On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter 
> >  wrote:
> > 
> > > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> > >
> > > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > > in case of big joiner used in i915 in which case even if the modeset
> > > > is requested on a single pipe, internally another consecutive
> > > > pipe is stolen and used to drive half of the transcoder timings.
> > > > So in this case it is expected that requested crtc and affected crtcs
> > > > do not match. Hence the added WARN ON becomes irrelevant.
> > 
> > The WARN_ON only happens if allow_modeset == false. If allow_modeset == 
> > true,
> > then the driver is allowed to steal an unrelated pipe.
> > 
> > Maybe i915 is stealing a pipe without allow_modeset?
> 
> No. All page flips etc. will have to get split up internally
> between multiple crtcs.
> 
> So I think there's basically three options:
> a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> b) allow i915 to silence that warning, which opens up the question
>whether the warn is doing any good if it can just be bypassed
> c) nuke the warning entirely
> 
> a) is not going to happen, and it would any way allow i915 to
> do things any which way it wants without tripping the warn,
> rendering the warn entirely toothless.
> 
> Hmm. Maybe there is a d) which would be to ignore all crtcs
> that are not logically enabled in the warn? Not sure if that
> could allow something to slit through that people want it to
> catch?

So as per the offline IRC discussions,
- We can check for crtc_state->enable and only use the enabled crtcs
in the affected crtc calculation. And this enable would only
be set when modeset is done. So in case of bigjoiner no modeset on Pipe A,
even if Pipe B is stolen, since no modeset and because that pipe doesnt
get enabled the affected crtcs would still be 0x1.

This should solve the problem. 
Ville, Danvet - I will make this change?

Manasi

> 
> -- 
> Ville Syrjälä
> Intel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915/gt: Sanitize GPU during 
prepare-to-suspend
URL   : https://patchwork.freedesktop.org/series/86962/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19655


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][2] -> [INCOMPLETE][3] ([i915#142] / 
[i915#2405])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@prime_vgem@basic-write:
- fi-tgl-y:   [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@prime_v...@basic-write.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/fi-tgl-y/igt@prime_v...@basic-write.html

  * igt@runner@aborted:
- fi-byt-j1900:   NOTRUN -> [FAIL][6] ([i915#1814] / [i915#2505])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/fi-byt-j1900/igt@run...@aborted.html

  
 Possible fixes 

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 40)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19655

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19655: dc3fc12481e856f11ba6b07ba8ebfbc7ada3d231 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

dc3fc12481e8 drm/i915: Remove unused debug functions
c838142ea4ef drm/i915: Check for scratch page scribbling
30b6655c5511 drm/i915/selftests: Restrict partial-tiling to write into the 
object
5721705d6546 drm/i915/selftests: Declare suspend_state before testing suspend
0ff6db946d04 drm/i915: Clear internal GT state on hibernate
1ab2892c8838 drm/i915/gt: Sanitize GPU during prepare-to-suspend

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Refine VT-d scanout workaround

[Chris Wilson]

VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 160 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.

If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c |  3 ++
 drivers/gpu/drm/i915/gt/intel_ggtt.c   | 37 --
 drivers/gpu/drm/i915/i915_gem_gtt.h|  1 +
 drivers/gpu/drm/i915/i915_vma.c| 23 ++
 drivers/gpu/drm/i915/i915_vma_types.h  |  1 +
 5 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 0478b069c202..9f2ccc255ca1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -345,6 +345,9 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
if (ret)
goto err;
 
+   if (intel_scanout_needs_vtd_wa(i915))
+   flags |= PIN_VTD;
+
/*
 * As the user may map the buffer once pinned in the display plane
 * (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index b0b8ded834f0..416f77f48561 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -238,6 +238,11 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
 
gte = (gen8_pte_t __iomem *)ggtt->gsm;
gte += vma->node.start / I915_GTT_PAGE_SIZE;
+
+   end = gte - vma->guard / I915_GTT_PAGE_SIZE;
+   while (end < gte)
+   gen8_set_pte(end++, vm->scratch[0]->encode);
+
end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
 
for_each_sgt_daddr(addr, iter, vma->pages)
@@ -245,6 +250,7 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
GEM_BUG_ON(gte > end);
 
/* Fill the allocated but "unused" space beyond the end of the buffer */
+   end += vma->guard / I915_GTT_PAGE_SIZE;
while (gte < end)
gen8_set_pte(gte++, vm->scratch[0]->encode);
 
@@ -289,6 +295,11 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
 
gte = (gen6_pte_t __iomem *)ggtt->gsm;
gte += vma->node.start / I915_GTT_PAGE_SIZE;
+
+   end = gte - vma->guard / I915_GTT_PAGE_SIZE;
+   while (end < gte)
+   gen8_set_pte(end++, vm->scratch[0]->encode);
+
end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
 
for_each_sgt_daddr(addr, iter, vma->pages)
@@ -296,6 +307,7 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
GEM_BUG_ON(gte > end);
 
/* Fill the allocated but "unused" space beyond the end of the buffer */
+   end += vma->guard / I915_GTT_PAGE_SIZE;
while (gte < end)
iowrite32(vm->scratch[0]->encode, gte++);
 
@@ -311,27 +323,6 @@ static void nop_clear_range(struct i915_address_space *vm,
 {
 }
 
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
-   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
-   unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
-   unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
-   const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
-   gen8_pte_t __iomem *gtt_base =
-   (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
-   const int max_entries = ggtt_total_entries(ggtt) - first_entry;
-   int i;
-
-   if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
-   num_entries = max_entries;
-
-   for (i = 0; i < num_entries; i++)
-   gen8_set_pte(>t_base[i], scratch_pte);
-}
-
 static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
 {
/*
@@ -898,8 +889,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
-   if (intel_scanout_needs_vtd_wa(i915))
-   ggtt->vm.clear_range = g

Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues

[Chris Wilson]

Quoting Hans de Goede (2021-02-10 10:37:19)
> Hi,
> 
> On 2/10/21 12:07 AM, Chris Wilson wrote:
> > Quoting Hans de Goede (2021-02-09 11:46:46)
> >> Hi,
> >>
> >> On 2/9/21 12:27 AM, Chris Wilson wrote:
> >>> Quoting Hans de Goede (2021-02-08 20:38:58)
>  Hi All,
> 
>  We (Fedora) have been receiving reports from multiple users about gfx 
>  issues / glitches
>  stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell 
>  iGPUs and all
>  reporters report that adding i915.mitigations=off to the cmdline fixes 
>  things, see:
> >>>
> >>> I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
> >>> did not report any differences with and without mitigations. I have yet
> >>> to test other platforms. So I don't yet have an alternative.
> >>
> >> Note the original / first reporter of:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1925346
> >>
> >> Is using hsw-gt2, so it seems that the problem is not just the enabling of
> >> the mitigations on ivy-bridge / bay-trail but that there actually is
> >> a regression on devices where the WA worked fine before...
> > 
> > There have been 3 crashes uploaded related to v5.10.9, and in all 3
> > cases the ACTHD has been in the first page. This strongly suggests that
> > the w/a is scribbling over address 0. And there's then a very good
> > chance that
> > 
> > commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6
> > Author: Chris Wilson 
> > Date:   Mon Jan 25 12:50:33 2021 +
> > 
> > drm/i915/gt: Always try to reserve GGTT address 0x0
> > 
> > commit 489140b5ba2e7cc4b853c29e0591895ddb462a82 upstream.
> > 
> > in v5.10.14 is sufficient to hide the issue.
> 
> That one actually is already in v5.10.13 and the various reportes of these
> issues have already tested 5.10.13. They did mention that it took longer
> to reproduce with 5.10.13 then with 5.10.10, but that could also be due to:
> 
> "drm/i915/gt: Clear CACHE_MODE prior to clearing residuals"
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=520d05a77b2866eb4cb9e548e1d8c8abcfe60ec5

There's also another pair of pipecontrols required for that:

d30bbd62b1bf ("drm/i915/gt: Flush before changing register state")

which didn't get picked up for stable.

https://intel-gfx-ci.01.org/tree/linux-stable/index-alt.html?

shows that we are still missing a couple of fixes for the w/a, at least
compare to BAT on drm-tip.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/18] drm/i915/display13: add Display13 characteristics

[Lucas De Marchi]

On Thu, Jan 28, 2021 at 11:23:56AM -0800, Matt Roper wrote:

Let's start preparing for upcoming platforms that will use a Display13
design.

Signed-off-by: Matt Roper 
---
drivers/gpu/drm/i915/i915_drv.h  |  1 +
drivers/gpu/drm/i915/i915_pci.c  | 11 +++
drivers/gpu/drm/i915/intel_device_info.h |  2 ++
3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9713ab963122..1c0fdbf800ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1778,6 +1778,7 @@ tgl_stepping_get(struct drm_i915_private *dev_priv)
#define INTEL_NUM_PIPES(dev_priv) (hweight8(INTEL_INFO(dev_priv)->pipe_mask))

#define HAS_DISPLAY(dev_priv) (INTEL_INFO(dev_priv)->pipe_mask != 0)
+#define HAS_DISPLAY13(dev_priv) (INTEL_INFO(dev_priv)->has_display13)

#define HAS_VRR(i915)   (INTEL_GEN(i915) >= 12)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6cff7cf0f17b..e5e10484bf8d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -936,6 +936,17 @@ static const struct intel_device_info adl_s_info = {
.dma_mask_size = 46,
};

+#define DISPLAY13_FEATURES \
+   .has_display13 = 1, \
+   .display.has_psr_hw_tracking = 0,   \
+   .abox_mask = GENMASK(1, 0), \
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), \
+   .cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |  \
+   BIT(TRANSCODER_C) | BIT(TRANSCODER_D),  \
+   .ddb_size = 4096,   \
+   .mbus_size = 2048,  \
+   .num_supported_dbuf_slices = 4,
+
#undef GEN
#undef PLATFORM

diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index e6ca1023ffcf..ba44c2c10ad8 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -116,6 +116,7 @@ enum intel_ppgtt_type {
func(is_dgfx); \
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
+   func(has_display13); \


shouldn't this be inside display struct?


func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_fpga_dbg); \
@@ -193,6 +194,7 @@ struct intel_device_info {
} display;

u16 ddb_size; /* in blocks */
+   u16 mbus_size; /* total ddb size on one mbus */


this is unused and afaics never will. It'd be better if if this is
introduced only together with the feature.

Lucas De Marchi


u8 num_supported_dbuf_slices; /* number of DBuf slices */

/* Register offsets for the various display pipes and transcoders */
--
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/18] drm/i915/display13: Handle proper AUX interrupt bits

[Lucas De Marchi]

On Thu, Jan 28, 2021 at 11:23:57AM -0800, Matt Roper wrote:

Display13 has new AUX interrupt bits for DDI-D and DDI-E.

Bspec: 50064
Cc: Anusha Srivatsa 
Signed-off-by: Matt Roper 
---
drivers/gpu/drm/i915/i915_irq.c | 12 +++-
drivers/gpu/drm/i915/i915_reg.h |  2 ++
2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 06937a2d2714..1bced71470a5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2251,7 +2251,17 @@ static u32 gen8_de_port_aux_mask(struct drm_i915_private 
*dev_priv)
{
u32 mask;

-   if (INTEL_GEN(dev_priv) >= 12)
+   if (HAS_DISPLAY13(dev_priv))
+   return TGL_DE_PORT_AUX_DDIA |
+   TGL_DE_PORT_AUX_DDIB |
+   TGL_DE_PORT_AUX_DDIC |
+   D13_DE_PORT_AUX_DDID |
+   D13_DE_PORT_AUX_DDIE |
+   TGL_DE_PORT_AUX_USBC1 |
+   TGL_DE_PORT_AUX_USBC2 |
+   TGL_DE_PORT_AUX_USBC3 |
+   TGL_DE_PORT_AUX_USBC4;
+   else if (INTEL_GEN(dev_priv) >= 12)
return TGL_DE_PORT_AUX_DDIA |
TGL_DE_PORT_AUX_DDIB |
TGL_DE_PORT_AUX_DDIC |
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3031897239a0..10fd0e3af2d4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7858,6 +7858,8 @@ enum {
#define  TGL_DE_PORT_AUX_USBC3  (1 << 10)
#define  TGL_DE_PORT_AUX_USBC2  (1 << 9)
#define  TGL_DE_PORT_AUX_USBC1  (1 << 8)
+#define  D13_DE_PORT_AUX_DDIE  (1 << 13)
+#define  D13_DE_PORT_AUX_DDID  (1 << 12)


maybe this is a gray area, but the rule here is to define following the
bit order, regardless of the meaning of the bit.

in gen8_de_port_aux_mask() I guess it's fine to leave it in the logical
order, but here it would be good not to create exceptions.

while at it, we could also add another commit to convert the surrounding
code to REG_BIT()

Lucas De Marchi


#define  TGL_DE_PORT_AUX_DDIC   (1 << 2)
#define  TGL_DE_PORT_AUX_DDIB   (1 << 1)
#define  TGL_DE_PORT_AUX_DDIA   (1 << 0)
--
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Refine VT-d scanout workaround

[Patchwork]

== Series Details ==

Series: drm/i915: Refine VT-d scanout workaround
URL   : https://patchwork.freedesktop.org/series/86967/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19656


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-glk-dsi: [PASS][1] -> [DMESG-WARN][2] ([i915#2943])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_tiled_blits@basic:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_tiled_bl...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/fi-tgl-y/igt@gem_tiled_bl...@basic.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [PASS][5] -> [DMESG-WARN][6] ([i915#165])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  
 Possible fixes 

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#2943]: https://gitlab.freedesktop.org/drm/intel/issues/2943
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 40)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19656

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19656: cb230263531710c4a26ddcd496b272493ea49eda @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

cb2302635317 drm/i915: Refine VT-d scanout workaround

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/18] drm/i915/display13: Enhanced pipe underrun reporting

[Lucas De Marchi]

On Thu, Jan 28, 2021 at 11:23:58AM -0800, Matt Roper wrote:

Display13 brings enhanced underrun recovery:  the hardware can somewhat
mitigate underruns by using an interpolated replacement pixel (soft
underrun) or the previous pixel (hard underrun).  Furthermore, underruns
can now be caused downstream by the port, even if the pipe itself is
operating properly.  The interrupt register gives us extra bits to
determine hard/soft underruns and whether the underrun was caused by the
port, so let's pass the iir down to the underrun handler and print some
more descriptive errors on Display13 platforms.

The context of the underrun is also available via PIPE_STATUS, but since
we have the same information in the IIR we don't have a need to read
from there.  PIPE_STATUS might be useful in debugfs in the future
though.


is this comment outdated? See below...



Bspec: 50335
Bspec: 50366
Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
.../drm/i915/display/intel_fifo_underrun.c| 55 ++-
drivers/gpu/drm/i915/i915_irq.c   | 14 -
drivers/gpu/drm/i915/i915_reg.h   |  7 +++
3 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c 
b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
index 813a4f7033e1..6c377f0fc1b3 100644
--- a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
@@ -359,6 +359,39 @@ bool intel_set_pch_fifo_underrun_reporting(struct 
drm_i915_private *dev_priv,
return old;
}

+static u32
+underrun_pipestat_mask(struct drm_i915_private *dev_priv)
+{
+   u32 mask = PIPE_FIFO_UNDERRUN_STATUS;
+
+   if (HAS_DISPLAY13(dev_priv))
+   mask |= PIPE_STAT_SOFT_UNDERRUN_D13 |
+   PIPE_STAT_HARD_UNDERRUN_D13 |
+   PIPE_STAT_PORT_UNDERRUN_D13;
+
+   return mask;
+}
+
+static const char *
+pipe_underrun_reason(u32 pipestat_underruns)
+{
+   if (pipestat_underruns & PIPE_STAT_SOFT_UNDERRUN_D13)
+   /*
+* Hardware used replacement/interpolated pixels at
+* underrun locations.
+*/
+   return "soft";
+   else if (pipestat_underruns & PIPE_STAT_HARD_UNDERRUN_D13)
+   /*
+* Hardware used previous pixel value at underrun
+* locations.
+*/
+   return "hard";
+   else
+   /* Old platform or no extra soft/hard bit set */
+   return "FIFO";
+}
+
/**
 * intel_cpu_fifo_underrun_irq_handler - handle CPU fifo underrun interrupt
 * @dev_priv: i915 device instance
@@ -372,6 +405,7 @@ void intel_cpu_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
 enum pipe pipe)
{
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+   u32 underruns = 0;

/* We may be called too early in init, thanks BIOS! */
if (crtc == NULL)
@@ -382,10 +416,27 @@ void intel_cpu_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
crtc->cpu_fifo_underrun_disabled)
return;

+   /*
+* On Display13, we can find out whether an underrun is soft/hard from
+* either the iir or PIPE_STAT, but we can only determine if underruns
+* were due to downstream port logic from PIPE_STAT.
+*/


so... we are actually reading PIPE_STAT somce we want to report if it's
from downstream port.


+   underruns = intel_uncore_read(&dev_priv->uncore, ICL_PIPESTAT(pipe)) &
+   underrun_pipestat_mask(dev_priv);
+   intel_uncore_write(&dev_priv->uncore, ICL_PIPESTAT(pipe), underruns);


maybe I'm missing something, but this doesn't look right to me.  We
unconditionally read/write ICL_PIPESTAT(pipe), even if it's not
display13.  Also, the `underruns = 0` initialization is just being
overwritten here.

intel_cpu_fifo_underrun_irq_handler() is called by very old gens as
well.

Lucas De Marchi


+
if (intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false)) {
trace_intel_cpu_fifo_underrun(dev_priv, pipe);
-   drm_err(&dev_priv->drm, "CPU pipe %c FIFO underrun\n",
-   pipe_name(pipe));
+
+   if (underruns & PIPE_STAT_PORT_UNDERRUN_D13)
+   /* Underrun was caused downstream from the pipes */
+   drm_err(&dev_priv->drm, "Port triggered a %s underrun on 
pipe %c\n",
+   pipe_underrun_reason(underruns),
+   pipe_name(pipe));
+   else
+   drm_err(&dev_priv->drm, "CPU pipe %c %s underrun\n",
+   pipe_name(pipe),
+   pipe_underrun_reason(underruns));
}

intel_fbc_handle_fifo_underrun_irq(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/dri

Re: [Intel-gfx] [PATCH 04/18] drm/i915/display13: Define plane capabilities

[Lucas De Marchi]

On Thu, Jan 28, 2021 at 11:23:59AM -0800, Matt Roper wrote:

Display13's plane support is identical to RKL --- 5 universal + 1 cursor
with NV12 UV support on planes 1-3 and NV12 Y support on planes 4-5.

Bspec: 53657
Bspec: 49251
Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
drivers/gpu/drm/i915/display/intel_sprite.c | 16 
drivers/gpu/drm/i915/i915_irq.c |  2 +-
drivers/gpu/drm/i915/intel_device_info.c|  2 +-
3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index ec931a08ff28..81bb5eb1cd15 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -382,7 +382,7 @@ int intel_plane_check_src_coordinates(struct 
intel_plane_state *plane_state)

static u8 icl_nv12_y_plane_mask(struct drm_i915_private *i915)
{
-   if (HAS_D12_PLANE_MINIMIZATION(i915))
+   if (HAS_DISPLAY13(i915) || HAS_D12_PLANE_MINIMIZATION(i915))
return BIT(PLANE_SPRITE2) | BIT(PLANE_SPRITE3);
else
return BIT(PLANE_SPRITE4) | BIT(PLANE_SPRITE5);
@@ -2322,6 +2322,11 @@ static int skl_plane_check_fb(const struct 
intel_crtc_state *crtc_state,
}

if (drm_rotation_90_or_270(rotation)) {
+   if (HAS_DISPLAY13(dev_priv)) {
+   DRM_DEBUG_KMS("90/270 rotation not supported on this 
platform\n");
+   return -EINVAL;
+   }
+


these are already forbidden in skl_universal_plane_create(), I don't
think we need the additional check here, do we?

with that removed or explained

Reviewed-by: Lucas De Marchi 

Lucas De Marchi


if (fb->modifier != I915_FORMAT_MOD_Y_TILED &&
fb->modifier != I915_FORMAT_MOD_Yf_TILED) {
drm_dbg_kms(&dev_priv->drm,
@@ -3338,9 +3343,12 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
if (ret)
goto fail;

-   supported_rotations =
-   DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 |
-   DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270;
+   if (HAS_DISPLAY13(dev_priv))
+   supported_rotations = DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180;
+   else
+   supported_rotations =
+   DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 |
+   DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270;

if (INTEL_GEN(dev_priv) >= 10)
supported_rotations |= DRM_MODE_REFLECT_X;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 407b42706a14..bb4fad71c429 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2290,7 +2290,7 @@ static u32 gen8_de_port_aux_mask(struct drm_i915_private 
*dev_priv)

static u32 gen8_de_pipe_fault_mask(struct drm_i915_private *dev_priv)
{
-   if (HAS_D12_PLANE_MINIMIZATION(dev_priv))
+   if (HAS_DISPLAY13(dev_priv) || HAS_D12_PLANE_MINIMIZATION(dev_priv))
return RKL_DE_PIPE_IRQ_FAULT_ERRORS;
else if (INTEL_GEN(dev_priv) >= 11)
return GEN11_DE_PIPE_IRQ_FAULT_ERRORS;
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 92ad3e7d1f6f..200d4eceaa4e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -265,7 +265,7 @@ void intel_device_info_runtime_init(struct drm_i915_private 
*dev_priv)

BUILD_BUG_ON(BITS_PER_TYPE(intel_engine_mask_t) < I915_NUM_ENGINES);

-   if (HAS_D12_PLANE_MINIMIZATION(dev_priv))
+   if (HAS_DISPLAY13(dev_priv) || HAS_D12_PLANE_MINIMIZATION(dev_priv))
for_each_pipe(dev_priv, pipe)
runtime->num_sprites[pipe] = 4;
else if (INTEL_GEN(dev_priv) >= 11)
--
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/18] drm/i915/display13: Support 128k plane stride

[Lucas De Marchi]

On Thu, Jan 28, 2021 at 11:24:00AM -0800, Matt Roper wrote:

From: Juha-Pekka Heikkilä 

Display13 supports plane strides up to 128KB.

Cc: Vandita Kulkarni 
Signed-off-by: Juha-Pekka Heikkilä 
Signed-off-by: Matt Roper 
---
drivers/gpu/drm/i915/display/intel_display.c |  6 -
drivers/gpu/drm/i915/display/intel_sprite.c  | 24 ++--
drivers/gpu/drm/i915/i915_reg.h  |  2 ++
3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index d013b0fab128..f56237aaa7b5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8396,7 +8396,11 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,

val = intel_de_read(dev_priv, PLANE_STRIDE(pipe, plane_id));
stride_mult = skl_plane_stride_mult(fb, 0, DRM_MODE_ROTATE_0);
-   fb->pitches[0] = (val & 0x3ff) * stride_mult;
+
+   if (HAS_DISPLAY13(dev_priv))
+   fb->pitches[0] = (val & PLANE_STRIDE_MASK_D13) * stride_mult;
+   else
+   fb->pitches[0] = (val & PLANE_STRIDE_MASK) * stride_mult;

aligned_height = intel_fb_align_height(fb, 0, fb->height);

diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 81bb5eb1cd15..c858ba6dc026 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -572,17 +572,37 @@ skl_plane_max_stride(struct intel_plane *plane,
 u32 pixel_format, u64 modifier,
 unsigned int rotation)
{
+   struct drm_i915_private *i915 = to_i915(plane->base.dev);
const struct drm_format_info *info = drm_format_info(pixel_format);
int cpp = info->cpp[0];
+   int max_horizontal_pixels = 8192;
+   int max_stride_bytes;
+
+   if (HAS_DISPLAY13(i915)) {
+   /*
+* The stride in bytes must not exceed of the size
+* of 128K bytes. For pixel formats of 64bpp will allow
+* for a 16K pixel surface.
+*/
+   max_stride_bytes = 131072;
+   if (cpp == 8)
+   max_horizontal_pixels = 16384;


missing here:

else
max_horizontal_pixels = 65536;


Also, we are starting to overcomplicate skl_plane_max_stride().
Time to start setting plane->max_stride based on the platform?
Although this could be done after landing this patch. With the fix
above:


Reviewed-by: Lucas De Marchi 

Lucas De Marchi


+   } else {
+   /*
+* "The stride in bytes must not exceed the
+* of the size of 8K pixels and 32K bytes."
+*/
+   max_stride_bytes = 32768;
+   }

/*
 * "The stride in bytes must not exceed the
 * of the size of 8K pixels and 32K bytes."
 */
if (drm_rotation_90_or_270(rotation))
-   return min(8192, 32768 / cpp);
+   return min(max_horizontal_pixels, max_stride_bytes / cpp);
else
-   return min(8192 * cpp, 32768);
+   return min(max_horizontal_pixels * cpp, max_stride_bytes);
}

static void
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a57593f7d7b1..9dfa4d711d6f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7198,6 +7198,8 @@ enum {
_PIPE(pipe, _PLANE_STRIDE_3_A, _PLANE_STRIDE_3_B)
#define PLANE_STRIDE(pipe, plane)   \
_MMIO_PLANE(plane, _PLANE_STRIDE_1(pipe), _PLANE_STRIDE_2(pipe))
+#define PLANE_STRIDE_MASK REG_GENMASK(10, 0)
+#define PLANE_STRIDE_MASK_D13 REG_GENMASK(11, 0)

#define _PLANE_POS_1_B  0x7118c
#define _PLANE_POS_2_B  0x7128c
--
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/18] drm/i915/display13: Only enable legacy gamma for now

[Lucas De Marchi]

On Thu, Jan 28, 2021 at 11:24:01AM -0800, Matt Roper wrote:

The multi-segment gamma used on past platforms is gone and replaced by a
logarithmic LUT.  Until logarithmic LUT is enabled, let's just turn off
uapi color management (aside from legacy gamma) since it doesn't really
make sense to expose the full degamma and CTM when we only have limited
legacy gamma support to go with them.  Note that the hardware
programming of the degamma and CTM is unchanged except that the degamma
table now has 128 entries instead of just 33.

The output CSC used implicitly for RGB->YUV conversions is also
unchanged and will continue to function as expected.

Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/i915_pci.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index e5e10484bf8d..fb28f3b24dd8 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -945,7 +945,18 @@ static const struct intel_device_info adl_s_info = {
BIT(TRANSCODER_C) | BIT(TRANSCODER_D),  \
.ddb_size = 4096,   \
.mbus_size = 2048,  \
-   .num_supported_dbuf_slices = 4,
+   .num_supported_dbuf_slices = 4, \
+   /*  \
+* FIXME: Just enable legacy gamma (and no degamma/csc) until   \
+* logarithmic LUT is implemented.  \
+*  \
+* LEGACY_LUT_LENGTH = 256 entries  \
+*  \
+* Note that once logarithmic LUT is enabled and we re-enable   \
+* real color management, degamma_lut_size here should be set   \
+* to 128.  \
+*/ \
+   .color = { .degamma_lut_size = 0, .gamma_lut_size = 256 }

#undef GEN
#undef PLATFORM
--
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/18] drm/i915/display13: Add Display13 power wells

[Lucas De Marchi]

On Thu, Jan 28, 2021 at 11:24:02AM -0800, Matt Roper wrote:

Aside from the hardware-managed PG0, Display13 has power wells 1-2 and
A-D.  These power wells should be enabled/disabled according to the
following dependency tree (enable top to bottom, disable bottom to top):

  PG0
   |
--PG1--
   /   \
 PGA --PG2--
/   |   \
  PGB  PGC  PGD

PWR_WELL_CTL follows the general ICL/TGL design and places PG A-D in the
bits that would have been PG 6-9 under the old scheme.

PWR_WELL_CTL_{DDI,AUX}'s bit indexing for DDI's A-C and TC1 is the same
as TGL, but DDI-D is placed at index 7 (bits 14 & 15).

Bspec: 49233
Bspec: 49503
Bspec: 49504
Bspec: 49505
Bspec: 49296
Bspec: 50090
Bspec: 53920
Cc: Anshuman Gupta 
Cc: Imre Deak 
Cc: Anshuman Gupta 
Cc: José Roberto de Souza 
Signed-off-by: Matt Roper 
---
.../drm/i915/display/intel_display_power.c| 422 +-
drivers/gpu/drm/i915/display/intel_vdsc.c |   5 +-
drivers/gpu/drm/i915/i915_reg.h   |  10 +
3 files changed, 433 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index e17b1ca356c3..7dd12fe9137e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1035,7 +1035,7 @@ static void assert_can_enable_dc5(struct drm_i915_private 
*dev_priv)
enum i915_power_well_id high_pg;

/* Power wells at this level and above must be disabled for DC5 entry */
-   if (INTEL_GEN(dev_priv) >= 12)
+   if (INTEL_GEN(dev_priv) >= 12 && !HAS_DISPLAY13(dev_priv))
high_pg = ICL_DISP_PW_3;
else
high_pg = SKL_DISP_PW_2;
@@ -3028,6 +3028,109 @@ intel_display_power_put_mask_in_set(struct 
drm_i915_private *i915,
BIT_ULL(POWER_DOMAIN_AUX_B) |   \
BIT_ULL(POWER_DOMAIN_INIT))

+/*
+ * Display13 Power Domains
+ *
+ * Previous platforms required that PG(n-1) be enabled before PG(n).  That
+ * dependency chain turns into a dependency tree on Display13:
+ *
+ *   PG0
+ *|
+ * --PG1--
+ */   \
+ *  PGA --PG2--
+ * /   |   \
+ *   PGB  PGC  PGD
+ *
+ * Power wells must be enabled from top to bottom and disabled from bottom
+ * to top.  This allows pipes to be power gated independently.
+ */
+
+#define D13_PW_D_POWER_DOMAINS (   \
+   BIT_ULL(POWER_DOMAIN_PIPE_D) |  \
+   BIT_ULL(POWER_DOMAIN_PIPE_D_PANEL_FITTER) | \
+   BIT_ULL(POWER_DOMAIN_TRANSCODER_D) |\
+   BIT_ULL(POWER_DOMAIN_INIT))
+
+#define D13_PW_C_POWER_DOMAINS (   \
+   BIT_ULL(POWER_DOMAIN_PIPE_C) |  \
+   BIT_ULL(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
+   BIT_ULL(POWER_DOMAIN_TRANSCODER_C) |\
+   BIT_ULL(POWER_DOMAIN_INIT))
+
+#define D13_PW_B_POWER_DOMAINS (   \
+   BIT_ULL(POWER_DOMAIN_PIPE_B) |  \
+   BIT_ULL(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
+   BIT_ULL(POWER_DOMAIN_TRANSCODER_B) |\


when reviewing this in the spec I thought this was wrong... apparently 
transcoder_{b,c,d} power wells
are in PG2, but there is a clarification in bspec 49233:

"Transcoder B (registers reside in PG2, but access path goes through 
associated pipe)"


Reviewed-by: Lucas De Marchi 

Lucas De Marchi


+   BIT_ULL(POWER_DOMAIN_INIT))
+
+#define D13_PW_A_POWER_DOMAINS (   \
+   BIT_ULL(POWER_DOMAIN_PIPE_A) |  \
+   BIT_ULL(POWER_DOMAIN_PIPE_A_PANEL_FITTER) | \
+   BIT_ULL(POWER_DOMAIN_INIT))
+
+#define D13_PW_2_POWER_DOMAINS (   \
+   D13_PW_B_POWER_DOMAINS |\
+   D13_PW_C_POWER_DOMAINS |\
+   D13_PW_D_POWER_DOMAINS |\
+   BIT_ULL(POWER_DOMAIN_AUDIO) |   \
+   BIT_ULL(POWER_DOMAIN_VGA) | \
+   BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
+   BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
+   BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
+   BIT_ULL(POWER_DOMAIN_PORT_DDI_F_LANES) |\
+   BIT_ULL(POWER_DOMAIN_PORT_DDI_G_LANES) |\
+   BIT_ULL(POWER_DOMAIN_PORT_DDI_H_LANES) |\
+   BIT_ULL(POWER_DOMAIN_PORT_DDI_I_LANES) |\
+   BIT_ULL(POWER_DOMAIN_AUX_C) |   \
+   BIT_ULL(POWER_DOMAIN_AUX_D) |   \
+   BIT_ULL(POWER_DOMAIN_AUX_E) |   \
+   BIT_ULL(POWER_DOMAIN_AUX_F) |   \
+   BIT_ULL(POWER_DOMAIN_AUX_G) |   \
+   BIT_ULL(POWER_DOMAIN_AUX_H) |   \
+   BIT_ULL(POWER_DOMAIN_AUX_I) |   \
+   BIT_ULL(POWER_DOMAIN_INIT))
+
+/*
+ * D13 

Re: [Intel-gfx] [PATCH 08/18] drm/i915/display13: Handle LPSP for Display 13

[Lucas De Marchi]

On Thu, Jan 28, 2021 at 11:24:03AM -0800, Matt Roper wrote:

From: Uma Shankar 

Enable LPSP for Display13 and get the proper power well
enable check in place. For Display13 it is PW2 which
need to check for LPSP.

Cc: Anshuman Gupta 
Cc: Animesh Manna 
Cc: Matt Roper 
Suggested-by: Matt Roper 
Signed-off-by: Uma Shankar 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Matt Roper 
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 7 +++
1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index d62b18d5ecd8..2af7d74d5960 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1316,6 +1316,13 @@ static int i915_lpsp_status(struct seq_file *m, void 
*unused)

switch (INTEL_GEN(i915)) {
case 12:
+   if (HAS_DISPLAY13(i915)) {


does it still make sense to check for gen && HAS_DISPLAY13? Shouldn't we
be checking only by HAS_DISPLAY13(i915) here, outside the switch()?

Lucas De Marchi


+   LPSP_STATUS(!intel_lpsp_power_well_enabled(i915,
+  
SKL_DISP_PW_2));
+   break;
+   }
+
+   fallthrough;
case 11:
LPSP_STATUS(!intel_lpsp_power_well_enabled(i915, 
ICL_DISP_PW_3));
break;
--
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/gen9_bc: Recognize TGP PCH + CML combos

[Rodrigo Vivi]

On Tue, Feb 09, 2021 at 04:28:28PM -0500, Lyude Paul wrote:
> Since Intel has introduced the gen9_bc platform, a combination of
> Tigerpoint PCHs and CML CPUs, let's recognize such platforms as valid and
> avoid WARNing on them.
> 
> Changes since v4:
> * Split this into it's own patch - vsyrjala
> 
> Cc: Matt Roper 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> [originally from Tejas's work]
> Signed-off-by: Tejas Upadhyay 
> Signed-off-by: Lyude Paul 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_pch.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pch.c 
> b/drivers/gpu/drm/i915/intel_pch.c
> index 4813207fc053..7476f0e063c6 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -121,7 +121,8 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
> unsigned short id)
>   case INTEL_PCH_TGP2_DEVICE_ID_TYPE:
>   drm_dbg_kms(&dev_priv->drm, "Found Tiger Lake LP PCH\n");
>   drm_WARN_ON(&dev_priv->drm, !IS_TIGERLAKE(dev_priv) &&
> - !IS_ROCKETLAKE(dev_priv));
> + !IS_ROCKETLAKE(dev_priv) &&
> + !IS_GEN9_BC(dev_priv));
>   return PCH_TGP;
>   case INTEL_PCH_JSP_DEVICE_ID_TYPE:
>   case INTEL_PCH_JSP2_DEVICE_ID_TYPE:
> -- 
> 2.29.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/gen9_bc: Introduce HPD pin mappings for TGP PCH + CML combos

[Rodrigo Vivi]

On Tue, Feb 09, 2021 at 04:28:30PM -0500, Lyude Paul wrote:
> Next, let's start introducing the HPD pin mappings for Intel's new gen9_bc
> platform in order to make hotplugging display connectors work. Since
> gen9_bc is just a TGP PCH along with a CML CPU, except with the same HPD
> mappings as ICL, we simply add a skl_hpd_pin function that is shared
> between gen9 and gen9_bc which handles both the traditional gen9 HPD pin
> mappings and the Icelake HPD pin mappings that gen9_bc uses.
> 
> Changes since v4:
> * Split this into its own commit
> * Introduce skl_hpd_pin() like vsyrjala suggested and use that instead of
>   sticking our HPD pin mappings in TGP code
> 
> Cc: Matt Roper 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> [originally from Tejas's work]
> Signed-off-by: Tejas Upadhyay 
> Signed-off-by: Lyude Paul 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3c4003605f93..01b171f52694 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3954,6 +3954,14 @@ static enum hpd_pin cnl_hpd_pin(struct 
> drm_i915_private *dev_priv,
>   return HPD_PORT_A + port - PORT_A;
>  }
>  
> +static enum hpd_pin skl_hpd_pin(struct drm_i915_private *dev_priv, enum port 
> port)
> +{
> + if (HAS_PCH_TGP(dev_priv))
> + return icl_hpd_pin(dev_priv, port);
> +
> + return HPD_PORT_A + port - PORT_A;
> +}
> +
>  #define port_tc_name(port) ((port) - PORT_TC1 + '1')
>  #define tc_port_name(tc_port) ((tc_port) - TC_PORT_1 + '1')
>  
> @@ -4070,6 +4078,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   encoder->hpd_pin = icl_hpd_pin(dev_priv, port);
>   else if (IS_GEN(dev_priv, 10))
>   encoder->hpd_pin = cnl_hpd_pin(dev_priv, port);
> + else if (IS_GEN(dev_priv, 9))
> + encoder->hpd_pin = skl_hpd_pin(dev_priv, port);
>   else
>   encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port);
>  
> -- 
> 2.29.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 4/4] drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos

[Rodrigo Vivi]

On Tue, Feb 09, 2021 at 04:28:31PM -0500, Lyude Paul wrote:
> Apparently the new gen9_bc platforms that Intel has introduced don't
> provide us with a STRAP config register to read from for initializing DDI
> B, C, and D detection. So, workaround this by hard-coding our strap config
> in intel_setup_outputs().
> 
> Changes since v4:
> * Split this into it's own commit
> 
> Cc: Matt Roper 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> [originally from Tejas's work]
> Signed-off-by: Tejas Upadhyay 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index beed08c00b6c..4dee37f8659d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11943,7 +11943,14 @@ static void intel_setup_outputs(struct 
> drm_i915_private *dev_priv)
>  
>   /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
>* register */
> - found = intel_de_read(dev_priv, SFUSE_STRAP);
> + if (HAS_PCH_TGP(dev_priv)) {
> + /* W/A due to lack of STRAP config on TGP PCH*/
> + found = (SFUSE_STRAP_DDIB_DETECTED |
> +  SFUSE_STRAP_DDIC_DETECTED |
> +  SFUSE_STRAP_DDID_DETECTED);

we have somewhere in this function these forced fuse straps for gen9 platform...
don't we have a ways to combine them?

Afterall, the reason that we need these forced bits is
because it is a gen9, not because it is a TGP...

> + } else {
> + found = intel_de_read(dev_priv, SFUSE_STRAP);
> + }
>  
>   if (found & SFUSE_STRAP_DDIB_DETECTED)
>   intel_ddi_init(dev_priv, PORT_B);
> -- 
> 2.29.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 2/4] drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappings

[Rodrigo Vivi]

On Tue, Feb 09, 2021 at 04:28:29PM -0500, Lyude Paul wrote:
> With the introduction of gen9_bc, where Intel combines Cometlake CPUs with
> a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this
> platform in order to make all of the display connectors work. So, let's do
> that.
> 
> Changes since v4:
> * Split this into it's own patch - vsyrjala
> 
> Cc: Matt Roper 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> [originally from Tejas's work]
> Signed-off-by: Tejas Upadhyay 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_bios.c |  9 +
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 20 
>  2 files changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 7118530a1c38..1289f9d437e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1638,6 +1638,12 @@ static const u8 adls_ddc_pin_map[] = {
>   [ADLS_DDC_BUS_PORT_TC4] = GMBUS_PIN_12_TC4_ICP,
>  };
>  
> +static const u8 gen9bc_tgp_ddc_pin_map[] = {
> + [DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
> + [DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
> + [DDC_BUS_DDI_D] = GMBUS_PIN_10_TC2_ICP,
> +};
> +
>  static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
>  {
>   const u8 *ddc_pin_map;
> @@ -1651,6 +1657,9 @@ static u8 map_ddc_pin(struct drm_i915_private 
> *dev_priv, u8 vbt_pin)
>   } else if (IS_ROCKETLAKE(dev_priv) && INTEL_PCH_TYPE(dev_priv) == 
> PCH_TGP) {
>   ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
>   n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
> + } else if (HAS_PCH_TGP(dev_priv) && IS_GEN9_BC(dev_priv)) {
> + ddc_pin_map = gen9bc_tgp_ddc_pin_map;
> + n_entries = ARRAY_SIZE(gen9bc_tgp_ddc_pin_map);
>   } else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
>   ddc_pin_map = icp_ddc_pin_map;
>   n_entries = ARRAY_SIZE(icp_ddc_pin_map);
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index dad54e116bc4..49528d07c7f3 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -3138,6 +3138,24 @@ static u8 rkl_port_to_ddc_pin(struct drm_i915_private 
> *dev_priv, enum port port)
>   return GMBUS_PIN_1_BXT + phy;
>  }
>  
> +static u8 gen9bc_port_to_ddc_pin(struct drm_i915_private *i915, enum port 
> port)
> +{
> + enum phy phy = intel_port_to_phy(i915, port);
> +
> + drm_WARN_ON(&i915->drm, port == PORT_A);
> +
> + /*
> +  * Pin mapping for GEN9 BC depends on which PCH is present.  With TGP,
> +  * final two outputs use type-c pins, even though they're actually
> +  * combo outputs.  With CMP, the traditional DDI A-D pins are used for
> +  * all outputs.
> +  */
> + if (INTEL_PCH_TYPE(i915) >= PCH_TGP && phy >= PHY_C)
> + return GMBUS_PIN_9_TC1_ICP + phy - PHY_C;
> +
> + return GMBUS_PIN_1_BXT + phy;
> +}
> +
>  static u8 dg1_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port 
> port)
>  {
>   return intel_port_to_phy(dev_priv, port) + 1;
> @@ -3202,6 +3220,8 @@ static u8 intel_hdmi_ddc_pin(struct intel_encoder 
> *encoder)
>   ddc_pin = dg1_port_to_ddc_pin(dev_priv, port);
>   else if (IS_ROCKETLAKE(dev_priv))
>   ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
> + else if (IS_GEN9_BC(dev_priv) && HAS_PCH_TGP(dev_priv))
> + ddc_pin = gen9bc_port_to_ddc_pin(dev_priv, port);

what about also calling this function gen9bc_tgp_ ?

but up to you...
this version is much better without the if gen9 inside a "tgp" func...
thanks

Reviewed-by: Rodrigo Vivi 

>   else if (HAS_PCH_MCC(dev_priv))
>   ddc_pin = mcc_port_to_ddc_pin(dev_priv, port);
>   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> -- 
> 2.29.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v4 09/11] drm/i915/dpcd_bl: Print return codes for VESA backlight failures

[Rodrigo Vivi]

On Mon, Feb 08, 2021 at 06:38:59PM -0500, Lyude Paul wrote:
> Also, stop printing the DPCD register that failed, and just describe it
> instead. Saves us from having to look up each register offset when reading
> through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
> us that anyway).
> 
> Signed-off-by: Lyude Paul 

Reviewed-by: Rodrigo Vivi 

> ---
>  .../drm/i915/display/intel_dp_aux_backlight.c | 101 +-
>  1 file changed, 52 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index a139f0e08839..a98d9bd4b0ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -274,14 +274,12 @@ static bool 
> intel_dp_aux_vesa_backlight_dpcd_mode(struct intel_connector *connec
>  {
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + int ret;
>   u8 mode_reg;
>  
> - if (drm_dp_dpcd_readb(&intel_dp->aux,
> -   DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> -   &mode_reg) != 1) {
> - drm_dbg_kms(&i915->drm,
> - "Failed to read the DPCD register 0x%x\n",
> - DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> + ret = drm_dp_dpcd_readb(&intel_dp->aux, 
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &mode_reg);
> + if (ret != 1) {
> + drm_dbg_kms(&i915->drm, "Failed to read backlight mode: %d\n", 
> ret);
>   return false;
>   }
>  
> @@ -297,6 +295,7 @@ static u32 intel_dp_aux_vesa_get_backlight(struct 
> intel_connector *connector, en
>  {
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + int ret;
>   u8 read_val[2] = { 0x0 };
>   u16 level = 0;
>  
> @@ -307,10 +306,10 @@ static u32 intel_dp_aux_vesa_get_backlight(struct 
> intel_connector *connector, en
>   if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
>   return connector->panel.backlight.max;
>  
> - if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, 
> &read_val,
> -  sizeof(read_val)) != sizeof(read_val)) {
> - drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
> - DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
> + ret = drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, 
> &read_val,
> +sizeof(read_val));
> + if (ret != sizeof(read_val)) {
> + drm_dbg_kms(&i915->drm, "Failed to read brightness level: 
> %d\n", ret);
>   return 0;
>   }
>  
> @@ -333,6 +332,7 @@ intel_dp_aux_vesa_set_backlight(const struct 
> drm_connector_state *conn_state,
>   struct intel_connector *connector = 
> to_intel_connector(conn_state->connector);
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + int ret;
>   u8 vals[2] = { 0x0 };
>  
>   /* Write the MSB and/or LSB */
> @@ -343,10 +343,10 @@ intel_dp_aux_vesa_set_backlight(const struct 
> drm_connector_state *conn_state,
>   vals[0] = level;
>   }
>  
> - if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, 
> vals,
> -   sizeof(vals)) != sizeof(vals)) {
> - drm_dbg_kms(&i915->drm,
> - "Failed to write aux backlight level\n");
> + ret = drm_dp_dpcd_write(&intel_dp->aux, 
> DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, vals,
> + sizeof(vals));
> + if (ret != sizeof(vals)) {
> + drm_dbg_kms(&i915->drm, "Failed to write aux backlight level: 
> %d\n", ret);
>   return;
>   }
>  }
> @@ -355,26 +355,28 @@ static void set_vesa_backlight_enable(struct 
> intel_connector *connector, bool en
>  {
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + int ret;
>   u8 reg_val = 0;
>  
>   /* Early return when display use other mechanism to enable backlight. */
>   if (!connector->panel.backlight.edp.vesa.aux_enable)
>   return;
>  
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER, 
> ®_val) != 1) {
> - drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
> - DP_EDP_DISPLAY_CONTROL_REGISTER);
> + ret = drm_dp_dpcd_readb(&intel_dp->aux, 
> DP_EDP_DISPLAY_CONTROL_REGISTER, ®_val);
> + if (ret != 1) {
> + drm_dbg_kms(&i915->drm, "Failed to read eDP display control 
> register: %d\n", ret);
>   return;
>   }
> +
>   if (enable)
>   reg_val |= DP_EDP_BACKLIGHT_ENABLE;
>   else

Re: [Intel-gfx] [RFC v4 08/11] drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT

[Rodrigo Vivi]

On Mon, Feb 08, 2021 at 06:38:58PM -0500, Lyude Paul wrote:
> If we can't read DP_EDP_PWMGEN_BIT_COUNT in
> intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
> defined in the VBT, we'll keep going in the function until we inevitably
> fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
> doing this, so just return early.
> 
> Signed-off-by: Lyude Paul 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 611eb3a7cc08..a139f0e08839 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -449,11 +449,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct 
> intel_connector *connecto
>   int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
>   u8 pn, pn_min, pn_max;
>  
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, &pn) == 
> 1) {
> - pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> - max_backlight = (1 << pn) - 1;
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, &pn) != 
> 1) {
> + drm_dbg_kms(&i915->drm, "Failed to read pwmgen bit count 
> cap\n");
> + return 0;
>   }
>  
> + pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> + max_backlight = (1 << pn) - 1;
> +
>   /* Find desired value of (F x P)
>* Note that, if F x P is out of supported range, the maximum value or
>* minimum value will applied automatically. So no need to check that.
> -- 
> 2.29.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v4 05/11] drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit

[Rodrigo Vivi]

On Mon, Feb 08, 2021 at 06:38:55PM -0500, Lyude Paul wrote:
> Get rid of the extraneous switch case in here, and just open code
> edp_backlight_mode as we only ever use it once.
> 
> v4:
> * Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
>   DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
> 
> Signed-off-by: Lyude Paul 

Reviewed-by: Rodrigo Vivi 

> ---
>  .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index c37ccc8538cb..57218faed4a3 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -382,7 +382,7 @@ intel_dp_aux_vesa_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   struct intel_panel *panel = &connector->panel;
> - u8 dpcd_buf, new_dpcd_buf, edp_backlight_mode;
> + u8 dpcd_buf, new_dpcd_buf;
>   u8 pwmgen_bit_count = panel->backlight.edp.vesa.pwmgen_bit_count;
>  
>   if (drm_dp_dpcd_readb(&intel_dp->aux,
> @@ -393,12 +393,8 @@ intel_dp_aux_vesa_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
>   }
>  
>   new_dpcd_buf = dpcd_buf;
> - edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>  
> - switch (edp_backlight_mode) {
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> + if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
> DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
>   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>  
> @@ -406,13 +402,6 @@ intel_dp_aux_vesa_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
>  pwmgen_bit_count) != 1)
>   drm_dbg_kms(&i915->drm,
>   "Failed to write aux pwmgen bit count\n");
> -
> - break;
> -
> - /* Do nothing when it is already DPCD mode */
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
> - default:
> - break;
>   }
>  
>   if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
> -- 
> 2.29.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers

[Rodrigo Vivi]

On Mon, Feb 08, 2021 at 06:39:00PM -0500, Lyude Paul wrote:
> Since we're about to implement eDP backlight support in nouveau using the
> standard protocol from VESA, we might as well just take the code that's
> already written for this and move it into a set of shared DRM helpers.
> 
> Note that these helpers are intended to handle DPCD related backlight
> control bits such as setting the brightness level over AUX, probing the
> backlight's TCON, enabling/disabling the backlight over AUX if supported,
> etc. Any PWM-related portions of backlight control are explicitly left up
> to the driver, as these will vary from platform to platform.
> 
> The only exception to this is the calculation of the PWM frequency
> pre-divider value. This is because the only platform-specific information
> required for this is the PWM frequency of the panel, which the driver is
> expected to provide if available. The actual algorithm for calculating this
> value is standard and is defined in the eDP specification from VESA.
> 
> Note that these helpers do not yet implement the full range of features
> the VESA backlight interface provides, and only provide the following
> functionality (all of which was already present in i915's DPCD backlight
> support):
> 
> * Basic control of brightness levels
> * Basic probing of backlight capabilities
> * Helpers for enabling and disabling the backlight
> 
> v3:
> * Split out changes to i915's backlight code to separate patches to make it
>   easier to review
> v4:
> * Style/spelling changes from Thomas Zimmermann
> 
> Signed-off-by: Lyude Paul 
> Cc: Jani Nikula 
> Cc: Dave Airlie 
> Cc: greg.depo...@gmail.com
> ---
>  drivers/gpu/drm/drm_dp_helper.c   | 332 ++
>  .../drm/i915/display/intel_display_types.h|   5 +-
>  .../drm/i915/display/intel_dp_aux_backlight.c | 285 ++-
>  include/drm/drm_dp_helper.h   |  48 +++
>  4 files changed, 412 insertions(+), 258 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index eedbb48815b7..1a3d4679d720 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -3082,3 +3082,335 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct 
> drm_dp_aux *aux, u8 color_spc)
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> +
> +/**
> + * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel 
> via AUX
> + * @aux: The DP AUX channel to use
> + * @bl: Backlight capability info from drm_edp_backlight_init()
> + * @level: The brightness level to set
> + *
> + * Sets the brightness level of an eDP panel's backlight. Note that the 
> panel's backlight must
> + * already have been enabled by the driver by calling 
> drm_edp_backlight_enable().
> + *
> + * Returns: %0 on success, negative error code on failure
> + */
> +int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct 
> drm_edp_backlight_info *bl,
> + u16 level)
> +{
> + int ret;
> + u8 buf[2] = { 0 };
> +
> + if (bl->lsb_reg_used) {
> + buf[0] = (level & 0xff00) >> 8;
> + buf[1] = (level & 0x00ff);
> + } else {
> + buf[0] = level;
> + }
> +
> + ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf, 
> sizeof(buf));
> + if (ret != sizeof(buf)) {
> + DRM_ERROR("%s: Failed to write aux backlight level: %d\n", 
> aux->name, ret);
> + return ret < 0 ? ret : -EIO;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> +
> +static int
> +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct 
> drm_edp_backlight_info *bl,
> +  bool enable)
> +{
> + int ret;
> + u8 buf;
> +
> + /* The panel uses something other then DPCD for enabling its backlight 
> */
> + if (!bl->aux_enable)
> + return 0;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, &buf);
> + if (ret != 1) {
> + DRM_ERROR("%s: Failed to read eDP display control register: 
> %d\n", aux->name, ret);
> + return ret < 0 ? ret : -EIO;
> + }
> + if (enable)
> + buf |= DP_EDP_BACKLIGHT_ENABLE;
> + else
> + buf &= ~DP_EDP_BACKLIGHT_ENABLE;
> +
> + ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
> + if (ret != 1) {
> + DRM_ERROR("%s: Failed to write eDP display control register: 
> %d\n", aux->name, ret);
> + return ret < 0 ? ret : -EIO;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
> + * @aux: The DP AUX channel to use
> + * @bl: Backlight capability info from drm_edp_backlight_init()
> + * @level: The initial backlight level to set via AUX, if there is one
> + *
> + * This function handles enabling DPCD backlight controls on a panel over 
> DP

Re: [Intel-gfx] [PATCH 1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend

[Rodrigo Vivi]

On Wed, Feb 10, 2021 at 10:19:50PM +, Chris Wilson wrote:
> After calling intel_gt_suspend_prepare(), the driver starts to turn off
> various subsystems, such as clearing the GGTT, before calling
> intel_gt_suspend_late() to relinquish control over the GT. However, if
> we still have internal GPU state active as we clear the GGTT, the GPU
> may write back its internal state to the residual GGTT addresses that
> are now pointing into scratch. Let's reset the GPU to clear that
> internal state as soon we have idled the GPU in prepare-to-suspend.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index 0bd303d2823e..f41612faa269 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -295,6 +295,9 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
>   wait_for_suspend(gt);

you just wedged the gpu here...

>  
>   intel_uc_suspend(>->uc);
> +
> + /* Flush all the contexts and internal state before turning off GGTT */
> + gt_sanitize(gt, false);

and now we are unsetting wedge here...

is this right?

>  }
>  
>  static suspend_state_t pm_suspend_target(void)
> @@ -337,7 +340,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)
>   intel_llc_disable(>->llc);
>   }
>  
> - gt_sanitize(gt, false);
> + gt_sanitize(gt, false); /* Be paranoid, remove all residual GPU state */
>  
>   GT_TRACE(gt, "\n");
>  }
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Clear internal GT state on hibernate

[Rodrigo Vivi]

On Wed, Feb 10, 2021 at 10:19:51PM +, Chris Wilson wrote:
> Call intel_gt_suspend_late() to disable the GT before hibernation.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 000e1cd8e920..da0ef483ad6b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -115,6 +115,8 @@ int i915_gem_freeze_late(struct drm_i915_private *i915)
>* the objects as well, see i915_gem_freeze()
>*/
>  
> + intel_gt_suspend_late(&i915->gt);
> +

why are you calling this here instead of directly in i915_drm_suspend_late ?

>   with_intel_runtime_pm(&i915->runtime_pm, wakeref)
>   i915_gem_shrink(i915, -1UL, NULL, ~0);
>   i915_gem_drain_freed_objects(i915);
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/adl_s: Add gmbus pin mapping

[Ram Moon, AnandX]

Hi Aditya,

Thanks for your review comments.

-Original Message-
From: Aditya Swarup  
Sent: Wednesday, February 10, 2021 9:54 PM
To: Ram Moon, AnandX ; 
intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Roper, 
Matthew D ; Auld, Matthew ; 
Surendrakumar Upadhyay, TejaskumarX 

Subject: Re: [PATCH] drm/i915/adl_s: Add gmbus pin mapping

On 2/10/21 3:54 AM, Anand Moon wrote:
> Add table to map the GMBUS pin pairs to GPIO registers and port to DDC 
> mapping for ADL_S as per below Bspec.

Has this patch been tested on an ADLS system? Upstream CI AFAIK doesn't have 
support for ADL-S. Also comments below..

Reason I send this patch so that I could get more review comments for this 
below changes.
I have gone through the Bspec 20124 and I have debug this patch earlier,  
so that the mapping with DDC pin is correctly mapped
with respect to the configuration table in the Bspec, 
but still we observe GMBUS i2c handshake failure. 
How can we debug this further. 

> 
> Bspec:20124, 53597.
> 
> Cc: Aditya Swarup 
> Cc: Matt Roper 
> Cc: Lucas De Marchi 
> Signed-off-by: Anand Moon 
> ---
>  drivers/gpu/drm/i915/display/intel_gmbus.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index 0c952e1d720e..58b8e42d4f90 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -52,6 +52,14 @@ static const struct gmbus_pin gmbus_pins[] = {
>   [GMBUS_PIN_DPD] = { "dpd", GPIOF },
>  };
>  
> +static const struct gmbus_pin gmbus_pins_adls[] = {
> + [GMBUS_PIN_1_BXT] = { "edp", GPIOA },

I am pretty sure that GMBUS_PIN_1_BXT should map to GPIOB(1) and not GPIOA(0) 
like what we have for ICP.

Ok, will update this in next version.

> + [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOD },
> + [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOE },
> + [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOF },
> + [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOG }, };
> +
>  static const struct gmbus_pin gmbus_pins_bdw[] = {
>   [GMBUS_PIN_VGADDC] = { "vga", GPIOA },
>   [GMBUS_PIN_DPC] = { "dpc", GPIOD },
> @@ -101,7 +109,9 @@ static const struct gmbus_pin gmbus_pins_dg1[] = {  
> static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private 
> *dev_priv,
>unsigned int pin)
>  {
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)

This check should be converted to IS_ALDERLAKE_S(dev_priv) instead of PCH check 
for PCH_ADP.
Unfortunately, we are reusing PCH_ADP for ADLS and ADLP which have different 
mappings but the same ADP PCH.
This will break ADLP. 

The PCH_ADP check for ADLS in intel_bios.c will also be changed in the ADLP 
patches that are going to be submitted upstream.

So might as well do the correct thing now and change this to 
IS_ALDERLAKE_S(dev_priv).

Ok will update this in next version.

> + return &gmbus_pins_adls[pin];
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
>   return &gmbus_pins_dg1[pin];
>   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>   return &gmbus_pins_icp[pin];
> @@ -122,7 +132,9 @@ bool intel_gmbus_is_valid_pin(struct 
> drm_i915_private *dev_priv,  {
>   unsigned int size;
>  
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)

See comment above. Change to IS_ALDERLAKE_S(dev_priv)

Ok.

Aditya Swarup

> + size = ARRAY_SIZE(gmbus_pins_adls);
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
>   size = ARRAY_SIZE(gmbus_pins_dg1);
>   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>   size = ARRAY_SIZE(gmbus_pins_icp);
> 

Thanks
-Anand
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vbt: update DP max link rate table

[Lee, Shawn C]

On Wed, Feb 10, 2021 at 04:51 p.m, Ville Syrjälä wrote:
>On Mon, Feb 08, 2021 at 01:31:57PM +, Lee, Shawn C wrote:
>> On Fri, Feb 05, 2021, at 8:26 p.m, Ville Syrjälä wrote:
>> >On Mon, Feb 01, 2021 at 11:02:28PM +0800, Lee Shawn C wrote:
>> >> According to Bspec #20124, max link rate table for DP was updated 
>> >> at BDB version 230. Max link rate can support upto UHBR.
>> >> 
>> >> After migrate to BDB v230, the definition for LBR, HBR2 and HBR3 
>> >> were changed. For backward compatibility. If BDB version was from 
>> >> 216 to 229. Driver have to follow original rule to configure DP max 
>> >> link rate value from VBT.
>> >> 
>> >> Cc: Ville Syrjala 
>> >> Cc: Imre Deak 
>> >> Cc: Jani Nikula 
>> >> Cc: Cooper Chiou 
>> >> Cc: William Tseng 
>> >> Signed-off-by: Lee Shawn C 
>> >> ---
>> >>  drivers/gpu/drm/i915/display/intel_bios.c | 24 ++-
>> >>  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 14 +++
>> >>  2 files changed, 32 insertions(+), 6 deletions(-)
>> >> 
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> >> b/drivers/gpu/drm/i915/display/intel_bios.c
>> >> index 04337ac6f8c4..be1f732e6550 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> >> @@ -1876,7 +1876,15 @@ static void parse_ddi_port(struct drm_i915_private 
>> >> *dev_priv,
>> >>   /* DP max link rate for CNL+ */
>> >>   if (bdb_version >= 216) {
>> >>   switch (child->dp_max_link_rate) {
>> >> - default:
>> >> + case VBT_DP_MAX_LINK_RATE_UHBR20:
>> >> + info->dp_max_link_rate = 200;
>> >> + break;
>> >> + case VBT_DP_MAX_LINK_RATE_UHBR13P5:
>> >> + info->dp_max_link_rate = 135;
>> >> + break;
>> >> + case VBT_DP_MAX_LINK_RATE_UHBR10:
>> >> + info->dp_max_link_rate = 100;
>> >> + break;
>> >>   case VBT_DP_MAX_LINK_RATE_HBR3:
>> >>   info->dp_max_link_rate = 81;
>> >>   break;
>> >> @@ -1889,7 +1897,21 @@ static void parse_ddi_port(struct drm_i915_private 
>> >> *dev_priv,
>> >>   case VBT_DP_MAX_LINK_RATE_LBR:
>> >>   info->dp_max_link_rate = 162000;
>> >>   break;
>> >> + case VBT_DP_MAX_LINK_RATE_DEFAULT:
>> >> + default:
>> >> + info->dp_max_link_rate = 0;
>> >> + break;
>> >> + }
>> >> +
>> >> + if (bdb_version < 230) {
>> >> + if (child->dp_max_link_rate == 
>> >> VBT_DP_MAX_LINK_RATE_DEFAULT)
>> >> + info->dp_max_link_rate = 81;
>> >> + else if (child->dp_max_link_rate == 
>> >> VBT_DP_MAX_LINK_RATE_LBR)
>> >> + info->dp_max_link_rate = 54;
>> >> + else if (child->dp_max_link_rate == 
>> >> VBT_DP_MAX_LINK_RATE_HBR2)
>> >> + info->dp_max_link_rate = 162000;
>> >>   }
>> >
>> >I would split this into two separate functions, one does the new mapping, 
>> >the other the old mapping. 
>> >
>> 
>> I will split this into two separate functions in patch v2.
>
>Actually looking through the VBT history this seems to have been
>retroactively changed for already rev 216+ to follow the new
>definitions. And naturally no actual explanation given. So it's
>the same old VBT==snafu as always.
>
>I guess the real question is whether any machines migth have shipped
>that depened on the old defitions? Unless someone manages to
>find that out I think we might just have to change this to follow
>only the new style and hope we don't regress a lot of machines.
>

Agree that we should just have the change follow new definition.
But as you mentioned, we are not sure any machines have shipped
with the old definition. :(

In my opinion, we should follow the new style. If we got bug report,
then we can consider to add some codes for backward compatible.

>I was a bit hopeful that this might have fixed [1], but looks
>like that just has this set to 0 which doesn't give us the desired
>2.7Gbps with either the old or new definition :(
>
>[1] https://gitlab.freedesktop.org/drm/intel/-/issues/3034
>

Just like what you said. This change should not be able to give 2.7GHz
on eDP port to help on this issue.

This might not be a good idea. But how about to add this OUI into
quirk list? Then driver can give bandwidth limitation for particular panel.

[2.422930] [drm:drm_dp_read_desc [drm_kms_helper]] AUX A/DDI A/PHY A: DP 
sink: OUI 38-ec-11 dev-ID  HW-rev 0.0 SW-rev 0.0 quirks 0x

Best regards,
Shawn

>--
>Ville Syrjälä
>Intel
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.

[Intel-gfx] [PATCH v2] drm/i915/debugfs: HDCP capability enc NULL check

[Anshuman Gupta]

DP-MST connector encoder initializes at modeset
Adding a connector->encoder NULL check in order to
avoid any NULL pointer dereference.
intel_hdcp_enable() already handle this but debugfs
can also invoke the intel_{hdcp,hdcp2_capable}.
Handling it gracefully.

v2:
- Use necessary lock and NULL check in
  i915_hdcp_sink_capability_show. [Imre]

Signed-off-by: Anshuman Gupta 
---
 .../gpu/drm/i915/display/intel_display_debugfs.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index d6e4a9237bda..ed5e2f65b171 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2198,14 +2198,26 @@ DEFINE_SHOW_ATTRIBUTE(i915_panel);
 static int i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
 {
struct drm_connector *connector = m->private;
+   struct drm_i915_private *i915 = to_i915(connector->dev);
struct intel_connector *intel_connector = to_intel_connector(connector);
+   int ret;
 
-   if (connector->status != connector_status_connected)
-   return -ENODEV;
+   ret = 
drm_modeset_lock_single_interruptible(&i915->drm.mode_config.connection_mutex);
+   if (ret)
+   return ret;
+
+   if (!connector->encoder || connector->status != 
connector_status_connected) {
+   ret = -ENODEV;
+   goto out;
+   }
 
seq_printf(m, "%s:%d HDCP version: ", connector->name,
   connector->base.id);
intel_hdcp_info(m, intel_connector);
+out:
+   drm_modeset_unlock(&i915->drm.mode_config.connection_mutex);
+   if (ret)
+   return ret;
 
return 0;
 }
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/3] drm/dp_helper: Define options for FRL training for HDMI2.1 PCON

[Ankit Nautiyal]

Currently the FRL training mode (Concurrent, Sequential) and
training type (Normal, Extended) are not defined properly and
are passed as bool values in drm_helpers for pcon
configuration for FRL training.

This patch:
-Add register masks for Sequential and Normal FRL training options.
-Fixes the drm_helpers for FRL Training configuration to use the
 appropriate masks.
-Modifies the calls to the above drm_helpers in i915/intel_dp as per
 the above change.

v2: Re-used the register masks for these options, instead of enum. (Ville)

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/drm_dp_helper.c | 24 ++--
 drivers/gpu/drm/i915/display/intel_dp.c | 10 --
 include/drm/drm_dp_helper.h |  6 --
 3 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..cb2f53e56685 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2635,14 +2635,16 @@ EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
  * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
  * @aux: DisplayPort AUX channel
  * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
- * @concurrent_mode: true if concurrent mode or operation is required,
- * false otherwise.
+ * @frl_mode: FRL Training mode, it can be either Concurrent or Sequential.
+ * In Concurrent Mode, the FRL link bring up can be done along with
+ * DP Link training. In Sequential mode, the FRL link bring up is done prior to
+ * the DP Link training.
  *
  * Returns 0 if success, else returns negative error code.
  */
 
 int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
-   bool concurrent_mode)
+   u8 frl_mode)
 {
int ret;
u8 buf;
@@ -2651,7 +2653,7 @@ int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, 
int max_frl_gbps,
if (ret < 0)
return ret;
 
-   if (concurrent_mode)
+   if (frl_mode == DP_PCON_ENABLE_CONCURRENT_LINK)
buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
else
buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
@@ -2694,21 +2696,23 @@ EXPORT_SYMBOL(drm_dp_pcon_frl_configure_1);
  * drm_dp_pcon_frl_configure_2() - Set HDMI Link configuration Step-2
  * @aux: DisplayPort AUX channel
  * @max_frl_mask : Max FRL BW to be tried by the PCON with HDMI Sink
- * @extended_train_mode : true for Extended Mode, false for Normal Mode.
- * In Normal mode, the PCON tries each frl bw from the max_frl_mask starting
- * from min, and stops when link training is successful. In Extended mode, all
- * frl bw selected in the mask are trained by the PCON.
+ * @frl_type : FRL training type, can be Extended, or Normal.
+ * In Normal FRL training, the PCON tries each frl bw from the max_frl_mask
+ * starting from min, and stops when link training is successful. In Extended
+ * FRL training, all frl bw selected in the mask are trained by the PCON.
  *
  * Returns 0 if success, else returns negative error code.
  */
 int drm_dp_pcon_frl_configure_2(struct drm_dp_aux *aux, int max_frl_mask,
-   bool extended_train_mode)
+   u8 frl_type)
 {
int ret;
u8 buf = max_frl_mask;
 
-   if (extended_train_mode)
+   if (frl_type == DP_PCON_FRL_LINK_TRAIN_EXTENDED)
buf |= DP_PCON_FRL_LINK_TRAIN_EXTENDED;
+   else
+   buf &= ~DP_PCON_FRL_LINK_TRAIN_EXTENDED;
 
ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_2, buf);
if (ret < 0)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 61beeb3161e2..510c6b442c1b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2559,10 +2559,6 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp 
*intel_dp)
 
 static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
 {
-#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
-#define PCON_CONCURRENT_MODE (1 > 0)
-#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
-#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
 #define TIMEOUT_FRL_READY_MS 500
 #define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
 
@@ -2596,10 +2592,12 @@ static int intel_dp_pcon_start_frl_training(struct 
intel_dp *intel_dp)
return -ETIMEDOUT;
 
max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
-   ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw, 
PCON_SEQUENTIAL_MODE);
+   ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
+ DP_PCON_ENABLE_SEQUENTIAL_LINK);
if (ret < 0)
return ret;
-   ret = drm_dp_pcon_frl_configure_2(&intel_dp->aux, max_frl_bw_mask, 
PCON_NORMAL_TRAIN_MODE);
+   ret = drm_dp_pcon_frl_configure_2(&intel_dp->aux, max_frl_bw_mask,
+ 

Re: [Intel-gfx] [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Almahallawy, Khaled]

On Wed, 2021-02-10 at 13:03 -0500, Lyude Paul wrote:
> On Wed, 2021-02-10 at 00:33 -0800, Khaled Almahallawy wrote:
> > The number of AUX retries specified in the DP specs is 7.
> > Currently, to make
> > Dell 4k monitors happier, the number of retries are 32.
> > i915 also retries 5 times (intel_dp_aux_xfer) which means in the
> > case of AUX
> > timeout we actually retries 32 * 5 = 160 times.
> 
> Is there any good reason for i915 to actually be doing retries
> itself? It seems
> like an easier solution here might just to be to fix i915 so it
> doesn't retry,
> and just rely on DRM to do the retries as appropriate.
> 
> That being said though, I'm open to this if there is a legitimate
> reason for
> i915 to be handling retries on its own

i915 or others may benefit from controlling AUX retries to optimize and
minimize timing spent on the aux transactions.
 
drm_dpcd_access handles multiple aux retries cases the same way (retry
32 times at worst case). The 4 cases are:
1- *AUX receive or IO error*. I believe it is up to specific
implementation/HW once it detects a receive error to retry based on
their internal understanding using the timeout appropriate to the HW
capabilities.
 
2- *AUX Timeout* As the driver follows the specs for the recommended
timeout timer as defined in section  (2.11.2 AUX Transaction
Response/Reply Timeouts), the driver has more intelligence to know how
many retries it needs. This is more useful in case of DP-ALT if some
issues happen in Type-C stack that cause AUX timeout (e.g. USB3 dock
detected as high speed (USB2) causing SBU/AUX lines to be disabled).
Also the disconnect of MST hub/docks is dependent how fast a userspace
disconnect all MST connectors.  Not all user spaces do it as fast like
Chrome (ubuntu is an example): 
https://chromium-review.googlesource.com/c/chromium/src/+/2512550/  

3- *AUX_NACK* DP spec mentions retry 3 times for NACK(2.16.1.3 GTC Lock
Acquisition). However, sometimes we really don’t need any retry for
NACK, if DPRX replied AUX_NACK for DPCD that it doesn’t support (e.g.
reading LTTPR Capability and ID Field at DPCD Fh ~ F0007).

4- *AUX_DEFER* The specs stated we may retry 7 times on AUX_DEFER
(3.5.1.2.3 LANEx_CHANNEL_EQ_DONE Sequence) and may terminate LT. Also
with the increased usage of USB4, TBT/Type-C Docks/Displays, and active
cables, the use of LTTPR becomes common which adds more challenge
especially if we have multiple LTTPRs and all operate in non-LTTPR
mode. In this case all LTTPRs will reply AUX_DEFER in 300us if it did
not receive any aux response from other LTTPRs and DPRX. The SCR states
we need to retry 7 times and not more than 50ms (DP v2.0 SCR on 8b/10b
DPTX and LTTPR Requirements Update to Section 3.6)

In addition I believe this function is not correct in treating
AUX_DEFER and AUX_NACK as -EIO. Especially for AUX_DEFER, it is a valid
1 byte response that can provide a valuable debugging information
especially in the case of on-board LTTPR where there is no way to
capture this AUX response between the SoC and LTTPR unless you solder
two wires on AUX_P and AUX_N lines and use i2c/aux analyzer to decode.
At least we should provide the same debug information as we do in
drm_dp_i2c_do_msg by printing AUX_DEFER and AUX_NACK.

Thank you for your feedback and review.

--Khaled
> 
> > So making the number of aux retires a variable to allow for fine
> > tuning and
> > optimization of aux timing.
> > 
> > Signed-off-by: Khaled Almahallawy 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 10 +++---
> >  include/drm/drm_dp_helper.h |  1 +
> >  2 files changed, 4 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index eedbb48815b7..8fdf57b4a06c 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -249,13 +249,7 @@ static int drm_dp_dpcd_access(struct
> > drm_dp_aux *aux, u8
> > request,
> >  
> > mutex_lock(&aux->hw_mutex);
> >  
> > -   /*
> > -* The specification doesn't give any recommendation on how
> > often to
> > -* retry native transactions. We used to retry 7 times like
> > for
> > -* aux i2c transactions but real world devices this wasn't
> > -* sufficient, bump to 32 which makes Dell 4k monitors
> > happier.
> > -*/
> > -   for (retry = 0; retry < 32; retry++) {
> > +   for (retry = 0; retry < aux->num_retries; retry++) {
> > if (ret != 0 && ret != -ETIMEDOUT) {
> > usleep_range(AUX_RETRY_INTERVAL,
> >  AUX_RETRY_INTERVAL + 100);
> > @@ -1744,6 +1738,8 @@ void drm_dp_aux_init(struct drm_dp_aux *aux)
> > aux->ddc.retries = 3;
> >  
> > aux->ddc.lock_ops = &drm_dp_i2c_lock_ops;
> > +   /*Still making the Dell 4k monitors happier*/
> > +   aux->num_retries = 32;
> >  }
> >  EXPORT_SYMBOL(drm_dp_aux_init);
> >  
> > diff --git a/include/drm/drm_dp_hel

Re: [Intel-gfx] [PATCH 2/3] drm/dp_helper: Define options for FRL training for HDMI2.1 PCON

[Nautiyal, Ankit K]

On 2/6/2021 1:30 AM, Ville Syrjälä wrote:

On Thu, Feb 04, 2021 at 12:18:41PM +0530, Ankit Nautiyal wrote:

Currently the FRL training mode (Concurrent, Sequential) and
training type (Normal, Extended) are not defined properly and
are passed as bool values in drm_helpers for pcon
configuration for FRL training.

This patch:
-Defines FRL training type and link bring up sequence mode as enum.
-Fixes the drm_helpers for FRL Training configuration to use these enums.
-Modifies the calls to the above drm_helpers in i915/intel_dp as per the
above change.

Signed-off-by: Ankit Nautiyal 
---
  drivers/gpu/drm/drm_dp_helper.c | 18 +-
  drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
  include/drm/drm_dp_helper.h | 46 +++--
  3 files changed, 56 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..2ca4ab5af470 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2635,14 +2635,13 @@ EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
   * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
   * @aux: DisplayPort AUX channel
   * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
- * @concurrent_mode: true if concurrent mode or operation is required,
- * false otherwise.
+ * @frl_mode: FRL Training mode, it can be either Concurrent or Sequential.
   *
   * Returns 0 if success, else returns negative error code.
   */
  
  int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,

-   bool concurrent_mode)
+   enum dp_pcon_frl_train_mode frl_mode)
  {
int ret;
u8 buf;
@@ -2651,7 +2650,7 @@ int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, 
int max_frl_gbps,
if (ret < 0)
return ret;
  
-	if (concurrent_mode)

+   if (frl_mode == DP_PCON_FRL_MODE_CONCURRENT)
buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
else
buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
@@ -2694,21 +2693,20 @@ EXPORT_SYMBOL(drm_dp_pcon_frl_configure_1);
   * drm_dp_pcon_frl_configure_2() - Set HDMI Link configuration Step-2
   * @aux: DisplayPort AUX channel
   * @max_frl_mask : Max FRL BW to be tried by the PCON with HDMI Sink
- * @extended_train_mode : true for Extended Mode, false for Normal Mode.
- * In Normal mode, the PCON tries each frl bw from the max_frl_mask starting
- * from min, and stops when link training is successful. In Extended mode, all
- * frl bw selected in the mask are trained by the PCON.
+ * @frl_type : FRL training type, can be Extended, or Normal.
   *
   * Returns 0 if success, else returns negative error code.
   */
  int drm_dp_pcon_frl_configure_2(struct drm_dp_aux *aux, int max_frl_mask,
-   bool extended_train_mode)
+   enum dp_pcon_frl_train_type frl_type)
  {
int ret;
u8 buf = max_frl_mask;
  
-	if (extended_train_mode)

+   if (frl_type == DP_PCON_FRL_TRAIN_EXTENDED)
buf |= DP_PCON_FRL_LINK_TRAIN_EXTENDED;
+   else
+   buf &= ~DP_PCON_FRL_LINK_TRAIN_EXTENDED;

These names are annoyingly close to each other. Prettu much
guaranteed to mix them up at some point. We should try to come
up something a bit more distinctive for the enum, or just forget
the enum and use the register values directly.


Agreed. Sent next version of the patch, dropping the enum and used only 
appropriate register values.


Thanks & Regards,

Ankit

  
  	ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_2, buf);

if (ret < 0)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2b83f0f433a2..1962d6dd8641 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2560,10 +2560,6 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp 
*intel_dp)
  
  static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)

  {
-#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
-#define PCON_CONCURRENT_MODE (1 > 0)
-#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
-#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
  #define TIMEOUT_FRL_READY_MS 500
  #define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
  
@@ -2597,10 +2593,12 @@ static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)

return -ETIMEDOUT;
  
  	max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);

-   ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw, 
PCON_SEQUENTIAL_MODE);
+   ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
+ DP_PCON_FRL_MODE_SEQUENTIAL);
if (ret < 0)
return ret;
-   ret = drm_dp_pcon_frl_configure_2(&intel_dp->aux, max_frl_bw_mask, 
PCON_NORMAL_TRAIN_MODE);
+   ret = drm_dp_pcon_frl_configure_2(&

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs: HDCP capability enc NULL check (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/debugfs: HDCP capability enc NULL check (rev2)
URL   : https://patchwork.freedesktop.org/series/86440/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19657


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@memory-alloc:
- fi-tgl-y:   NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) +2 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/fi-tgl-y/igt@amdgpu/amd_ba...@memory-alloc.html

  * igt@gem_linear_blits@basic:
- fi-tgl-y:   [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +1 similar 
issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_linear_bl...@basic.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/fi-tgl-y/igt@gem_linear_bl...@basic.html

  
 Possible fixes 

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [DMESG-WARN][4] ([i915#402]) -> [PASS][5] +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19657

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19657: 78edb3ea251872417662b5eee6a039047b3e7694 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

78edb3ea2518 drm/i915/debugfs: HDCP capability enc NULL check

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDMI2.1 PCON Misc Fixes (rev2)

[Patchwork]

== Series Details ==

Series: HDMI2.1 PCON Misc Fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/86677/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/a