[PATCH 3/3] drm/i915/display: Increase number of fast wake precharge pulses

2024-02-20 Thread Jouni Högander
Increasing number of fast wake sync pulses seem to fix problems with
certain PSR panels. This should be ok for other panels as well as the eDP
specification allows 10...16 precharge pulses and we are still within that
range.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9739
Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index fad39b2e3022..4641c5bb8fb9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -145,7 +145,7 @@ static int intel_dp_aux_sync_len(void)
 
 static u8 intel_dp_aux_fw_sync_len(void)
 {
-   u8 precharge = 10; /* 10-16 */
+   u8 precharge = 12; /* 10-16 */
u8 preamble = 8;
 
return precharge + preamble;
-- 
2.34.1



[PATCH 2/3] drm/i915/psr: Improve fast and IO wake lines calculation

2024-02-20 Thread Jouni Högander
Current fast and IO wake lines calculation is assuming fast wake sync
length is 18 pulses. Let's improve this by checking the actual length.

Also 10 us IO buffer wake time is currently assumed. This is not the case
with LunarLake and beyond. Fix this by adding getter for IO wake time and
return values there according to Bspec.

Bspec: 65450

Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 40 +++-
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 72cadad09db5..4a1e07411716 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1150,6 +1150,28 @@ static bool _lnl_compute_alpm_params(struct intel_dp 
*intel_dp,
return true;
 }
 
+/*
+ * From Bspec:
+ *
+ * For Xe2 and beyond
+ * RBR 15us, HBR1 11us, higher rates 10us
+ *
+ * For pre-Xe2
+ * 10 us
+ */
+static int get_io_wake_time(struct intel_dp *intel_dp,
+   struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   if (DISPLAY_VER(i915) < 20 || crtc_state->port_clock > 27)
+   return 10;
+   else if (crtc_state->port_clock > 162000)
+   return 11;
+   else
+   return 15;
+}
+
 static bool _compute_alpm_params(struct intel_dp *intel_dp,
 struct intel_crtc_state *crtc_state)
 {
@@ -1157,13 +1179,17 @@ static bool _compute_alpm_params(struct intel_dp 
*intel_dp,
int io_wake_lines, io_wake_time, fast_wake_lines, fast_wake_time;
u8 max_wake_lines;
 
-   if (DISPLAY_VER(i915) >= 12) {
-   io_wake_time = 42;
-   /*
-* According to Bspec it's 42us, but based on testing
-* it is not enough -> use 45 us.
-*/
-   fast_wake_time = 45;
+   if (intel_dp->get_aux_fw_sync_len) {
+   int io_wake_time = get_io_wake_time(intel_dp, crtc_state);
+   int tfw_exit_latency = 20; /* eDP spec */
+   int phy_wake = 4;  /* eDP spec */
+   int preamble = 8;  /* eDP spec */
+   int precharge = intel_dp->get_aux_fw_sync_len() - preamble;
+
+   io_wake_time = max(precharge, io_wake_time) + preamble +
+   phy_wake + tfw_exit_latency;
+   fast_wake_time = precharge + preamble + phy_wake +
+   tfw_exit_latency;
 
/* TODO: Check how we can use ALPM_CTL fast wake extended field 
*/
max_wake_lines = 12;
-- 
2.34.1



[PATCH 1/3] drm/i915/display: Add aux function pointer for fast wake sync pulse count

2024-02-20 Thread Jouni Högander
ALPM AUX-Wake fast wake sync pulse count is needed by PSR to calculate IO
wake and fast wake lines.

Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_display_types.h |  6 ++
 drivers/gpu/drm/i915/display/intel_dp_aux.c| 12 +++-
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0d4012097db1..1231d374aeec 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1798,6 +1798,12 @@ struct intel_dp {
u32 (*get_aux_send_ctl)(struct intel_dp *dp, int send_bytes,
u32 aux_clock_divider);
 
+   /*
+* This function returns the number of fast wake sync pulses. It is
+* needed by PSR code to calculate needed fast wake and io wake lines.
+*/
+   u8 (*get_aux_fw_sync_len)(void);
+
i915_reg_t (*aux_ch_ctl_reg)(struct intel_dp *dp);
i915_reg_t (*aux_ch_data_reg)(struct intel_dp *dp, int index);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 4f4a0e3b3114..fad39b2e3022 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -143,10 +143,10 @@ static int intel_dp_aux_sync_len(void)
return precharge + preamble;
 }
 
-static int intel_dp_aux_fw_sync_len(void)
+static u8 intel_dp_aux_fw_sync_len(void)
 {
-   int precharge = 10; /* 10-16 */
-   int preamble = 8;
+   u8 precharge = 10; /* 10-16 */
+   u8 preamble = 8;
 
return precharge + preamble;
 }
@@ -793,10 +793,12 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
else
intel_dp->get_aux_clock_divider = g4x_get_aux_clock_divider;
 
-   if (DISPLAY_VER(i915) >= 9)
+   if (DISPLAY_VER(i915) >= 9) {
intel_dp->get_aux_send_ctl = skl_get_aux_send_ctl;
-   else
+   intel_dp->get_aux_fw_sync_len = intel_dp_aux_fw_sync_len;
+   } else {
intel_dp->get_aux_send_ctl = g4x_get_aux_send_ctl;
+   }
 
intel_dp->aux.drm_dev = >drm;
drm_dp_aux_init(_dp->aux);
-- 
2.34.1



[PATCH 0/3] IO and fast wake lines calculation and increase fw sync length

2024-02-20 Thread Jouni Högander
This patch set is improving IO and fast wake lines calculation in PSR
code:

Use actual fast wake sync pulse count in calculation
Implement getter for IO buffer wake times and use that
Better presentation on how these are calculated

Also number of precharge pulses is increased by 2 pulses to fix
problems with certain panel models.

Jouni Högander (3):
  drm/i915/display: Add aux function pointer for fast wake sync pulse
count
  drm/i915/psr: Improve fast and IO wake lines calculation
  drm/i915/display: Increase number of fast wake precharge pulses

 .../drm/i915/display/intel_display_types.h|  6 +++
 drivers/gpu/drm/i915/display/intel_dp_aux.c   | 12 +++---
 drivers/gpu/drm/i915/display/intel_psr.c  | 40 +++
 3 files changed, 46 insertions(+), 12 deletions(-)

-- 
2.34.1



[PATCH] drm/ttm: Fix an invalid freeing on already freed page in error path

2024-02-20 Thread Thomas Hellström
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.

However the second step was incorrectly freeing the pages already
freed in the first step.

Fix.

Signed-off-by: Thomas Hellström 
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König 
Cc: Dave Airlie 
Cc: Christian Koenig 
Cc: Huang Rui 
Cc: dri-de...@lists.freedesktop.org
Cc:  # v6.4+
---
 drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index b62f420a9f96..112438d965ff 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -387,7 +387,7 @@ static void ttm_pool_free_range(struct ttm_pool *pool, 
struct ttm_tt *tt,
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
 {
-   struct page **pages = tt->pages;
+   struct page **pages = >pages[start_page];
unsigned int order;
pgoff_t i, nr;
 
-- 
2.43.0



✗ Fi.CI.BAT: failure for drm/i915/guc: Add Compute context hint

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Add Compute context hint
URL   : https://patchwork.freedesktop.org/series/130163/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14305 -> Patchwork_130163v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_130163v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_130163v1, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_130163v1/index.html

Participating hosts (40 -> 38)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload:
- bat-adlp-6: [PASS][1] -> [DMESG-WARN][2] +39 other tests 
dmesg-warn
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-adlp-6/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-adlp-6/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@client:
- bat-dg2-8:  [PASS][3] -> [DMESG-WARN][4] +39 other tests 
dmesg-warn
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-dg2-8/igt@i915_selftest@l...@client.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-dg2-8/igt@i915_selftest@l...@client.html
- bat-adlm-1: [PASS][5] -> [DMESG-WARN][6] +39 other tests 
dmesg-warn
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-adlm-1/igt@i915_selftest@l...@client.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-adlm-1/igt@i915_selftest@l...@client.html

  * igt@i915_selftest@live@coherency:
- bat-dg2-9:  [PASS][7] -> [DMESG-WARN][8] +38 other tests 
dmesg-warn
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-dg2-9/igt@i915_selftest@l...@coherency.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-dg2-9/igt@i915_selftest@l...@coherency.html

  * igt@i915_selftest@live@dmabuf:
- bat-rplp-1: [PASS][9] -> [DMESG-WARN][10] +39 other tests 
dmesg-warn
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-rplp-1/igt@i915_selftest@l...@dmabuf.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-rplp-1/igt@i915_selftest@l...@dmabuf.html

  * igt@i915_selftest@live@gem_contexts:
- bat-mtlp-6: [PASS][11] -> [DMESG-WARN][12] +39 other tests 
dmesg-warn
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-mtlp-6/igt@i915_selftest@live@gem_contexts.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-mtlp-6/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_tlb:
- bat-adlp-9: [PASS][13] -> [DMESG-WARN][14] +39 other tests 
dmesg-warn
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-adlp-9/igt@i915_selftest@live@gt_tlb.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-adlp-9/igt@i915_selftest@live@gt_tlb.html

  * igt@i915_selftest@live@late_gt_pm:
- bat-adln-1: [PASS][15] -> [DMESG-WARN][16] +39 other tests 
dmesg-warn
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-adln-1/igt@i915_selftest@live@late_gt_pm.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-adln-1/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@perf:
- bat-dg2-11: [PASS][17] -> [DMESG-WARN][18] +38 other tests 
dmesg-warn
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-dg2-11/igt@i915_selftest@l...@perf.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-dg2-11/igt@i915_selftest@l...@perf.html

  * igt@i915_selftest@live@slpc:
- bat-atsm-1: [PASS][19] -> [DMESG-WARN][20] +39 other tests 
dmesg-warn
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-atsm-1/igt@i915_selftest@l...@slpc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-atsm-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_selftest@live@uncore:
- bat-dg1-7:  [PASS][21] -> [DMESG-WARN][22] +39 other tests 
dmesg-warn
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-dg1-7/igt@i915_selftest@l...@uncore.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130163v1/bat-dg1-7/igt@i915_selftest@l...@uncore.html

  
 Suppressed 

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

  * 

✗ Fi.CI.SPARSE: warning for drm/i915/guc: Add Compute context hint

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Add Compute context hint
URL   : https://patchwork.freedesktop.org/series/130163/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




✓ Fi.CI.BAT: success for drm/i915: Fix doc build issue on intel_cdclk.c

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix doc build issue on intel_cdclk.c
URL   : https://patchwork.freedesktop.org/series/130159/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14305 -> Patchwork_130159v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 38)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-tgl-1115g4:  [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-tgl-1115g4/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130159v1/fi-tgl-1115g4/boot.html

  

### IGT changes ###

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

  [i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293


Build changes
-

  * Linux: CI_DRM_14305 -> Patchwork_130159v1

  CI-20190529: 20190529
  CI_DRM_14305: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7718: 40e8b9122853f455c84afcfa56469a6bc9a0d564 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_130159v1: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

b0baa3015648 drm/i915: Fix doc build issue on intel_cdclk.c

== Logs ==

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


Re: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0

2024-02-20 Thread Almahallawy, Khaled
Thank You for the patch.

Do you think we need to revert:

9c058492b16f ("drm/i915/mst: Reject modes that require the bigjoiner")


On Wed, 2024-02-21 at 00:09 +0200, Stanislav Lisovskiy wrote:
> Patch calculates bigjoiner pipes in mst compute.
> Patch also passes bigjoiner bool to validate plane
> max size.
> 
> Signed-off-by: vsrini4 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 5307ddd4edcf5..fd27d9976c050 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -523,6 +523,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>  struct drm_connector_state
> *conn_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_crtc *crtc = to_intel_crtc(pipe_config-
> >uapi.crtc);
>   struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
>   struct intel_dp *intel_dp = _mst->primary->dp;
>   const struct intel_connector *connector =
> @@ -540,6 +541,10 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
>   return -EINVAL;
>  
> + if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode-
> >crtc_hdisplay,
> + adjusted_mode->crtc_clock))
> + pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1,
> crtc->pipe);
> +
>   pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
>   pipe_config->has_pch_encoder = false;
> @@ -1318,12 +1323,6 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
>*   corresponding link capabilities of the sink) in case the
>*   stream is uncompressed for it by the last branch device.
>*/
> - if (mode_rate > max_rate || mode->clock > max_dotclk ||
> - drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port-
> >full_pbn) {
> - *status = MODE_CLOCK_HIGH;
> - return 0;
> - }
> -
>   if (mode->clock < 1) {
>   *status = MODE_CLOCK_LOW;
>   return 0;
> @@ -1343,6 +1342,12 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
>   return 0;
>   }
>  
> + if (mode_rate > max_rate || mode->clock > max_dotclk ||
> + drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port-
> >full_pbn) {
> + *status = MODE_CLOCK_HIGH;
> + return 0;
> + }
> +
>   if (DISPLAY_VER(dev_priv) >= 10 &&
>   drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
>   /*
> @@ -1385,7 +1390,7 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
>   return 0;
>   }
>  
> - *status = intel_mode_valid_max_plane_size(dev_priv, mode,
> false);
> + *status = intel_mode_valid_max_plane_size(dev_priv, mode,
> bigjoiner);
>   return 0;
>  }
>  


✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix doc build issue on intel_cdclk.c

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix doc build issue on intel_cdclk.c
URL   : https://patchwork.freedesktop.org/series/130159/
State : warning

== Summary ==

Error: dim checkpatch failed
cb8bedefef59 drm/i915: Fix doc build issue on intel_cdclk.c
-:18: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed 
by Closes: with a URL to the report
#18: 
Reported-by: Stephen Rothwell 
Signed-off-by: Rodrigo Vivi 

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




✓ Fi.CI.BAT: success for VBT read cleanup

2024-02-20 Thread Patchwork
== Series Details ==

Series: VBT read cleanup
URL   : https://patchwork.freedesktop.org/series/130158/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14305 -> Patchwork_130158v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 38)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_lrc:
- bat-rplp-1: [PASS][1] -> [INCOMPLETE][2] ([i915#9413])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-rplp-1/igt@i915_selftest@live@gt_lrc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130158v1/bat-rplp-1/igt@i915_selftest@live@gt_lrc.html

  
 Possible fixes 

  * igt@vgem_basic@create:
- {bat-arls-2}:   [FAIL][3] -> [PASS][4] +4 other tests pass
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@vgem_ba...@create.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130158v1/bat-arls-2/igt@vgem_ba...@create.html

  * igt@vgem_basic@dmabuf-mmap:
- {bat-arls-2}:   [INCOMPLETE][5] -> [PASS][6] +6 other tests pass
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@vgem_ba...@dmabuf-mmap.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130158v1/bat-arls-2/igt@vgem_ba...@dmabuf-mmap.html

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

  [i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
  [i915#10196]: https://gitlab.freedesktop.org/drm/intel/issues/10196
  [i915#10212]: https://gitlab.freedesktop.org/drm/intel/issues/10212
  [i915#10213]: https://gitlab.freedesktop.org/drm/intel/issues/10213
  [i915#10214]: https://gitlab.freedesktop.org/drm/intel/issues/10214
  [i915#10215]: https://gitlab.freedesktop.org/drm/intel/issues/10215
  [i915#10216]: https://gitlab.freedesktop.org/drm/intel/issues/10216
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#9413]: https://gitlab.freedesktop.org/drm/intel/issues/9413


Build changes
-

  * Linux: CI_DRM_14305 -> Patchwork_130158v1

  CI-20190529: 20190529
  CI_DRM_14305: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7718: 40e8b9122853f455c84afcfa56469a6bc9a0d564 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_130158v1: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

019fa6ae6288 drm/i915: Show bios vbt when read from firmware/spi/oprom
53e0b8eef3f3 drm/i915: Move vbt read from firmware to intel_bios.c
2b287ce2f0a9 drm/i915: Pass size to spi_oprom_get_vbt
92df00f7dca1 drm/i915: Pass size to oprom_get_vbt

== Logs ==

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


✗ Fi.CI.SPARSE: warning for VBT read cleanup

2024-02-20 Thread Patchwork
== Series Details ==

Series: VBT read cleanup
URL   : https://patchwork.freedesktop.org/series/130158/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:58:9: warning: unreplaced 

✗ Fi.CI.BAT: failure for Bigjoiner refactoring (rev7)

2024-02-20 Thread Patchwork
== Series Details ==

Series: Bigjoiner refactoring (rev7)
URL   : https://patchwork.freedesktop.org/series/128311/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14305 -> Patchwork_128311v7


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_128311v7 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_128311v7, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_128311v7/index.html

Participating hosts (40 -> 39)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- bat-jsl-1:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-jsl-1/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/bat-jsl-1/igt@i915_module_l...@load.html
- bat-adlp-6: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-adlp-6/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/bat-adlp-6/igt@i915_module_l...@load.html
- fi-rkl-11600:   [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-rkl-11600/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/fi-rkl-11600/igt@i915_module_l...@load.html
- fi-apl-guc: [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-apl-guc/igt@i915_module_l...@load.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/fi-apl-guc/igt@i915_module_l...@load.html
- bat-dg1-7:  [PASS][9] -> [ABORT][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-dg1-7/igt@i915_module_l...@load.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/bat-dg1-7/igt@i915_module_l...@load.html
- bat-jsl-3:  [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-jsl-3/igt@i915_module_l...@load.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/bat-jsl-3/igt@i915_module_l...@load.html
- fi-glk-j4005:   [PASS][13] -> [INCOMPLETE][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-glk-j4005/igt@i915_module_l...@load.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/fi-glk-j4005/igt@i915_module_l...@load.html
- bat-adlp-9: [PASS][15] -> [INCOMPLETE][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-adlp-9/igt@i915_module_l...@load.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/bat-adlp-9/igt@i915_module_l...@load.html
- fi-skl-guc: [PASS][17] -> [ABORT][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-skl-guc/igt@i915_module_l...@load.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/fi-skl-guc/igt@i915_module_l...@load.html
- bat-dg2-11: [PASS][19] -> [INCOMPLETE][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-dg2-11/igt@i915_module_l...@load.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/bat-dg2-11/igt@i915_module_l...@load.html
- fi-kbl-7567u:   [PASS][21] -> [INCOMPLETE][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-kbl-7567u/igt@i915_module_l...@load.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/fi-kbl-7567u/igt@i915_module_l...@load.html
- bat-adln-1: [PASS][23] -> [INCOMPLETE][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-adln-1/igt@i915_module_l...@load.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/bat-adln-1/igt@i915_module_l...@load.html
- fi-cfl-8700k:   [PASS][25] -> [INCOMPLETE][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-cfl-8700k/igt@i915_module_l...@load.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/fi-cfl-8700k/igt@i915_module_l...@load.html
- bat-rplp-1: [PASS][27] -> [INCOMPLETE][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-rplp-1/igt@i915_module_l...@load.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128311v7/bat-rplp-1/igt@i915_module_l...@load.html
- fi-tgl-1115g4:  [PASS][29] -> [INCOMPLETE][30]
   [29]: 

✗ Fi.CI.SPARSE: warning for Bigjoiner refactoring (rev7)

2024-02-20 Thread Patchwork
== Series Details ==

Series: Bigjoiner refactoring (rev7)
URL   : https://patchwork.freedesktop.org/series/128311/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'

✗ Fi.CI.CHECKPATCH: warning for Bigjoiner refactoring (rev7)

2024-02-20 Thread Patchwork
== Series Details ==

Series: Bigjoiner refactoring (rev7)
URL   : https://patchwork.freedesktop.org/series/128311/
State : warning

== Summary ==

Error: dim checkpatch failed
3d859da21658 drm/i915/bigjoiner: Refactor bigjoiner state readout
c0d98dc3a01a Start separating pipe vs transcoder set logic for bigjoiner during 
modeset
-:12: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line 
(possible unwrapped commit description?)
#12: 
That way we can also remove a bunch of checks like 
intel_crtc_is_bigjoiner_slave.

-:184: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a 
separate line
#184: FILE: drivers/gpu/drm/i915/display/intel_display.c:1750:
+* to change the workaround. */

-:310: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#310: FILE: drivers/gpu/drm/i915/display/intel_display.h:283:
+#define for_each_intel_crtc_in_pipe_mask_reverse(dev, intel_crtc, pipe_mask)   
\
+   list_for_each_entry_reverse(intel_crtc, 
\
+   &(dev)->mode_config.crtc_list,  
\
+   base.head)  
\
+   for_each_if((pipe_mask) & BIT(intel_crtc->pipe))

-:310: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_crtc' - possible 
side-effects?
#310: FILE: drivers/gpu/drm/i915/display/intel_display.h:283:
+#define for_each_intel_crtc_in_pipe_mask_reverse(dev, intel_crtc, pipe_mask)   
\
+   list_for_each_entry_reverse(intel_crtc, 
\
+   &(dev)->mode_config.crtc_list,  
\
+   base.head)  
\
+   for_each_if((pipe_mask) & BIT(intel_crtc->pipe))

total: 1 errors, 2 warnings, 1 checks, 274 lines checked
805a2c1900a3 drm/i915: Fix bigjoiner case for DP2.0




✓ Fi.CI.BAT: success for drm/i915: Add Display Port tunnel BW allocation support (rev2)

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Add Display Port tunnel BW allocation support (rev2)
URL   : https://patchwork.freedesktop.org/series/129082/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14305 -> Patchwork_129082v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_softpin@safe-alignment:
- {bat-arls-2}:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@gem_soft...@safe-alignment.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129082v2/bat-arls-2/igt@gem_soft...@safe-alignment.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-bsw-n3050/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129082v2/fi-bsw-n3050/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][5] -> [ABORT][6] ([i915#7911])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129082v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

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

  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293


Build changes
-

  * Linux: CI_DRM_14305 -> Patchwork_129082v2

  CI-20190529: 20190529
  CI_DRM_14305: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7718: 40e8b9122853f455c84afcfa56469a6bc9a0d564 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_129082v2: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

ac3d933462e0 drm/i915/dp: Enable DP tunnel BW allocation mode
8a3130d98ca2 drm/i915/dp: Read DPRX for all long HPD pulses
9e26545ff64e drm/i915/dp: Suspend/resume DP tunnels
4a6ed7708e66 drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders
633260352fcf drm/i915/dp: Handle DP tunnel IRQs
e655a8dad126 drm/i915/dp: Allocate/free DP tunnel BW in the encoder 
enable/disable hooks
861868fa5b1f drm/i915/dp: Compute DP tunnel BW during encoder state computation
e6e8be41fc8e drm/i915/dp: Account for tunnel BW limit in 
intel_dp_max_link_data_rate()
fdc02281f1ae drm/i915/dp: Add DP tunnel atomic state and check BW limit
f65489307c55 drm/i915/dp: Add support for DP tunnel BW allocation
389f06304a2f drm/i915/dp: Add way to get active pipes with syncing commits
2ca5a931db6d drm/i915/dp: Add intel_dp_max_link_data_rate()
348ef611b934 drm/i915/dp: Factor out intel_dp_read_dprx_caps()
0d0ce61a14da drm/i915/dp: Factor out intel_dp_update_sink_caps()
696cdaf32b54 drm/i915/dp: Export intel_dp_max_common_rate/lane_count()
06addb22b256 drm/i915/dp: Factor out intel_dp_config_required_rate()
b6c0fee143a2 drm/i915/dp: Use drm_dp_max_dprx_data_rate()
6f16dda74ee5 drm/i915/dp: Add support to notify MST connectors to retry modesets
6461ebe4ef9e drm/i915: Fix display bpp limit computation during system resume
e34814cf0972 drm/dp: Add support for DP tunneling
4bf7a633951f drm/dp: Add drm_dp_max_dprx_data_rate()

== Logs ==

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


✗ Fi.CI.SPARSE: warning for drm/i915: Add Display Port tunnel BW allocation support (rev2)

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Add Display Port tunnel BW allocation support (rev2)
URL   : https://patchwork.freedesktop.org/series/129082/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add Display Port tunnel BW allocation support (rev2)

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Add Display Port tunnel BW allocation support (rev2)
URL   : https://patchwork.freedesktop.org/series/129082/
State : warning

== Summary ==

Error: dim checkpatch failed
501cc0798f87 drm/dp: Add drm_dp_max_dprx_data_rate()
14d74f578b99 drm/dp: Add support for DP tunneling
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:118: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#118: 
new file mode 100644

-:148: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#148: FILE: drivers/gpu/drm/display/drm_dp_tunnel.c:26:
+#define for_each_new_group_in_state(__state, __new_group_state, __i) \
+   for ((__i) = 0; \
+(__i) < (__state)->num_private_objs; \
+(__i)++) \
+   for_each_if ((__state)->private_objs[__i].ptr && \
+
is_dp_tunnel_private_obj((__state)->private_objs[__i].ptr) && \
+((__new_group_state) = \
+   
to_group_state((__state)->private_objs[__i].new_state), 1))

-:148: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__state' - possible 
side-effects?
#148: FILE: drivers/gpu/drm/display/drm_dp_tunnel.c:26:
+#define for_each_new_group_in_state(__state, __new_group_state, __i) \
+   for ((__i) = 0; \
+(__i) < (__state)->num_private_objs; \
+(__i)++) \
+   for_each_if ((__state)->private_objs[__i].ptr && \
+
is_dp_tunnel_private_obj((__state)->private_objs[__i].ptr) && \
+((__new_group_state) = \
+   
to_group_state((__state)->private_objs[__i].new_state), 1))

-:148: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible 
side-effects?
#148: FILE: drivers/gpu/drm/display/drm_dp_tunnel.c:26:
+#define for_each_new_group_in_state(__state, __new_group_state, __i) \
+   for ((__i) = 0; \
+(__i) < (__state)->num_private_objs; \
+(__i)++) \
+   for_each_if ((__state)->private_objs[__i].ptr && \
+
is_dp_tunnel_private_obj((__state)->private_objs[__i].ptr) && \
+((__new_group_state) = \
+   
to_group_state((__state)->private_objs[__i].new_state), 1))

-:152: WARNING:SPACING: space prohibited between function name and open 
parenthesis '('
#152: FILE: drivers/gpu/drm/display/drm_dp_tunnel.c:30:
+   for_each_if ((__state)->private_objs[__i].ptr && \

-:157: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#157: FILE: drivers/gpu/drm/display/drm_dp_tunnel.c:35:
+#define for_each_old_group_in_state(__state, __old_group_state, __i) \
+   for ((__i) = 0; \
+(__i) < (__state)->num_private_objs; \
+(__i)++) \
+   for_each_if ((__state)->private_objs[__i].ptr && \
+
is_dp_tunnel_private_obj((__state)->private_objs[__i].ptr) && \
+((__old_group_state) = \
+   
to_group_state((__state)->private_objs[__i].old_state), 1))

-:157: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__state' - possible 
side-effects?
#157: FILE: drivers/gpu/drm/display/drm_dp_tunnel.c:35:
+#define for_each_old_group_in_state(__state, __old_group_state, __i) \
+   for ((__i) = 0; \
+(__i) < (__state)->num_private_objs; \
+(__i)++) \
+   for_each_if ((__state)->private_objs[__i].ptr && \
+
is_dp_tunnel_private_obj((__state)->private_objs[__i].ptr) && \
+((__old_group_state) = \
+   
to_group_state((__state)->private_objs[__i].old_state), 1))

-:157: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible 
side-effects?
#157: FILE: drivers/gpu/drm/display/drm_dp_tunnel.c:35:
+#define for_each_old_group_in_state(__state, __old_group_state, __i) \
+   for ((__i) = 0; \
+(__i) < (__state)->num_private_objs; \
+(__i)++) \
+   for_each_if ((__state)->private_objs[__i].ptr && \
+
is_dp_tunnel_private_obj((__state)->private_objs[__i].ptr) && \
+((__old_group_state) = \
+   
to_group_state((__state)->private_objs[__i].old_state), 1))

-:161: WARNING:SPACING: space prohibited between function name and open 
parenthesis '('
#161: FILE: drivers/gpu/drm/display/drm_dp_tunnel.c:39:
+   for_each_if ((__state)->private_objs[__i].ptr && \

-:179: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__bw' - possible 

✓ Fi.CI.BAT: success for drivers/i915/intel_bios: Fix parsing backlight BDB data

2024-02-20 Thread Patchwork
== Series Details ==

Series: drivers/i915/intel_bios: Fix parsing backlight BDB data
URL   : https://patchwork.freedesktop.org/series/130152/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14305 -> Patchwork_130152v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 38)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

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

  

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-7567u:   [PASS][3] -> [CRASH][4] ([i915#9947])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/fi-kbl-7567u/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130152v1/fi-kbl-7567u/igt@i915_pm_...@module-reload.html

  
 Possible fixes 

  * igt@vgem_basic@create:
- {bat-arls-2}:   [FAIL][5] -> [PASS][6] +4 other tests pass
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@vgem_ba...@create.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130152v1/bat-arls-2/igt@vgem_ba...@create.html

  * igt@vgem_basic@dmabuf-mmap:
- {bat-arls-2}:   [INCOMPLETE][7] -> [PASS][8] +6 other tests pass
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@vgem_ba...@dmabuf-mmap.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130152v1/bat-arls-2/igt@vgem_ba...@dmabuf-mmap.html

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

  [i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
  [i915#10196]: https://gitlab.freedesktop.org/drm/intel/issues/10196
  [i915#10212]: https://gitlab.freedesktop.org/drm/intel/issues/10212
  [i915#10213]: https://gitlab.freedesktop.org/drm/intel/issues/10213
  [i915#10214]: https://gitlab.freedesktop.org/drm/intel/issues/10214
  [i915#10215]: https://gitlab.freedesktop.org/drm/intel/issues/10215
  [i915#10216]: https://gitlab.freedesktop.org/drm/intel/issues/10216
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
  [i915#9947]: https://gitlab.freedesktop.org/drm/intel/issues/9947


Build changes
-

  * Linux: CI_DRM_14305 -> Patchwork_130152v1

  CI-20190529: 20190529
  CI_DRM_14305: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7718: 40e8b9122853f455c84afcfa56469a6bc9a0d564 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_130152v1: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

1a284db2ac66 drivers/i915/intel_bios: Fix parsing backlight BDB data

== Logs ==

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


✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] drm/dp: move intel_dp_vsc_sdp_pack() to 
generic helper
URL   : https://patchwork.freedesktop.org/series/130145/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14305 -> Patchwork_130145v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 37)
--

  Missing(3): bat-mtlp-8 fi-snb-2520m fi-elk-e7500 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@guc_hang:
- {bat-arls-2}:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130145v1/bat-arls-2/igt@i915_selftest@live@guc_hang.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

  

### IGT changes ###

 Possible fixes 

  * igt@vgem_basic@create:
- {bat-arls-2}:   [FAIL][4] -> [PASS][5] +4 other tests pass
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@vgem_ba...@create.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130145v1/bat-arls-2/igt@vgem_ba...@create.html

  * igt@vgem_basic@dmabuf-mmap:
- {bat-arls-2}:   [INCOMPLETE][6] -> [PASS][7] +6 other tests pass
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14305/bat-arls-2/igt@vgem_ba...@dmabuf-mmap.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130145v1/bat-arls-2/igt@vgem_ba...@dmabuf-mmap.html

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

  [i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
  [i915#10196]: https://gitlab.freedesktop.org/drm/intel/issues/10196
  [i915#10212]: https://gitlab.freedesktop.org/drm/intel/issues/10212
  [i915#10213]: https://gitlab.freedesktop.org/drm/intel/issues/10213
  [i915#10214]: https://gitlab.freedesktop.org/drm/intel/issues/10214
  [i915#10215]: https://gitlab.freedesktop.org/drm/intel/issues/10215
  [i915#10216]: https://gitlab.freedesktop.org/drm/intel/issues/10216
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293


Build changes
-

  * Linux: CI_DRM_14305 -> Patchwork_130145v1

  CI-20190529: 20190529
  CI_DRM_14305: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7718: 40e8b9122853f455c84afcfa56469a6bc9a0d564 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_130145v1: 4b8a238dee9c18201f3652695414587cd2ef6d8f @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

3d7e9163d672 drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()
3add9b372a8d drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

== Logs ==

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


✗ Fi.CI.SPARSE: warning for series starting with [v3,1/2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] drm/dp: move intel_dp_vsc_sdp_pack() to 
generic helper
URL   : https://patchwork.freedesktop.org/series/130145/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload

2024-02-20 Thread Andi Shyti
Hi Tvrtko,

On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
> On 20/02/2024 14:35, Andi Shyti wrote:
> > Enable only one CCS engine by default with all the compute sices
> 
> slices

Thanks!

> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 833987015b8b..7041acc77810 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct 
> > drm_i915_private *i915)
> > if (engine->uabi_class == I915_NO_UABI_CLASS)
> > continue;
> > +   /*
> > +* Do not list and do not count CCS engines other than the first
> > +*/
> > +   if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> > +   engine->uabi_instance > 0) {
> > +   i915->engine_uabi_class_count[engine->uabi_class]--;
> > +   continue;
> > +   }
> 
> It's a bit ugly to decrement after increment, instead of somehow
> restructuring the loop to satisfy both cases more elegantly.

yes, agree, indeed I had a hard time here to accept this change
myself.

But moving the check above where the counter was incremented it
would have been much uglier.

This check looks ugly everywhere you place it :-)

In any case, I'm working on a patch that is splitting this
function in two parts and there is some refactoring happening
here (for the first initialization and the dynamic update).

Please let me know if it's OK with you or you want me to fix it
in this run.

> And I wonder if
> internally (in dmesg when engine name is logged) we don't end up with ccs0
> ccs0 ccs0 ccs0.. for all instances.

I don't see this. Even in sysfs we see only one ccs. Where is it?

> > +
> > rb_link_node(>uabi_node, prev, p);
> > rb_insert_color(>uabi_node, >uabi_engines);

[...]

> > diff --git a/drivers/gpu/drm/i915/i915_query.c 
> > b/drivers/gpu/drm/i915/i915_query.c
> > index 3baa2f54a86e..d5a5143971f5 100644
> > --- a/drivers/gpu/drm/i915/i915_query.c
> > +++ b/drivers/gpu/drm/i915/i915_query.c
> > @@ -124,6 +124,7 @@ static int query_geometry_subslices(struct 
> > drm_i915_private *i915,
> > return fill_topology_info(sseu, query_item, 
> > sseu->geometry_subslice_mask);
> >   }
> > +
> 
> Zap please.

yes... yes... I noticed it after sending the patch :-)

Thanks,
Andi


[PATCH] drm/i915/guc: Add Compute context hint

2024-02-20 Thread Vinay Belgaumkar
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will also be
lower so GuC will ramp down the GT freq for this context more slowly.
We also disable waitboost for this context as that will interfere with
the strategy.

We need to enable the use of Compute strategy during SLPC init, but
it will apply only to contexts that set this bit during context
creation.

Userland can check whether this feature is supported using a new param-
I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true for all guc submission
enabled platforms since they use SLPC for freq management.

The Mesa usage model for this flag is here -
https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint

Cc: Rodrigo Vivi 
Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  8 +++
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  1 +
 drivers/gpu/drm/i915/gt/intel_rps.c   |  8 +++
 .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   | 17 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h   |  1 +
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  7 +++
 drivers/gpu/drm/i915/i915_getparam.c  | 11 ++
 include/uapi/drm/i915_drm.h   | 15 +
 9 files changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..ceab7dbe9b47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private 
*fpriv,
   struct i915_gem_proto_context *pc,
   struct drm_i915_gem_context_param *args)
 {
+   struct drm_i915_private *i915 = fpriv->i915;
int ret = 0;
 
switch (args->param) {
@@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct 
drm_i915_file_private *fpriv,
pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
break;
 
+   case I915_CONTEXT_PARAM_IS_COMPUTE:
+   if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
+   ret = -EINVAL;
+   else
+   pc->user_flags |= BIT(UCONTEXT_COMPUTE);
+   break;
+
case I915_CONTEXT_PARAM_RECOVERABLE:
if (args->size)
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 03bc7f9d191b..db86d6f6245f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -338,6 +338,7 @@ struct i915_gem_context {
 #define UCONTEXT_BANNABLE  2
 #define UCONTEXT_RECOVERABLE   3
 #define UCONTEXT_PERSISTENCE   4
+#define UCONTEXT_COMPUTE   5
 
/**
 * @flags: small set of booleans
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 4feef874e6d6..1ed40cd61b70 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -24,6 +24,7 @@
 #include "intel_pcode.h"
 #include "intel_rps.h"
 #include "vlv_sideband.h"
+#include "../gem/i915_gem_context.h"
 #include "../../../platform/x86/intel_ips.h"
 
 #define BUSY_MAX_EI20u /* ms */
@@ -1018,6 +1019,13 @@ void intel_rps_boost(struct i915_request *rq)
struct intel_rps *rps = _ONCE(rq->engine)->gt->rps;
 
if (rps_uses_slpc(rps)) {
+   const struct i915_gem_context *ctx;
+
+   ctx = i915_request_gem_context(rq);
+   if (ctx &&
+   test_bit(UCONTEXT_COMPUTE, >user_flags))
+   return;
+
slpc = rps_to_slpc(rps);
 
if (slpc->min_freq_softlimit >= slpc->boost_freq)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
index 811add10c30d..c34674e797c6 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h
@@ -207,6 +207,27 @@ struct slpc_shared_data {
u8 reserved_mode_definition[4096];
 } __packed;
 
+struct slpc_context_frequency_request {
+   u32 frequency_request:16;
+   u32 reserved:12;
+   u32 is_compute:1;
+   u32 ignore_busyness:1;
+   u32 is_minimum:1;
+   u32 is_predefined:1;
+} __packed;
+
+#define SLPC_CTX_FREQ_REQ_IS_COMPUTE   REG_BIT(28)
+
+struct slpc_optimized_strategies {
+   u32 compute:1;
+   u32 async_flip:1;
+   u32 media:1;
+   

Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload

2024-02-20 Thread Andi Shyti
Hi Matt,

thanks a lot for looking into this.

On Tue, Feb 20, 2024 at 03:39:18PM -0800, Matt Roper wrote:
> On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:

[...]

> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 833987015b8b..7041acc77810 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct 
> > drm_i915_private *i915)
> > if (engine->uabi_class == I915_NO_UABI_CLASS)
> > continue;
> >  
> > +   /*
> > +* Do not list and do not count CCS engines other than the first
> > +*/
> > +   if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> > +   engine->uabi_instance > 0) {
> > +   i915->engine_uabi_class_count[engine->uabi_class]--;
> > +   continue;
> > +   }
> 
> Wouldn't it be simpler to just add a workaround to the end of
> engine_mask_apply_compute_fuses() if we want to ensure only a single
> compute engine gets exposed?  Then both the driver internals and uapi
> will agree that's there's just one CCS (and on which one there is).
> 
> If we want to do something fancy with "hotplugging" a new engine later
> on or whatever, that can be handled in the future series (although as
> noted on the previous patch, it sounds like these changes might not
> actually be aligned with the workaround we were trying to address).

The hotplugging capability is one of the features I was looking
for, actually.

I have done some more refactoring in this piece of code in
upcoming patches.

Will check, though, if I can do something with compute_fuses(),
even though, the other cslices are not really fused off (read
below).

> > +
> > rb_link_node(>uabi_node, prev, p);
> > rb_insert_color(>uabi_node, >uabi_engines);
> >  
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index a425db5ed3a2..e19df4ef47f6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
> > }
> >  }
> >  
> > +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> > +{
> > +   if (!IS_DG2(gt->i915))
> > +   return;
> > +
> > +   intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
> 
> This doesn't look right to me.  A value of 0 means every cslice gets
> associated with CCS0.

Yes, that's what I'm trying to do. The behavior I'm looking for
is this one:

 /*
  ...
  * With 1 engine (ccs0):
  *   slice 0, 1, 2, 3: ccs0
  *
  * With 2 engines (ccs0, ccs1):
  *   slice 0, 2: ccs0
  *   slice 1, 3: ccs1
  *
  * With 4 engines (ccs0, ccs1, ccs2, ccs3):
  *   slice 0: ccs0
  *   slice 1: ccs1
  *   slice 2: ccs2
  *   slice 3: ccs3
  ...
  */

where the user can configure runtime the mode, making sure that
no client is connected to i915.

But, this needs to be written 

As we are now forcing mode '1', then all cslices are connected
with ccs0.

> On a DG2-G11 platform, that will flat out break
> compute since CCS0 is never present (G11 only has a single CCS and it's
> always the hardware's CCS1).  Even on a G10 or G12 this could also break
> things depending on the fusing of your card if the hardware CCS0 happens
> to be missing.
> 
> Also, the register says that we need a field value of 0x7 for each
> cslice that's fused off.  By passing 0, we're telling the CCS engine
> that it can use cslices that may not actually exist.

does it? Or do I need to write the id (0x0-0x3) of the user
engine? That's how the mode is calculated in this algorithm.

> > +}
> > +

[...]

> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index cf709f6c05ae..c148113770ea 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -1605,6 +1605,8 @@
> >  #define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
> >  #define   GEN12_CAGF_MASK  REG_GENMASK(19, 11)
> >  
> > +#define XEHP_CCS_MODE  _MMIO(0x14804)
> 
> Nitpick:  this doesn't seem to be in the proper place and also breaks
> the file's convention of using tabs to move over to column 48 for the
> definition value.

This was something I actually forgot to fix. Thanks!


Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload

2024-02-20 Thread Matt Roper
On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
> Enable only one CCS engine by default with all the compute sices
> allocated to it.
> 
> While generating the list of UABI engines to be exposed to the
> user, exclude any additional CCS engines beyond the first
> instance.
> 
> This change can be tested with igt i915_query.
> 
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Matt Roper 
> Cc:  # v6.2+
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_user.c |  9 +
>  drivers/gpu/drm/i915/gt/intel_gt.c  | 11 +++
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h |  2 ++
>  drivers/gpu/drm/i915/i915_query.c   |  1 +
>  4 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 833987015b8b..7041acc77810 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct 
> drm_i915_private *i915)
>   if (engine->uabi_class == I915_NO_UABI_CLASS)
>   continue;
>  
> + /*
> +  * Do not list and do not count CCS engines other than the first
> +  */
> + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> + engine->uabi_instance > 0) {
> + i915->engine_uabi_class_count[engine->uabi_class]--;
> + continue;
> + }

Wouldn't it be simpler to just add a workaround to the end of
engine_mask_apply_compute_fuses() if we want to ensure only a single
compute engine gets exposed?  Then both the driver internals and uapi
will agree that's there's just one CCS (and on which one there is).

If we want to do something fancy with "hotplugging" a new engine later
on or whatever, that can be handled in the future series (although as
noted on the previous patch, it sounds like these changes might not
actually be aligned with the workaround we were trying to address).

> +
>   rb_link_node(>uabi_node, prev, p);
>   rb_insert_color(>uabi_node, >uabi_engines);
>  
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index a425db5ed3a2..e19df4ef47f6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
>   }
>  }
>  
> +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> +{
> + if (!IS_DG2(gt->i915))
> + return;
> +
> + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);

This doesn't look right to me.  A value of 0 means every cslice gets
associated with CCS0.  On a DG2-G11 platform, that will flat out break
compute since CCS0 is never present (G11 only has a single CCS and it's
always the hardware's CCS1).  Even on a G10 or G12 this could also break
things depending on the fusing of your card if the hardware CCS0 happens
to be missing.

Also, the register says that we need a field value of 0x7 for each
cslice that's fused off.  By passing 0, we're telling the CCS engine
that it can use cslices that may not actually exist.

> +}
> +
>  int intel_gt_init_hw(struct intel_gt *gt)
>  {
>   struct drm_i915_private *i915 = gt->i915;
> @@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
>  
>   intel_gt_init_swizzling(gt);
>  
> + /* Configure CCS mode */
> + intel_gt_apply_ccs_mode(gt);
> +
>   /*
>* At least 830 can leave some of the unused rings
>* "active" (ie. head != tail) after resume which
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index cf709f6c05ae..c148113770ea 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1605,6 +1605,8 @@
>  #define   GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
>  #define   GEN12_CAGF_MASKREG_GENMASK(19, 11)
>  
> +#define XEHP_CCS_MODE  _MMIO(0x14804)

Nitpick:  this doesn't seem to be in the proper place and also breaks
the file's convention of using tabs to move over to column 48 for the
definition value.


Matt

> +
>  #define GEN11_GT_INTR_DW(x)  _MMIO(0x190018 + ((x) * 4))
>  #define   GEN11_CSME (31)
>  #define   GEN12_HECI_2   (30)
> diff --git a/drivers/gpu/drm/i915/i915_query.c 
> b/drivers/gpu/drm/i915/i915_query.c
> index 3baa2f54a86e..d5a5143971f5 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -124,6 +124,7 @@ static int query_geometry_subslices(struct 
> drm_i915_private *i915,
>   return fill_topology_info(sseu, query_item, 
> sseu->geometry_subslice_mask);
>  }
>  
> +
>  static 

Re: [PATCH v2 1/2] drm/i915/gt: Disable HW load balancing for CCS

2024-02-20 Thread Matt Roper
On Tue, Feb 20, 2024 at 03:35:25PM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_14019159160 recommends disabling it across all
> platforms.
> 
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Matt Roper 
> Cc:  # v6.2+
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 50962cfd1353..cf709f6c05ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1478,6 +1478,7 @@
>  
>  #define GEN12_RCU_MODE   _MMIO(0x14800)
>  #define   GEN12_RCU_MODE_CCS_ENABLE  REG_BIT(0)
> +#define   XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
>  
>  #define CHV_FUSE_GT  _MMIO(VLV_GUNIT_BASE + 0x2168)
>  #define   CHV_FGT_DISABLE_SS0(1 << 10)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..9126b37186fc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2988,6 +2988,12 @@ general_render_compute_wa_init(struct intel_engine_cs 
> *engine, struct i915_wa_li
>   wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN1,
>GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
>   }
> +
> + /*
> +  * Wa_14019159160: disable the CCS load balancing
> +  * indiscriminately for all the platforms

The database's description of this workaround is a bit confusing since
it's been modified a few times, but if I'm reading it correctly it
doesn't sound like this is what it's asking us to do.  What I see says
that load balancing shouldn't be allowed specifically while the RCS is
active.  If the RCS is sitting idle, I believe you're free to use as
many CCS engines as you like, with load balancing still active.

We already have other workarounds that prevent different address spaces
from executing on the RCS/CCS engines at the same time, so the part
about "same address space" in the description should already be
satisfied.  It sounds like the issues now are if 2+ CCS's are in use and
something new shows up to run on the previously-idle RCS, or if
something's already running on the RCS and 1 CCS, and something new
shows up to run on an additional CCS.  The workaround details make it
sound like it's supposed to be the GuC's responsibility to prevent the
new work from getting scheduled onto the additional engine while we're
already in one of those two situations, so I don't see anything asking
us to change the hardware-level load balance enable/disable (actually
the spec specifically tells us *not* to do this).  Aren't we supposed to
be just setting a GuC workaround flag for this?


Matt

> +  */
> + wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
>  }
>  
>  static void
> -- 
> 2.43.0
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


Re: GuC issue

2024-02-20 Thread John Harrison

Hello,

Something is very corrupted with that GuC log. The log consists of a 
header page and then a stream of log entry structures. The structure is 
supposed to be 20 bytes long and starts with a four byte time stamp. But 
I am seeing what is conceivably a 32bit timestamp appearing at 21 byte 
increments through the log. Even more curiously, the time stamp seems to 
have an 0x0D, 0x0A after it. Are you doing any printf type operation in 
order to write the log out from memory to disk?


INTEL_GUC_LOAD_STATUS_INIT_DATA_INVALID means that the GuC did not like 
the initialisation data passed in. Most likely, something in the ADS 
structure is not valid. If you try with the latest GuC version, that 
might give you more information as to what is the incorrect. More status 
codes have been added since 70.1.1.


John.


On 2/20/2024 05:03, mak...@wezdecki.pl wrote:

Hi,

Please see GuC log attached to this email.

Log size is "PAGE_SIZE+Debug Log(64KB) + Crash Log (8KB) + Capture Log (1M)"

Can anybody from Intel decode this log buffer? Thanks.

What am I doing wrong?

Maksym


poniedziałek, 19 lutego 2024 09:44, mak...@wezdecki.pl  
napisał(a):



Hi,

I fixed one issue in my driver. Log address was set incorrectly.

Right now, after GuC uploading, GUC_STATUS changed.
Right now, intel_guc_load_status is INTEL_GUC_LOAD_STATUS_INIT_DATA_INVALID = 
0x71.

What does it mean?
Could you please help me with this?

Thanks,
Maksym



piątek, 9 lutego 2024 08:42, natur.prod...@pm.me natur.prod...@pm.me napisał(a):


Hello,

Please see my comments below.

piątek, 9 lutego 2024 2:45 AM, John Harrison john.c.harri...@intel.com 
napisał(a):


Hello,

What platform is this on? And which GuC firmware version are you using?

It's TGL. I'm using tgl_guc_70.1.1.bin firmware blob.


One thing you made need to do is force maximum GT frequency during GuC
load. That is something the i915 driver does. If the system decides the
GPU is idle and drops the frequency to minimum then it can take multiple
seconds for the GuC initialisation to complete.

Thanks for the hint. I'm not doing that at all in my code. How am I supposed to 
do this? Is there a specific register for that?


Did the status change at all during that second of waiting? Or was it
still reading LAPIC_DONE?

It's always LAPIC_DONE.


For ADS documentation, I'm afraid that the best we currently have
publicly available is the i915 driver code. If you are not intending to
use GuC submission then most of the ADS can be ignored.

Ok, that great. Which part of ADS is must-have then?


If you can share the GuC log, that might provide some clues as to what
is happening. For just logging the boot process, you shouldn't need to
allocate a large log. The default size of i915 for release builds is
64KB. That should be plenty.

I'll collect GuC log as soon as possible. Is it something that can be 
understood without a knowledge of GuC internals? Or is it simply hex dumps?


John.

On 2/6/2024 23:59, natur.prod...@pm.me wrote:


Hi,

I'm currently implementing GuC/HuC firmware support in one Safety Critical OS.
I'm following i915 code and I implemented all paths (I don't want GuC 
submission or SLPC features). I need GuC to authenticate HuC firmware blob.

I mirrored GuC implementation in my code.

After GuC DMA transfer succeeds, I'm reading GUC_STATUS register.
HW returns INTEL_BOOTROM_STATUS_JUMP_PASSED as bootrom status and 
INTEL_GUC_LOAD_STATUS_LAPIC_DONE as GuC load status.

Unfortunately, after one second of waiting, the status didn't get changed to 
INTEL_GUC_LOAD_STATUS_READY at all.

What is a potential issue here?
Could you please help me?

In addition to this, could you please point out some documentation about GuC's 
ADS struct?

Thanks,
Maksym




Re: [RFC] drm/i915: Support replaying GPU hangs with captured context image

2024-02-20 Thread Rodrigo Vivi
On Tue, Feb 13, 2024 at 01:14:34PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> When debugging GPU hangs Mesa developers are finding it useful to replay
> the captured error state against the simulator. But due various simulator
> limitations which prevent replicating all hangs, one step further is being
> able to replay against a real GPU.
> 
> This is almost doable today with the missing part being able to upload the
> captured context image into the driver state prior to executing the
> uploaded hanging batch and all the buffers.
> 
> To enable this last part we add a new context parameter called
> I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU
> configuration pattern of being able to select which context to apply
> against, paired with the actual image and its size.
> 
> Since this is adding a new concept of debug only uapi, we hide it behind
> a new kconfig option and also require activation with a module parameter.
> Together with a warning banner printed at driver load, all those combined
> should be sufficient to guard against inadvertently enabling the feature.
> 
> In terms of implementation the only trivial change is shadowing of the
> default state from engine to context. We also allow the legacy context
> set param to be used since that removes the need to record the per context
> data in the proto context, while still allowing flexibility of specifying
> context images for any context.
> 
> Mesa MR using the uapi can be seen at:
>   https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594

I just wonder if it would be better to split the default_state in a separate
patch but from what I could see it looks correct.

Also, I have to say that this approach is nice, clean and well protected.
And much simpler then I imagined when I saw the idea around.

Feel free to use:
Reviewed-by: Rodrigo Vivi 

> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Lionel Landwerlin 
> Cc: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/Kconfig.debug|  17 +++
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 106 ++
>  drivers/gpu/drm/i915/gt/intel_context.c   |   2 +
>  drivers/gpu/drm/i915/gt/intel_context.h   |  22 
>  drivers/gpu/drm/i915/gt/intel_context_types.h |   3 +
>  drivers/gpu/drm/i915/gt/intel_lrc.c   |   8 +-
>  .../gpu/drm/i915/gt/intel_ring_submission.c   |   8 +-
>  drivers/gpu/drm/i915/i915_params.c|   5 +
>  drivers/gpu/drm/i915/i915_params.h|   3 +-
>  include/uapi/drm/i915_drm.h   |  27 +
>  10 files changed, 194 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 5b7162076850..32e9f70e91ed 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -16,6 +16,23 @@ config DRM_I915_WERROR
>  
> If in doubt, say "N".
>  
> +config DRM_I915_REPLAY_GPU_HANGS_API
> + bool "Enable GPU hang replay userspace API"
> + depends on DRM_I915
> + depends on EXPERT
> + default n
> + help
> +   Choose this option if you want to enable special and unstable
> +   userspace API used for replaying GPU hangs on a running system.
> +
> +   This API is intended to be used by userspace graphics stack developers
> +   and provides no stability guarantees.
> +
> +   The API needs to be activated at boot time using the
> +   enable_debug_only_api module parameter.
> +
> +   If in doubt, say "N".
> +
>  config DRM_I915_DEBUG
>   bool "Enable additional driver debugging"
>   depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index dcbfe32fd30c..1cfd624bd978 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -78,6 +78,7 @@
>  #include "gt/intel_engine_user.h"
>  #include "gt/intel_gpu_commands.h"
>  #include "gt/intel_ring.h"
> +#include "gt/shmem_utils.h"
>  
>  #include "pxp/intel_pxp.h"
>  
> @@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct 
> drm_i915_file_private *fpriv,
>   case I915_CONTEXT_PARAM_NO_ZEROMAP:
>   case I915_CONTEXT_PARAM_BAN_PERIOD:
>   case I915_CONTEXT_PARAM_RINGSIZE:
> + case I915_CONTEXT_PARAM_CONTEXT_IMAGE:
>   default:
>   ret = -EINVAL;
>   break;
> @@ -2092,6 +2094,88 @@ static int get_protected(struct i915_gem_context *ctx,
>   return 0;
>  }
>  
> +static int set_context_image(struct i915_gem_context *ctx,
> +  struct drm_i915_gem_context_param *args)
> +{
> + struct i915_gem_context_param_context_image user;
> + struct intel_context *ce;
> + struct file *shmem_state;
> + unsigned long lookup;
> + void *state;
> + int ret = 0;
> +
> + if (!IS_ENABLED(CONFIG_DRM_I915_REPLAY_GPU_HANGS_API))
> + return -EINVAL;
> +
> + if 

[PATCH] drm/i915: Fix doc build issue on intel_cdclk.c

2024-02-20 Thread Rodrigo Vivi
Fixing some doc build issues:

Documentation/gpu/i915:222: drivers/gpu/drm/i915/display/intel_cdclk.c:69: 
ERROR: Unexpected indentation.
Documentation/gpu/i915:222: ./drivers/gpu/drm/i915/display/intel_cdclk.c:70: 
WARNING: Block quote ends without a blank line; unexpected unindent.

Closes: https://lore.kernel.org/all/20240219161747.0e867...@canb.auug.org.au/
Fixes: 79e2ea2eaaa6 ("drm/i915/cdclk: Document CDCLK update methods")
Cc: Ville Syrjälä 
Cc: Gustavo Sousa 
Reported-by: Stephen Rothwell 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 30dae4fef6cb..42cbc3203d2c 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -65,13 +65,19 @@
  *
  * Several methods exist to change the CDCLK frequency, which ones are
  * supported depends on the platform:
+ *
  * - Full PLL disable + re-enable with new VCO frequency. Pipes must be 
inactive.
+ *
  * - CD2X divider update. Single pipe can be active as the divider update
  *   can be synchronized with the pipe's start of vblank.
+ *
  * - Crawl the PLL smoothly to the new VCO frequency. Pipes can be active.
+ *
  * - Squash waveform update. Pipes can be active.
+ *
  * - Crawl and squash can also be done back to back. Pipes can be active.
  *
+ *
  * RAWCLK is a fixed frequency clock, often used by various auxiliary
  * blocks such as AUX CH or backlight PWM. Hence the only thing we
  * really need to know about RAWCLK is its frequency so that various
-- 
2.43.2



[PATCH v2 0/4] VBT read cleanup

2024-02-20 Thread Radhakrishna Sripada
This series is originally based out of [1], and built on top of [2].

The primary departure from [1] was that vbt is no longer cached. During vbt
show, based on the source of vbt, it would simply be re-read reducing the
read/cleanup complexity. With this series debugfs dump of vbt should work on
all the platforms that support display.

1. https://patchwork.freedesktop.org/series/128341/
2. https://patchwork.freedesktop.org/series/128683/

Radhakrishna Sripada (4):
  drm/i915: Pass size to oprom_get_vbt
  drm/i915: Pass size to spi_oprom_get_vbt
  drm/i915: Move vbt read from firmware to intel_bios.c
  drm/i915: Show bios vbt when read from firmware/spi/oprom

 drivers/gpu/drm/i915/display/intel_bios.c | 104 +++---
 drivers/gpu/drm/i915/display/intel_opregion.c |  46 
 2 files changed, 86 insertions(+), 64 deletions(-)

-- 
2.34.1



[PATCH v2 1/4] drm/i915: Pass size to oprom_get_vbt

2024-02-20 Thread Radhakrishna Sripada
oprom_get_vbt will later be used to show the contents of vbt for which
the size of vbt is needed.

Cc: Jani Nikula 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index fe52c06271ef..ceb6e4145c62 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -3008,38 +3008,39 @@ static struct vbt_header *spi_oprom_get_vbt(struct 
drm_i915_private *i915)
return NULL;
 }
 
-static struct vbt_header *oprom_get_vbt(struct drm_i915_private *i915)
+static struct vbt_header *oprom_get_vbt(struct drm_i915_private *i915,
+   size_t *size)
 {
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
void __iomem *p = NULL, *oprom;
struct vbt_header *vbt;
u16 vbt_size;
-   size_t i, size;
+   size_t i;
 
-   oprom = pci_map_rom(pdev, );
+   oprom = pci_map_rom(pdev, size);
if (!oprom)
return NULL;
 
/* Scour memory looking for the VBT signature. */
-   for (i = 0; i + 4 < size; i += 4) {
+   for (i = 0; i + 4 < *size; i += 4) {
if (ioread32(oprom + i) != *((const u32 *)"$VBT"))
continue;
 
p = oprom + i;
-   size -= i;
+   *size -= i;
break;
}
 
if (!p)
goto err_unmap_oprom;
 
-   if (sizeof(struct vbt_header) > size) {
+   if (sizeof(struct vbt_header) > *size) {
drm_dbg(>drm, "VBT header incomplete\n");
goto err_unmap_oprom;
}
 
vbt_size = ioread16(p + offsetof(struct vbt_header, vbt_size));
-   if (vbt_size > size) {
+   if (vbt_size > *size) {
drm_dbg(>drm,
"VBT incomplete (vbt_size overflows)\n");
goto err_unmap_oprom;
@@ -3082,6 +3083,7 @@ void intel_bios_init(struct drm_i915_private *i915)
const struct vbt_header *vbt;
struct vbt_header *oprom_vbt = NULL;
const struct bdb_header *bdb;
+   size_t size;
 
INIT_LIST_HEAD(>display.vbt.display_devices);
INIT_LIST_HEAD(>display.vbt.bdb_blocks);
@@ -3106,7 +3108,7 @@ void intel_bios_init(struct drm_i915_private *i915)
}
 
if (!vbt) {
-   oprom_vbt = oprom_get_vbt(i915);
+   oprom_vbt = oprom_get_vbt(i915, );
vbt = oprom_vbt;
}
 
-- 
2.34.1



[PATCH v2 4/4] drm/i915: Show bios vbt when read from firmware/spi/oprom

2024-02-20 Thread Radhakrishna Sripada
Make debugfs vbt only shows valid vbt when read from ACPI opregion.
Make it work when read from firmware/spi/pci oprom cases.

Cc: Jani Nikula 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 30 +--
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4cd338ed362d..b9b4ebc0ecd6 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -3723,14 +3723,30 @@ static int intel_bios_vbt_show(struct seq_file *m, void 
*unused)
struct drm_i915_private *i915 = m->private;
const void *vbt;
size_t vbt_size;
+   bool need_cleanup = false;
 
-   /*
-* FIXME: VBT might originate from other places than opregion, and then
-* this would be incorrect.
-*/
-   vbt = intel_opregion_get_vbt(i915, _size);
-   if (vbt)
-   seq_write(m, vbt, vbt_size);
+   vbt = firmware_get_vbt(i915, _size);
+
+   if (!vbt)
+   vbt = intel_opregion_get_vbt(i915, _size);
+
+   if (!vbt && IS_DGFX(i915)) {
+   vbt = spi_oprom_get_vbt(i915, _size);
+   need_cleanup = true;
+   }
+
+   if (!vbt) {
+   vbt = oprom_get_vbt(i915, _size);
+   need_cleanup = true;
+   }
+
+   if (!vbt)
+   return 0;
+
+   seq_write(m, vbt, vbt_size);
+
+   if (need_cleanup)
+   kfree(vbt);
 
return 0;
 }
-- 
2.34.1



[PATCH v2 2/4] drm/i915: Pass size to spi_oprom_get_vbt

2024-02-20 Thread Radhakrishna Sripada
spi_oprom_get_vbt will later be used to show the contents of vbt for
which the size of vbt is needed.

Cc: Jani Nikula 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index ceb6e4145c62..2624a4528b21 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2957,7 +2957,8 @@ static u32 intel_spi_read(struct intel_uncore *uncore, 
u32 offset)
return intel_uncore_read(uncore, PRIMARY_SPI_TRIGGER);
 }
 
-static struct vbt_header *spi_oprom_get_vbt(struct drm_i915_private *i915)
+static struct vbt_header *spi_oprom_get_vbt(struct drm_i915_private *i915,
+   size_t *size)
 {
u32 count, data, found, store = 0;
u32 static_region, oprom_offset;
@@ -3000,6 +3001,9 @@ static struct vbt_header *spi_oprom_get_vbt(struct 
drm_i915_private *i915)
 
drm_dbg_kms(>drm, "Found valid VBT in SPI flash\n");
 
+   if (size)
+   *size = vbt_size;
+
return (struct vbt_header *)vbt;
 
 err_free_vbt:
@@ -3103,7 +3107,7 @@ void intel_bios_init(struct drm_i915_private *i915)
 * PCI mapping
 */
if (!vbt && IS_DGFX(i915)) {
-   oprom_vbt = spi_oprom_get_vbt(i915);
+   oprom_vbt = spi_oprom_get_vbt(i915, NULL);
vbt = oprom_vbt;
}
 
-- 
2.34.1



[PATCH v2 3/4] drm/i915: Move vbt read from firmware to intel_bios.c

2024-02-20 Thread Radhakrishna Sripada
VBT read from firmware is currently nested within opregion vbt read.
Extract it and place it together with other vbt read mechanisms and
dis-associate vbt-firmware from opregion structure.

Cc: Jani Nikula 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 48 ++-
 drivers/gpu/drm/i915/display/intel_opregion.c | 46 --
 2 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 2624a4528b21..4cd338ed362d 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -25,6 +25,8 @@
  *
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -2950,6 +2952,47 @@ bool intel_bios_is_valid_vbt(struct drm_i915_private 
*i915,
return vbt;
 }
 
+static struct vbt_header *firmware_get_vbt(struct drm_i915_private *i915,
+  size_t *size)
+{
+   struct vbt_header *vbt = NULL;
+   const struct firmware *fw = NULL;
+   const char *name = i915->display.params.vbt_firmware;
+   int ret;
+
+   if (!name || !*name)
+   return vbt;
+
+   ret = request_firmware(, name, i915->drm.dev);
+   if (ret) {
+   drm_err(>drm,
+   "Requesting VBT firmware \"%s\" failed (%d)\n",
+   name, ret);
+   return vbt;
+   }
+
+   if (intel_bios_is_valid_vbt(i915, fw->data, fw->size)) {
+   vbt = kmemdup(fw->data, fw->size, GFP_KERNEL);
+   if (vbt) {
+   drm_dbg_kms(>drm,
+   "Found valid VBT firmware \"%s\"\n", name);
+   *size = fw->size;
+   } else {
+   drm_err(>drm,
+   "Requesting VBT firmware \"%s\" failed (%d)\n",
+   name, ENOMEM);
+   vbt = NULL;
+   }
+   } else {
+   drm_dbg_kms(>drm, "Invalid VBT firmware \"%s\"\n",
+   name);
+   }
+
+   release_firmware(fw);
+
+   return vbt;
+}
+
 static u32 intel_spi_read(struct intel_uncore *uncore, u32 offset)
 {
intel_uncore_write(uncore, PRIMARY_SPI_ADDRESS, offset);
@@ -3100,7 +3143,10 @@ void intel_bios_init(struct drm_i915_private *i915)
 
init_vbt_defaults(i915);
 
-   vbt = intel_opregion_get_vbt(i915, NULL);
+   vbt = firmware_get_vbt(i915, );
+
+   if (!vbt)
+   vbt = intel_opregion_get_vbt(i915, NULL);
 
/*
 * If the OpRegion does not have VBT, look in SPI flash through MMIO or
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
b/drivers/gpu/drm/i915/display/intel_opregion.c
index fcbb083318a7..5d07a002edaa 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -27,7 +27,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -263,7 +262,6 @@ struct intel_opregion {
struct opregion_asle *asle;
struct opregion_asle_ext *asle_ext;
void *rvda;
-   void *vbt_firmware;
const void *vbt;
u32 vbt_size;
struct work_struct asle_work;
@@ -869,46 +867,6 @@ static const struct dmi_system_id intel_no_opregion_vbt[] 
= {
{ }
 };
 
-static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv)
-{
-   struct intel_opregion *opregion = dev_priv->display.opregion;
-   const struct firmware *fw = NULL;
-   const char *name = dev_priv->display.params.vbt_firmware;
-   int ret;
-
-   if (!name || !*name)
-   return -ENOENT;
-
-   ret = request_firmware(, name, dev_priv->drm.dev);
-   if (ret) {
-   drm_err(_priv->drm,
-   "Requesting VBT firmware \"%s\" failed (%d)\n",
-   name, ret);
-   return ret;
-   }
-
-   if (intel_bios_is_valid_vbt(dev_priv, fw->data, fw->size)) {
-   opregion->vbt_firmware = kmemdup(fw->data, fw->size, 
GFP_KERNEL);
-   if (opregion->vbt_firmware) {
-   drm_dbg_kms(_priv->drm,
-   "Found valid VBT firmware \"%s\"\n", name);
-   opregion->vbt = opregion->vbt_firmware;
-   opregion->vbt_size = fw->size;
-   ret = 0;
-   } else {
-   ret = -ENOMEM;
-   }
-   } else {
-   drm_dbg_kms(_priv->drm, "Invalid VBT firmware \"%s\"\n",
-   name);
-   ret = -EINVAL;
-   }
-
-   release_firmware(fw);
-
-   return ret;
-}
-
 int intel_opregion_setup(struct drm_i915_private *dev_priv)
 {
struct intel_opregion *opregion;
@@ -1006,9 +964,6 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)

linux-next: manual merge of the drm-misc-fixes tree with Linus' tree

2024-02-20 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc-fixes tree got a conflict in:

  drivers/gpu/drm/tests/drm_buddy_test.c

between commit:

  fca7526b7d89 ("drm/tests/drm_buddy: fix build failure on 32-bit targets")

from Linus' tree and commit:

  335126937753 ("drm/tests/drm_buddy: fix 32b build")

from the drm-misc-fixes tree.

I fixed it up (I just used the version from Linus' tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpfNZXAtObxC.pgp
Description: OpenPGP digital signature


[PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0

2024-02-20 Thread Stanislav Lisovskiy
Patch calculates bigjoiner pipes in mst compute.
Patch also passes bigjoiner bool to validate plane
max size.

Signed-off-by: vsrini4 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 5307ddd4edcf5..fd27d9976c050 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -523,6 +523,7 @@ static int intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
   struct drm_connector_state *conn_state)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
struct intel_dp *intel_dp = _mst->primary->dp;
const struct intel_connector *connector =
@@ -540,6 +541,10 @@ static int intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
return -EINVAL;
 
+   if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
+   adjusted_mode->crtc_clock))
+   pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1, 
crtc->pipe);
+
pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
pipe_config->has_pch_encoder = false;
@@ -1318,12 +1323,6 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector 
*connector,
 *   corresponding link capabilities of the sink) in case the
 *   stream is uncompressed for it by the last branch device.
 */
-   if (mode_rate > max_rate || mode->clock > max_dotclk ||
-   drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port->full_pbn) {
-   *status = MODE_CLOCK_HIGH;
-   return 0;
-   }
-
if (mode->clock < 1) {
*status = MODE_CLOCK_LOW;
return 0;
@@ -1343,6 +1342,12 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector 
*connector,
return 0;
}
 
+   if (mode_rate > max_rate || mode->clock > max_dotclk ||
+   drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port->full_pbn) {
+   *status = MODE_CLOCK_HIGH;
+   return 0;
+   }
+
if (DISPLAY_VER(dev_priv) >= 10 &&
drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
/*
@@ -1385,7 +1390,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector 
*connector,
return 0;
}
 
-   *status = intel_mode_valid_max_plane_size(dev_priv, mode, false);
+   *status = intel_mode_valid_max_plane_size(dev_priv, mode, bigjoiner);
return 0;
 }
 
-- 
2.37.3



[PATCH 2/3] Start separating pipe vs transcoder set logic for bigjoiner during modeset

2024-02-20 Thread Stanislav Lisovskiy
Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
slave crtcs should be handled by master hooks. Same for encoders.
That way we can also remove a bunch of checks like 
intel_crtc_is_bigjoiner_slave.

v2: Get rid of master vs slave checks and separation in crtc enable/disable 
hooks.
Use unified iteration cycle for all of those, while enabling/disabling
transcoder only for those pipes where its needed(Ville Syrjälä)

v3: Move all the intel_encoder_* calls under transcoder code path(Ville Syrjälä)

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |   3 +-
 drivers/gpu/drm/i915/display/intel_display.c | 183 ---
 drivers/gpu/drm/i915/display/intel_display.h |   6 +
 3 files changed, 121 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bea4415902044..9b459d3228b8b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3363,8 +3363,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
 {
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
 
-   if (!intel_crtc_is_bigjoiner_slave(crtc_state))
-   intel_ddi_enable_transcoder_func(encoder, crtc_state);
+   intel_ddi_enable_transcoder_func(encoder, crtc_state);
 
/* Enable/Disable DP2.0 SDP split config before transcoder */
intel_audio_sdp_split_update(crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 916c13a149fd5..522362aff7d95 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1631,31 +1631,12 @@ static void hsw_configure_cpu_transcoder(const struct 
intel_crtc_state *crtc_sta
hsw_set_transconf(crtc_state);
 }
 
-static void hsw_crtc_enable(struct intel_atomic_state *state,
-   struct intel_crtc *crtc)
+static void hsw_crtc_enable_pre_transcoder(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
 {
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
-   enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
-   bool psl_clkgate_wa;
-
-   if (drm_WARN_ON(_priv->drm, crtc->active))
-   return;
-
-   intel_dmc_enable_pipe(dev_priv, crtc->pipe);
-
-   if (!new_crtc_state->bigjoiner_pipes) {
-   intel_encoders_pre_pll_enable(state, crtc);
-
-   if (new_crtc_state->shared_dpll)
-   intel_enable_shared_dpll(new_crtc_state);
-
-   intel_encoders_pre_enable(state, crtc);
-   } else {
-   icl_ddi_bigjoiner_pre_enable(state, new_crtc_state);
-   }
 
intel_dsc_enable(new_crtc_state);
 
@@ -1665,19 +1646,17 @@ static void hsw_crtc_enable(struct intel_atomic_state 
*state,
intel_set_pipe_src_size(new_crtc_state);
if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
bdw_set_pipe_misc(new_crtc_state);
+}
 
-   if (!intel_crtc_is_bigjoiner_slave(new_crtc_state) &&
-   !transcoder_is_dsi(cpu_transcoder))
-   hsw_configure_cpu_transcoder(new_crtc_state);
+static void hsw_crtc_enable_post_transcoder(struct intel_atomic_state *state,
+   struct intel_crtc *crtc)
+{
+   const struct intel_crtc_state *new_crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 
crtc->active = true;
 
-   /* Display WA #1180: WaDisableScalarClockGating: glk */
-   psl_clkgate_wa = DISPLAY_VER(dev_priv) == 10 &&
-   new_crtc_state->pch_pfit.enabled;
-   if (psl_clkgate_wa)
-   glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
-
if (DISPLAY_VER(dev_priv) >= 9)
skl_pfit_enable(new_crtc_state);
else
@@ -1701,26 +1680,83 @@ static void hsw_crtc_enable(struct intel_atomic_state 
*state,
 
intel_initial_watermarks(state, crtc);
 
-   if (intel_crtc_is_bigjoiner_slave(new_crtc_state))
-   intel_crtc_vblank_on(new_crtc_state);
+   intel_crtc_vblank_on(new_crtc_state);
+}
 
-   intel_encoders_enable(state, crtc);
+static void hsw_crtc_enable(struct intel_atomic_state *state,
+   struct intel_crtc *crtc)
+{
+   const struct intel_crtc_state *new_crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
+   struct 

[PATCH 1/3] drm/i915/bigjoiner: Refactor bigjoiner state readout

2024-02-20 Thread Stanislav Lisovskiy
Don't call enabled_bigjoiner_pipes twice, lets just move
intel_get_bigjoiner_config earlier, because it is anyway
calling same function.
Also cleanup hsw_enabled_transcoders from irrelevant bigjoiner code.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 22 ++--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 00ac65a140298..916c13a149fd5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3535,7 +3535,6 @@ static u8 hsw_enabled_transcoders(struct intel_crtc *crtc)
struct drm_i915_private *dev_priv = to_i915(dev);
u8 panel_transcoder_mask = hsw_panel_transcoders(dev_priv);
enum transcoder cpu_transcoder;
-   u8 master_pipes, slave_pipes;
u8 enabled_transcoders = 0;
 
/*
@@ -3586,15 +3585,6 @@ static u8 hsw_enabled_transcoders(struct intel_crtc 
*crtc)
if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
enabled_transcoders |= BIT(cpu_transcoder);
 
-   /* bigjoiner slave -> consider the master pipe's transcoder as well */
-   enabled_bigjoiner_pipes(dev_priv, _pipes, _pipes);
-   if (slave_pipes & BIT(crtc->pipe)) {
-   cpu_transcoder = (enum transcoder)
-   get_bigjoiner_master_pipe(crtc->pipe, master_pipes, 
slave_pipes);
-   if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
-   enabled_transcoders |= BIT(cpu_transcoder);
-   }
-
return enabled_transcoders;
 }
 
@@ -3641,6 +3631,15 @@ static bool hsw_get_transcoder_state(struct intel_crtc 
*crtc,
u32 tmp;
 
enabled_transcoders = hsw_enabled_transcoders(crtc);
+
+   /* bigjoiner slave -> consider the master pipe's transcoder as well */
+   if (intel_crtc_is_bigjoiner_slave(pipe_config)) {
+   unsigned long cpu_transcoder = (enum transcoder)
+   bigjoiner_master_pipe(pipe_config);
+   if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
+   enabled_transcoders |= BIT(cpu_transcoder);
+   }
+
if (!enabled_transcoders)
return false;
 
@@ -3745,6 +3744,8 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
 
pipe_config->shared_dpll = NULL;
 
+   intel_bigjoiner_get_config(pipe_config);
+
active = hsw_get_transcoder_state(crtc, pipe_config, 
>hw_readout_power_domains);
 
if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
@@ -3756,7 +3757,6 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
if (!active)
goto out;
 
-   intel_bigjoiner_get_config(pipe_config);
intel_dsc_get_config(pipe_config);
 
if (!transcoder_is_dsi(pipe_config->cpu_transcoder) ||
-- 
2.37.3



[PATCH 0/3] Bigjoiner refactoring

2024-02-20 Thread Stanislav Lisovskiy
There are few things we need to do for bigjoiner, in order
to improve code maintenance and also make testing for Bigjoiner
easier.
Those series contain addition of bigjoiner force debugfs option,
in order to be able to force bigjoiner even if there is no display
support, also we refactor pipe vs transcoder logic, as currently
it is a bit scattered between *_commit_modeset_enables/disables
and *_crtc_enable/disable functions. Same applies to encoders.
We made a decision to handle all the slaves in correspondent master
hook, so slaves and slave checks no longer would be in modesetting
level logic.

Stanislav Lisovskiy (3):
  drm/i915/bigjoiner: Refactor bigjoiner state readout
  Start separating pipe vs transcoder set logic for bigjoiner during
modeset
  drm/i915: Fix bigjoiner case for DP2.0

 drivers/gpu/drm/i915/display/intel_ddi.c |   3 +-
 drivers/gpu/drm/i915/display/intel_display.c | 205 +++
 drivers/gpu/drm/i915/display/intel_display.h |   6 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  19 +-
 4 files changed, 144 insertions(+), 89 deletions(-)

-- 
2.37.3



Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170

2024-02-20 Thread Rodrigo Vivi
On Tue, Feb 20, 2024 at 11:52:04AM -0800, John Harrison wrote:
> On 2/19/2024 12:28, Rodrigo Vivi wrote:
> > On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison 
> > > 
> > > The above w/a is required for every platform that the i915 driver
> > > supports. It is fixed on the latest platforms but they are only
> > > supported by Xe instead of i915. So just remove the platform check
> > > completely and keep the code simple.
> > Well, I was going to say that I would prefer a GMD version greater-than
> > check to be future proof. However if this code gets used in some other
> > new platform a new specific guc support would likely need to be added
> > as well right?
> There is no future for i915. That's the point. The only platforms that have
> the hardware fix are all ones that will only ever be supported by the Xe
> driver. So if such a platform were to be backported to i915 then there would
> be a lot more work than just adding a new GuC firmware platform.
> 
> And going backwards, the bug affects all platforms that have a GuC. So if
> any GuC code is being executed at all, then this w/a is applicable.
> 
> > 
> > Perhaps at least adding a comment in the code?
> Such as this?
>     /*
>  * Wa_14018913170: Applicable to all platforms supported by i915.

I believe only this first line would be enough. but up to you and feel free
to put my rv-b with whatever version you get.

 so
>  * don't bother testing for all X/Y/Z platforms explicitly.
>  */
> 
> John.
> 
> 
> > 
> > with that
> > Reviewed-by: Rodrigo Vivi 
> > 
> > 
> > > Signed-off-by: John Harrison 
> > > ---
> > >   drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
> > >   1 file changed, 1 insertion(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > index 2b450c43bbd7f..a3662edb42032 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > @@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
> > >   /* Wa_14018913170 */
> > >   if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
> > > - if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) || 
> > > IS_PONTEVECCHIO(gt->i915))
> > > - flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> > > + flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> > >   }
> > >   return flags;
> > > -- 
> > > 2.43.0
> > > 
> 


[PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses

2024-02-20 Thread Imre Deak
The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager
depends on the GFX driver reading out the sink's DPRX capabilities in
response to a long HPD pulse. Since in i915 this read-out can be blocked
by another connector's/encoder's hotplug event handling (which is
serialized by drm_mode_config::connection_mutex), do a dummy DPRX read-out
in the encoder's HPD pulse handler (which is not blocked by other
encoders).

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 35ef17439038a..f7f8bd5742ad4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6162,6 +6162,7 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port, 
bool long_hpd)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_dp *intel_dp = _port->dp;
+   u8 dpcd[DP_RECEIVER_CAP_SIZE];
 
if (dig_port->base.type == INTEL_OUTPUT_EDP &&
(long_hpd || !intel_pps_have_panel_power_or_vdd(intel_dp))) {
@@ -6184,6 +6185,17 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port, 
bool long_hpd)
dig_port->base.base.name,
long_hpd ? "long" : "short");
 
+   /*
+* TBT DP tunnels require the GFX driver to read out the DPRX caps in
+* response to long HPD pulses. The DP hotplug handler does that,
+* however the hotplug handler may be blocked by another
+* connector's/encoder's hotplug handler. Since the TBT CM may not
+* complete the DP tunnel BW request for the latter connector/encoder
+* waiting for this encoder's DPRX read, perform a dummy read here.
+*/
+   if (long_hpd)
+   intel_dp_read_dprx_caps(intel_dp, dpcd);
+
if (long_hpd) {
intel_dp->reset_link_params = true;
return IRQ_NONE;
-- 
2.39.2



[PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode

2024-02-20 Thread Imre Deak
Detect DP tunnels and enable the BW allocation mode on them. Send a
hotplug notification to userspace in response to a BW change.

Signed-off-by: Imre Deak 
---
 .../drm/i915/display/intel_display_driver.c   | 20 +++
 drivers/gpu/drm/i915/display/intel_dp.c   | 14 +++--
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 4f7ba7eb03d27..87dd07e0d138d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -35,6 +35,7 @@
 #include "intel_dkl_phy.h"
 #include "intel_dmc.h"
 #include "intel_dp.h"
+#include "intel_dp_tunnel.h"
 #include "intel_dpll.h"
 #include "intel_dpll_mgr.h"
 #include "intel_fb.h"
@@ -434,10 +435,8 @@ int intel_display_driver_probe_nogem(struct 
drm_i915_private *i915)
 
for_each_pipe(i915, pipe) {
ret = intel_crtc_init(i915, pipe);
-   if (ret) {
-   intel_mode_config_cleanup(i915);
-   return ret;
-   }
+   if (ret)
+   goto err_mode_config;
}
 
intel_plane_possible_crtcs_init(i915);
@@ -457,6 +456,10 @@ int intel_display_driver_probe_nogem(struct 
drm_i915_private *i915)
intel_vga_disable(i915);
intel_setup_outputs(i915);
 
+   ret = intel_dp_tunnel_mgr_init(i915);
+   if (ret)
+   goto err_hdcp;
+
intel_display_driver_disable_user_access(i915);
 
drm_modeset_lock_all(dev);
@@ -475,6 +478,13 @@ int intel_display_driver_probe_nogem(struct 
drm_i915_private *i915)
ilk_wm_sanitize(i915);
 
return 0;
+
+err_hdcp:
+   intel_hdcp_component_fini(i915);
+err_mode_config:
+   intel_mode_config_cleanup(i915);
+
+   return ret;
 }
 
 /* part #3: call after gem init */
@@ -599,6 +609,8 @@ void intel_display_driver_remove_noirq(struct 
drm_i915_private *i915)
 
intel_mode_config_cleanup(i915);
 
+   intel_dp_tunnel_mgr_cleanup(i915);
+
intel_overlay_cleanup(i915);
 
intel_gmbus_teardown(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f7f8bd5742ad4..789b5fa074fd0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5726,6 +5726,7 @@ intel_dp_detect(struct drm_connector *connector,
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _port->base;
enum drm_connector_status status;
+   int ret;
 
drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
@@ -5761,9 +5762,18 @@ intel_dp_detect(struct drm_connector *connector,
intel_dp->is_mst);
}
 
+   intel_dp_tunnel_disconnect(intel_dp);
+
goto out;
}
 
+   ret = intel_dp_tunnel_detect(intel_dp, ctx);
+   if (ret == -EDEADLK)
+   return ret;
+
+   if (ret == 1)
+   intel_connector->base.epoch_counter++;
+
intel_dp_detect_dsc_caps(intel_dp, intel_connector);
 
intel_dp_configure_mst(intel_dp);
@@ -5794,8 +5804,6 @@ intel_dp_detect(struct drm_connector *connector,
 * with an IRQ_HPD, so force a link status check.
 */
if (!intel_dp_is_edp(intel_dp)) {
-   int ret;
-
ret = intel_dp_retrain_link(encoder, ctx);
if (ret)
return ret;
@@ -5935,6 +5943,8 @@ void intel_dp_encoder_flush_work(struct drm_encoder 
*encoder)
 
intel_dp_mst_encoder_cleanup(dig_port);
 
+   intel_dp_tunnel_destroy(intel_dp);
+
intel_pps_vdd_off_sync(intel_dp);
 
/*
-- 
2.39.2



[PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels

2024-02-20 Thread Imre Deak
Suspend and resume DP tunnels during system suspend/resume, disabling
the BW allocation mode during suspend, re-enabling it after resume. This
reflects the link's BW management component (Thunderbolt CM) disabling
BWA during suspend. Before any BW requests the driver must read the
sink's DPRX capabilities (since the BW manager requires this
information, so snoops for it on AUX), so ensure this read takes place.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a3dfcbb710027..35ef17439038a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -36,6 +36,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3313,18 +3314,21 @@ void intel_dp_sync_state(struct intel_encoder *encoder,
 const struct intel_crtc_state *crtc_state)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
-   if (!crtc_state)
-   return;
+   bool dpcd_updated = false;
 
/*
 * Don't clobber DPCD if it's been already read out during output
 * setup (eDP) or detect.
 */
-   if (intel_dp->dpcd[DP_DPCD_REV] == 0)
+   if (crtc_state && intel_dp->dpcd[DP_DPCD_REV] == 0) {
intel_dp_get_dpcd(intel_dp);
+   dpcd_updated = true;
+   }
 
-   intel_dp_reset_max_link_params(intel_dp);
+   intel_dp_tunnel_resume(intel_dp, crtc_state, dpcd_updated);
+
+   if (crtc_state)
+   intel_dp_reset_max_link_params(intel_dp);
 }
 
 bool intel_dp_initial_fastset_check(struct intel_encoder *encoder,
@@ -5947,6 +5951,8 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
 
intel_pps_vdd_off_sync(intel_dp);
+
+   intel_dp_tunnel_suspend(intel_dp);
 }
 
 void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder)
-- 
2.39.2



[PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs

2024-02-20 Thread Imre Deak
Handle DP tunnel IRQs a sink (or rather a BW management component like
the Thunderbolt Connection Manager) raises to signal the completion of a
BW request by the driver, or to signal any state change related to the
link BW.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 37 +++--
 include/drm/display/drm_dp.h|  1 +
 2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5ad7808788745..a3dfcbb710027 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4904,13 +4904,15 @@ static bool intel_dp_mst_link_status(struct intel_dp 
*intel_dp)
  * - %true if pending interrupts were serviced (or no interrupts were
  *   pending) w/o detecting an error condition.
  * - %false if an error condition - like AUX failure or a loss of link - is
- *   detected, which needs servicing from the hotplug work.
+ *   detected, or another condition - like a DP tunnel BW state change - needs
+ *   servicing from the hotplug work.
  */
 static bool
 intel_dp_check_mst_status(struct intel_dp *intel_dp)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
bool link_ok = true;
+   bool reprobe_needed = false;
 
drm_WARN_ON_ONCE(>drm, intel_dp->active_mst_links < 0);
 
@@ -4937,6 +4939,13 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
 
intel_dp_mst_hpd_irq(intel_dp, esi, ack);
 
+   if (esi[3] & DP_TUNNELING_IRQ) {
+   if 
(drm_dp_tunnel_handle_irq(i915->display.dp_tunnel_mgr,
+_dp->aux))
+   reprobe_needed = true;
+   ack[3] |= DP_TUNNELING_IRQ;
+   }
+
if (!memchr_inv(ack, 0, sizeof(ack)))
break;
 
@@ -4947,7 +4956,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
drm_dp_mst_hpd_irq_send_new_request(_dp->mst_mgr);
}
 
-   return link_ok;
+   return link_ok && !reprobe_needed;
 }
 
 static void
@@ -5304,23 +5313,32 @@ static void intel_dp_check_device_service_irq(struct 
intel_dp *intel_dp)
drm_dbg_kms(>drm, "Sink specific irq unhandled\n");
 }
 
-static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+static bool intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
 {
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool reprobe_needed = false;
u8 val;
 
if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
-   return;
+   return false;
 
if (drm_dp_dpcd_readb(_dp->aux,
  DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 || 
!val)
-   return;
+   return false;
+
+   if ((val & DP_TUNNELING_IRQ) &&
+   drm_dp_tunnel_handle_irq(i915->display.dp_tunnel_mgr,
+_dp->aux))
+   reprobe_needed = true;
 
if (drm_dp_dpcd_writeb(_dp->aux,
   DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1)
-   return;
+   return reprobe_needed;
 
if (val & HDMI_LINK_STATUS_CHANGED)
intel_dp_handle_hdmi_link_status_change(intel_dp);
+
+   return reprobe_needed;
 }
 
 /*
@@ -5341,6 +5359,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u8 old_sink_count = intel_dp->sink_count;
+   bool reprobe_needed = false;
bool ret;
 
/*
@@ -5363,7 +5382,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
}
 
intel_dp_check_device_service_irq(intel_dp);
-   intel_dp_check_link_service_irq(intel_dp);
+   reprobe_needed = intel_dp_check_link_service_irq(intel_dp);
 
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(_dp->aux);
@@ -5390,10 +5409,10 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
 * FIXME get rid of the ad-hoc phy test modeset code
 * and properly incorporate it into the normal modeset.
 */
-   return false;
+   reprobe_needed = true;
}
 
-   return true;
+   return !reprobe_needed;
 }
 
 /* XXX this is probably wrong for multiple downstream ports */
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 8bfd5d007be8d..4891bd916d26a 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1081,6 +1081,7 @@
 # define STREAM_STATUS_CHANGED   (1 << 2)
 # define HDMI_LINK_STATUS_CHANGED(1 << 3)
 # define CONNECTED_OFF_ENTRY_REQUESTED   (1 << 4)
+# define DP_TUNNELING_IRQ(1 << 5)
 
 #define DP_PSR_ERROR_STATUS 0x2006  /* XXX 1.2? */
 # define DP_PSR_LINK_CRC_ERROR   

[PATCH v2 14/21] drm/i915/dp: Account for tunnel BW limit in intel_dp_max_link_data_rate()

2024-02-20 Thread Imre Deak
Take any link BW limitation into account in
intel_dp_max_link_data_rate(). Such a limitation can be due to multiple
displays on (Thunderbolt) links with DP tunnels sharing the link BW.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 32 +
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d0452d3e534a7..f4f748d95ad17 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -63,6 +63,7 @@
 #include "intel_dp_hdcp.h"
 #include "intel_dp_link_training.h"
 #include "intel_dp_mst.h"
+#include "intel_dp_tunnel.h"
 #include "intel_dpio_phy.h"
 #include "intel_dpll.h"
 #include "intel_fifo_underrun.h"
@@ -152,6 +153,22 @@ int intel_dp_link_symbol_clock(int rate)
return DIV_ROUND_CLOSEST(rate * 10, intel_dp_link_symbol_size(rate));
 }
 
+static int max_dprx_rate(struct intel_dp *intel_dp)
+{
+   if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
+   return drm_dp_tunnel_max_dprx_rate(intel_dp->tunnel);
+
+   return drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
+}
+
+static int max_dprx_lane_count(struct intel_dp *intel_dp)
+{
+   if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
+   return drm_dp_tunnel_max_dprx_lane_count(intel_dp->tunnel);
+
+   return drm_dp_max_lane_count(intel_dp->dpcd);
+}
+
 static void intel_dp_set_default_sink_rates(struct intel_dp *intel_dp)
 {
intel_dp->sink_rates[0] = 162000;
@@ -180,7 +197,7 @@ static void intel_dp_set_dpcd_sink_rates(struct intel_dp 
*intel_dp)
/*
 * Sink rates for 8b/10b.
 */
-   max_rate = 
drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
+   max_rate = max_dprx_rate(intel_dp);
max_lttpr_rate = 
drm_dp_lttpr_max_link_rate(intel_dp->lttpr_common_caps);
if (max_lttpr_rate)
max_rate = min(max_rate, max_lttpr_rate);
@@ -259,7 +276,7 @@ static void intel_dp_set_max_sink_lane_count(struct 
intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _dig_port->base;
 
-   intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+   intel_dp->max_sink_lane_count = max_dprx_lane_count(intel_dp);
 
switch (intel_dp->max_sink_lane_count) {
case 1:
@@ -389,14 +406,21 @@ int intel_dp_effective_data_rate(int pixel_clock, int 
bpp_x16,
  * @max_dprx_rate: Maximum data rate of the DPRX
  * @max_dprx_lanes: Maximum lane count of the DPRX
  *
- * Calculate the maximum data rate for the provided link parameters.
+ * Calculate the maximum data rate for the provided link parameters taking into
+ * account any BW limitations by a DP tunnel attached to @intel_dp.
  *
  * Returns the maximum data rate in kBps units.
  */
 int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
int max_dprx_rate, int max_dprx_lanes)
 {
-   return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes);
+   int max_rate = drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes);
+
+   if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
+   max_rate = min(max_rate,
+  drm_dp_tunnel_available_bw(intel_dp->tunnel));
+
+   return max_rate;
 }
 
 bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
-- 
2.39.2



[PATCH v2 18/21] drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders

2024-02-20 Thread Imre Deak
A follow-up change will need to resume DP tunnels during system resume,
so call intel_dp_sync_state() always for DDI encoders, so this function
can resume the tunnels for all DP connectors.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ed7301808604d..c587a8efeafcf 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4151,7 +4151,7 @@ static void intel_ddi_sync_state(struct intel_encoder 
*encoder,
intel_tc_port_sanitize_mode(enc_to_dig_port(encoder),
crtc_state);
 
-   if (crtc_state && intel_crtc_has_dp_encoder(crtc_state))
+   if (intel_encoder_is_dp(encoder))
intel_dp_sync_state(encoder, crtc_state);
 }
 
-- 
2.39.2



[PATCH v2 16/21] drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable hooks

2024-02-20 Thread Imre Deak
Allocate and free the DP tunnel BW required by a stream while
enabling/disabling the stream during a modeset.

v2:
- Move the allocation up from encoder hooks to
  intel_atomic_commit_tail().

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar  (v1)
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
 drivers/gpu/drm/i915/display/intel_display.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bea4415902044..ed7301808604d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -54,6 +54,7 @@
 #include "intel_dp_aux.h"
 #include "intel_dp_link_training.h"
 #include "intel_dp_mst.h"
+#include "intel_dp_tunnel.h"
 #include "intel_dpio_phy.h"
 #include "intel_dsi.h"
 #include "intel_fdi.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 20647c97e86fa..445efe0087cde 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7123,6 +7123,8 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
 
intel_commit_modeset_disables(state);
 
+   intel_dp_tunnel_atomic_alloc_bw(state);
+
/* FIXME: Eventually get rid of our crtc->config pointer */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
crtc->config = new_crtc_state;
-- 
2.39.2



[PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check BW limit

2024-02-20 Thread Imre Deak
Add the atomic state during a modeset required to enable the DP tunnel
BW allocation mode on links where such a tunnel was detected. This state
applies to an already enabled output, the state added for a newly
enabled output will be computed and added/cleared to/from the atomic
state in a follow-up patch.

v2:
- s/old_crtc_state/crtc_state in intel_crtc_duplicate_state().
- Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up
  patch adding the corresponding state. (Ville)
- Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up
  patch adding the corresponding state.

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_atomic.c  |  6 ++
 drivers/gpu/drm/i915/display/intel_display.c | 12 
 drivers/gpu/drm/i915/display/intel_link_bw.c |  5 +
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 96ab37e158995..798cb90361a83 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -260,6 +260,10 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
if (crtc_state->post_csc_lut)
drm_property_blob_get(crtc_state->post_csc_lut);
 
+   if (crtc_state->dp_tunnel_ref.tunnel)
+   drm_dp_tunnel_ref_get(crtc_state->dp_tunnel_ref.tunnel,
+ _state->dp_tunnel_ref);
+
crtc_state->update_pipe = false;
crtc_state->update_m_n = false;
crtc_state->update_lrr = false;
@@ -311,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
 
__drm_atomic_helper_crtc_destroy_state(_state->uapi);
intel_crtc_free_hw_state(crtc_state);
+   if (crtc_state->dp_tunnel_ref.tunnel)
+   drm_dp_tunnel_ref_put(_state->dp_tunnel_ref);
kfree(crtc_state);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e1a4200f67a7e..16973ebb7865d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -33,6 +33,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -73,6 +74,7 @@
 #include "intel_dp.h"
 #include "intel_dp_link_training.h"
 #include "intel_dp_mst.h"
+#include "intel_dp_tunnel.h"
 #include "intel_dpll.h"
 #include "intel_dpll_mgr.h"
 #include "intel_dpt.h"
@@ -4490,6 +4492,8 @@ copy_bigjoiner_crtc_state_modeset(struct 
intel_atomic_state *state,
saved_state->crc_enabled = slave_crtc_state->crc_enabled;
 
intel_crtc_free_hw_state(slave_crtc_state);
+   if (slave_crtc_state->dp_tunnel_ref.tunnel)
+   drm_dp_tunnel_ref_put(_crtc_state->dp_tunnel_ref);
memcpy(slave_crtc_state, saved_state, sizeof(*slave_crtc_state));
kfree(saved_state);
 
@@ -4505,6 +4509,10 @@ copy_bigjoiner_crtc_state_modeset(struct 
intel_atomic_state *state,
  _crtc_state->hw.adjusted_mode);
slave_crtc_state->hw.scaling_filter = 
master_crtc_state->hw.scaling_filter;
 
+   if (master_crtc_state->dp_tunnel_ref.tunnel)
+   drm_dp_tunnel_ref_get(master_crtc_state->dp_tunnel_ref.tunnel,
+   _crtc_state->dp_tunnel_ref);
+
copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc);
 
slave_crtc_state->uapi.mode_changed = 
master_crtc_state->uapi.mode_changed;
@@ -5365,6 +5373,10 @@ static int intel_modeset_pipe(struct intel_atomic_state 
*state,
if (ret)
return ret;
 
+   ret = intel_dp_tunnel_atomic_add_state_for_crtc(state, crtc);
+   if (ret)
+   return ret;
+
ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c 
b/drivers/gpu/drm/i915/display/intel_link_bw.c
index 27ea858897c9f..dfd7d5e23f3fa 100644
--- a/drivers/gpu/drm/i915/display/intel_link_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
@@ -9,6 +9,7 @@
 #include "intel_crtc.h"
 #include "intel_display_types.h"
 #include "intel_dp_mst.h"
+#include "intel_dp_tunnel.h"
 #include "intel_fdi.h"
 #include "intel_link_bw.h"
 
@@ -163,6 +164,10 @@ static int check_all_link_config(struct intel_atomic_state 
*state,
if (ret)
return ret;
 
+   ret = intel_dp_tunnel_atomic_check_link(state, limits);
+   if (ret)
+   return ret;
+
ret = intel_fdi_atomic_check_link(state, limits);
if (ret)
return ret;
-- 
2.39.2



[PATCH v2 15/21] drm/i915/dp: Compute DP tunnel BW during encoder state computation

2024-02-20 Thread Imre Deak
Compute the BW required through a DP tunnel on links with such tunnels
detected and add the corresponding atomic state during a modeset.

v2:
- Fix error check of intel_dp_tunnel_compute_stream_bw(). (Ville)
- Move intel_dp_tunnel_atomic_cleanup_inherited_state() to this patch.
  (Ville)
- Move intel_dp_tunnel_atomic_clear_stream_bw() to this patch.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar  (v1)
---
 drivers/gpu/drm/i915/display/intel_atomic.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_display.c |  2 ++
 drivers/gpu/drm/i915/display/intel_dp.c  | 16 
 drivers/gpu/drm/i915/display/intel_dp_mst.c  | 13 -
 4 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 798cb90361a83..2bb270f82932e 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -352,6 +352,8 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
/* state->internal not reset on purpose */
 
state->dpll_set = state->modeset = false;
+
+   intel_dp_tunnel_atomic_cleanup_inherited_state(state);
 }
 
 struct intel_crtc_state *
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 16973ebb7865d..20647c97e86fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4541,6 +4541,8 @@ intel_crtc_prepare_cleared_state(struct 
intel_atomic_state *state,
/* free the old crtc_state->hw members */
intel_crtc_free_hw_state(crtc_state);
 
+   intel_dp_tunnel_atomic_clear_stream_bw(state, crtc_state);
+
/* FIXME: before the switch to atomic started, a new pipe_config was
 * kzalloc'd. Code that depends on any field being zero should be
 * fixed, so that the crtc_state can be safely duplicated. For now,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f4f748d95ad17..5ad7808788745 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2875,6 +2875,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct drm_connector_state *conn_state)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_atomic_state *state = 
to_intel_atomic_state(conn_state->state);
struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
const struct drm_display_mode *fixed_mode;
@@ -2975,7 +2976,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config, 
conn_state);
 
-   return 0;
+   return intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, 
connector,
+   pipe_config);
 }
 
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
@@ -6063,6 +6065,15 @@ static int intel_dp_connector_atomic_check(struct 
drm_connector *conn,
return ret;
}
 
+   if (!intel_connector_needs_modeset(state, conn))
+   return 0;
+
+   ret = intel_dp_tunnel_atomic_check_state(state,
+intel_dp,
+intel_conn);
+   if (ret)
+   return ret;
+
/*
 * We don't enable port sync on BDW due to missing w/as and
 * due to not having adjusted the modeset sequence appropriately.
@@ -6070,9 +6081,6 @@ static int intel_dp_connector_atomic_check(struct 
drm_connector *conn,
if (DISPLAY_VER(dev_priv) < 9)
return 0;
 
-   if (!intel_connector_needs_modeset(state, conn))
-   return 0;
-
if (conn->has_tile) {
ret = intel_modeset_tile_group(state, conn->tile_group->id);
if (ret)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 4b6c8ff974297..db1254b036f18 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -42,6 +42,7 @@
 #include "intel_dp.h"
 #include "intel_dp_hdcp.h"
 #include "intel_dp_mst.h"
+#include "intel_dp_tunnel.h"
 #include "intel_dpio_phy.h"
 #include "intel_hdcp.h"
 #include "intel_hotplug.h"
@@ -523,6 +524,7 @@ static int intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
   struct drm_connector_state *conn_state)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_atomic_state *state = 
to_intel_atomic_state(conn_state->state);
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
  

[PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation

2024-02-20 Thread Imre Deak
Add support to enable the DP tunnel BW allocation mode. Follow-up
patches will call the required helpers added here to prepare for a
modeset on a link with DP tunnels, the last change in the patchset
actually enabling BWA.

With BWA enabled, the driver will expose the full mode list a display
supports, regardless of any BW limitation on a shared (Thunderbolt)
link. Such BW limits will be checked against only during a modeset, when
the driver has the full knowledge of each display's BW requirement.

If the link BW changes in a way that a connector's modelist may also
change, userspace will get a hotplug notification for all the connectors
sharing the same link (so it can adjust the mode used for a display).

The BW limitation can change at any point, asynchronously to modesets
on a given connector, so a modeset can fail even though the atomic check
for it passed. In such scenarios userspace will get a bad link
notification and in response is supposed to retry the modeset.

v2:
- Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state().
  (Ville)
- Fix propagating the error from
  intel_dp_tunnel_atomic_compute_stream_bw(). (Ville)
- Move tunnel==NULL checks from driver to DRM core helpers. (Ville)
- Simplify return flow from intel_dp_tunnel_detect(). (Ville)
- s/dp_tunnel_state/inherited_dp_tunnels (Ville)
- Simplify struct intel_dp_tunnel_inherited_state. (Ville)
- Unconstify object pointers (vs. states) where possible. (Ville)
- Init crtc_state while declaring it in check_group_state(). (Ville)
- Join obj->base.id, obj->name arg lines in debug prints to reduce LOC.
  (Ville)
- Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the
  BW allocation from encoder hooks up to intel_atomic_commit_tail()
  later in the patchset.
- Disable BW alloc mode during system suspend.
- Allocate the required BW for all tunnels during system resume.
- Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded
  sequence in a follow-up patch.
- Add function documentation to all exported functions.
- Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL.

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/Kconfig  |  14 +
 drivers/gpu/drm/i915/Kconfig.debug|   1 +
 drivers/gpu/drm/i915/Makefile |   3 +
 drivers/gpu/drm/i915/display/intel_atomic.c   |   2 +
 drivers/gpu/drm/i915/display/intel_crtc.c |  25 +
 drivers/gpu/drm/i915/display/intel_crtc.h |   1 +
 .../gpu/drm/i915/display/intel_display_core.h |   1 +
 .../drm/i915/display/intel_display_types.h|   9 +
 .../gpu/drm/i915/display/intel_dp_tunnel.c| 815 ++
 .../gpu/drm/i915/display/intel_dp_tunnel.h| 133 +++
 10 files changed, 1004 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 3089029abba48..5932024f8f954 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -155,6 +155,20 @@ config DRM_I915_PXP
  protected session and manage the status of the alive software session,
  as well as its life cycle.
 
+config DRM_I915_DP_TUNNEL
+   bool "Enable DP tunnel support"
+   depends on DRM_I915
+   depends on USB4
+   select DRM_DISPLAY_DP_TUNNEL
+   default y
+   help
+ Choose this option to detect DP tunnels and enable the Bandwidth
+ Allocation mode for such tunnels. This allows using the maximum
+ resolution allowed by the link BW on all displays sharing the
+ link BW, for instance on a Thunderbolt link.
+
+ If in doubt, say "Y".
+
 menu "drm/i915 Debugging"
 depends on DRM_I915
 depends on EXPERT
diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 5b7162076850c..bc18e2d9ea05d 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -28,6 +28,7 @@ config DRM_I915_DEBUG
select STACKDEPOT
select STACKTRACE
select DRM_DP_AUX_CHARDEV
+   select DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE if DRM_I915_DP_TUNNEL
select X86_MSR # used by igt/pm_rpm
select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
select DRM_DEBUG_MM if DRM=y
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c13f14edb5088..3ef6ed41e62b4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -369,6 +369,9 @@ i915-y += \
display/vlv_dsi.o \
display/vlv_dsi_pll.o
 
+i915-$(CONFIG_DRM_I915_DP_TUNNEL) += \
+   display/intel_dp_tunnel.o
+
 i915-y += \
i915_perf.o
 
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index ec0d5168b5035..96ab37e158995 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ 

[PATCH v2 08/21] drm/i915/dp: Factor out intel_dp_update_sink_caps()

2024-02-20 Thread Imre Deak
Factor out a function updating the sink's link rate and lane count
capabilities, used by a follow-up patch enabling the DP tunnel BW
allocation mode.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
 drivers/gpu/drm/i915/display/intel_dp.h |  1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 20e04cbdffcae..520c04245c2df 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3944,6 +3944,13 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
  _dp->desc);
 }
 
+void intel_dp_update_sink_caps(struct intel_dp *intel_dp)
+{
+   intel_dp_set_sink_rates(intel_dp);
+   intel_dp_set_max_sink_lane_count(intel_dp);
+   intel_dp_set_common_rates(intel_dp);
+}
+
 static bool
 intel_dp_get_dpcd(struct intel_dp *intel_dp)
 {
@@ -3960,9 +3967,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
drm_dp_read_desc(_dp->aux, _dp->desc,
 drm_dp_is_branch(intel_dp->dpcd));
 
-   intel_dp_set_sink_rates(intel_dp);
-   intel_dp_set_max_sink_lane_count(intel_dp);
-   intel_dp_set_common_rates(intel_dp);
+   intel_dp_update_sink_caps(intel_dp);
}
 
if (intel_dp_has_sink_count(intel_dp)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index ee0600b4425e1..10e859b62bbe9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -104,6 +104,7 @@ int intel_dp_config_required_rate(const struct 
intel_crtc_state *crtc_state);
 int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
 int intel_dp_max_common_rate(struct intel_dp *intel_dp);
 int intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
+void intel_dp_update_sink_caps(struct intel_dp *intel_dp);
 
 void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
   u8 *link_bw, u8 *rate_select);
-- 
2.39.2



[PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits

2024-02-20 Thread Imre Deak
Add a way to get the active pipes through a given DP port by syncing
against a related pending non-blocking commit. Atm
intel_dp_get_active_pipes() will only try to sync a given pipe and if
that would block ignore the pipe. A follow-up change enabling the DP
tunnel BW allocation mode will need to ensure that all active pipes are
returned.

This change will use intel_crtc_state::uapi.commit instead of the
corresponding commit in the connector state. This shouldn't make a
difference, since the two commit objects match for an active pipe.

A follow-up patchset will remove syncing during TC port reset, which
should reset a port/pipe even if syncing against a commit would block.
Syncing OTOH is not needed there, since the commit used for the reset
implies a sync already. For now add a TODO comment for this.

v2:
- Add a separate function to try-sync the pipes. (Ville)

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
 drivers/gpu/drm/i915/display/intel_crtc.h |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  6 ++---
 drivers/gpu/drm/i915/display/intel_tc.c   |  7 ++
 4 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 25593f6aae7de..17ed2e62cc66a 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state 
*state,
 out:
intel_psr_unlock(new_crtc_state);
 }
+
+/**
+ * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of pipes
+ * @i915: i915 device object
+ * @pipe_mask: Mask of pipes to sync
+ *
+ * Try to sync a pending non-blocking commit for the provided pipes in
+ * @pipe_mask. The commit won't be synced if this would block.
+ *
+ * Return a mask of the pipes that got synced or didn't need syncing.
+ */
+u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask)
+{
+   struct intel_crtc *crtc;
+   u32 synced = 0;
+
+   for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
+   const struct intel_crtc_state *crtc_state =
+   to_intel_crtc_state(crtc->base.state);
+
+   if (!crtc_state->uapi.commit ||
+   try_wait_for_completion(_state->uapi.commit->hw_done))
+   synced |= BIT(crtc->pipe);
+   }
+
+   return synced;
+}
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h 
b/drivers/gpu/drm/i915/display/intel_crtc.h
index 22d7993d1f0ba..71a5b93166da7 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.h
+++ b/drivers/gpu/drm/i915/display/intel_crtc.h
@@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct 
drm_i915_private *i915,
 void intel_wait_for_vblank_if_active(struct drm_i915_private *i915,
 enum pipe pipe);
 void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
+u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask);
 
 #endif
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d9e75922ff8f5..d0452d3e534a7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp *intel_dp,
if (!crtc_state->hw.active)
continue;
 
-   if (conn_state->commit &&
-   !try_wait_for_completion(_state->commit->hw_done))
-   continue;
-
*pipe_mask |= BIT(crtc->pipe);
}
drm_connector_list_iter_end(_iter);
@@ -5091,6 +5087,8 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
if (ret)
return ret;
 
+   pipe_mask &= intel_crtc_try_sync_pipes(dev_priv, pipe_mask);
+
if (pipe_mask == 0)
return 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 6b374d481cd9e..14d17903a81f5 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -7,6 +7,7 @@
 #include "i915_reg.h"
 #include "intel_atomic.h"
 #include "intel_cx0_phy_regs.h"
+#include "intel_crtc.h"
 #include "intel_ddi.h"
 #include "intel_de.h"
 #include "intel_display.h"
@@ -1663,6 +1664,12 @@ static int reset_link_commit(struct intel_tc_port *tc,
if (ret)
return ret;
 
+   /*
+* TODO: remove the following, since an output must be reset
+* even if we had to wait for a non-blocking commit on a pipe.
+*/
+   pipe_mask &= intel_crtc_try_sync_pipes(i915, pipe_mask);
+
if (!pipe_mask)
return 0;
 
-- 
2.39.2



[PATCH v2 09/21] drm/i915/dp: Factor out intel_dp_read_dprx_caps()

2024-02-20 Thread Imre Deak
Factor out a function to read the sink's DPRX capabilities used by a
follow-up patch enabling the DP tunnel BW allocation mode.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 .../drm/i915/display/intel_dp_link_training.c | 30 +++
 .../drm/i915/display/intel_dp_link_training.h |  1 +
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 7b140cbf8dd31..fb84ca98bb7ab 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -162,6 +162,28 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp, 
const u8 dpcd[DP_RECEI
return lttpr_count;
 }
 
+int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8 
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   if (intel_dp_is_edp(intel_dp))
+   return 0;
+
+   /*
+* Detecting LTTPRs must be avoided on platforms with an AUX timeout
+* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
+*/
+   if (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))
+   if (drm_dp_dpcd_probe(_dp->aux,
+ 
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
+   return -EIO;
+
+   if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
+   return -EIO;
+
+   return 0;
+}
+
 /**
  * intel_dp_init_lttpr_and_dprx_caps - detect LTTPR and DPRX caps, init the 
LTTPR link training mode
  * @intel_dp: Intel DP struct
@@ -192,12 +214,10 @@ int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp 
*intel_dp)
if (!intel_dp_is_edp(intel_dp) &&
(DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
u8 dpcd[DP_RECEIVER_CAP_SIZE];
+   int err = intel_dp_read_dprx_caps(intel_dp, dpcd);
 
-   if (drm_dp_dpcd_probe(_dp->aux, 
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
-   return -EIO;
-
-   if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
-   return -EIO;
+   if (err != 0)
+   return err;
 
lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 2c8f2775891b0..19836a8a4f904 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -11,6 +11,7 @@
 struct intel_crtc_state;
 struct intel_dp;
 
+int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8 
dpcd[DP_RECEIVER_CAP_SIZE]);
 int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp);
 
 void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
-- 
2.39.2



[PATCH v2 10/21] drm/i915/dp: Add intel_dp_max_link_data_rate()

2024-02-20 Thread Imre Deak
Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX
BW used by a follow-up patch enabling the DP tunnel BW allocation mode.
The link BW can be below the DPRX BW due to a BW limitation on a link
shared by multiple sinks.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 32 +
 drivers/gpu/drm/i915/display/intel_dp.h |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  3 +-
 3 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 520c04245c2df..d9e75922ff8f5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -383,6 +383,22 @@ int intel_dp_effective_data_rate(int pixel_clock, int 
bpp_x16,
100 * 16 * 8);
 }
 
+/**
+ * intel_dp_max_link_data_rate: Calculate the maximum rate for the given link 
params
+ * @intel_dp: Intel DP object
+ * @max_dprx_rate: Maximum data rate of the DPRX
+ * @max_dprx_lanes: Maximum lane count of the DPRX
+ *
+ * Calculate the maximum data rate for the provided link parameters.
+ *
+ * Returns the maximum data rate in kBps units.
+ */
+int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
+   int max_dprx_rate, int max_dprx_lanes)
+{
+   return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes);
+}
+
 bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -612,7 +628,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct 
intel_dp *intel_dp,
int mode_rate, max_rate;
 
mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
-   max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
+   max_rate = intel_dp_max_link_data_rate(intel_dp, link_rate, lane_count);
if (mode_rate > max_rate)
return false;
 
@@ -1216,7 +1232,8 @@ intel_dp_mode_valid(struct drm_connector *_connector,
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
 
-   max_rate = drm_dp_max_dprx_data_rate(max_link_clock, max_lanes);
+   max_rate = intel_dp_max_link_data_rate(intel_dp, max_link_clock, 
max_lanes);
+
mode_rate = intel_dp_link_required(target_clock,
   
intel_dp_mode_min_output_bpp(connector, mode));
 
@@ -1566,8 +1583,10 @@ intel_dp_compute_link_config_wide(struct intel_dp 
*intel_dp,
for (lane_count = limits->min_lane_count;
 lane_count <= limits->max_lane_count;
 lane_count <<= 1) {
-   link_avail = 
drm_dp_max_dprx_data_rate(link_rate,
-  
lane_count);
+   link_avail = 
intel_dp_max_link_data_rate(intel_dp,
+
link_rate,
+
lane_count);
+
 
if (mode_rate <= link_avail) {
pipe_config->lane_count = lane_count;
@@ -2427,8 +2446,9 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
pipe_config->pipe_bpp,
BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
intel_dp_config_required_rate(pipe_config),
-   drm_dp_max_dprx_data_rate(pipe_config->port_clock,
- pipe_config->lane_count));
+   intel_dp_max_link_data_rate(intel_dp,
+   pipe_config->port_clock,
+   pipe_config->lane_count));
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 10e859b62bbe9..564a587e2d018 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -115,6 +115,8 @@ bool intel_dp_get_colorimetry_status(struct intel_dp 
*intel_dp);
 int intel_dp_link_required(int pixel_clock, int bpp);
 int intel_dp_effective_data_rate(int pixel_clock, int bpp_x16,
 int bw_overhead);
+int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
+   int max_dprx_rate, int max_dprx_lanes);
 bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp);
 bool intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index b4d4bb90126e9..4b6c8ff974297 100644
--- 

[PATCH v2 07/21] drm/i915/dp: Export intel_dp_max_common_rate/lane_count()

2024-02-20 Thread Imre Deak
Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by
a follow-up patch enabling the DP tunnel BW allocation mode.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
 drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c7e3e4efc324e..20e04cbdffcae 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -309,7 +309,7 @@ static int intel_dp_common_rate(struct intel_dp *intel_dp, 
int index)
 }
 
 /* Theoretical max between source and sink */
-static int intel_dp_max_common_rate(struct intel_dp *intel_dp)
+int intel_dp_max_common_rate(struct intel_dp *intel_dp)
 {
return intel_dp_common_rate(intel_dp, intel_dp->num_common_rates - 1);
 }
@@ -326,7 +326,7 @@ static int intel_dp_max_source_lane_count(struct 
intel_digital_port *dig_port)
 }
 
 /* Theoretical max between source and sink */
-static int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
+int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
int source_max = intel_dp_max_source_lane_count(dig_port);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 4667870fed31a..ee0600b4425e1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -102,6 +102,8 @@ int intel_dp_max_link_rate(struct intel_dp *intel_dp);
 int intel_dp_max_lane_count(struct intel_dp *intel_dp);
 int intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state);
 int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
+int intel_dp_max_common_rate(struct intel_dp *intel_dp);
+int intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
 
 void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
   u8 *link_bw, u8 *rate_select);
-- 
2.39.2



[PATCH v2 03/21] drm/i915: Fix display bpp limit computation during system resume

2024-02-20 Thread Imre Deak
The system resume display mode restoration should happen with an output
configuration matching that of the suspend time saved mode. Since the
restored mode configuration is subject to the bpp fallback logic,
starting out with an unlimited bpp and reducing the bpp as required by
any (MST) link BW limit, the resulting bpp will match the one during
suspend only if the BW limit checks during suspend and resume are
applied in an identical way. The latter is not guaranteed at the moment,
since the pre-suspend MST topology may not be in place during resume
(for instance if the MST sink was disconnected while being suspended),
which makes the MST link BW check accept the unlimited bpp mode
configuration unconditionally without ensuring that the required BW fits
into the available MST link BW.

To fix the above, initialize the bpp fallback logic with the max link
bpp / force-FEC limits left behind by the suspend time mode save.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_display.c |  3 +--
 drivers/gpu/drm/i915/display/intel_link_bw.c | 22 
 drivers/gpu/drm/i915/display/intel_link_bw.h |  2 +-
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 00ac65a140298..485c38d71f106 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6252,12 +6252,11 @@ static int intel_atomic_check_config(struct 
intel_atomic_state *state,
 
 static int intel_atomic_check_config_and_link(struct intel_atomic_state *state)
 {
-   struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_link_bw_limits new_limits;
struct intel_link_bw_limits old_limits;
int ret;
 
-   intel_link_bw_init_limits(i915, _limits);
+   intel_link_bw_init_limits(state, _limits);
old_limits = new_limits;
 
while (true) {
diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c 
b/drivers/gpu/drm/i915/display/intel_link_bw.c
index 9c6d35a405a18..27ea858897c9f 100644
--- a/drivers/gpu/drm/i915/display/intel_link_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
@@ -6,6 +6,7 @@
 #include "i915_drv.h"
 
 #include "intel_atomic.h"
+#include "intel_crtc.h"
 #include "intel_display_types.h"
 #include "intel_dp_mst.h"
 #include "intel_fdi.h"
@@ -13,19 +14,32 @@
 
 /**
  * intel_link_bw_init_limits - initialize BW limits
- * @i915: device instance
+ * @state: Atomic state
  * @limits: link BW limits
  *
  * Initialize @limits.
  */
-void intel_link_bw_init_limits(struct drm_i915_private *i915, struct 
intel_link_bw_limits *limits)
+void intel_link_bw_init_limits(struct intel_atomic_state *state,
+  struct intel_link_bw_limits *limits)
 {
+   struct drm_i915_private *i915 = to_i915(state->base.dev);
enum pipe pipe;
 
limits->force_fec_pipes = 0;
limits->bpp_limit_reached_pipes = 0;
-   for_each_pipe(i915, pipe)
-   limits->max_bpp_x16[pipe] = INT_MAX;
+   for_each_pipe(i915, pipe) {
+   const struct intel_crtc_state *crtc_state =
+   intel_atomic_get_new_crtc_state(state,
+   
intel_crtc_for_pipe(i915, pipe));
+
+   if (state->base.duplicated && crtc_state) {
+   limits->max_bpp_x16[pipe] = 
crtc_state->max_link_bpp_x16;
+   if (crtc_state->fec_enable)
+   limits->force_fec_pipes |= BIT(pipe);
+   } else {
+   limits->max_bpp_x16[pipe] = INT_MAX;
+   }
+   }
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.h 
b/drivers/gpu/drm/i915/display/intel_link_bw.h
index 2cf57307cc249..6b0ccfff59dab 100644
--- a/drivers/gpu/drm/i915/display/intel_link_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_link_bw.h
@@ -22,7 +22,7 @@ struct intel_link_bw_limits {
int max_bpp_x16[I915_MAX_PIPES];
 };
 
-void intel_link_bw_init_limits(struct drm_i915_private *i915,
+void intel_link_bw_init_limits(struct intel_atomic_state *state,
   struct intel_link_bw_limits *limits);
 int intel_link_bw_reduce_bpp(struct intel_atomic_state *state,
 struct intel_link_bw_limits *limits,
-- 
2.39.2



[PATCH v2 06/21] drm/i915/dp: Factor out intel_dp_config_required_rate()

2024-02-20 Thread Imre Deak
Factor out intel_dp_config_required_rate() used by a follow-up patch
enabling the DP tunnel BW allocation mode.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 43 +++--
 drivers/gpu/drm/i915/display/intel_dp.h |  1 +
 2 files changed, 20 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a2ee43392142..c7e3e4efc324e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2343,6 +2343,17 @@ intel_dp_compute_config_limits(struct intel_dp *intel_dp,
   limits);
 }
 
+int intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state)
+{
+   const struct drm_display_mode *adjusted_mode =
+   _state->hw.adjusted_mode;
+   int bpp = crtc_state->dsc.compression_enable ?
+   to_bpp_int_roundup(crtc_state->dsc.compressed_bpp_x16) :
+   crtc_state->pipe_bpp;
+
+   return intel_dp_link_required(adjusted_mode->crtc_clock, bpp);
+}
+
 static int
 intel_dp_compute_link_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config,
@@ -2410,31 +2421,15 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
return ret;
}
 
-   if (pipe_config->dsc.compression_enable) {
-   drm_dbg_kms(>drm,
-   "DP lane count %d clock %d Input bpp %d Compressed 
bpp " BPP_X16_FMT "\n",
-   pipe_config->lane_count, pipe_config->port_clock,
-   pipe_config->pipe_bpp,
-   BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16));
+   drm_dbg_kms(>drm,
+   "DP lane count %d clock %d bpp input %d compressed " 
BPP_X16_FMT " link rate required %d available %d\n",
+   pipe_config->lane_count, pipe_config->port_clock,
+   pipe_config->pipe_bpp,
+   BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
+   intel_dp_config_required_rate(pipe_config),
+   drm_dp_max_dprx_data_rate(pipe_config->port_clock,
+ pipe_config->lane_count));
 
-   drm_dbg_kms(>drm,
-   "DP link rate required %i available %i\n",
-   intel_dp_link_required(adjusted_mode->crtc_clock,
-  
to_bpp_int_roundup(pipe_config->dsc.compressed_bpp_x16)),
-   drm_dp_max_dprx_data_rate(pipe_config->port_clock,
- pipe_config->lane_count));
-   } else {
-   drm_dbg_kms(>drm, "DP lane count %d clock %d bpp %d\n",
-   pipe_config->lane_count, pipe_config->port_clock,
-   pipe_config->pipe_bpp);
-
-   drm_dbg_kms(>drm,
-   "DP link rate required %i available %i\n",
-   intel_dp_link_required(adjusted_mode->crtc_clock,
-  pipe_config->pipe_bpp),
-   drm_dp_max_dprx_data_rate(pipe_config->port_clock,
- pipe_config->lane_count));
-   }
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 20252984b3b04..4667870fed31a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -100,6 +100,7 @@ void intel_dp_mst_suspend(struct drm_i915_private 
*dev_priv);
 void intel_dp_mst_resume(struct drm_i915_private *dev_priv);
 int intel_dp_max_link_rate(struct intel_dp *intel_dp);
 int intel_dp_max_lane_count(struct intel_dp *intel_dp);
+int intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state);
 int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
 
 void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
-- 
2.39.2



[PATCH v2 04/21] drm/i915/dp: Add support to notify MST connectors to retry modesets

2024-02-20 Thread Imre Deak
On shared (Thunderbolt) links with DP tunnels, the modeset may need to
be retried on all connectors on the link due to a link BW limitation
arising only after the atomic check phase. To support this add a helper
function queuing a work to retry the modeset on a given port's connector
and at the same time any MST connector with streams through the same
port. A follow-up change enabling the DP tunnel Bandwidth Allocation
Mode will take this into use.

v2:
- Send the uevent only to enabled MST connectors. (Jouni)

Cc: Jouni Högander 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  5 ++-
 drivers/gpu/drm/i915/display/intel_dp.c   | 45 ++-
 drivers/gpu/drm/i915/display/intel_dp.h   |  6 +++
 .../drm/i915/display/intel_dp_link_training.c |  3 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +
 5 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 485c38d71f106..2ee26d19c200b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8085,8 +8085,9 @@ void intel_hpd_poll_fini(struct drm_i915_private *i915)
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(>drm, _iter);
for_each_intel_connector_iter(connector, _iter) {
-   if (connector->modeset_retry_work.func)
-   cancel_work_sync(>modeset_retry_work);
+   if (connector->modeset_retry_work.func &&
+   cancel_work_sync(>modeset_retry_work))
+   drm_connector_put(>base);
if (connector->hdcp.shim) {
cancel_delayed_work_sync(>hdcp.check_work);
cancel_work_sync(>hdcp.prop_work);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 217196196e50a..88606e336a920 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2842,6 +2842,40 @@ intel_dp_audio_compute_config(struct intel_encoder 
*encoder,
intel_dp_is_uhbr(pipe_config);
 }
 
+void intel_dp_queue_modeset_retry_work(struct intel_connector *connector)
+{
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
+
+   drm_connector_get(>base);
+   if (!queue_work(i915->unordered_wq, >modeset_retry_work))
+   drm_connector_put(>base);
+}
+
+void
+intel_dp_queue_modeset_retry_for_link(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+   struct intel_connector *connector;
+   struct intel_digital_connector_state *conn_state;
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   int i;
+
+   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
+   intel_dp_queue_modeset_retry_work(intel_dp->attached_connector);
+
+   return;
+   }
+
+   for_each_new_intel_connector_in_state(state, connector, conn_state, i) {
+   if (!conn_state->base.crtc)
+   continue;
+
+   if (connector->mst_port == intel_dp)
+   intel_dp_queue_modeset_retry_work(connector);
+   }
+}
+
 int
 intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -6441,6 +6475,14 @@ static void intel_dp_modeset_retry_work_fn(struct 
work_struct *work)
mutex_unlock(>dev->mode_config.mutex);
/* Send Hotplug uevent so userspace can reprobe */
drm_kms_helper_connector_hotplug_event(connector);
+
+   drm_connector_put(connector);
+}
+
+void intel_dp_init_modeset_retry_work(struct intel_connector *connector)
+{
+   INIT_WORK(>modeset_retry_work,
+ intel_dp_modeset_retry_work_fn);
 }
 
 bool
@@ -6457,8 +6499,7 @@ intel_dp_init_connector(struct intel_digital_port 
*dig_port,
int type;
 
/* Initialize the work for modeset in case of link train failure */
-   INIT_WORK(_connector->modeset_retry_work,
- intel_dp_modeset_retry_work_fn);
+   intel_dp_init_modeset_retry_work(intel_connector);
 
if (drm_WARN(dev, dig_port->max_lanes < 1,
 "Not enough lanes (%d) for DP on [ENCODER:%d:%s]\n",
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 530cc97bc42f4..e2875e03afba0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -43,6 +43,12 @@ void intel_dp_adjust_compliance_config(struct intel_dp 
*intel_dp,
 bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
  const struct drm_connector_state 

[PATCH v2 05/21] drm/i915/dp: Use drm_dp_max_dprx_data_rate()

2024-02-20 Thread Imre Deak
Instead of intel_dp_max_data_rate() use the equivalent
drm_dp_max_dprx_data_rate() which was copied from the former one in a
previous patch.

Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c  | 62 +++-
 drivers/gpu/drm/i915/display/intel_dp.h  |  1 -
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  2 +-
 4 files changed, 10 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 2ee26d19c200b..e1a4200f67a7e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2478,7 +2478,7 @@ intel_link_compute_m_n(u16 bits_per_pixel_x16, int nlanes,
u32 link_symbol_clock = intel_dp_link_symbol_clock(link_clock);
u32 data_m = intel_dp_effective_data_rate(pixel_clock, 
bits_per_pixel_x16,
  bw_overhead);
-   u32 data_n = intel_dp_max_data_rate(link_clock, nlanes);
+   u32 data_n = drm_dp_max_dprx_data_rate(link_clock, nlanes);
 
/*
 * Windows/BIOS uses fixed M/N values always. Follow suit.
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 88606e336a920..0a2ee43392142 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -383,52 +383,6 @@ int intel_dp_effective_data_rate(int pixel_clock, int 
bpp_x16,
100 * 16 * 8);
 }
 
-/*
- * Given a link rate and lanes, get the data bandwidth.
- *
- * Data bandwidth is the actual payload rate, which depends on the data
- * bandwidth efficiency and the link rate.
- *
- * For 8b/10b channel encoding, SST and non-FEC, the data bandwidth efficiency
- * is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80 * (1/8) =
- * 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol clock. Just by
- * coincidence, the port clock in kHz matches the data bandwidth in kBps, and
- * they equal the link bit rate in Gbps multiplied by 10. (Note that this 
no
- * longer holds for data bandwidth as soon as FEC or MST is taken into 
account!)
- *
- * For 128b/132b channel encoding, the data bandwidth efficiency is 96.71%. For
- * example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) = 1208875
- * kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The value 
100
- * does not match the symbol clock, the port clock (not even if you think in
- * terms of a byte clock), nor the data bandwidth. It only matches the link bit
- * rate in units of 1 bps.
- */
-int
-intel_dp_max_data_rate(int max_link_rate, int max_lanes)
-{
-   int ch_coding_efficiency =
-   
drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_rate));
-   int max_link_rate_kbps = max_link_rate * 10;
-
-   /*
-* UHBR rates always use 128b/132b channel encoding, and have
-* 97.71% data bandwidth efficiency. Consider max_link_rate the
-* link bit rate in units of 1 bps.
-*/
-   /*
-* Lower than UHBR rates always use 8b/10b channel encoding, and have
-* 80% data bandwidth efficiency for SST non-FEC. However, this turns
-* out to be a nop by coincidence:
-*
-*  int max_link_rate_kbps = max_link_rate * 10;
-*  max_link_rate_kbps = DIV_ROUND_DOWN_ULL(max_link_rate_kbps * 8, 
10);
-*  max_link_rate = max_link_rate_kbps / 8;
-*/
-   return DIV_ROUND_DOWN_ULL(mul_u32_u32(max_link_rate_kbps * max_lanes,
- ch_coding_efficiency),
- 100 * 8);
-}
-
 bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -658,7 +612,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct 
intel_dp *intel_dp,
int mode_rate, max_rate;
 
mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
-   max_rate = intel_dp_max_data_rate(link_rate, lane_count);
+   max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
if (mode_rate > max_rate)
return false;
 
@@ -1262,7 +1216,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
 
-   max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
+   max_rate = drm_dp_max_dprx_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock,
   
intel_dp_mode_min_output_bpp(connector, mode));
 
@@ -1612,8 +1566,8 @@ intel_dp_compute_link_config_wide(struct intel_dp 
*intel_dp,
for (lane_count = limits->min_lane_count;
 

[PATCH v2 01/21] drm/dp: Add drm_dp_max_dprx_data_rate()

2024-02-20 Thread Imre Deak
Copy intel_dp_max_data_rate() to DRM core. It will be needed by a
follow-up DP tunnel patch, checking the maximum rate the DPRX (sink)
supports. Accordingly use the drm_dp_max_dprx_data_rate() name for
clarity. This patchset will also switch calling the new DRM function
in i915 instead of intel_dp_max_data_rate().

While at it simplify the function documentation/comments, removing
parts described already by drm_dp_bw_channel_coding_efficiency().

v2: (Ville)
- Remove max_link_rate_kbps.
- Simplify the function documentation.

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/display/drm_dp_helper.c | 30 +
 include/drm/display/drm_dp_helper.h |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae6..d046dfa79504f 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -4055,3 +4055,33 @@ int drm_dp_bw_channel_coding_efficiency(bool is_uhbr)
return 80;
 }
 EXPORT_SYMBOL(drm_dp_bw_channel_coding_efficiency);
+
+/**
+ * drm_dp_max_dprx_data_rate - Get the max data bandwidth of a DPRX sink
+ * @max_link_rate: max DPRX link rate in 10kbps units
+ * @max_lanes: max DPRX lane count
+ *
+ * Given a link rate and lanes, get the data bandwidth.
+ *
+ * Data bandwidth is the actual payload rate, which depends on the data
+ * bandwidth efficiency and the link rate.
+ *
+ * Note that protocol layers above the DPRX link level considered here can
+ * further limit the maximum data rate. Such layers are the MST topology (with
+ * limits on the link between the source and first branch device as well as on
+ * the whole MST path until the DPRX link) and (Thunderbolt) DP tunnels -
+ * which in turn can encapsulate an MST link with its own limit - with each
+ * SST or MST encapsulated tunnel sharing the BW of a tunnel group.
+ *
+ * Returns the maximum data rate in kBps units.
+ */
+int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes)
+{
+   int ch_coding_efficiency =
+   
drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_rate));
+
+   return DIV_ROUND_DOWN_ULL(mul_u32_u32(max_link_rate * 10 * max_lanes,
+ ch_coding_efficiency),
+ 100 * 8);
+}
+EXPORT_SYMBOL(drm_dp_max_dprx_data_rate);
diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index d02014a87f127..65dae9a9f2fb6 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -812,4 +812,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
   int bpp_x16, unsigned long flags);
 int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
 
+int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes);
+
 #endif /* _DRM_DP_HELPER_H_ */
-- 
2.39.2



[PATCH v2 02/21] drm/dp: Add support for DP tunneling

2024-02-20 Thread Imre Deak
Add support for Display Port tunneling. For now this includes the
support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay
support for later.

BWA allows using displays that share the same (Thunderbolt) link with
their maximum resolution. Atm, this may not be possible due to the
coarse granularity of partitioning the link BW among the displays on the
link: the BW allocation policy is in a SW/FW/HW component on the link
(on Thunderbolt it's the SW or FW Connection Manager), independent of
the driver. This policy will set the DPRX maximum rate and lane count
DPCD registers the GFX driver will see (0x0, 0x1, 0x02200,
0x02201) based on the available link BW.

The granularity of the current BW allocation policy is coarse, based on
the required link rate in the 1.62Gbs..8.1Gbps range and it may prevent
using higher resolutions all together: the display connected first will
get a share of the link BW which corresponds to its full DPRX capability
(regardless of the actual mode it uses). A subsequent display connected
will only get the remaining BW, which could be well below its full
capability.

BWA solves the above coarse granularity (reducing it to a 250Mbs..1Gps
range) and first-come/first-served issues by letting the driver request
the BW for each display on a link which reflects the actual modes the
displays use.

This patch adds the DRM core helper functions, while a follow-up change
in the patchset takes them into use in the i915 driver.

v2:
- Fix prepare_to_wait vs. wake-up cond check order in
  allocate_tunnel_bw(). (Ville)
- Move tunnel==NULL checks from callers in drivers to here. (Ville)
- Avoid var inits in declaration blocks that can fail or have
  side-effects. (Ville)
- Use u8 for driver and group IDs. (Ville)
- Simplify API removing drm_dp_tunnel_get/put_untracked(). (Ville)
- Reuse str_yes_no() instead of a local yes_no_chr(). (Ville)
- s/drm_dp_tunnel_atomic_clear_state()/free_tunnel_state() and unexport
  the function. (Ville)
- s/clear_tunnel_group_state()/free_group_state() and move kfree() to
  this function. (Ville)
- Add separate group_free_bw() helper and describe what the tunnel
  estimated BW includes. (Ville)
- Improve help text for CONFIG_DRM_DISPLAY_DP_TUNNEL. (Ville)
- Add code comment explaining the purpose of DPCD reg read helpers.
  (Ville)
- Add code comment describing the tunnel group name prefix format.
  (Ville)
- Report the allocated BW as undetermined until the first allocation
  request.
- Skip allocation requests matching the previous request.
- Clear any stale BW request status flags before a new request.
- Add missing error return check of drm_dp_tunnel_atomic_get_group_state()
  in drm_dp_tunnel_atomic_set_stream_bw().
- Add drm_dp_tunnel_get_allocated_bw().
- s/drm_dp_tunnel_atomic_get_tunnel_bw/drm_dp_tunnel_atomic_get_required_bw
- Fix return value description in function doc of drm_dp_tunnel_detect().
- Add function documentation to all exported functions.

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/display/Kconfig |   21 +
 drivers/gpu/drm/display/Makefile|2 +
 drivers/gpu/drm/display/drm_dp_tunnel.c | 1929 +++
 include/drm/display/drm_dp.h|   60 +
 include/drm/display/drm_dp_tunnel.h |  248 +++
 5 files changed, 2260 insertions(+)
 create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c
 create mode 100644 include/drm/display/drm_dp_tunnel.h

diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig
index 09712b88a5b83..c0f56888c3280 100644
--- a/drivers/gpu/drm/display/Kconfig
+++ b/drivers/gpu/drm/display/Kconfig
@@ -17,6 +17,27 @@ config DRM_DISPLAY_DP_HELPER
help
  DRM display helpers for DisplayPort.
 
+config DRM_DISPLAY_DP_TUNNEL
+   bool
+   select DRM_DISPLAY_DP_HELPER
+   help
+ Enable support for DisplayPort tunnels. This allows drivers to use
+ DP tunnel features like the Bandwidth Allocation mode to maximize the
+ BW utilization for display streams on Thunderbolt links.
+
+config DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE
+   bool "Enable debugging the DP tunnel state"
+   depends on REF_TRACKER
+   depends on DRM_DISPLAY_DP_TUNNEL
+   depends on DEBUG_KERNEL
+   depends on EXPERT
+   help
+ Enables debugging the DP tunnel manager's state, including the
+ consistency of all managed tunnels' reference counting and the state 
of
+ streams contained in tunnels.
+
+ If in doubt, say "N".
+
 config DRM_DISPLAY_HDCP_HELPER
bool
depends on DRM_DISPLAY_HELPER
diff --git a/drivers/gpu/drm/display/Makefile b/drivers/gpu/drm/display/Makefile
index 17ac4a1006a80..7ca61333c6696 100644
--- a/drivers/gpu/drm/display/Makefile
+++ b/drivers/gpu/drm/display/Makefile
@@ -8,6 +8,8 @@ drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER) += \
drm_dp_helper.o \
drm_dp_mst_topology.o \
drm_dsc_helper.o

[PATCH v2 00/21] drm/i915: Add Display Port tunnel BW allocation support

2024-02-20 Thread Imre Deak
This is v2 of [1], with the following changes:

- Several functional/typo/formatting fixes, detailed in the patches.
- Move the BW allocation from encoder hooks to
  intel_atomic_commit_tail() fixing the allocation for MST streams
  enabled/disabled w/o a full modeset (i.e. w/o re-enabling the master
  stream).
- Fix an MST mode restore issue during system resume, which also lead
  to a tunnel BW allocation failure. (Patch 3)
- Ensure a DPCD DPRX cap read as required by the TBT CM any time a long
  HPD pulse is detected. (Patch 20)
- Explicitly disable the BW allocation mode during system suspend.

The patchset is also available at:
https://github.com/ideak/linux/commits/dp_tun_bw_alloc

Cc: Mika Westerberg 
Cc: Ville Syrjälä 
Cc: Uma Shankar 
Cc: Jouni Högander 
Cc: Saranya Gopal 
Cc: Rajaram Regupathy 
Cc: Gil Fine 
Cc: Naama Shachar 
Cc: Pengfei Xu 

[1] https://lore.kernel.org/all/20240123102850.390126-1-imre.d...@intel.com

Imre Deak (21):
  drm/dp: Add drm_dp_max_dprx_data_rate()
  drm/dp: Add support for DP tunneling
  drm/i915: Fix display bpp limit computation during system resume
  drm/i915/dp: Add support to notify MST connectors to retry modesets
  drm/i915/dp: Use drm_dp_max_dprx_data_rate()
  drm/i915/dp: Factor out intel_dp_config_required_rate()
  drm/i915/dp: Export intel_dp_max_common_rate/lane_count()
  drm/i915/dp: Factor out intel_dp_update_sink_caps()
  drm/i915/dp: Factor out intel_dp_read_dprx_caps()
  drm/i915/dp: Add intel_dp_max_link_data_rate()
  drm/i915/dp: Add way to get active pipes with syncing commits
  drm/i915/dp: Add support for DP tunnel BW allocation
  drm/i915/dp: Add DP tunnel atomic state and check BW limit
  drm/i915/dp: Account for tunnel BW limit in
intel_dp_max_link_data_rate()
  drm/i915/dp: Compute DP tunnel BW during encoder state computation
  drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable
hooks
  drm/i915/dp: Handle DP tunnel IRQs
  drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders
  drm/i915/dp: Suspend/resume DP tunnels
  drm/i915/dp: Read DPRX for all long HPD pulses
  drm/i915/dp: Enable DP tunnel BW allocation mode

 drivers/gpu/drm/display/Kconfig   |   21 +
 drivers/gpu/drm/display/Makefile  |2 +
 drivers/gpu/drm/display/drm_dp_helper.c   |   30 +
 drivers/gpu/drm/display/drm_dp_tunnel.c   | 1929 +
 drivers/gpu/drm/i915/Kconfig  |   14 +
 drivers/gpu/drm/i915/Kconfig.debug|1 +
 drivers/gpu/drm/i915/Makefile |3 +
 drivers/gpu/drm/i915/display/intel_atomic.c   |   10 +
 drivers/gpu/drm/i915/display/intel_crtc.c |   52 +
 drivers/gpu/drm/i915/display/intel_crtc.h |2 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |3 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   26 +-
 .../gpu/drm/i915/display/intel_display_core.h |1 +
 .../drm/i915/display/intel_display_driver.c   |   20 +-
 .../drm/i915/display/intel_display_types.h|9 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  292 ++-
 drivers/gpu/drm/i915/display/intel_dp.h   |   13 +-
 .../drm/i915/display/intel_dp_link_training.c |   33 +-
 .../drm/i915/display/intel_dp_link_training.h |1 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   18 +-
 .../gpu/drm/i915/display/intel_dp_tunnel.c|  815 +++
 .../gpu/drm/i915/display/intel_dp_tunnel.h|  133 ++
 drivers/gpu/drm/i915/display/intel_link_bw.c  |   27 +-
 drivers/gpu/drm/i915/display/intel_link_bw.h  |2 +-
 drivers/gpu/drm/i915/display/intel_tc.c   |7 +
 include/drm/display/drm_dp.h  |   61 +
 include/drm/display/drm_dp_helper.h   |2 +
 include/drm/display/drm_dp_tunnel.h   |  248 +++
 28 files changed, 3650 insertions(+), 125 deletions(-)
 create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h
 create mode 100644 include/drm/display/drm_dp_tunnel.h

-- 
2.39.2



[PATCH v1] drivers/i915/intel_bios: Fix parsing backlight BDB data

2024-02-20 Thread Karthikeyan Ramasubramanian
Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to
backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB
contents") updated the backlight BDB data accordingly. This broke the
parsing of backlight BDB data in VBT for versions 236 - 238 (both
inclusive) and hence the backlight controls are not responding on units
with the concerned BDB version.

backlight_control information has been present in backlight BDB data
from at least BDB version 191 onwards, if not before. Hence this patch
extracts the backlight_control information if the block size of
backlight BDB is >= version 191 backlight BDB block size.
Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236).
Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251).

Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents")
Cc: sta...@vger.kernel.org
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Karthikeyan Ramasubramanian 
---

 drivers/gpu/drm/i915/display/intel_bios.c | 22 +--
 drivers/gpu/drm/i915/display/intel_vbt_defs.h |  2 --
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index aa169b0055e97..4ec50903b9e64 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1041,23 +1041,13 @@ parse_lfp_backlight(struct drm_i915_private *i915,
 
panel->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
panel->vbt.backlight.controller = 0;
-   if (i915->display.vbt.version >= 191) {
-   size_t exp_size;
+   if (i915->display.vbt.version >= 191 &&
+   get_blocksize(backlight_data) >= EXP_BDB_LFP_BL_DATA_SIZE_REV_191) {
+   const struct lfp_backlight_control_method *method;
 
-   if (i915->display.vbt.version >= 236)
-   exp_size = sizeof(struct bdb_lfp_backlight_data);
-   else if (i915->display.vbt.version >= 234)
-   exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
-   else
-   exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_191;
-
-   if (get_blocksize(backlight_data) >= exp_size) {
-   const struct lfp_backlight_control_method *method;
-
-   method = _data->backlight_control[panel_type];
-   panel->vbt.backlight.type = method->type;
-   panel->vbt.backlight.controller = method->controller;
-   }
+   method = _data->backlight_control[panel_type];
+   panel->vbt.backlight.type = method->type;
+   panel->vbt.backlight.controller = method->controller;
}
 
panel->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index a9f44abfc9fc2..aeea5635a37ff 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -899,8 +899,6 @@ struct lfp_brightness_level {
 
 #define EXP_BDB_LFP_BL_DATA_SIZE_REV_191 \
offsetof(struct bdb_lfp_backlight_data, brightness_level)
-#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
-   offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
 
 struct bdb_lfp_backlight_data {
u8 entry_size;
-- 
2.44.0.rc0.258.g7320e95886-goog



Re: [PATCH v3 2/2] drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()

2024-02-20 Thread Dmitry Baryshkov
On Tue, 20 Feb 2024 at 21:54, Abhinav Kumar  wrote:
>
> Currently the size parameter of drm_dp_vsc_sdp_pack() is always
> the size of struct dp_sdp. Hence lets drop this parameter and
> use sizeof() directly.
>
> Suggested-by: Dmitry Baryshkov 
> Signed-off-by: Abhinav Kumar 
> ---
>  drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
>  drivers/gpu/drm/i915/display/intel_dp.c | 3 +--
>  include/drm/display/drm_dp_helper.h | 3 +--
>  3 files changed, 4 insertions(+), 10 deletions(-)

Thank you!

Acked-by: Dmitry Baryshkov 



-- 
With best wishes
Dmitry


[PATCH v3 1/2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Abhinav Kumar
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.

changes in v2:
- rebased on top of drm-tip

Acked-by: Dmitry Baryshkov 
Signed-off-by: Abhinav Kumar 
Acked-by: Jani Nikula 
---
 drivers/gpu/drm/display/drm_dp_helper.c | 78 +
 drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
 include/drm/display/drm_dp_helper.h |  3 +
 3 files changed, 83 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae..6c91f400ecb1 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,84 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const 
struct drm_dp_vsc_sdp *vsc)
 }
 EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
 
+/**
+ * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
+ * @vsc: vsc sdp initialized according to its purpose as defined in
+ *   table 2-118 - table 2-120 in DP 1.4a specification
+ * @sdp: valid handle to the generic dp_sdp which will be packed
+ * @size: valid size of the passed sdp handle
+ *
+ * Returns length of sdp on success and error code on failure
+ */
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
+   struct dp_sdp *sdp, size_t size)
+{
+   size_t length = sizeof(struct dp_sdp);
+
+   if (size < length)
+   return -ENOSPC;
+
+   memset(sdp, 0, size);
+
+   /*
+* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
+* VSC SDP Header Bytes
+*/
+   sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
+   sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
+   sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
+   sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+
+   if (vsc->revision == 0x6) {
+   sdp->db[0] = 1;
+   sdp->db[3] = 1;
+   }
+
+   /*
+* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
+* Format as per DP 1.4a spec and DP 2.0 respectively.
+*/
+   if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
+   goto out;
+
+   /* VSC SDP Payload for DB16 through DB18 */
+   /* Pixel Encoding and Colorimetry Formats  */
+   sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
+   sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
+
+   switch (vsc->bpc) {
+   case 6:
+   /* 6bpc: 0x0 */
+   break;
+   case 8:
+   sdp->db[17] = 0x1; /* DB17[3:0] */
+   break;
+   case 10:
+   sdp->db[17] = 0x2;
+   break;
+   case 12:
+   sdp->db[17] = 0x3;
+   break;
+   case 16:
+   sdp->db[17] = 0x4;
+   break;
+   default:
+   WARN(1, "Missing case %d\n", vsc->bpc);
+   return -EINVAL;
+   }
+
+   /* Dynamic Range and Component Bit Depth */
+   if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
+   sdp->db[17] |= 0x80;  /* DB17[7] */
+
+   /* Content Type */
+   sdp->db[18] = vsc->content_type & 0x7;
+
+out:
+   return length;
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_pack);
+
 /**
  * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
  * @dpcd: DisplayPort configuration data
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 217196196e50..a9458df475e2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4089,73 +4089,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state 
*crtc_state,
return false;
 }
 
-static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-struct dp_sdp *sdp, size_t size)
-{
-   size_t length = sizeof(struct dp_sdp);
-
-   if (size < length)
-   return -ENOSPC;
-
-   memset(sdp, 0, size);
-
-   /*
-* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
-* VSC SDP Header Bytes
-*/
-   sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
-   sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
-   sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
-   sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
-
-   if (vsc->revision == 0x6) {
-   sdp->db[0] = 1;
-   sdp->db[3] = 1;
-   }
-
-   /*
-* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
-* Format as per DP 1.4a spec and DP 2.0 respectively.
-*/
-   if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
-   goto out;
-
-   /* VSC SDP Payload for DB16 through DB18 */
-   /* Pixel Encoding and 

[PATCH v3 2/2] drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()

2024-02-20 Thread Abhinav Kumar
Currently the size parameter of drm_dp_vsc_sdp_pack() is always
the size of struct dp_sdp. Hence lets drop this parameter and
use sizeof() directly.

Suggested-by: Dmitry Baryshkov 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
 drivers/gpu/drm/i915/display/intel_dp.c | 3 +--
 include/drm/display/drm_dp_helper.h | 3 +--
 3 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 6c91f400ecb1..10ee82e34de7 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2918,19 +2918,15 @@ EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
  * @vsc: vsc sdp initialized according to its purpose as defined in
  *   table 2-118 - table 2-120 in DP 1.4a specification
  * @sdp: valid handle to the generic dp_sdp which will be packed
- * @size: valid size of the passed sdp handle
  *
  * Returns length of sdp on success and error code on failure
  */
 ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-   struct dp_sdp *sdp, size_t size)
+   struct dp_sdp *sdp)
 {
size_t length = sizeof(struct dp_sdp);
 
-   if (size < length)
-   return -ENOSPC;
-
-   memset(sdp, 0, size);
+   memset(sdp, 0, sizeof(struct dp_sdp));
 
/*
 * Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a9458df475e2..e13121dc3a03 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4181,8 +4181,7 @@ static void intel_write_dp_sdp(struct intel_encoder 
*encoder,
 
switch (type) {
case DP_SDP_VSC:
-   len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, ,
- sizeof(sdp));
+   len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, );
break;
case HDMI_PACKET_TYPE_GAMUT_METADATA:
len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index 8474504d4c88..1f41994796d3 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -812,7 +812,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
   int bpp_x16, unsigned long flags);
 int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
 
-ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-   struct dp_sdp *sdp, size_t size);
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc, struct dp_sdp 
*sdp);
 
 #endif /* _DRM_DP_HELPER_H_ */
-- 
2.34.1



Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170

2024-02-20 Thread John Harrison

On 2/19/2024 12:28, Rodrigo Vivi wrote:

On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:

From: John Harrison 

The above w/a is required for every platform that the i915 driver
supports. It is fixed on the latest platforms but they are only
supported by Xe instead of i915. So just remove the platform check
completely and keep the code simple.

Well, I was going to say that I would prefer a GMD version greater-than
check to be future proof. However if this code gets used in some other
new platform a new specific guc support would likely need to be added
as well right?
There is no future for i915. That's the point. The only platforms that 
have the hardware fix are all ones that will only ever be supported by 
the Xe driver. So if such a platform were to be backported to i915 then 
there would be a lot more work than just adding a new GuC firmware platform.


And going backwards, the bug affects all platforms that have a GuC. So 
if any GuC code is being executed at all, then this w/a is applicable.




Perhaps at least adding a comment in the code?

Such as this?
    /*
 * Wa_14018913170: Applicable to all platforms supported by i915 so
 * don't bother testing for all X/Y/Z platforms explicitly.
 */

John.




with that
Reviewed-by: Rodrigo Vivi 



Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2b450c43bbd7f..a3662edb42032 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
  
  	/* Wa_14018913170 */

if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
-   if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) || 
IS_PONTEVECCHIO(gt->i915))
-   flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
+   flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
}
  
  	return flags;

--
2.43.0





Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Abhinav Kumar




On 2/20/2024 11:41 AM, Ville Syrjälä wrote:

On Tue, Feb 20, 2024 at 11:27:18AM -0800, Abhinav Kumar wrote:



On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote:

On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov
 wrote:


On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar  wrote:




On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:

On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  wrote:


intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.

changes in v2:
   - rebased on top of drm-tip

Acked-by: Dmitry Baryshkov 


v1 had an explicit comment before the ack:



Yes, I remember the comment. I did not make any changes to v2 other than
just rebasing it on drm-tip to get the ack from i915 folks.


  From my side, with the promise of the size fixup.


However I observe neither a second patch removing the size argument
nor it being dropped as a part of this patch.



Yes, now that in v2 we got the ack for this patch, I can spin a v3 with
the addition of the next patch to remove the size OR as another series
so as to not block the main series which needs this patch.

I would prefer the latter.


It doesn't work this way. The comment should have been fixed for v2.


This probably deserves some explanation. Currently there is only one
user of this function. So it is easy to fix it. Once there are several
users, you have to fix all of them at the same time, patching
different drm subtrees. That complicates the life of maintainers.



Yes, understood. Its easier to fix it now if its really needed.

Actually, I think the reason the size was passed was to make sure
a valid struct dp_sdp *sdp was being passed.


The size is supposed to be the size of *hardware* buffer where this
gets written into. But looks like this wasn't done correctly when
the code was copy-pasted from the HDMI inforframe code.



Alright, in that case, let me post a patch to drop this and let me know 
if that works for you.


Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Ville Syrjälä
On Tue, Feb 20, 2024 at 11:27:18AM -0800, Abhinav Kumar wrote:
> 
> 
> On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote:
> > On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov
> >  wrote:
> >>
> >> On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar  
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
>  On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  
>  wrote:
> >
> > intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
> > Lets move this to drm_dp_helper to achieve this.
> >
> > changes in v2:
> >   - rebased on top of drm-tip
> >
> > Acked-by: Dmitry Baryshkov 
> 
>  v1 had an explicit comment before the ack:
> 
> >>>
> >>> Yes, I remember the comment. I did not make any changes to v2 other than
> >>> just rebasing it on drm-tip to get the ack from i915 folks.
> >>>
> >  From my side, with the promise of the size fixup.
> 
>  However I observe neither a second patch removing the size argument
>  nor it being dropped as a part of this patch.
> 
> >>>
> >>> Yes, now that in v2 we got the ack for this patch, I can spin a v3 with
> >>> the addition of the next patch to remove the size OR as another series
> >>> so as to not block the main series which needs this patch.
> >>>
> >>> I would prefer the latter.
> >>
> >> It doesn't work this way. The comment should have been fixed for v2.
> > 
> > This probably deserves some explanation. Currently there is only one
> > user of this function. So it is easy to fix it. Once there are several
> > users, you have to fix all of them at the same time, patching
> > different drm subtrees. That complicates the life of maintainers.
> > 
> 
> Yes, understood. Its easier to fix it now if its really needed.
> 
> Actually, I think the reason the size was passed was to make sure
> a valid struct dp_sdp *sdp was being passed.

The size is supposed to be the size of *hardware* buffer where this
gets written into. But looks like this wasn't done correctly when
the code was copy-pasted from the HDMI inforframe code.

-- 
Ville Syrjälä
Intel


Re: [PATCH 00/21] drm/i915: remove unused structure members

2024-02-20 Thread Rodrigo Vivi
On Fri, Feb 16, 2024 at 02:40:26PM +0200, Zhi Wang wrote:
> On Fri, 16 Feb 2024 10:51:20 +0200
> Jani Nikula  wrote:
> 
> > On Fri, 16 Feb 2024, "Jiri Slaby (SUSE)"  wrote:
> > > this series removes unused i915 structure members as found by
> > > clang-struct (and manually checked by me).
> > 
> > Thanks Jiri, good stuff!
> > 
> > Acked-by: Jani Nikula 
> > 
> > However, you may have overlooked that drivers/gpu/drm/i915/gvt/ is
> > maintained separately.
> > 
> > Cc: Zhenyu, Zhi, how do you want the gvt patches in this series
> > handled?
> > 
> 
> Many thanks for the clean-up patch Jiri! Jani, it would be easier
> for us that you can help to apply the patches through i915.

I pushed the entire series through drm-intel-next.
Thanks for the patches and acks.

> 
> Thanks,
> Zhi.
> 
> > 
> > BR,
> > Jani.
> > 
> > 
> > >
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: Jani Nikula 
> > > Cc: Joonas Lahtinen 
> > > Cc: Rodrigo Vivi 
> > > Cc: Tvrtko Ursulin 
> > >
> > > Jiri Slaby (SUSE) (21):
> > >   drm/i915: remove unused intel_dvo_dev_ops hooks
> > >   drm/i915: remove structs intel_vgpu_pipe_format and
> > > intel_vgpu_fb_format
> > >   drm/i915: remove intel_dsi::{port_bits,hs}
> > >   drm/i915: remove
> > > intel_gvt_gtt::{mm_alloc_page_table,mm_free_page_table}
> > >   drm/i915: remove intel_gvt_mmio_info::{device,addr_range}
> > >   drm/i915: remove
> > > intel_vgpu_workload::{ring_context,restore_inhibit} drm/i915:
> > > remove intel_vbt_panel_data::edp::initialized drm/i915: remove
> > > intel_guc::ads_engine_usage_size drm/i915: remove
> > > i915_drm_client::id drm/i915: remove i915_perf_stream::size_exponent
> > >   drm/i915: remove intel_vgpu_gtt::active_ppgtt_mm_bitmap
> > >   drm/i915: remove intel_vgpu_fence::base
> > >   drm/i915: remove intel_vgpu_opregion::mapped
> > >   drm/i915: remove intel_vgpu::intx_trigger
> > >   drm/i915: remove gvt_mmio_block::device
> > >   drm/i915: remove intel_gvt_irq_info::warned
> > >   drm/i915: remove intel_gvt_event_info::policy
> > >   drm/i915: remove intel_gvt_irq::pending_events
> > >   drm/i915: remove execute_cb::signal
> > >   drm/i915: remove i915_vma::obj_hash
> > >   drm/i915: remove intel_memory_region_ops::flags
> > >
> > >  .../drm/i915/display/intel_display_types.h|  1 -
> > >  drivers/gpu/drm/i915/display/intel_dsi.h  |  4 ---
> > >  drivers/gpu/drm/i915/display/intel_dvo_dev.h  | 25
> > > --- drivers/gpu/drm/i915/gt/uc/intel_guc.h|
> > >  2 -- drivers/gpu/drm/i915/gvt/fb_decoder.h | 11 
> > >  drivers/gpu/drm/i915/gvt/gtt.h|  3 ---
> > >  drivers/gpu/drm/i915/gvt/gvt.h|  5 
> > >  drivers/gpu/drm/i915/gvt/interrupt.c  |  1 -
> > >  drivers/gpu/drm/i915/gvt/interrupt.h  |  2 --
> > >  drivers/gpu/drm/i915/gvt/mmio.h   |  2 --
> > >  drivers/gpu/drm/i915/gvt/scheduler.h  |  2 --
> > >  drivers/gpu/drm/i915/i915_drm_client.h|  2 --
> > >  drivers/gpu/drm/i915/i915_perf_types.h|  1 -
> > >  drivers/gpu/drm/i915/i915_request.c   |  1 -
> > >  drivers/gpu/drm/i915/i915_vma_types.h |  1 -
> > >  drivers/gpu/drm/i915/intel_memory_region.h|  2 --
> > >  16 files changed, 65 deletions(-)
> > 
> 


Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Abhinav Kumar




On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote:

On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov
 wrote:


On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar  wrote:




On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:

On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  wrote:


intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.

changes in v2:
  - rebased on top of drm-tip

Acked-by: Dmitry Baryshkov 


v1 had an explicit comment before the ack:



Yes, I remember the comment. I did not make any changes to v2 other than
just rebasing it on drm-tip to get the ack from i915 folks.


 From my side, with the promise of the size fixup.


However I observe neither a second patch removing the size argument
nor it being dropped as a part of this patch.



Yes, now that in v2 we got the ack for this patch, I can spin a v3 with
the addition of the next patch to remove the size OR as another series
so as to not block the main series which needs this patch.

I would prefer the latter.


It doesn't work this way. The comment should have been fixed for v2.


This probably deserves some explanation. Currently there is only one
user of this function. So it is easy to fix it. Once there are several
users, you have to fix all of them at the same time, patching
different drm subtrees. That complicates the life of maintainers.



Yes, understood. Its easier to fix it now if its really needed.

Actually, I think the reason the size was passed was to make sure
a valid struct dp_sdp *sdp was being passed.

If we drop the size, we need to have a if (!sdp) check as there is a 
memset followed by dereference.


So maybe, if we want to keep this API protected, its not too bad to have?



Re: [PATCH] drm/i915/tv: Fix TV mode

2024-02-20 Thread Rodrigo Vivi
On Tue, Feb 20, 2024 at 08:06:01PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> > On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > > > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > > > to update all the users of the struct drm_tv_connector_state mode field,
> > > > which resulted in a build failure in i915.
> > > > 
> > > > However, a subsequent commit in the same series reintroduced a mode
> > > > field in that structure, with a different semantic but the same type,
> > > > with the assumption that all previous users were updated.
> > > > 
> > > > Since that didn't happen, the i915 driver now compiles, but mixes
> > > > accesses to the legacy_mode field and the newer mode field, but with the
> > > > previous semantics.
> > > > 
> > > > This obviously doesn't work very well, so we need to update the accesses
> > > > that weren't in the legacy renaming commit.
> > > > 
> > > > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > > > Reported-by: Ville Syrjälä 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > > >  drivers/gpu/drm/i915/display/intel_tv.c   | 10 +-
> > > >  2 files changed, 10 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
> > > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > index 825638702ac1..5f9e748adc89 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct 
> > > > intel_sdvo *intel_sdvo,
> > > > struct intel_sdvo_tv_format format;
> > > > u32 format_map;
> > > >  
> > > > -   format_map = 1 << conn_state->tv.mode;
> > > > +   format_map = 1 << conn_state->tv.legacy_mode;
> > > > memset(, 0, sizeof(format));
> > > > memcpy(, _map, min(sizeof(format), 
> > > > sizeof(format_map)));
> > > >  
> > > > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct 
> > > > drm_connector *connector)
> > > >  * Read the list of supported input resolutions for the 
> > > > selected TV
> > > >  * format.
> > > >  */
> > > > -   format_map = 1 << conn_state->tv.mode;
> > > > +   format_map = 1 << conn_state->tv.legacy_mode;
> > > > memcpy(_res, _map,
> > > >min(sizeof(format_map), sizeof(struct 
> > > > intel_sdvo_sdtv_resolution_request)));
> > > >  
> > > > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct 
> > > > drm_connector *connector,
> > > > int i;
> > > >  
> > > > for (i = 0; i < 
> > > > intel_sdvo_connector->format_supported_num; i++)
> > > > -   if (state->tv.mode == 
> > > > intel_sdvo_connector->tv_format_supported[i]) {
> > > > +   if (state->tv.legacy_mode == 
> > > > intel_sdvo_connector->tv_format_supported[i]) {
> > > > *val = i;
> > > >  
> > > > return 0;
> > > > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct 
> > > > drm_connector *connector,
> > > > struct intel_sdvo_connector_state *sdvo_state = 
> > > > to_intel_sdvo_connector_state(state);
> > > >  
> > > > if (property == intel_sdvo_connector->tv_format) {
> > > > -   state->tv.mode = 
> > > > intel_sdvo_connector->tv_format_supported[val];
> > > > +   state->tv.legacy_mode = 
> > > > intel_sdvo_connector->tv_format_supported[val];
> > > >  
> > > > if (state->crtc) {
> > > > struct drm_crtc_state *crtc_state =
> > > > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct 
> > > > intel_sdvo *intel_sdvo,
> > > > drm_property_add_enum(intel_sdvo_connector->tv_format, 
> > > > i,
> > > >   
> > > > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> > > >  
> > > > -   intel_sdvo_connector->base.base.state->tv.mode = 
> > > > intel_sdvo_connector->tv_format_supported[0];
> > > > +   intel_sdvo_connector->base.base.state->tv.legacy_mode = 
> > > > intel_sdvo_connector->tv_format_supported[0];
> > > > 
> > > > drm_object_attach_property(_sdvo_connector->base.base.base,
> > > >intel_sdvo_connector->tv_format, 0);
> > > > return true;
> > > 
> > > Hmm. I didn't realize we are using this in the SDVO code as well.
> > > I don't *think* that one is actually broken since it has its own
> > > .{set,get}_property() hooks. But I suppose doing the rename
> > > there as well is a good idea anyway.
> > > 
> > > Can you split the SDVO vs. TV into separate patches? We need to
> > > backport 

Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Dmitry Baryshkov
On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov
 wrote:
>
> On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar  wrote:
> >
> >
> >
> > On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
> > > On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  
> > > wrote:
> > >>
> > >> intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
> > >> Lets move this to drm_dp_helper to achieve this.
> > >>
> > >> changes in v2:
> > >>  - rebased on top of drm-tip
> > >>
> > >> Acked-by: Dmitry Baryshkov 
> > >
> > > v1 had an explicit comment before the ack:
> > >
> >
> > Yes, I remember the comment. I did not make any changes to v2 other than
> > just rebasing it on drm-tip to get the ack from i915 folks.
> >
> > >> From my side, with the promise of the size fixup.
> > >
> > > However I observe neither a second patch removing the size argument
> > > nor it being dropped as a part of this patch.
> > >
> >
> > Yes, now that in v2 we got the ack for this patch, I can spin a v3 with
> > the addition of the next patch to remove the size OR as another series
> > so as to not block the main series which needs this patch.
> >
> > I would prefer the latter.
>
> It doesn't work this way. The comment should have been fixed for v2.

This probably deserves some explanation. Currently there is only one
user of this function. So it is easy to fix it. Once there are several
users, you have to fix all of them at the same time, patching
different drm subtrees. That complicates the life of maintainers.

-- 
With best wishes
Dmitry


Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Dmitry Baryshkov
On Tue, 20 Feb 2024 at 21:09, Abhinav Kumar  wrote:
>
>
>
> On 2/20/2024 11:05 AM, Dmitry Baryshkov wrote:
> > On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar  
> > wrote:
> >>
> >>
> >>
> >> On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
> >>> On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  
> >>> wrote:
> 
>  intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
>  Lets move this to drm_dp_helper to achieve this.
> 
>  changes in v2:
>    - rebased on top of drm-tip
> 
>  Acked-by: Dmitry Baryshkov 
> >>>
> >>> v1 had an explicit comment before the ack:
> >>>
> >>
> >> Yes, I remember the comment. I did not make any changes to v2 other than
> >> just rebasing it on drm-tip to get the ack from i915 folks.
> >>
>   From my side, with the promise of the size fixup.
> >>>
> >>> However I observe neither a second patch removing the size argument
> >>> nor it being dropped as a part of this patch.
> >>>
> >>
> >> Yes, now that in v2 we got the ack for this patch, I can spin a v3 with
> >> the addition of the next patch to remove the size OR as another series
> >> so as to not block the main series which needs this patch.
> >>
> >> I would prefer the latter.
> >
> > It doesn't work this way. The comment should have been fixed for v2.
> >
>
> Ack, I can post a v3 now by adding the removal in patch 2 of this series.

Yes, please.

-- 
With best wishes
Dmitry


Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Abhinav Kumar




On 2/20/2024 11:05 AM, Dmitry Baryshkov wrote:

On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar  wrote:




On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:

On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  wrote:


intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.

changes in v2:
  - rebased on top of drm-tip

Acked-by: Dmitry Baryshkov 


v1 had an explicit comment before the ack:



Yes, I remember the comment. I did not make any changes to v2 other than
just rebasing it on drm-tip to get the ack from i915 folks.


 From my side, with the promise of the size fixup.


However I observe neither a second patch removing the size argument
nor it being dropped as a part of this patch.



Yes, now that in v2 we got the ack for this patch, I can spin a v3 with
the addition of the next patch to remove the size OR as another series
so as to not block the main series which needs this patch.

I would prefer the latter.


It doesn't work this way. The comment should have been fixed for v2.



Ack, I can post a v3 now by adding the removal in patch 2 of this series.






Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Dmitry Baryshkov
On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar  wrote:
>
>
>
> On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
> > On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  
> > wrote:
> >>
> >> intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
> >> Lets move this to drm_dp_helper to achieve this.
> >>
> >> changes in v2:
> >>  - rebased on top of drm-tip
> >>
> >> Acked-by: Dmitry Baryshkov 
> >
> > v1 had an explicit comment before the ack:
> >
>
> Yes, I remember the comment. I did not make any changes to v2 other than
> just rebasing it on drm-tip to get the ack from i915 folks.
>
> >> From my side, with the promise of the size fixup.
> >
> > However I observe neither a second patch removing the size argument
> > nor it being dropped as a part of this patch.
> >
>
> Yes, now that in v2 we got the ack for this patch, I can spin a v3 with
> the addition of the next patch to remove the size OR as another series
> so as to not block the main series which needs this patch.
>
> I would prefer the latter.

It doesn't work this way. The comment should have been fixed for v2.



-- 
With best wishes
Dmitry


Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Abhinav Kumar




On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:

On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  wrote:


intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.

changes in v2:
 - rebased on top of drm-tip

Acked-by: Dmitry Baryshkov 


v1 had an explicit comment before the ack:



Yes, I remember the comment. I did not make any changes to v2 other than 
just rebasing it on drm-tip to get the ack from i915 folks.



From my side, with the promise of the size fixup.


However I observe neither a second patch removing the size argument
nor it being dropped as a part of this patch.



Yes, now that in v2 we got the ack for this patch, I can spin a v3 with 
the addition of the next patch to remove the size OR as another series 
so as to not block the main series which needs this patch.


I would prefer the latter.


Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/display/drm_dp_helper.c | 78 +
  drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
  include/drm/display/drm_dp_helper.h |  3 +
  3 files changed, 83 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae..6c91f400ecb1 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,84 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const 
struct drm_dp_vsc_sdp *vsc)
  }
  EXPORT_SYMBOL(drm_dp_vsc_sdp_log);

+/**
+ * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
+ * @vsc: vsc sdp initialized according to its purpose as defined in
+ *   table 2-118 - table 2-120 in DP 1.4a specification
+ * @sdp: valid handle to the generic dp_sdp which will be packed
+ * @size: valid size of the passed sdp handle
+ *
+ * Returns length of sdp on success and error code on failure
+ */
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
+   struct dp_sdp *sdp, size_t size)
+{
+   size_t length = sizeof(struct dp_sdp);
+
+   if (size < length)
+   return -ENOSPC;
+
+   memset(sdp, 0, size);
+
+   /*
+* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
+* VSC SDP Header Bytes
+*/
+   sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
+   sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
+   sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
+   sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+
+   if (vsc->revision == 0x6) {
+   sdp->db[0] = 1;
+   sdp->db[3] = 1;
+   }
+
+   /*
+* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
+* Format as per DP 1.4a spec and DP 2.0 respectively.
+*/
+   if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
+   goto out;
+
+   /* VSC SDP Payload for DB16 through DB18 */
+   /* Pixel Encoding and Colorimetry Formats  */
+   sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
+   sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
+
+   switch (vsc->bpc) {
+   case 6:
+   /* 6bpc: 0x0 */
+   break;
+   case 8:
+   sdp->db[17] = 0x1; /* DB17[3:0] */
+   break;
+   case 10:
+   sdp->db[17] = 0x2;
+   break;
+   case 12:
+   sdp->db[17] = 0x3;
+   break;
+   case 16:
+   sdp->db[17] = 0x4;
+   break;
+   default:
+   WARN(1, "Missing case %d\n", vsc->bpc);
+   return -EINVAL;
+   }
+
+   /* Dynamic Range and Component Bit Depth */
+   if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
+   sdp->db[17] |= 0x80;  /* DB17[7] */
+
+   /* Content Type */
+   sdp->db[18] = vsc->content_type & 0x7;
+
+out:
+   return length;
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_pack);
+
  /**
   * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
   * @dpcd: DisplayPort configuration data
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 217196196e50..a9458df475e2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4089,73 +4089,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state 
*crtc_state,
 return false;
  }

-static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-struct dp_sdp *sdp, size_t size)
-{
-   size_t length = sizeof(struct dp_sdp);
-
-   if (size < length)
-   return -ENOSPC;
-
-   memset(sdp, 0, size);
-
-   /*
-* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
-* VSC SDP Header Bytes
-*/
-   sdp->sdp_header.HB0 = 0; /* Secondary-Data 

Re: [PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper

2024-02-20 Thread Dmitry Baryshkov
On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar  wrote:
>
> intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
> Lets move this to drm_dp_helper to achieve this.
>
> changes in v2:
> - rebased on top of drm-tip
>
> Acked-by: Dmitry Baryshkov 

v1 had an explicit comment before the ack:

>From my side, with the promise of the size fixup.

However I observe neither a second patch removing the size argument
nor it being dropped as a part of this patch.

> Signed-off-by: Abhinav Kumar 
> ---
>  drivers/gpu/drm/display/drm_dp_helper.c | 78 +
>  drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
>  include/drm/display/drm_dp_helper.h |  3 +
>  3 files changed, 83 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 8d6ce46471ae..6c91f400ecb1 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2913,6 +2913,84 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const 
> struct drm_dp_vsc_sdp *vsc)
>  }
>  EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
>
> +/**
> + * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
> + * @vsc: vsc sdp initialized according to its purpose as defined in
> + *   table 2-118 - table 2-120 in DP 1.4a specification
> + * @sdp: valid handle to the generic dp_sdp which will be packed
> + * @size: valid size of the passed sdp handle
> + *
> + * Returns length of sdp on success and error code on failure
> + */
> +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> +   struct dp_sdp *sdp, size_t size)
> +{
> +   size_t length = sizeof(struct dp_sdp);
> +
> +   if (size < length)
> +   return -ENOSPC;
> +
> +   memset(sdp, 0, size);
> +
> +   /*
> +* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> +* VSC SDP Header Bytes
> +*/
> +   sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
> +   sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
> +   sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
> +   sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
> +
> +   if (vsc->revision == 0x6) {
> +   sdp->db[0] = 1;
> +   sdp->db[3] = 1;
> +   }
> +
> +   /*
> +* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
> +* Format as per DP 1.4a spec and DP 2.0 respectively.
> +*/
> +   if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
> +   goto out;
> +
> +   /* VSC SDP Payload for DB16 through DB18 */
> +   /* Pixel Encoding and Colorimetry Formats  */
> +   sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
> +   sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
> +
> +   switch (vsc->bpc) {
> +   case 6:
> +   /* 6bpc: 0x0 */
> +   break;
> +   case 8:
> +   sdp->db[17] = 0x1; /* DB17[3:0] */
> +   break;
> +   case 10:
> +   sdp->db[17] = 0x2;
> +   break;
> +   case 12:
> +   sdp->db[17] = 0x3;
> +   break;
> +   case 16:
> +   sdp->db[17] = 0x4;
> +   break;
> +   default:
> +   WARN(1, "Missing case %d\n", vsc->bpc);
> +   return -EINVAL;
> +   }
> +
> +   /* Dynamic Range and Component Bit Depth */
> +   if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
> +   sdp->db[17] |= 0x80;  /* DB17[7] */
> +
> +   /* Content Type */
> +   sdp->db[18] = vsc->content_type & 0x7;
> +
> +out:
> +   return length;
> +}
> +EXPORT_SYMBOL(drm_dp_vsc_sdp_pack);
> +
>  /**
>   * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
>   * @dpcd: DisplayPort configuration data
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 217196196e50..a9458df475e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4089,73 +4089,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state 
> *crtc_state,
> return false;
>  }
>
> -static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> -struct dp_sdp *sdp, size_t size)
> -{
> -   size_t length = sizeof(struct dp_sdp);
> -
> -   if (size < length)
> -   return -ENOSPC;
> -
> -   memset(sdp, 0, size);
> -
> -   /*
> -* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> -* VSC SDP Header Bytes
> -*/
> -   sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
> -   sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
> -   sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
> -   

Re: [PATCH] drm/i915/tv: Fix TV mode

2024-02-20 Thread Ville Syrjälä
On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > > to update all the users of the struct drm_tv_connector_state mode field,
> > > which resulted in a build failure in i915.
> > > 
> > > However, a subsequent commit in the same series reintroduced a mode
> > > field in that structure, with a different semantic but the same type,
> > > with the assumption that all previous users were updated.
> > > 
> > > Since that didn't happen, the i915 driver now compiles, but mixes
> > > accesses to the legacy_mode field and the newer mode field, but with the
> > > previous semantics.
> > > 
> > > This obviously doesn't work very well, so we need to update the accesses
> > > that weren't in the legacy renaming commit.
> > > 
> > > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > > Reported-by: Ville Syrjälä 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > >  drivers/gpu/drm/i915/display/intel_tv.c   | 10 +-
> > >  2 files changed, 10 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
> > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > index 825638702ac1..5f9e748adc89 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct 
> > > intel_sdvo *intel_sdvo,
> > >   struct intel_sdvo_tv_format format;
> > >   u32 format_map;
> > >  
> > > - format_map = 1 << conn_state->tv.mode;
> > > + format_map = 1 << conn_state->tv.legacy_mode;
> > >   memset(, 0, sizeof(format));
> > >   memcpy(, _map, min(sizeof(format), sizeof(format_map)));
> > >  
> > > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct 
> > > drm_connector *connector)
> > >* Read the list of supported input resolutions for the selected TV
> > >* format.
> > >*/
> > > - format_map = 1 << conn_state->tv.mode;
> > > + format_map = 1 << conn_state->tv.legacy_mode;
> > >   memcpy(_res, _map,
> > >  min(sizeof(format_map), sizeof(struct 
> > > intel_sdvo_sdtv_resolution_request)));
> > >  
> > > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct 
> > > drm_connector *connector,
> > >   int i;
> > >  
> > >   for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> > > - if (state->tv.mode == 
> > > intel_sdvo_connector->tv_format_supported[i]) {
> > > + if (state->tv.legacy_mode == 
> > > intel_sdvo_connector->tv_format_supported[i]) {
> > >   *val = i;
> > >  
> > >   return 0;
> > > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct 
> > > drm_connector *connector,
> > >   struct intel_sdvo_connector_state *sdvo_state = 
> > > to_intel_sdvo_connector_state(state);
> > >  
> > >   if (property == intel_sdvo_connector->tv_format) {
> > > - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> > > + state->tv.legacy_mode = 
> > > intel_sdvo_connector->tv_format_supported[val];
> > >  
> > >   if (state->crtc) {
> > >   struct drm_crtc_state *crtc_state =
> > > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct 
> > > intel_sdvo *intel_sdvo,
> > >   drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> > > 
> > > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> > >  
> > > - intel_sdvo_connector->base.base.state->tv.mode = 
> > > intel_sdvo_connector->tv_format_supported[0];
> > > + intel_sdvo_connector->base.base.state->tv.legacy_mode = 
> > > intel_sdvo_connector->tv_format_supported[0];
> > >   drm_object_attach_property(_sdvo_connector->base.base.base,
> > >  intel_sdvo_connector->tv_format, 0);
> > >   return true;
> > 
> > Hmm. I didn't realize we are using this in the SDVO code as well.
> > I don't *think* that one is actually broken since it has its own
> > .{set,get}_property() hooks. But I suppose doing the rename
> > there as well is a good idea anyway.
> > 
> > Can you split the SDVO vs. TV into separate patches? We need to
> > backport at least the TV part, and a smaller patch means less
> > chance of conflicts. Or if you prefer I can chunk it up while
> > pushing.
> 
> hmm ouch... I shouldn't had rushed with it, I'm sorry.
> But I already merged this as is.

Did you at least slap a cc:stable on it? Or maybe the Fixes: tag is
enough these days...

> 
> > 
> > Both parts are
> > Reviewed-by: Ville Syrjälä 
> > 
> > Thanks.
> > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tv.c 
> > > 

Re: [PATCH] drm/i915/tv: Fix TV mode

2024-02-20 Thread Rodrigo Vivi
On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > to update all the users of the struct drm_tv_connector_state mode field,
> > which resulted in a build failure in i915.
> > 
> > However, a subsequent commit in the same series reintroduced a mode
> > field in that structure, with a different semantic but the same type,
> > with the assumption that all previous users were updated.
> > 
> > Since that didn't happen, the i915 driver now compiles, but mixes
> > accesses to the legacy_mode field and the newer mode field, but with the
> > previous semantics.
> > 
> > This obviously doesn't work very well, so we need to update the accesses
> > that weren't in the legacy renaming commit.
> > 
> > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > Reported-by: Ville Syrjälä 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> >  drivers/gpu/drm/i915/display/intel_tv.c   | 10 +-
> >  2 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
> > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > index 825638702ac1..5f9e748adc89 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct 
> > intel_sdvo *intel_sdvo,
> > struct intel_sdvo_tv_format format;
> > u32 format_map;
> >  
> > -   format_map = 1 << conn_state->tv.mode;
> > +   format_map = 1 << conn_state->tv.legacy_mode;
> > memset(, 0, sizeof(format));
> > memcpy(, _map, min(sizeof(format), sizeof(format_map)));
> >  
> > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct 
> > drm_connector *connector)
> >  * Read the list of supported input resolutions for the selected TV
> >  * format.
> >  */
> > -   format_map = 1 << conn_state->tv.mode;
> > +   format_map = 1 << conn_state->tv.legacy_mode;
> > memcpy(_res, _map,
> >min(sizeof(format_map), sizeof(struct 
> > intel_sdvo_sdtv_resolution_request)));
> >  
> > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct 
> > drm_connector *connector,
> > int i;
> >  
> > for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> > -   if (state->tv.mode == 
> > intel_sdvo_connector->tv_format_supported[i]) {
> > +   if (state->tv.legacy_mode == 
> > intel_sdvo_connector->tv_format_supported[i]) {
> > *val = i;
> >  
> > return 0;
> > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct 
> > drm_connector *connector,
> > struct intel_sdvo_connector_state *sdvo_state = 
> > to_intel_sdvo_connector_state(state);
> >  
> > if (property == intel_sdvo_connector->tv_format) {
> > -   state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> > +   state->tv.legacy_mode = 
> > intel_sdvo_connector->tv_format_supported[val];
> >  
> > if (state->crtc) {
> > struct drm_crtc_state *crtc_state =
> > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct 
> > intel_sdvo *intel_sdvo,
> > drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> >   
> > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> >  
> > -   intel_sdvo_connector->base.base.state->tv.mode = 
> > intel_sdvo_connector->tv_format_supported[0];
> > +   intel_sdvo_connector->base.base.state->tv.legacy_mode = 
> > intel_sdvo_connector->tv_format_supported[0];
> > drm_object_attach_property(_sdvo_connector->base.base.base,
> >intel_sdvo_connector->tv_format, 0);
> > return true;
> 
> Hmm. I didn't realize we are using this in the SDVO code as well.
> I don't *think* that one is actually broken since it has its own
> .{set,get}_property() hooks. But I suppose doing the rename
> there as well is a good idea anyway.
> 
> Can you split the SDVO vs. TV into separate patches? We need to
> backport at least the TV part, and a smaller patch means less
> chance of conflicts. Or if you prefer I can chunk it up while
> pushing.

hmm ouch... I shouldn't had rushed with it, I'm sorry.
But I already merged this as is.

> 
> Both parts are
> Reviewed-by: Ville Syrjälä 
> 
> Thanks.
> 
> > diff --git a/drivers/gpu/drm/i915/display/intel_tv.c 
> > b/drivers/gpu/drm/i915/display/intel_tv.c
> > index a96bcfcf90a3..2b77d399f1a1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> > @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
> >  
> >  static const struct tv_mode *intel_tv_mode_find(const struct 
> > 

Re: [PATCH] drm/i915/tv: Fix TV mode

2024-02-20 Thread Ville Syrjälä
On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> to update all the users of the struct drm_tv_connector_state mode field,
> which resulted in a build failure in i915.
> 
> However, a subsequent commit in the same series reintroduced a mode
> field in that structure, with a different semantic but the same type,
> with the assumption that all previous users were updated.
> 
> Since that didn't happen, the i915 driver now compiles, but mixes
> accesses to the legacy_mode field and the newer mode field, but with the
> previous semantics.
> 
> This obviously doesn't work very well, so we need to update the accesses
> that weren't in the legacy renaming commit.
> 
> Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> Reported-by: Ville Syrjälä 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
>  drivers/gpu/drm/i915/display/intel_tv.c   | 10 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 825638702ac1..5f9e748adc89 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct intel_sdvo 
> *intel_sdvo,
>   struct intel_sdvo_tv_format format;
>   u32 format_map;
>  
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
>   memset(, 0, sizeof(format));
>   memcpy(, _map, min(sizeof(format), sizeof(format_map)));
>  
> @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct drm_connector 
> *connector)
>* Read the list of supported input resolutions for the selected TV
>* format.
>*/
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
>   memcpy(_res, _map,
>  min(sizeof(format_map), sizeof(struct 
> intel_sdvo_sdtv_resolution_request)));
>  
> @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct 
> drm_connector *connector,
>   int i;
>  
>   for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> - if (state->tv.mode == 
> intel_sdvo_connector->tv_format_supported[i]) {
> + if (state->tv.legacy_mode == 
> intel_sdvo_connector->tv_format_supported[i]) {
>   *val = i;
>  
>   return 0;
> @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct 
> drm_connector *connector,
>   struct intel_sdvo_connector_state *sdvo_state = 
> to_intel_sdvo_connector_state(state);
>  
>   if (property == intel_sdvo_connector->tv_format) {
> - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> + state->tv.legacy_mode = 
> intel_sdvo_connector->tv_format_supported[val];
>  
>   if (state->crtc) {
>   struct drm_crtc_state *crtc_state =
> @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct 
> intel_sdvo *intel_sdvo,
>   drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> 
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>  
> - intel_sdvo_connector->base.base.state->tv.mode = 
> intel_sdvo_connector->tv_format_supported[0];
> + intel_sdvo_connector->base.base.state->tv.legacy_mode = 
> intel_sdvo_connector->tv_format_supported[0];
>   drm_object_attach_property(_sdvo_connector->base.base.base,
>  intel_sdvo_connector->tv_format, 0);
>   return true;

Hmm. I didn't realize we are using this in the SDVO code as well.
I don't *think* that one is actually broken since it has its own
.{set,get}_property() hooks. But I suppose doing the rename
there as well is a good idea anyway.

Can you split the SDVO vs. TV into separate patches? We need to
backport at least the TV part, and a smaller patch means less
chance of conflicts. Or if you prefer I can chunk it up while
pushing.

Both parts are
Reviewed-by: Ville Syrjälä 

Thanks.

> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c 
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index a96bcfcf90a3..2b77d399f1a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
>  
>  static const struct tv_mode *intel_tv_mode_find(const struct 
> drm_connector_state *conn_state)
>  {
> - int format = conn_state->tv.mode;
> + int format = conn_state->tv.legacy_mode;
>  
>   return _modes[format];
>  }
> @@ -1705,7 +1705,7 @@ static void intel_tv_find_better_format(struct 
> drm_connector *connector)
>   break;
>   }
>  
> - 

Re: [PATCH] drm/i915/tv: Fix TV mode

2024-02-20 Thread Rodrigo Vivi
On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> to update all the users of the struct drm_tv_connector_state mode field,
> which resulted in a build failure in i915.
> 
> However, a subsequent commit in the same series reintroduced a mode
> field in that structure, with a different semantic but the same type,
> with the assumption that all previous users were updated.

just for the record, commit 7d63cd8526f1 ("drm/connector: Add TV standard 
property")

> 
> Since that didn't happen, the i915 driver now compiles, but mixes
> accesses to the legacy_mode field and the newer mode field, but with the
> previous semantics.
> 
> This obviously doesn't work very well, so we need to update the accesses
> that weren't in the legacy renaming commit.
> 
> Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> Reported-by: Ville Syrjälä 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Rodrigo Vivi 

and pushing to drm-intel-next soon...

> ---
>  drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
>  drivers/gpu/drm/i915/display/intel_tv.c   | 10 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 825638702ac1..5f9e748adc89 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct intel_sdvo 
> *intel_sdvo,
>   struct intel_sdvo_tv_format format;
>   u32 format_map;
>  
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
>   memset(, 0, sizeof(format));
>   memcpy(, _map, min(sizeof(format), sizeof(format_map)));
>  
> @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct drm_connector 
> *connector)
>* Read the list of supported input resolutions for the selected TV
>* format.
>*/
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
>   memcpy(_res, _map,
>  min(sizeof(format_map), sizeof(struct 
> intel_sdvo_sdtv_resolution_request)));
>  
> @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct 
> drm_connector *connector,
>   int i;
>  
>   for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> - if (state->tv.mode == 
> intel_sdvo_connector->tv_format_supported[i]) {
> + if (state->tv.legacy_mode == 
> intel_sdvo_connector->tv_format_supported[i]) {
>   *val = i;
>  
>   return 0;
> @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct 
> drm_connector *connector,
>   struct intel_sdvo_connector_state *sdvo_state = 
> to_intel_sdvo_connector_state(state);
>  
>   if (property == intel_sdvo_connector->tv_format) {
> - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> + state->tv.legacy_mode = 
> intel_sdvo_connector->tv_format_supported[val];
>  
>   if (state->crtc) {
>   struct drm_crtc_state *crtc_state =
> @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct 
> intel_sdvo *intel_sdvo,
>   drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> 
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>  
> - intel_sdvo_connector->base.base.state->tv.mode = 
> intel_sdvo_connector->tv_format_supported[0];
> + intel_sdvo_connector->base.base.state->tv.legacy_mode = 
> intel_sdvo_connector->tv_format_supported[0];
>   drm_object_attach_property(_sdvo_connector->base.base.base,
>  intel_sdvo_connector->tv_format, 0);
>   return true;
> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c 
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index a96bcfcf90a3..2b77d399f1a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
>  
>  static const struct tv_mode *intel_tv_mode_find(const struct 
> drm_connector_state *conn_state)
>  {
> - int format = conn_state->tv.mode;
> + int format = conn_state->tv.legacy_mode;
>  
>   return _modes[format];
>  }
> @@ -1705,7 +1705,7 @@ static void intel_tv_find_better_format(struct 
> drm_connector *connector)
>   break;
>   }
>  
> - connector->state->tv.mode = i;
> + connector->state->tv.legacy_mode = i;
>  }
>  
>  static int
> @@ -1863,7 +1863,7 @@ static int intel_tv_atomic_check(struct drm_connector 
> *connector,
>   old_state = drm_atomic_get_old_connector_state(state, connector);
>   new_crtc_state = 

Re: [PATCH v3] drm/i915/panelreplay: Panel replay workaround with VRR

2024-02-20 Thread Rodrigo Vivi
On Tue, Feb 20, 2024 at 07:49:19PM +0530, Animesh Manna wrote:
> Panel Replay VSC SDP not getting sent when VRR is enabled
> and W1 and W2 are 0. So Program Set Context Latency in
> TRANS_SET_CONTEXT_LATENCY register to at least a value of 1.
> 
> HSD: 14015406119

Unnecessary mark since the wa_name already is a pointer to the HSD.

> 
> v1: Initial version.
> v2: Update timings stored in adjusted_mode struct. [Ville]
> v3: Add WA in compute_config(). [Ville]
> 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 217196196e50..eb0fa513cd0f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2948,6 +2948,18 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
>   intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config, 
> conn_state);
>  
> + /*
> +  * WA: HSD-14015406119

this is not the right one. You should use the lineage one and then mark the 
platforms.

/* wa_14015401596: xe_lpd, xe_hpd */

or perhaps

/* wa_14015401596: display versions: 13, 14 */

and also add a check for the display version with it.

> +  * Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY register
> +  * to at least a value of 1 when Panel Replay is enabled with VRR.
> +  * Value for TRANS_SET_CONTEXT_LATENCY is calculated by substracting
> +  * crtc_vdisplay from crtc_vblank_start, so incrementing 
> crtc_vblank_start
> +  * by 1 if both are equal.
> +  */
> + if (pipe_config->vrr.enable && pipe_config->has_panel_replay &&
> + adjusted_mode->crtc_vblank_start == adjusted_mode->crtc_vdisplay)
> + adjusted_mode->crtc_vblank_start += 1;

why to mess with the vblank start instead of going to 
intel_set_transcoder_timings()
and change directly what is getting written to the register when the register
gets written?

In case the answer is becasue by then we don't have the vrr.enable or something 
like
that, then we should consider move around when we set that register?

or perhaps create a specific flag? one extra variable, 3 less comment lines...

> +
>   return 0;
>  }
>  
> -- 
> 2.29.0
> 


✓ Fi.CI.IGT: success for drm/i915/panelreplay: Panel replay workaround with VRR (rev3)

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915/panelreplay: Panel replay workaround with VRR (rev3)
URL   : https://patchwork.freedesktop.org/series/129632/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14300_full -> Patchwork_129632v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (8 -> 8)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-rkl:  ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [FAIL][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) ([i915#8293]) -> ([PASS][26], [PASS][27], [PASS][28], 
[PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], 
[PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], 
[PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], 
[PASS][47], [PASS][48], [PASS][49], [PASS][50])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-6/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-6/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-5/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-5/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-2/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-2/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-4/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-4/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-4/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-3/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-3/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-3/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-3/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-3/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-1/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-1/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-1/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-7/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-7/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-7/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-7/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-6/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/shard-rkl-6/boot.html
   [43]: 

✗ Fi.CI.BAT: failure for Disable automatic load CCS load balancing (rev3)

2024-02-20 Thread Patchwork
== Series Details ==

Series: Disable automatic load CCS load balancing (rev3)
URL   : https://patchwork.freedesktop.org/series/129951/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14300 -> Patchwork_129951v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_129951v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_129951v3, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_129951v3/index.html

Participating hosts (40 -> 40)
--

  Additional (1): bat-arls-3 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-bsw-n3050:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-bsw-n3050/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-bsw-n3050/igt@i915_module_l...@load.html
- fi-skl-6600u:   [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-skl-6600u/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-skl-6600u/igt@i915_module_l...@load.html
- fi-apl-guc: NOTRUN -> [ABORT][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-apl-guc/igt@i915_module_l...@load.html
- fi-glk-j4005:   [PASS][6] -> [ABORT][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-glk-j4005/igt@i915_module_l...@load.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-glk-j4005/igt@i915_module_l...@load.html
- fi-skl-guc: [PASS][8] -> [ABORT][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-skl-guc/igt@i915_module_l...@load.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-skl-guc/igt@i915_module_l...@load.html
- fi-kbl-7567u:   [PASS][10] -> [ABORT][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-kbl-7567u/igt@i915_module_l...@load.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-kbl-7567u/igt@i915_module_l...@load.html
- fi-cfl-8700k:   [PASS][12] -> [ABORT][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-cfl-8700k/igt@i915_module_l...@load.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-cfl-8700k/igt@i915_module_l...@load.html
- fi-bsw-nick:[PASS][14] -> [ABORT][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-bsw-nick/igt@i915_module_l...@load.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-bsw-nick/igt@i915_module_l...@load.html
- bat-kbl-2:  [PASS][16] -> [ABORT][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/bat-kbl-2/igt@i915_module_l...@load.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/bat-kbl-2/igt@i915_module_l...@load.html
- fi-cfl-guc: [PASS][18] -> [ABORT][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-cfl-guc/igt@i915_module_l...@load.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-cfl-guc/igt@i915_module_l...@load.html
- fi-kbl-x1275:   [PASS][20] -> [ABORT][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-kbl-x1275/igt@i915_module_l...@load.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-kbl-x1275/igt@i915_module_l...@load.html
- fi-cfl-8109u:   [PASS][22] -> [ABORT][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-cfl-8109u/igt@i915_module_l...@load.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-cfl-8109u/igt@i915_module_l...@load.html
- fi-ivb-3770:[PASS][24] -> [ABORT][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-ivb-3770/igt@i915_module_l...@load.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-ivb-3770/igt@i915_module_l...@load.html
- fi-kbl-guc: [PASS][26] -> [ABORT][27]
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-kbl-guc/igt@i915_module_l...@load.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v3/fi-kbl-guc/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@client:
- fi-elk-e7500:   [PASS][28] -> [DMESG-WARN][29] +42 other tests 
dmesg-warn
   [28]: 

✓ Fi.CI.IGT: success for drm/i915/tv: Fix TV mode

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915/tv: Fix TV mode
URL   : https://patchwork.freedesktop.org/series/130123/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14300_full -> Patchwork_130123v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (8 -> 8)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_14300_full and 
Patchwork_130123v1_full:

### New IGT tests (4) ###

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-75-unity-scaling@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-75-unity-scaling@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.16] s

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-75-unity-scaling@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-75-unity-scaling@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@device_reset@cold-reset-bound:
- shard-dg2:  NOTRUN -> [SKIP][1] ([i915#7701])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-dg2-2/igt@device_re...@cold-reset-bound.html

  * igt@drm_fdinfo@virtual-busy-all:
- shard-dg2:  NOTRUN -> [SKIP][2] ([i915#8414]) +1 other test skip
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-dg2-2/igt@drm_fdi...@virtual-busy-all.html

  * igt@fbdev@pan:
- shard-snb:  [PASS][3] -> [FAIL][4] ([i915#4435])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-snb5/igt@fb...@pan.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-snb7/igt@fb...@pan.html

  * igt@gem_bad_reloc@negative-reloc:
- shard-rkl:  NOTRUN -> [SKIP][5] ([i915#3281]) +2 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-rkl-5/igt@gem_bad_re...@negative-reloc.html

  * igt@gem_ccs@block-copy-compressed:
- shard-mtlp: NOTRUN -> [SKIP][6] ([i915#3555] / [i915#9323])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-mtlp-1/igt@gem_...@block-copy-compressed.html

  * igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-smem-lmem0:
- shard-dg2:  NOTRUN -> [INCOMPLETE][7] ([i915#7297])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-dg2-1/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglu: [PASS][8] -> [FAIL][9] ([i915#6268])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-tglu-10/igt@gem_ctx_e...@basic-nohangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-tglu-9/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_ctx_persistence@heartbeat-close:
- shard-dg2:  NOTRUN -> [SKIP][10] ([i915#8555])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-dg2-5/igt@gem_ctx_persiste...@heartbeat-close.html

  * igt@gem_ctx_persistence@heartbeat-hostile:
- shard-mtlp: NOTRUN -> [SKIP][11] ([i915#8555])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-mtlp-1/igt@gem_ctx_persiste...@heartbeat-hostile.html

  * igt@gem_ctx_sseu@engines:
- shard-dg2:  NOTRUN -> [SKIP][12] ([i915#280])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-dg2-5/igt@gem_ctx_s...@engines.html

  * igt@gem_exec_balancer@hog:
- shard-dg2:  NOTRUN -> [SKIP][13] ([i915#4812])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-dg2-2/igt@gem_exec_balan...@hog.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-rkl:  NOTRUN -> [SKIP][14] ([i915#4525])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-rkl-5/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_capture@many-4k-incremental:
- shard-mtlp: NOTRUN -> [FAIL][15] ([i915#9606])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-mtlp-1/igt@gem_exec_capt...@many-4k-incremental.html

  * igt@gem_exec_fair@basic-flow:
- shard-dg2:  NOTRUN -> [SKIP][16] ([i915#3539] / [i915#4852]) +1 
other test skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130123v1/shard-dg2-2/igt@gem_exec_f...@basic-flow.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [18]: 

✗ Fi.CI.CHECKPATCH: warning for Disable automatic load CCS load balancing (rev3)

2024-02-20 Thread Patchwork
== Series Details ==

Series: Disable automatic load CCS load balancing (rev3)
URL   : https://patchwork.freedesktop.org/series/129951/
State : warning

== Summary ==

Error: dim checkpatch failed
c2b6f7fef25d drm/i915/gt: Disable HW load balancing for CCS
63fd178cadec drm/i915/gt: Enable only one CCS for compute workload
-:92: CHECK:LINE_SPACING: Please don't use multiple blank lines
#92: FILE: drivers/gpu/drm/i915/i915_query.c:127:
 
+

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




✓ Fi.CI.BAT: success for drm/i915/panelreplay: Panel replay workaround with VRR (rev3)

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915/panelreplay: Panel replay workaround with VRR (rev3)
URL   : https://patchwork.freedesktop.org/series/129632/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14300 -> Patchwork_129632v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_fence@basic-busy@rcs0:
- {bat-arls-1}:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/bat-arls-1/igt@gem_exec_fence@basic-b...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/bat-arls-1/igt@gem_exec_fence@basic-b...@rcs0.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-tgl-1115g4:  [PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-tgl-1115g4/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/fi-tgl-1115g4/boot.html

  
 Possible fixes 

  * boot:
- fi-apl-guc: [FAIL][5] ([i915#8293]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-apl-guc/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/fi-apl-guc/boot.html

  

### IGT changes ###

 Issues hit 

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

  * igt@kms_hdmi_inject@inject-audio:
- fi-apl-guc: NOTRUN -> [SKIP][8] ([fdo#109271]) +13 other tests 
skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/fi-apl-guc/igt@kms_hdmi_inj...@inject-audio.html

  
 Possible fixes 

  * igt@gem_busy@busy@all-engines:
- {bat-arls-2}:   [INCOMPLETE][9] ([i915#10194]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/bat-arls-2/igt@gem_busy@b...@all-engines.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/bat-arls-2/igt@gem_busy@b...@all-engines.html

  * igt@gem_exec_create@basic@smem:
- {bat-arls-1}:   [DMESG-WARN][11] ([i915#10194]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/bat-arls-1/igt@gem_exec_create@ba...@smem.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v3/bat-arls-1/igt@gem_exec_create@ba...@smem.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
  [i915#10196]: https://gitlab.freedesktop.org/drm/intel/issues/10196
  [i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
  [i915#10200]: https://gitlab.freedesktop.org/drm/intel/issues/10200
  [i915#10202]: https://gitlab.freedesktop.org/drm/intel/issues/10202
  [i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
  [i915#10207]: https://gitlab.freedesktop.org/drm/intel/issues/10207
  [i915#10208]: https://gitlab.freedesktop.org/drm/intel/issues/10208
  [i915#10209]: https://gitlab.freedesktop.org/drm/intel/issues/10209
  [i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
  [i915#10212]: https://gitlab.freedesktop.org/drm/intel/issues/10212
  [i915#10213]: https://gitlab.freedesktop.org/drm/intel/issues/10213
  [i915#10214]: https://gitlab.freedesktop.org/drm/intel/issues/10214
  [i915#10215]: https://gitlab.freedesktop.org/drm/intel/issues/10215
  [i915#10216]: https://gitlab.freedesktop.org/drm/intel/issues/10216
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
  [i915#8809]: https://gitlab.freedesktop.org/drm/intel/issues/8809
  [i915#9688]: https://gitlab.freedesktop.org/drm/intel/issues/9688
  [i915#9886]: https://gitlab.freedesktop.org/drm/intel/issues/9886


Build changes
-

  * Linux: 

Re: [PULL] drm-intel-gt-next

2024-02-20 Thread Joonas Lahtinen
Quoting Joonas Lahtinen (2024-02-16 11:41:44)
> (+ Jonathan)
> 
> Quoting Dave Airlie (2024-02-16 04:58:03)
> > On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin
> >  wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > First pull request for 6.9 with probably one more coming in one to two
> > > weeks.
> > >
> > > Nothing to interesting in this one, mostly a sprinkle of small fixes in
> > > GuC, HuC, Perf/OA, a tiny bit of prep work for future platforms and some
> > > code cleanups.
> > >
> > > One new uapi in the form of a GuC submission version query which Mesa
> > > wants for implementing Vulkan async compute queues.
> > >
> > > Regards,
> > >
> > > Tvrtko
> > >
> > > drm-intel-gt-next-2024-02-15:
> > > UAPI Changes:
> > >
> > > - Add GuC submission interface version query (Tvrtko Ursulin)
> > >
> > > Driver Changes:
> > >
> > > Fixes/improvements/new stuff:
> > >
> > > - Atomically invalidate userptr on mmu-notifier (Jonathan Cavitt)
> > 
> > I've pulled this, but the above patch is triggering my this seems
> > wrong spider sense.
> > 
> > This and probably the preceeding patch that this references seem to
> > move i915 to a long term pinning of userptr in memory with what I can
> > see no accounting, and away from what the desired behaviour for
> > drivers should be.
> 
> I asked Thomas to take a more detailed look. Jonathan, Thomas really should
> have been Cc'd in the original patch as the patch was explicitly referred
> in the text even.
> 
> > It also feels like the authorship on this might be lies which also worries 
> > me.
> 
> Fear not. This can probably be blamed on the i915 maintainers.
> 
> When we have an internal patch which has many revisions and is then
> essentially rewritten for upstreaming, we specifically asked NOT to keep
> the "From:" line intact, but instead swap in person who rewrote the patch[1].

Just to state the obvious for the public record:

This should never be done lightly or without reaching out to the
original author. This should only be for the exceptional cases where the
patch has significantly changed.

This was just the explanation why it's not an immediate red flag to see
such a patch. Based on the discussion around the topic we should be more
explicit if such a case has happened or if there simply has been an error
in the patch handling.

So we'll work on clarifying the instructions here.

Regards, Joonas

> To document credits/involvement of the original author we've recommended
> to keep the Signed-off-by line however. "Co-developed-by" does not really
> express the situation correctly. "Based on patch by" style pure textual
> credit reference was also discussed but is hard to grep.
> 
> Discussed with Sima who suggested if we should consider something like
> "Original-patch-by:" tag to better express this situation?
> 
> Regards, Joonas
> 
> [1] If the "From: " line is not updated, it sometimes leads to
> situation where you can see a patch with "From:" pointing to you, that
> doesn't contain a single unmodified line anymore.
> 
> > 
> > Dave.


✗ Fi.CI.IGT: failure for drm/i915: check before removing mm notifier (rev3)

2024-02-20 Thread Patchwork
== Series Details ==

Series: drm/i915: check before removing mm notifier (rev3)
URL   : https://patchwork.freedesktop.org/series/101170/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14300_full -> Patchwork_101170v3_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_101170v3_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_101170v3_full, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (8 -> 8)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_mmap_offset@open-flood:
- shard-rkl:  [PASS][1] -> [INCOMPLETE][2] +1 other test incomplete
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-6/igt@gem_mmap_off...@open-flood.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101170v3/shard-rkl-6/igt@gem_mmap_off...@open-flood.html

  
New tests
-

  New tests have been introduced between CI_DRM_14300_full and 
Patchwork_101170v3_full:

### New IGT tests (4) ###

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-75-unity-scaling@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.10] s

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-75-unity-scaling@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-75-unity-scaling@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-75-unity-scaling@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-rkl:  ([PASS][3], [PASS][4], [PASS][5], [PASS][6], 
[PASS][7], [PASS][8], [FAIL][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26], [PASS][27]) ([i915#8293]) -> ([PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [PASS][50], [PASS][51])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/shard-rkl-1/boot.html
  

✗ Fi.CI.BAT: failure for Disable automatic load CCS load balancing (rev2)

2024-02-20 Thread Patchwork
== Series Details ==

Series: Disable automatic load CCS load balancing (rev2)
URL   : https://patchwork.freedesktop.org/series/129951/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14300 -> Patchwork_129951v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_129951v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_129951v2, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_129951v2/index.html

Participating hosts (40 -> 38)
--

  Missing(2): fi-glk-j4005 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-bsw-n3050:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-bsw-n3050/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-bsw-n3050/igt@i915_module_l...@load.html
- fi-skl-6600u:   [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-skl-6600u/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-skl-6600u/igt@i915_module_l...@load.html
- fi-apl-guc: NOTRUN -> [ABORT][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-apl-guc/igt@i915_module_l...@load.html
- fi-skl-guc: [PASS][6] -> [ABORT][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-skl-guc/igt@i915_module_l...@load.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-skl-guc/igt@i915_module_l...@load.html
- fi-kbl-7567u:   [PASS][8] -> [ABORT][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-kbl-7567u/igt@i915_module_l...@load.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-kbl-7567u/igt@i915_module_l...@load.html
- fi-cfl-8700k:   [PASS][10] -> [ABORT][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-cfl-8700k/igt@i915_module_l...@load.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-cfl-8700k/igt@i915_module_l...@load.html
- fi-bsw-nick:[PASS][12] -> [ABORT][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-bsw-nick/igt@i915_module_l...@load.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-bsw-nick/igt@i915_module_l...@load.html
- bat-kbl-2:  [PASS][14] -> [ABORT][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/bat-kbl-2/igt@i915_module_l...@load.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/bat-kbl-2/igt@i915_module_l...@load.html
- fi-cfl-guc: [PASS][16] -> [ABORT][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-cfl-guc/igt@i915_module_l...@load.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-cfl-guc/igt@i915_module_l...@load.html
- fi-kbl-x1275:   [PASS][18] -> [ABORT][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-kbl-x1275/igt@i915_module_l...@load.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-kbl-x1275/igt@i915_module_l...@load.html
- fi-cfl-8109u:   [PASS][20] -> [ABORT][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-cfl-8109u/igt@i915_module_l...@load.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-cfl-8109u/igt@i915_module_l...@load.html
- fi-ivb-3770:[PASS][22] -> [ABORT][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-ivb-3770/igt@i915_module_l...@load.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-ivb-3770/igt@i915_module_l...@load.html
- fi-kbl-guc: [PASS][24] -> [ABORT][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-kbl-guc/igt@i915_module_l...@load.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-kbl-guc/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@client:
- fi-elk-e7500:   [PASS][26] -> [DMESG-WARN][27] +42 other tests 
dmesg-warn
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14300/fi-elk-e7500/igt@i915_selftest@l...@client.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129951v2/fi-elk-e7500/igt@i915_selftest@l...@client.html

  * igt@i915_selftest@live@coherency:
- bat-jsl-3:  [PASS][28] -> [DMESG-WARN][29] +40 other tests 
dmesg-warn
   [28]: 

Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload

2024-02-20 Thread Tvrtko Ursulin



On 20/02/2024 14:35, Andi Shyti wrote:

Enable only one CCS engine by default with all the compute sices


slices


allocated to it.

While generating the list of UABI engines to be exposed to the
user, exclude any additional CCS engines beyond the first
instance.

This change can be tested with igt i915_query.

Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc:  # v6.2+
---
  drivers/gpu/drm/i915/gt/intel_engine_user.c |  9 +
  drivers/gpu/drm/i915/gt/intel_gt.c  | 11 +++
  drivers/gpu/drm/i915/gt/intel_gt_regs.h |  2 ++
  drivers/gpu/drm/i915/i915_query.c   |  1 +
  4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..7041acc77810 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -243,6 +243,15 @@ void intel_engines_driver_register(struct drm_i915_private 
*i915)
if (engine->uabi_class == I915_NO_UABI_CLASS)
continue;
  
+		/*

+* Do not list and do not count CCS engines other than the first
+*/
+   if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
+   engine->uabi_instance > 0) {
+   i915->engine_uabi_class_count[engine->uabi_class]--;
+   continue;
+   }


It's a bit ugly to decrement after increment, instead of somehow 
restructuring the loop to satisfy both cases more elegantly. And I 
wonder if internally (in dmesg when engine name is logged) we don't end 
up with ccs0 ccs0 ccs0 ccs0.. for all instances.



+
rb_link_node(>uabi_node, prev, p);
rb_insert_color(>uabi_node, >uabi_engines);
  
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c

index a425db5ed3a2..e19df4ef47f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
}
  }
  
+static void intel_gt_apply_ccs_mode(struct intel_gt *gt)

+{
+   if (!IS_DG2(gt->i915))
+   return;
+
+   intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
+}
+
  int intel_gt_init_hw(struct intel_gt *gt)
  {
struct drm_i915_private *i915 = gt->i915;
@@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
  
  	intel_gt_init_swizzling(gt);
  
+	/* Configure CCS mode */

+   intel_gt_apply_ccs_mode(gt);
+
/*
 * At least 830 can leave some of the unused rings
 * "active" (ie. head != tail) after resume which
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index cf709f6c05ae..c148113770ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1605,6 +1605,8 @@
  #define   GEN12_VOLTAGE_MASK  REG_GENMASK(10, 0)
  #define   GEN12_CAGF_MASK REG_GENMASK(19, 11)
  
+#define XEHP_CCS_MODE  _MMIO(0x14804)

+
  #define GEN11_GT_INTR_DW(x)   _MMIO(0x190018 + ((x) * 4))
  #define   GEN11_CSME  (31)
  #define   GEN12_HECI_2(30)
diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 3baa2f54a86e..d5a5143971f5 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -124,6 +124,7 @@ static int query_geometry_subslices(struct drm_i915_private 
*i915,
return fill_topology_info(sseu, query_item, 
sseu->geometry_subslice_mask);
  }
  
+


Zap please.


  static int
  query_engine_info(struct drm_i915_private *i915,
  struct drm_i915_query_item *query_item)


Regards,

Tvrtko


✗ Fi.CI.SPARSE: warning for Disable automatic load CCS load balancing (rev2)

2024-02-20 Thread Patchwork
== Series Details ==

Series: Disable automatic load CCS load balancing (rev2)
URL   : https://patchwork.freedesktop.org/series/129951/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




✗ Fi.CI.CHECKPATCH: warning for Disable automatic load CCS load balancing (rev2)

2024-02-20 Thread Patchwork
== Series Details ==

Series: Disable automatic load CCS load balancing (rev2)
URL   : https://patchwork.freedesktop.org/series/129951/
State : warning

== Summary ==

Error: dim checkpatch failed
2065c72a8acd drm/i915/gt: Disable HW load balancing for CCS
5e600e4db29b drm/i915/gt: Set default CCS mode '1'
-:80: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#80: FILE: drivers/gpu/drm/i915/i915_drv.h:409:
+#define for_each_available_uabi_engine(engine__, i915__) \
+   for_each_uabi_engine(engine__, i915__) \
+   if ((IS_DG2(i915__)) && \
+   ((engine__)->uabi_class == I915_ENGINE_CLASS_COMPUTE) && \
+   ((engine__)->uabi_instance)) { } \
+   else

-:80: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine__' - possible 
side-effects?
#80: FILE: drivers/gpu/drm/i915/i915_drv.h:409:
+#define for_each_available_uabi_engine(engine__, i915__) \
+   for_each_uabi_engine(engine__, i915__) \
+   if ((IS_DG2(i915__)) && \
+   ((engine__)->uabi_class == I915_ENGINE_CLASS_COMPUTE) && \
+   ((engine__)->uabi_instance)) { } \
+   else

-:80: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915__' - possible 
side-effects?
#80: FILE: drivers/gpu/drm/i915/i915_drv.h:409:
+#define for_each_available_uabi_engine(engine__, i915__) \
+   for_each_uabi_engine(engine__, i915__) \
+   if ((IS_DG2(i915__)) && \
+   ((engine__)->uabi_class == I915_ENGINE_CLASS_COMPUTE) && \
+   ((engine__)->uabi_instance)) { } \
+   else

-:82: ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
#82: FILE: drivers/gpu/drm/i915/i915_drv.h:411:
+   if ((IS_DG2(i915__)) && \
[...]
+   ((engine__)->uabi_instance)) { } \

-:98: CHECK:LINE_SPACING: Please don't use multiple blank lines
#98: FILE: drivers/gpu/drm/i915/i915_query.c:127:
 
+

total: 2 errors, 0 warnings, 3 checks, 77 lines checked




Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload

2024-02-20 Thread Andi Shyti
Hi,

[...]

> diff --git a/drivers/gpu/drm/i915/i915_query.c 
> b/drivers/gpu/drm/i915/i915_query.c
> index 3baa2f54a86e..d5a5143971f5 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -124,6 +124,7 @@ static int query_geometry_subslices(struct 
> drm_i915_private *i915,
>   return fill_topology_info(sseu, query_item, 
> sseu->geometry_subslice_mask);
>  }
>  
> +

sorry, this is a leftover from the cleanup.

Andi

>  static int
>  query_engine_info(struct drm_i915_private *i915,
> struct drm_i915_query_item *query_item)
> -- 
> 2.43.0


[PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload

2024-02-20 Thread Andi Shyti
Enable only one CCS engine by default with all the compute sices
allocated to it.

While generating the list of UABI engines to be exposed to the
user, exclude any additional CCS engines beyond the first
instance.

This change can be tested with igt i915_query.

Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc:  # v6.2+
---
 drivers/gpu/drm/i915/gt/intel_engine_user.c |  9 +
 drivers/gpu/drm/i915/gt/intel_gt.c  | 11 +++
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  2 ++
 drivers/gpu/drm/i915/i915_query.c   |  1 +
 4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..7041acc77810 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -243,6 +243,15 @@ void intel_engines_driver_register(struct drm_i915_private 
*i915)
if (engine->uabi_class == I915_NO_UABI_CLASS)
continue;
 
+   /*
+* Do not list and do not count CCS engines other than the first
+*/
+   if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
+   engine->uabi_instance > 0) {
+   i915->engine_uabi_class_count[engine->uabi_class]--;
+   continue;
+   }
+
rb_link_node(>uabi_node, prev, p);
rb_insert_color(>uabi_node, >uabi_engines);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a425db5ed3a2..e19df4ef47f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
}
 }
 
+static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
+{
+   if (!IS_DG2(gt->i915))
+   return;
+
+   intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
+}
+
 int intel_gt_init_hw(struct intel_gt *gt)
 {
struct drm_i915_private *i915 = gt->i915;
@@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
 
intel_gt_init_swizzling(gt);
 
+   /* Configure CCS mode */
+   intel_gt_apply_ccs_mode(gt);
+
/*
 * At least 830 can leave some of the unused rings
 * "active" (ie. head != tail) after resume which
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index cf709f6c05ae..c148113770ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1605,6 +1605,8 @@
 #define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
 #define   GEN12_CAGF_MASK  REG_GENMASK(19, 11)
 
+#define XEHP_CCS_MODE  _MMIO(0x14804)
+
 #define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
 #define   GEN11_CSME   (31)
 #define   GEN12_HECI_2 (30)
diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 3baa2f54a86e..d5a5143971f5 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -124,6 +124,7 @@ static int query_geometry_subslices(struct drm_i915_private 
*i915,
return fill_topology_info(sseu, query_item, 
sseu->geometry_subslice_mask);
 }
 
+
 static int
 query_engine_info(struct drm_i915_private *i915,
  struct drm_i915_query_item *query_item)
-- 
2.43.0



[PATCH v2 1/2] drm/i915/gt: Disable HW load balancing for CCS

2024-02-20 Thread Andi Shyti
The hardware should not dynamically balance the load between CCS
engines. Wa_14019159160 recommends disabling it across all
platforms.

Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc:  # v6.2+
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 50962cfd1353..cf709f6c05ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1478,6 +1478,7 @@
 
 #define GEN12_RCU_MODE _MMIO(0x14800)
 #define   GEN12_RCU_MODE_CCS_ENABLEREG_BIT(0)
+#define   XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE   REG_BIT(1)
 
 #define CHV_FUSE_GT_MMIO(VLV_GUNIT_BASE + 0x2168)
 #define   CHV_FGT_DISABLE_SS0  (1 << 10)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index d67d44611c28..9126b37186fc 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2988,6 +2988,12 @@ general_render_compute_wa_init(struct intel_engine_cs 
*engine, struct i915_wa_li
wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN1,
 GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
}
+
+   /*
+* Wa_14019159160: disable the CCS load balancing
+* indiscriminately for all the platforms
+*/
+   wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
 }
 
 static void
-- 
2.43.0



[PATCH 0/2] Disable automatic load CCS load balancing

2024-02-20 Thread Andi Shyti
Hi,

this series does basically two things:

1. Disables automatic load balancing as adviced by the hardware
   workaround.

2. Assigns all the CCS slices to one single user engine. The user
   will then be able to query only one CCS engine

Changelog
=
- In Patch 1 use the correct workaround number (thanks Matt).
- In Patch 2 do not add the extra CCS engines to the exposed UABI
  engine list and adapt the engine counting accordingly (thanks
  Tvrtko).
- Reword the commit of Patch 2 (thanks John).

Andi Shyti (2):
  drm/i915/gt: Disable HW load balancing for CCS
  drm/i915/gt: Enable only one CCS for compute workload

 drivers/gpu/drm/i915/gt/intel_engine_user.c |  9 +
 drivers/gpu/drm/i915/gt/intel_gt.c  | 11 +++
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  3 +++
 drivers/gpu/drm/i915/gt/intel_workarounds.c |  6 ++
 drivers/gpu/drm/i915/i915_query.c   |  1 +
 5 files changed, 30 insertions(+)

-- 
2.43.0



Re: [PATCH 0/2] Disable automatic load CCS load balancing

2024-02-20 Thread Andi Shyti
Please, ignore, I sent V1 again.

Sorry about the noise!

Andi

On Tue, Feb 20, 2024 at 03:20:32PM +0100, Andi Shyti wrote:
> Hi,
> 
> this series does basically two things:
> 
> 1. Disables automatic load balancing as adviced by the hardware
>workaround.
> 
> 2. Forces the sharing of the load submitted to CCS among all the
>CCS available (as of now only DG2 has more than one CCS). This
>way the user, when sending a query, will see only one CCS
>available.
> 
> Andi
> 
> Andi Shyti (2):
>   drm/i915/gt: Disable HW load balancing for CCS
>   drm/i915/gt: Set default CCS mode '1'
> 
>  drivers/gpu/drm/i915/gt/intel_gt.c  | 11 +++
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h |  3 +++
>  drivers/gpu/drm/i915/gt/intel_workarounds.c |  6 ++
>  drivers/gpu/drm/i915/i915_drv.h | 17 +
>  drivers/gpu/drm/i915/i915_query.c   |  5 +++--
>  5 files changed, 40 insertions(+), 2 deletions(-)
> 
> -- 
> 2.43.0


Re: [PATCH 2/2] drm/i915/gt: Set default CCS mode '1'

2024-02-20 Thread Andi Shyti
On Tue, Feb 20, 2024 at 02:27:07PM +, Tvrtko Ursulin wrote:
> 
> On 20/02/2024 14:20, Andi Shyti wrote:
> > Since CCS automatic load balancing is disabled, we will impose a
> > fixed balancing policy that involves setting all the CCS engines
> > to work together on the same load.
> 
> Erm *all* CSS engines work together..
> 
> > Simultaneously, the user will see only 1 CCS rather than the
> > actual number. As of now, this change affects only DG2.
> 
> ... *one* CCS engine.

ops... I sent V1 again!

Sorry, I will send v2 now

Thanks!

Andi


  1   2   >