Re: [Intel-gfx] [PATCH 0/6] drm/i915: Reject bogus modes with fixed mode panels

2021-09-28 Thread Jani Nikula
On Thu, 23 Sep 2021, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Let's start to reject user modes whose refresh rate is
> nowhere near the actual fixed mode refresh rate we're
> going to use. ATM we're just flat out lying to the user.
>
> We'll also pimp the connector's mode list validation 
> a bit.

On the series,

Reviewed-by: Jani Nikula 


>
> Ville Syrjälä (6):
>   drm/i915: Extract intel_panel_mode_valid()
>   drm/i915: Use intel_panel_mode_valid() for DSI/LVDS/DVO
>   drm/i915: Reject modes that don't match fixed_mode vrefresh
>   drm/i915: Introduce intel_panel_compute_config()
>   drm/i915: Reject user modes that don't match fixed mode's refresh rate
>   drm/i915: Drop pointless fixed_mode checks from dsi code
>
>  drivers/gpu/drm/i915/display/icl_dsi.c |  7 ++--
>  drivers/gpu/drm/i915/display/intel_dp.c| 13 ---
>  drivers/gpu/drm/i915/display/intel_dsi.c   | 16 -
>  drivers/gpu/drm/i915/display/intel_dvo.c   | 24 -
>  drivers/gpu/drm/i915/display/intel_lvds.c  | 15 
>  drivers/gpu/drm/i915/display/intel_panel.c | 41 --
>  drivers/gpu/drm/i915/display/intel_panel.h |  5 +++
>  drivers/gpu/drm/i915/display/intel_sdvo.c  | 21 ++-
>  drivers/gpu/drm/i915/display/vlv_dsi.c | 39 +---
>  9 files changed, 116 insertions(+), 65 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center


[Intel-gfx] [PATCH V7] drm/i915/gen11: Disable cursor clock gating in HDR mode

2021-09-28 Thread Tejas Upadhyay
Display underrun in HDR mode when cursor is enabled.
RTL fix will be implemented CLKGATE_DIS_PSL_A bit 28-46520h.
As per W/A 1604331009, Disable cursor clock gating in HDR mode.

Bspec : 33451

Changes since V6:
- Address checkpatch warnings
- Bit ordering
Changes since V5:
- replace intel_de_read with intel_de_rmw - Jani
Changes since V4:
- Added WA needed check - Ville
- Replace BIT with REG_BIT - Ville
- Add WA enable/disable support back which was
  added in V1 - Ville
Changes since V3:
- Disable WA when not in HDR mode or cursor plane
  not active - Ville
- Extract required args from crtc_state - Ville
- Create HDR mode API using bdw_set_pipemisc ref - Ville
- Tested with HDR video as well full setmode, WA
  applies and disables
Changes since V2:
- Made it general gen11 WA
- Removed WA needed check
- Added cursor plane active check
- Once WA enable, software will not disable
Changes since V1:
- Modified way CLKGATE_DIS_PSL bit 28 was modified

Reviewed-by: Ville Syrjälä 
Signed-off-by: Tejas Upadhyay 
---
 drivers/gpu/drm/i915/display/intel_display.c | 32 
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f27c294beb92..7095f78eb353 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -214,6 +214,15 @@ icl_wa_scalerclkgating(struct drm_i915_private *dev_priv, 
enum pipe pipe,
   intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
~DPFR_GATING_DIS);
 }
 
+/* Wa_1604331009:icl,jsl,ehl */
+static void
+icl_wa_cursorclkgating(struct drm_i915_private *dev_priv, enum pipe pipe,
+  bool enable)
+{
+   intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe), CURSOR_GATING_DIS,
+enable ? CURSOR_GATING_DIS : 0);
+}
+
 static bool
 is_trans_port_sync_slave(const struct intel_crtc_state *crtc_state)
 {
@@ -2356,6 +2365,19 @@ static bool needs_scalerclk_wa(const struct 
intel_crtc_state *crtc_state)
return false;
 }
 
+static bool needs_cursorclk_wa(const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
+
+   /* Wa_1604331009:icl,jsl,ehl */
+   if (is_hdr_mode(crtc_state) &&
+   crtc_state->active_planes & BIT(PLANE_CURSOR) &&
+   DISPLAY_VER(dev_priv) == 11)
+   return true;
+
+   return false;
+}
+
 static bool planes_enabling(const struct intel_crtc_state *old_crtc_state,
const struct intel_crtc_state *new_crtc_state)
 {
@@ -2398,6 +2420,11 @@ static void intel_post_plane_update(struct 
intel_atomic_state *state,
if (needs_scalerclk_wa(old_crtc_state) &&
!needs_scalerclk_wa(new_crtc_state))
icl_wa_scalerclkgating(dev_priv, pipe, false);
+
+   if (needs_cursorclk_wa(old_crtc_state) &&
+   !needs_cursorclk_wa(new_crtc_state))
+   icl_wa_cursorclkgating(dev_priv, pipe, false);
+
 }
 
 static void intel_crtc_enable_flip_done(struct intel_atomic_state *state,
@@ -2494,6 +2521,11 @@ static void intel_pre_plane_update(struct 
intel_atomic_state *state,
needs_scalerclk_wa(new_crtc_state))
icl_wa_scalerclkgating(dev_priv, pipe, true);
 
+   /* Wa_1604331009:icl,jsl,ehl */
+   if (!needs_cursorclk_wa(old_crtc_state) &&
+   needs_cursorclk_wa(new_crtc_state))
+   icl_wa_cursorclkgating(dev_priv, pipe, true);
+
/*
 * Vblank time updates from the shadow to live plane control register
 * are blocked if the memory self-refresh mode is active at that
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ef594df039db..3a20a55d2512 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4269,6 +4269,7 @@ enum {
 #define   DUPS1_GATING_DIS (1 << 15)
 #define   DUPS2_GATING_DIS (1 << 19)
 #define   DUPS3_GATING_DIS (1 << 23)
+#define   CURSOR_GATING_DISREG_BIT(28)
 #define   DPF_GATING_DIS   (1 << 10)
 #define   DPF_RAM_GATING_DIS   (1 << 9)
 #define   DPFR_GATING_DIS  (1 << 8)
-- 
2.31.1



[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Update memory bandwidth formulae (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Update memory bandwidth formulae (rev2)
URL   : https://patchwork.freedesktop.org/series/95138/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655_full -> Patchwork_21184_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-iclb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][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]) -> ([FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], 
[FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], 
[FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], 
[FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47], 
[FAIL][48], [FAIL][49], [FAIL][50]) ([i915#3521])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb8/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb8/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb8/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb7/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb5/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb5/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb5/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb4/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb4/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb4/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb3/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb3/boot.html
   [43]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb3/boot.html
   [44]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/shard-iclb2/boot.html
   [45]: 

Re: [Intel-gfx] [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined

2021-09-28 Thread Navare, Manasi D
We have merged such DRM definition dependencies previously through a topic 
branch in order to avoid redefining inside the driver.
But yes guarding this with ifdef is good.

Reviewed-by: Manasi Navare 

Manasi

-Original Message-
From: Zuo, Jerry  
Sent: Tuesday, September 28, 2021 11:11 PM
To: Wentland, Harry ; Deucher, Alexander 
; amd-...@lists.freedesktop.org
Cc: Nikula, Jani ; Li, Sun peng (Leo) 
; nat...@kernel.org; intel-gfx@lists.freedesktop.org; 
dri-de...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Navare, Manasi 
D ; Koenig, Christian ; 
Pan, Xinhui ; s...@canb.auug.org.au; 
linux-n...@vger.kernel.org; airl...@gmail.com; daniel.vet...@ffwll.ch; 
Wentland, Harry 
Subject: RE: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not 
already defined

[AMD Official Use Only]

> -Original Message-
> From: Harry Wentland 
> Sent: September 28, 2021 1:08 PM
> To: Deucher, Alexander ; amd- 
> g...@lists.freedesktop.org; Zuo, Jerry 
> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ; 
> nat...@kernel.org; intel-gfx@lists.freedesktop.org; dri- 
> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com; 
> manasi.d.nav...@intel.com; Koenig, Christian 
> ; Pan, Xinhui ; 
> s...@canb.auug.org.au; linux- n...@vger.kernel.org; airl...@gmail.com; 
> daniel.vet...@ffwll.ch; Wentland, Harry 
> Subject: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not 
> already defined
>
> [Why]
> For some reason we're defining DP 2.0 definitions inside our driver. 
> Now that patches to introduce relevant definitions are slated to be 
> merged into drm- next this is causing conflicts.
>
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
> ./include/drm/drm_dp_helper.h:1322:9: error:
> 'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined [- 
> Werror,-Wmacro-redefined]
> ^
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note:
> previous definition is here
> ^
> 1 error generated.
>
> v2: Add one missing endif
>
> [How]
> Guard all display driver defines with #ifndef for now. Once we pull in 
> the new definitions into amd-staging-drm-next we will follow up and 
> drop definitions from our driver and provide follow-up header updates 
> for any addition DP
> 2.0 definitions required by our driver.
>
> Signed-off-by: Harry Wentland 

Reviewed-by: Fangzhi Zuo 

> ---
>  drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54
> ++--
>  1 file changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> index a5e798b5da79..9de86ff5ef1b 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> @@ -860,28 +860,72 @@ struct psr_caps {  };
>
>  #if defined(CONFIG_DRM_AMD_DC_DCN)
> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
>  #define DP_MAIN_LINK_CHANNEL_CODING_CAP  0x006
> +#endif
> +#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
>  #define DP_SINK_VIDEO_FALLBACK_FORMATS   0x020
> +#endif
> +#ifndef DP_FEC_CAPABILITY_1
>  #define DP_FEC_CAPABILITY_1  0x091
> +#endif
> +#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
>  #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0A3
> +#endif
> +#ifndef DP_DSC_CONFIGURATION
>  #define DP_DSC_CONFIGURATION 0x161
> +#endif
> +#ifndef DP_PHY_SQUARE_PATTERN
>  #define DP_PHY_SQUARE_PATTERN0x249
> +#endif
> +#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
>  #define DP_128b_132b_SUPPORTED_LINK_RATES0x2215
> +#endif
> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>  #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>   0x2216
> +#endif
> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
>  #define DP_TEST_264BIT_CUSTOM_PATTERN_7_00X2230
> +#endif
> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
>  #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256
>   0X2250
> +#endif
> +#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
>  #define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260
> +#endif
> +#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
>  #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
>   0x2270
> -# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK   (1 <<
> 0)
> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
>   (0b111 << 1)
> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT  1
> -# define DP_DSC_DECODER_COUNT_MASK   (0b111 << 5)
> -# define DP_DSC_DECODER_COUNT_SHIFT  5
> +#endif
> +#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
> +#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK(1 <<
> 0)
> +#endif
> +#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
> +#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
>  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update memory bandwidth formulae (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Update memory bandwidth formulae (rev2)
URL   : https://patchwork.freedesktop.org/series/95138/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655 -> Patchwork_21184


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### CI changes ###

 Suppressed 

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

  * boot:
- {fi-jsl-1}: [PASS][1] -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-jsl-1/boot.html
- {fi-ehl-2}: [PASS][3] -> [FAIL][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-ehl-2/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-ehl-2/boot.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-icl-y:   [PASS][5] -> [FAIL][6] ([i915#3521])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-icl-y/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-icl-y/boot.html
- fi-icl-u2:  [PASS][7] -> [FAIL][8] ([i915#3521])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-icl-u2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-icl-u2/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u:   NOTRUN -> [SKIP][9] ([fdo#109271]) +27 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4:  [PASS][11] -> [FAIL][12] ([i915#1888])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u:   NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][14] ([i915#1602] / [i915#2029])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][15] ([i915#2927] / [i915#3428]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [FAIL][17] ([i915#1161]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Warnings 

  * igt@kms_chamelium@vga-hpd-fast:
- fi-kbl-7500u:   [{ABORT}][19] ([i915#1814]) -> [SKIP][20] 
([fdo#109271])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21184/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.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#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3521]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for i915/display: split and constify vtable, again

2021-09-28 Thread Patchwork
== Series Details ==

Series: i915/display: split and constify vtable, again
URL   : https://patchwork.freedesktop.org/series/95184/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655_full -> Patchwork_21183_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][2] ([fdo#109314])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-iclb2/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-tglb8/igt@gem_...@unwedge-stress.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-tglb2/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][5] ([i915#2846])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-apl8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-kbl7/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][10] ([i915#2842]) +1 similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_params@no-bsd:
- shard-tglb: NOTRUN -> [SKIP][11] ([fdo#109283])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-tglb3/igt@gem_exec_par...@no-bsd.html

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

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

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#644])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-glk1/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-apl3/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@unsync-overlap:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#3297])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-iclb2/igt@gem_userptr_bl...@unsync-overlap.html

  * igt@gem_userptr_blits@vma-merge:
- shard-apl:  NOTRUN -> [FAIL][18] ([i915#3318])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-apl3/igt@gem_userptr_bl...@vma-merge.html

  * igt@gem_workarounds@suspend-resume:
- shard-kbl:  [PASS][19] -> [DMESG-WARN][20] ([i915#180])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl4/igt@gem_workarou...@suspend-resume.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-kbl1/igt@gem_workarou...@suspend-resume.html

  * igt@gen7_exec_parse@basic-allocation:
- shard-glk:  NOTRUN -> [SKIP][21] ([fdo#109271]) +33 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-glk7/igt@gen7_exec_pa...@basic-allocation.html

  * igt@gen9_exec_parse@unaligned-jump:
- shard-tglb: NOTRUN -> [SKIP][22] ([i915#2856])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/shard-tglb3/igt@gen9_exec_pa...@unaligned-jump.html

  * igt@i915_pm_rpm@cursor-dpms:
- shard-glk:  

[Intel-gfx] [PATCH v2] drm/i915: Update memory bandwidth formulae

2021-09-28 Thread Radhakrishna Sripada
The formulae has been updated to include more variables. Make
sure the code carries the same.

Bspec: 64631

v2: Make GEN11 follow the default route and fix calculation of
maxdebw(RK)

Cc: Ville Syrjälä 
Suggested-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 71 +++--
 1 file changed, 55 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 4b94256d7319..d24b2000bc3f 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -27,6 +27,9 @@ struct intel_qgv_info {
u8 num_points;
u8 num_psf_points;
u8 t_bl;
+   u8 max_numchannels;
+   u8 channel_width;
+   u8 deinterleave;
 };
 
 static int dg1_mchbar_read_qgv_point_info(struct drm_i915_private *dev_priv,
@@ -137,6 +140,7 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
 {
const struct dram_info *dram_info = _priv->dram_info;
int i, ret;
+   bool is_y_tile = true; /* assume y tile may be used */
 
qi->num_points = dram_info->num_qgv_points;
qi->num_psf_points = dram_info->num_psf_gv_points;
@@ -144,10 +148,31 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
if (DISPLAY_VER(dev_priv) == 12)
switch (dram_info->type) {
case INTEL_DRAM_DDR4:
-   qi->t_bl = 4;
+   qi->t_bl = is_y_tile ? 8 : 4;
+   qi->max_numchannels = 2;
+   qi->channel_width = 64;
+   qi->deinterleave = is_y_tile ? 1 : 2;
break;
case INTEL_DRAM_DDR5:
-   qi->t_bl = 8;
+   qi->t_bl = is_y_tile ? 16 : 8;
+   qi->max_numchannels = 4;
+   qi->channel_width = 32;
+   qi->deinterleave = is_y_tile ? 1 : 2;
+   break;
+   case INTEL_DRAM_LPDDR4:
+   if (IS_ROCKETLAKE(dev_priv)) {
+   qi->t_bl = 8;
+   qi->max_numchannels = 4;
+   qi->channel_width = 32;
+   qi->deinterleave = 2;
+   break;
+   }
+   fallthrough;
+   case INTEL_DRAM_LPDDR5:
+   qi->t_bl = 16;
+   qi->max_numchannels = 8;
+   qi->channel_width = 16;
+   qi->deinterleave = is_y_tile ? 2 : 4;
break;
default:
qi->t_bl = 16;
@@ -263,12 +288,13 @@ static const struct intel_sa_info adlp_sa_info = {
 static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct 
intel_sa_info *sa)
 {
struct intel_qgv_info qi = {};
-   bool is_y_tile = true; /* assume y tile may be used */
+   const struct dram_info *dram_info = _priv->dram_info;
int num_channels = max_t(u8, 1, dev_priv->dram_info.num_channels);
-   int deinterleave;
int ipqdepth, ipqdepthpch;
int dclk_max;
-   int maxdebw;
+   int maxdebw, peakbw;
+   int clperchgroup;
+   int num_groups = ARRAY_SIZE(dev_priv->max_bw);
int i, ret;
 
ret = icl_get_qgv_points(dev_priv, );
@@ -278,22 +304,38 @@ static int icl_get_bw_info(struct drm_i915_private 
*dev_priv, const struct intel
return ret;
}
 
-   deinterleave = DIV_ROUND_UP(num_channels, is_y_tile ? 4 : 2);
-   dclk_max = icl_sagv_max_dclk();
+   if (dram_info->type == INTEL_DRAM_LPDDR4 || dram_info->type == 
INTEL_DRAM_LPDDR5)
+   num_channels *= 2;
+
+   if (num_channels < qi.max_numchannels && DISPLAY_VER(dev_priv) >= 12)
+   qi.deinterleave = DIV_ROUND_UP(qi.deinterleave, 2);
+
+   num_channels = min_t(u8, num_channels, qi.max_numchannels);
+   dclk_max = icl_calc_bw(icl_sagv_max_dclk(), 16, 1);
 
ipqdepthpch = 16;
 
-   maxdebw = min(sa->deprogbwlimit * 1000,
- icl_calc_bw(dclk_max, 16, 1) * 6 / 10); /* 60% */
+   peakbw = num_channels * DIV_ROUND_UP(qi.deinterleave, 8) * dclk_max;
+   maxdebw = min(sa->deprogbwlimit * 1000, peakbw * 6 / 10); /* 60% */
ipqdepth = min(ipqdepthpch, sa->displayrtids / num_channels);
+   /*
+* clperchgroup = 4kpagespermempage * clperchperblock,
+* clperchperblock = 8 /num_channels * interleave
+*/
+   clperchgroup = 4 * DIV_ROUND_UP(8, num_channels) * qi.deinterleave;
 
-   for (i = 0; i < ARRAY_SIZE(dev_priv->max_bw); i++) {
+   for (i = 0; i < num_groups; i++) {
struct intel_bw_info *bi = _priv->max_bw[i];
int clpchgroup;
int j;
 
-   clpchgroup = 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/locking: add backtrace for locking contended locks without backoff

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/locking: add backtrace for locking contended locks without backoff
URL   : https://patchwork.freedesktop.org/series/95182/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655_full -> Patchwork_21182_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][2] ([fdo#109314])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-iclb1/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_ctx_persistence@smoketest:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-snb7/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +3 similar 
issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl4/igt@gem_...@in-flight-suspend.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-kbl1/igt@gem_...@in-flight-suspend.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-tglb8/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-tglb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][8] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-apl3/igt@gem_exec_f...@basic-deadline.html

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

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_params@no-bsd:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109283])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-tglb5/igt@gem_exec_par...@no-bsd.html

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][17] ([i915#2658])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-kbl4/igt@gem_pwr...@basic-exhaustion.html
- shard-apl:  NOTRUN -> [WARN][18] ([i915#2658])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-apl6/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@unsync-overlap:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#3297])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-iclb1/igt@gem_userptr_bl...@unsync-overlap.html

  * igt@gen7_exec_parse@basic-allocation:
- shard-glk:  NOTRUN -> [SKIP][20] ([fdo#109271]) +33 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-glk1/igt@gen7_exec_pa...@basic-allocation.html

  * igt@gen9_exec_parse@unaligned-jump:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#2856])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-tglb5/igt@gen9_exec_pa...@unaligned-jump.html

  * igt@i915_pm_rpm@dpms-non-lpsp:
- shard-iclb: NOTRUN -> [SKIP][22] ([fdo#110892])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/shard-iclb1/igt@i915_pm_...@dpms-non-lpsp.html

  * 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: DP per-lane drive settings prep work (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/i915: DP per-lane drive settings prep work (rev2)
URL   : https://patchwork.freedesktop.org/series/95122/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10655_full -> Patchwork_21181_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@busy-flip@b-edp1:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-skl7/igt@kms_flip@busy-f...@b-edp1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-skl6/igt@kms_flip@busy-f...@b-edp1.html

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-iclb: NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-iclb4/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html

  

### Piglit changes ###

 Possible regressions 

  * 
spec@glsl-1.50@execution@built-in-functions@gs-op-selection-bool-mat2x3-mat2x3 
(NEW):
- pig-snb-2600:   NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/pig-snb-2600/spec@glsl-1.50@execution@built-in-functi...@gs-op-selection-bool-mat2x3-mat2x3.html

  
New tests
-

  New tests have been introduced between CI_DRM_10655_full and 
Patchwork_21181_full:

### New Piglit tests (1) ###

  * 
spec@glsl-1.50@execution@built-in-functions@gs-op-selection-bool-mat2x3-mat2x3:
- Statuses : 1 fail(s)
- Exec time: [0.16] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][5] ([fdo#109314])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-iclb4/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +2 similar 
issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl4/igt@gem_...@in-flight-suspend.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-kbl1/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-kbl4/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2849])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@no-bsd:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109283])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-tglb6/igt@gem_exec_par...@no-bsd.html

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][17] ([i915#2658])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-apl8/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@input-checking:
- shard-snb:  NOTRUN -> [DMESG-WARN][18] ([i915#3002])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/shard-snb2/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@unsync-overlap:
- shard-iclb:  

[Intel-gfx] [PATCH v3] drm/amd/display: Only define DP 2.0 symbols if not already defined

2021-09-28 Thread Harry Wentland
[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.

In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
./include/drm/drm_dp_helper.h:1322:9: error: 
'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined 
[-Werror,-Wmacro-redefined]
^
./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note: previous 
definition is here
^
1 error generated.

[How]
Guard all display driver defines with #ifndef for now. Once we pull
in the new definitions into amd-staging-drm-next we will follow
up and drop definitions from our driver and provide follow-up
header updates for any addition DP 2.0 definitions required
by our driver.

We also ensure drm_dp_helper.h is included before dc_dp_types.h.

v3: Ensure drm_dp_helper.h is included before dc_dp_types.h

v2: Add one missing endif

Signed-off-by: Harry Wentland 
Reviewed-by: Fangzhi Zuo 
---
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54 ++--
 drivers/gpu/drm/amd/display/dc/os_types.h|  1 +
 2 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index a5e798b5da79..9de86ff5ef1b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -860,28 +860,72 @@ struct psr_caps {
 };
 
 #if defined(CONFIG_DRM_AMD_DC_DCN)
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
 #define DP_MAIN_LINK_CHANNEL_CODING_CAP0x006
+#endif
+#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
 #define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
+#endif
+#ifndef DP_FEC_CAPABILITY_1
 #define DP_FEC_CAPABILITY_10x091
+#endif
+#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
 #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0A3
+#endif
+#ifndef DP_DSC_CONFIGURATION
 #define DP_DSC_CONFIGURATION   0x161
+#endif
+#ifndef DP_PHY_SQUARE_PATTERN
 #define DP_PHY_SQUARE_PATTERN  0x249
+#endif
+#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
 #define DP_128b_132b_SUPPORTED_LINK_RATES  0x2215
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL  0x2216
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
 #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0  0X2230
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
 #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256  0X2250
+#endif
+#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
 #define DP_DSC_SUPPORT_AND_DECODER_COUNT   0x2260
+#endif
+#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
 #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0   0x2270
-# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1
-# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
-# define DP_DSC_DECODER_COUNT_SHIFT5
+#endif
+#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
+#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK  (1 << 0)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK  (0b111 << 1)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
+#endif
+#ifndef DP_DSC_DECODER_COUNT_MASK
+#define DP_DSC_DECODER_COUNT_MASK  (0b111 << 5)
+#endif
+#ifndef DP_DSC_DECODER_COUNT_SHIFT
+#define DP_DSC_DECODER_COUNT_SHIFT 5
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
 #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER   0xF0006
+#endif
+#ifndef DP_PHY_REPEATER_128b_132b_RATES
 #define DP_PHY_REPEATER_128b_132b_RATES0xF0007
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER10xF0022
+#endif
+#ifndef DP_INTRA_HOP_AUX_REPLY_INDICATION
 #define DP_INTRA_HOP_AUX_REPLY_INDICATION  (1 << 3)
+#endif
 /* TODO - Use DRM header to replace above once available */
 
 union dp_main_line_channel_coding_cap {
diff --git a/drivers/gpu/drm/amd/display/dc/os_types.h 
b/drivers/gpu/drm/amd/display/dc/os_types.h
index f50cae252de4..34efb708ea12 100644
--- a/drivers/gpu/drm/amd/display/dc/os_types.h
+++ b/drivers/gpu/drm/amd/display/dc/os_types.h
@@ -35,6 +35,7 @@
 #include 
 
 #include 
+#include 
 
 #include "cgs_common.h"
 
-- 
2.33.0



Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

2021-09-28 Thread Matthew Brost
On Tue, Sep 28, 2021 at 04:33:24PM -0700, John Harrison wrote:
> On 9/28/2021 15:33, Matthew Brost wrote:
> > On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:
> > > On 8/20/2021 15:44, Matthew Brost wrote:
> > > > For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
> > > > mid BB. To safely enable preemption at the BB boundary, a handshake
> > > > between to parent and child is needed. This is implemented via custom
> > > > emit_bb_start & emit_fini_breadcrumb functions and enabled via by
> > > via by -> by
> > > 
> > > > default if a context is configured by set parallel extension.
> > > I tend to agree with Tvrtko that this should probably be an opt in change.
> > > Is there a flags word passed in when creating the context?
> > > 
> > I don't disagree but the uAPI in this series is where we landed. It has
> > been acked all by the relevant parties in the RFC, ported to our
> > internal tree, and the media UMD has been updated / posted. Concerns
> > with the uAPI should've been raised in the RFC phase, not now. I really
> > don't feel like changing this uAPI another time.
> The counter argument is that once a UAPI has been merged, it cannot be
> changed. Ever. So it is worth taking the trouble to get it right first time.
> 
> The proposal isn't a major re-write of the interface. It is simply a request
> to set an extra flag when creating the context.
> 

We are basically just talking about the polarity of a flag at this
point. Either by default you can't be preempted mid batch (current GPU /
UMD requirement) or by default you can be preempted mid-batch (no
current GPU / UMD can do this yet but add flags that everyone opts
into). I think Daniel's opinion was just default to what the current GPU
/ UMD wants and if future requirements arise we add flags to the
interface. I understand both points of view for flag / not flag but in
the end it doesn't really matter. Either way the interface works now and
will in the future too.

> 
> > 
> > > Also, it's not just a change in pre-emption behaviour but a change in
> > > synchronisation too, right? Previously, if you had a whole bunch of back 
> > > to
> > > back submissions then one child could run ahead of another and/or the
> > > parent. After this change, there is a forced regroup at the end of each
> > > batch. So while one could end sooner/later than the others, they can't 
> > > ever
> > > get an entire batch (or more) ahead or behind. Or was that synchronisation
> > > already in there through other means anyway?
> > > 
> > Yes, each parent / child sync at the of each batch - this is the only
> > way safely insert preemption points. Without this the GuC could attempt
> > a preemption and hang the batches.
> To be clear, I'm not saying that this is wrong. I'm just saying that this
> appears to be new behaviour with this patch but it is not explicitly called
> out in the description of the patch.
> 

Will add some comments explaining this behavior (unless I already have
them).

> 
> > 
> > > > Signed-off-by: Matthew Brost 
> > > > ---
> > > >drivers/gpu/drm/i915/gt/intel_context.c   |   2 +-
> > > >drivers/gpu/drm/i915/gt/intel_context_types.h |   3 +
> > > >drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   2 +-
> > > >.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 
> > > > +-
> > > >4 files changed, 287 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
> > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > index 5615be32879c..2de62649e275 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > @@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct 
> > > > intel_context *parent,
> > > > GEM_BUG_ON(intel_context_is_child(child));
> > > > GEM_BUG_ON(intel_context_is_parent(child));
> > > > -   parent->guc_number_children++;
> > > > +   child->guc_child_index = parent->guc_number_children++;
> > > > list_add_tail(>guc_child_link,
> > > >   >guc_child_list);
> > > > child->parent = parent;
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
> > > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > index 713d85b0b364..727f91e7f7c2 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > @@ -246,6 +246,9 @@ struct intel_context {
> > > > /** @guc_number_children: number of children if parent 
> > > > */
> > > > u8 guc_number_children;
> > > > +   /** @guc_child_index: index into guc_child_list if 
> > > > child */
> > > > +   u8 guc_child_index;
> > > > +
> > > > /**
> > > >  * @parent_page: page in context used by parent for 
> > > > work queue,
> > > >  * work queue descriptor
> > > > diff --git 

[Intel-gfx] ✓ Fi.CI.BAT: success for i915/display: split and constify vtable, again

2021-09-28 Thread Patchwork
== Series Details ==

Series: i915/display: split and constify vtable, again
URL   : https://patchwork.freedesktop.org/series/95184/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655 -> Patchwork_21183


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@execlists:
- {fi-ehl-2}: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-ehl-2/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-ehl-2/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u:   NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271]) +8 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4:  [PASS][6] -> [FAIL][7] ([i915#1888])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

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

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][13] ([i915#2927] / [i915#3428]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [FAIL][15] ([i915#1161]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Warnings 

  * igt@kms_chamelium@vga-hpd-fast:
- fi-kbl-7500u:   [{ABORT}][17] ([i915#1814]) -> [SKIP][18] 
([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21183/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.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
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/amd/display: Only define DP 2.0 symbols if not already defined (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/amd/display: Only define DP 2.0 symbols if not already defined 
(rev2)
URL   : https://patchwork.freedesktop.org/series/95164/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10655_full -> Patchwork_21180_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fence@syncobj-channel:
- shard-skl:  [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-skl5/igt@gem_exec_fe...@syncobj-channel.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-skl3/igt@gem_exec_fe...@syncobj-channel.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-plflip-blt:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-indfb-plflip-blt.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-primscrn-indfb-plflip-blt.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][6] ([fdo#109314])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-iclb4/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_exec_endless@dispatch@rcs0:
- shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#3778])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb6/igt@gem_exec_endless@dispa...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-iclb3/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-kbl1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][13] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_params@no-bsd:
- shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109283])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-tglb5/igt@gem_exec_par...@no-bsd.html

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-kbl4/igt@gem_pwr...@basic-exhaustion.html
- shard-apl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/shard-apl7/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@input-checking:
- shard-snb:  NOTRUN -> [DMESG-WARN][21] ([i915#3002])
   [21]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915/display: split and constify vtable, again

2021-09-28 Thread Patchwork
== Series Details ==

Series: i915/display: split and constify vtable, again
URL   : https://patchwork.freedesktop.org/series/95184/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
25d35099ae19 drm/i915/uncore: split the fw get function into separate vfunc
5f03d3269e3b drm/i915/pm: drop get_fifo_size vfunc.
24df6bfbd0d7 drm/i915: make update_wm take a dev_priv.
d4b95ca78a50 drm/i915/wm: provide wrappers around watermark vfuncs calls (v3)
-:10: WARNING:TYPO_SPELLING: 'existance' may be misspelled - perhaps 
'existence'?
#10: 
One thing to note is that the code checks the existance of some
  ^

-:31: CHECK:LINE_SPACING: Please don't use multiple blank lines
#31: FILE: drivers/gpu/drm/i915/display/intel_display.c:129:
 
+

-:75: WARNING:LINE_SPACING: Missing a blank line after declarations
#75: FILE: drivers/gpu/drm/i915/display/intel_display.c:173:
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.compute_pipe_wm)

-:84: WARNING:LINE_SPACING: Missing a blank line after declarations
#84: FILE: drivers/gpu/drm/i915/display/intel_display.c:182:
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (!dev_priv->display.compute_intermediate_wm)

-:96: WARNING:LINE_SPACING: Missing a blank line after declarations
#96: FILE: drivers/gpu/drm/i915/display/intel_display.c:194:
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.initial_watermarks) {

-:107: WARNING:LINE_SPACING: Missing a blank line after declarations
#107: FILE: drivers/gpu/drm/i915/display/intel_display.c:205:
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.atomic_update_watermarks)

-:115: WARNING:LINE_SPACING: Missing a blank line after declarations
#115: FILE: drivers/gpu/drm/i915/display/intel_display.c:213:
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.optimize_watermarks)

-:122: WARNING:LINE_SPACING: Missing a blank line after declarations
#122: FILE: drivers/gpu/drm/i915/display/intel_display.c:220:
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.compute_global_watermarks)

-:137: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional 
statements (16, 20)
#137: FILE: drivers/gpu/drm/i915/display/intel_display.c:2636:
+   if (!intel_initial_watermarks(state, crtc))
+   if (new_crtc_state->update_wm_pre)

-:138: WARNING:TABSTOP: Statements should start on a tabstop
#138: FILE: drivers/gpu/drm/i915/display/intel_display.c:2637:
+   if (new_crtc_state->update_wm_pre)

-:179: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional 
statements (8, 12)
#179: FILE: drivers/gpu/drm/i915/display/intel_display.c:3680:
+   if (!intel_initial_watermarks(state, crtc))
+   intel_update_watermarks(dev_priv);

total: 0 errors, 10 warnings, 1 checks, 318 lines checked
d3c4c93bef02 drm/i915: add wrappers around cdclk vtable funcs.
-:32: WARNING:LINE_SPACING: Missing a blank line after declarations
#32: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:71:
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   return dev_priv->display.bw_calc_min_cdclk(state);

total: 0 errors, 1 warnings, 0 checks, 127 lines checked
c4b0939b010d drm/i915/display: add intel_fdi_link_train wrapper.
9d3f3b043262 drm/i915: split clock gating init from display vtable
8df3e5e24fe7 drm/i915: split watermark vfuncs from display vtable.
80ba7c9dbea7 drm/i915: split color functions from display vtable
a81f8a74d4b1 drm/i915: split audio functions from display vtable
3ae5dbfc9499 drm/i915: split cdclk functions from display vtable.
6e370e4bdfb0 drm/i915: split irq hotplug function from display vtable
79b631289768 drm/i915: split fdi link training from display vtable.
0395cf21d5df drm/i915: split the dpll clock compute out from display vtable.
d526b29f70d4 drm/i915: constify fdi link training vtable
6827900a4832 drm/i915: constify hotplug function vtable.
096e5c68a7c4 drm/i915: constify color function vtable.
-:197: CHECK:BRACES: Unbalanced braces around else statement
#197: FILE: drivers/gpu/drm/i915/display/intel_color.c:2194:
+   } else

total: 0 errors, 0 warnings, 1 checks, 187 lines checked
a78732944517 drm/i915: constify the audio function vtable
ddb35a2f7d67 drm/i915: constify the dpll clock vtable
878a6d800e78 drm/i915: constify the cdclk vtable
b7681cd2bcf8 drm/i915: drop unused function ptr and comments.
f29192572174 drm/i915: constify display function vtable
19f4875109d1 drm/i915: constify clock gating init vtable.
3b9c79bb2e0a drm/i915: constify display wm vtable




Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

2021-09-28 Thread John Harrison

On 9/28/2021 15:33, Matthew Brost wrote:

On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:

On 8/20/2021 15:44, Matthew Brost wrote:

For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functions and enabled via by

via by -> by


default if a context is configured by set parallel extension.

I tend to agree with Tvrtko that this should probably be an opt in change.
Is there a flags word passed in when creating the context?


I don't disagree but the uAPI in this series is where we landed. It has
been acked all by the relevant parties in the RFC, ported to our
internal tree, and the media UMD has been updated / posted. Concerns
with the uAPI should've been raised in the RFC phase, not now. I really
don't feel like changing this uAPI another time.
The counter argument is that once a UAPI has been merged, it cannot be 
changed. Ever. So it is worth taking the trouble to get it right first 
time.


The proposal isn't a major re-write of the interface. It is simply a 
request to set an extra flag when creating the context.






Also, it's not just a change in pre-emption behaviour but a change in
synchronisation too, right? Previously, if you had a whole bunch of back to
back submissions then one child could run ahead of another and/or the
parent. After this change, there is a forced regroup at the end of each
batch. So while one could end sooner/later than the others, they can't ever
get an entire batch (or more) ahead or behind. Or was that synchronisation
already in there through other means anyway?


Yes, each parent / child sync at the of each batch - this is the only
way safely insert preemption points. Without this the GuC could attempt
a preemption and hang the batches.
To be clear, I'm not saying that this is wrong. I'm just saying that 
this appears to be new behaviour with this patch but it is not 
explicitly called out in the description of the patch.






Signed-off-by: Matthew Brost 
---
   drivers/gpu/drm/i915/gt/intel_context.c   |   2 +-
   drivers/gpu/drm/i915/gt/intel_context_types.h |   3 +
   drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   2 +-
   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 +-
   4 files changed, 287 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5615be32879c..2de62649e275 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct intel_context 
*parent,
GEM_BUG_ON(intel_context_is_child(child));
GEM_BUG_ON(intel_context_is_parent(child));
-   parent->guc_number_children++;
+   child->guc_child_index = parent->guc_number_children++;
list_add_tail(>guc_child_link,
  >guc_child_list);
child->parent = parent;
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 713d85b0b364..727f91e7f7c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -246,6 +246,9 @@ struct intel_context {
/** @guc_number_children: number of children if parent */
u8 guc_number_children;
+   /** @guc_child_index: index into guc_child_list if child */
+   u8 guc_child_index;
+
/**
 * @parent_page: page in context used by parent for work queue,
 * work queue descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 6cd26dc060d1..9f61cfa5566a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -188,7 +188,7 @@ struct guc_process_desc {
u32 wq_status;
u32 engine_presence;
u32 priority;
-   u32 reserved[30];
+   u32 reserved[36];

What is this extra space for? All the extra storage is grabbed from after
the end of this structure, isn't it?


This is the size of process descriptor in the GuC spec. Even though this
is unused space we really don't want the child go / join memory using
anything within the process descriptor.
Okay. So it's more that the code was previously broken and we just 
hadn't hit a problem because of it? Again, worth adding a comment in the 
description to call it out as a bug fix.





   } __packed;
   #define CONTEXT_REGISTRATION_FLAG_KMDBIT(0)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 91330525330d..1a18f99bf12a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -11,6 +11,7 @@

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/locking: add backtrace for locking contended locks without backoff

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/locking: add backtrace for locking contended locks without backoff
URL   : https://patchwork.freedesktop.org/series/95182/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655 -> Patchwork_21182


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [PASS][4] -> [FAIL][5] ([i915#1888])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

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

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][11] ([i915#2927] / [i915#3428]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [FAIL][13] ([i915#1161]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Warnings 

  * igt@kms_chamelium@vga-hpd-fast:
- fi-kbl-7500u:   [{ABORT}][15] ([i915#1814]) -> [SKIP][16] 
([fdo#109271])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21182/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (45 -> 35)
--

  Additional (1): fi-kbl-soraka 
  Missing(11): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-hsw-4200u fi-icl-u2 
fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 bat-jsl-2 bat-jsl-1 fi-snb-2600 


Build changes
-

  * Linux: CI_DRM_10655 -> Patchwork_21182

  CI-20190529: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/locking: add backtrace for locking contended locks without backoff

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/locking: add backtrace for locking contended locks without backoff
URL   : https://patchwork.freedesktop.org/series/95182/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
420743808c1f drm/locking: add backtrace for locking contended locks without 
backoff
-:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#19: 
<7> [98.002465] drm_modeset_lock attempting to lock a contended lock without 
backoff:

-:112: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#112: FILE: drivers/gpu/drm/drm_modeset_lock.c:115:
+}
+static void __stack_depot_print(depot_stack_handle_t stack_depot)

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




[Intel-gfx] [PATCH 24/24] drm/i915: constify display wm vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

Use a nop table for the cases where CxSR doesn't init properly.

v2: use a nop table (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 34 -
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 80 ++--
 3 files changed, 75 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index bf3298cc1f6c..b405779186e4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -162,16 +162,16 @@ static void intel_modeset_setup_hw_state(struct 
drm_device *dev,
  */
 static void intel_update_watermarks(struct drm_i915_private *dev_priv)
 {
-   if (dev_priv->wm_disp.update_wm)
-   dev_priv->wm_disp.update_wm(dev_priv);
+   if (dev_priv->wm_disp->update_wm)
+   dev_priv->wm_disp->update_wm(dev_priv);
 }
 
 static int intel_compute_pipe_wm(struct intel_atomic_state *state,
 struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->wm_disp.compute_pipe_wm)
-   return dev_priv->wm_disp.compute_pipe_wm(state, crtc);
+   if (dev_priv->wm_disp->compute_pipe_wm)
+   return dev_priv->wm_disp->compute_pipe_wm(state, crtc);
return 0;
 }
 
@@ -179,20 +179,20 @@ static int intel_compute_intermediate_wm(struct 
intel_atomic_state *state,
 struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (!dev_priv->wm_disp.compute_intermediate_wm)
+   if (!dev_priv->wm_disp->compute_intermediate_wm)
return 0;
if (drm_WARN_ON(_priv->drm,
-   !dev_priv->wm_disp.compute_pipe_wm))
+   !dev_priv->wm_disp->compute_pipe_wm))
return 0;
-   return dev_priv->wm_disp.compute_intermediate_wm(state, crtc);
+   return dev_priv->wm_disp->compute_intermediate_wm(state, crtc);
 }
 
 static bool intel_initial_watermarks(struct intel_atomic_state *state,
 struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->wm_disp.initial_watermarks) {
-   dev_priv->wm_disp.initial_watermarks(state, crtc);
+   if (dev_priv->wm_disp->initial_watermarks) {
+   dev_priv->wm_disp->initial_watermarks(state, crtc);
return true;
}
return false;
@@ -202,23 +202,23 @@ static void intel_atomic_update_watermarks(struct 
intel_atomic_state *state,
   struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->wm_disp.atomic_update_watermarks)
-   dev_priv->wm_disp.atomic_update_watermarks(state, crtc);
+   if (dev_priv->wm_disp->atomic_update_watermarks)
+   dev_priv->wm_disp->atomic_update_watermarks(state, crtc);
 }
 
 static void intel_optimize_watermarks(struct intel_atomic_state *state,
  struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->wm_disp.optimize_watermarks)
-   dev_priv->wm_disp.optimize_watermarks(state, crtc);
+   if (dev_priv->wm_disp->optimize_watermarks)
+   dev_priv->wm_disp->optimize_watermarks(state, crtc);
 }
 
 static int intel_compute_global_watermarks(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->wm_disp.compute_global_watermarks)
-   return dev_priv->wm_disp.compute_global_watermarks(state);
+   if (dev_priv->wm_disp->compute_global_watermarks)
+   return dev_priv->wm_disp->compute_global_watermarks(state);
return 0;
 }
 
@@ -3744,7 +3744,7 @@ static void i9xx_crtc_disable(struct intel_atomic_state 
*state,
if (DISPLAY_VER(dev_priv) != 2)
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
 
-   if (!dev_priv->wm_disp.initial_watermarks)
+   if (!dev_priv->wm_disp->initial_watermarks)
intel_update_watermarks(dev_priv);
 
/* clock the pipe down to 640x480@60 to potentially save power */
@@ -11426,7 +11426,7 @@ static void sanitize_watermarks(struct drm_i915_private 
*dev_priv)
int i;
 
/* Only supported on platforms that use atomic watermark design */
-   if (!dev_priv->wm_disp.optimize_watermarks)
+   if (!dev_priv->wm_disp->optimize_watermarks)
return;
 
state = drm_atomic_state_alloc(_priv->drm);
diff --git a/drivers/gpu/drm/i915/i915_drv.h 

[Intel-gfx] [PATCH 23/24] drm/i915: constify clock gating init vtable.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

I used a macro to avoid making any really silly mistakes here.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_pm.c | 78 +++--
 2 files changed, 55 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c94a70155937..21f2e97bf122 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -975,7 +975,7 @@ struct drm_i915_private {
struct workqueue_struct *flip_wq;
 
/* pm private clock gating functions */
-   struct drm_i915_clock_gating_funcs clock_gating_funcs;
+   const struct drm_i915_clock_gating_funcs *clock_gating_funcs;
 
/* pm display functions */
struct drm_i915_wm_disp_funcs wm_disp;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b37888781ec9..08e0195edeb7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7869,7 +7869,7 @@ static void i830_init_clock_gating(struct 
drm_i915_private *dev_priv)
 
 void intel_init_clock_gating(struct drm_i915_private *dev_priv)
 {
-   dev_priv->clock_gating_funcs.init_clock_gating(dev_priv);
+   dev_priv->clock_gating_funcs->init_clock_gating(dev_priv);
 }
 
 void intel_suspend_hw(struct drm_i915_private *dev_priv)
@@ -7884,6 +7884,36 @@ static void nop_init_clock_gating(struct 
drm_i915_private *dev_priv)
"No clock gating settings or workarounds applied.\n");
 }
 
+#define CG_FUNCS(platform) \
+static const struct drm_i915_clock_gating_funcs platform##_clock_gating_funcs 
= { \
+   .init_clock_gating = platform##_init_clock_gating,  \
+}
+
+CG_FUNCS(adlp);
+CG_FUNCS(dg1);
+CG_FUNCS(gen12lp);
+CG_FUNCS(icl);
+CG_FUNCS(cfl);
+CG_FUNCS(skl);
+CG_FUNCS(kbl);
+CG_FUNCS(bxt);
+CG_FUNCS(glk);
+CG_FUNCS(bdw);
+CG_FUNCS(chv);
+CG_FUNCS(hsw);
+CG_FUNCS(ivb);
+CG_FUNCS(vlv);
+CG_FUNCS(gen6);
+CG_FUNCS(ilk);
+CG_FUNCS(g4x);
+CG_FUNCS(i965gm);
+CG_FUNCS(i965g);
+CG_FUNCS(gen3);
+CG_FUNCS(i85x);
+CG_FUNCS(i830);
+CG_FUNCS(nop);
+#undef CG_FUNCS
+
 /**
  * intel_init_clock_gating_hooks - setup the clock gating hooks
  * @dev_priv: device private
@@ -7896,52 +7926,52 @@ static void nop_init_clock_gating(struct 
drm_i915_private *dev_priv)
 void intel_init_clock_gating_hooks(struct drm_i915_private *dev_priv)
 {
if (IS_ALDERLAKE_P(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
adlp_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_DG1(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
dg1_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (GRAPHICS_VER(dev_priv) == 12)
-   dev_priv->clock_gating_funcs.init_clock_gating = 
gen12lp_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (GRAPHICS_VER(dev_priv) == 11)
-   dev_priv->clock_gating_funcs.init_clock_gating = 
icl_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_COFFEELAKE(dev_priv) || IS_COMETLAKE(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
cfl_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_SKYLAKE(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
skl_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_KABYLAKE(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
kbl_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_BROXTON(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
bxt_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_GEMINILAKE(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
glk_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_BROADWELL(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
bdw_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_CHERRYVIEW(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
chv_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_HASWELL(dev_priv))
-   dev_priv->clock_gating_funcs.init_clock_gating = 
hsw_init_clock_gating;
+   dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_IVYBRIDGE(dev_priv))
-   

[Intel-gfx] [PATCH 22/24] drm/i915: constify display function vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

Make nice clear tables instead of having things in two places.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 81 
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 2 files changed, 52 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index d6c051dbfaf3..bf3298cc1f6c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3798,7 +3798,7 @@ static void intel_crtc_disable_noatomic(struct intel_crtc 
*crtc,
 
drm_WARN_ON(_priv->drm, IS_ERR(temp_crtc_state) || ret);
 
-   dev_priv->display.crtc_disable(to_intel_atomic_state(state), crtc);
+   dev_priv->display->crtc_disable(to_intel_atomic_state(state), crtc);
 
drm_atomic_state_put(state);
 
@@ -6007,7 +6007,7 @@ static bool intel_crtc_get_pipe_config(struct 
intel_crtc_state *crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
 
-   if (!i915->display.get_pipe_config(crtc, crtc_state))
+   if (!i915->display->get_pipe_config(crtc, crtc_state))
return false;
 
crtc_state->hw.active = true;
@@ -9817,7 +9817,7 @@ static void intel_enable_crtc(struct intel_atomic_state 
*state,
 
intel_crtc_update_active_timings(new_crtc_state);
 
-   dev_priv->display.crtc_enable(state, crtc);
+   dev_priv->display->crtc_enable(state, crtc);
 
if (new_crtc_state->bigjoiner_slave)
return;
@@ -9905,7 +9905,7 @@ static void intel_old_crtc_state_disables(struct 
intel_atomic_state *state,
 */
intel_crtc_disable_pipe_crc(crtc);
 
-   dev_priv->display.crtc_disable(state, crtc);
+   dev_priv->display->crtc_disable(state, crtc);
crtc->active = false;
intel_fbc_disable(crtc);
intel_disable_shared_dpll(old_crtc_state);
@@ -10285,7 +10285,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
}
 
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
-   dev_priv->display.commit_modeset_enables(state);
+   dev_priv->display->commit_modeset_enables(state);
 
if (state->modeset) {
intel_encoders_update_complete(state);
@@ -11289,6 +11289,46 @@ static const struct drm_mode_config_funcs 
intel_mode_funcs = {
.atomic_state_free = intel_atomic_state_free,
 };
 
+static const struct drm_i915_display_funcs skl_display_funcs = {
+   .get_pipe_config = hsw_get_pipe_config,
+   .crtc_enable = hsw_crtc_enable,
+   .crtc_disable = hsw_crtc_disable,
+   .commit_modeset_enables = skl_commit_modeset_enables,
+   .get_initial_plane_config = skl_get_initial_plane_config,
+};
+
+static const struct drm_i915_display_funcs ddi_display_funcs = {
+   .get_pipe_config = hsw_get_pipe_config,
+   .crtc_enable = hsw_crtc_enable,
+   .crtc_disable = hsw_crtc_disable,
+   .commit_modeset_enables = intel_commit_modeset_enables,
+   .get_initial_plane_config = i9xx_get_initial_plane_config,
+};
+
+static const struct drm_i915_display_funcs pch_split_display_funcs = {
+   .get_pipe_config = ilk_get_pipe_config,
+   .crtc_enable = ilk_crtc_enable,
+   .crtc_disable = ilk_crtc_disable,
+   .commit_modeset_enables = intel_commit_modeset_enables,
+   .get_initial_plane_config = i9xx_get_initial_plane_config,
+};
+
+static const struct drm_i915_display_funcs vlv_display_funcs = {
+   .get_pipe_config = i9xx_get_pipe_config,
+   .crtc_enable = valleyview_crtc_enable,
+   .crtc_disable = i9xx_crtc_disable,
+   .commit_modeset_enables = intel_commit_modeset_enables,
+   .get_initial_plane_config = i9xx_get_initial_plane_config,
+};
+
+static const struct drm_i915_display_funcs i9xx_display_funcs = {
+   .get_pipe_config = i9xx_get_pipe_config,
+   .crtc_enable = i9xx_crtc_enable,
+   .crtc_disable = i9xx_crtc_disable,
+   .commit_modeset_enables = intel_commit_modeset_enables,
+   .get_initial_plane_config = i9xx_get_initial_plane_config,
+};
+
 /**
  * intel_init_display_hooks - initialize the display modesetting hooks
  * @dev_priv: device private
@@ -11304,38 +11344,19 @@ void intel_init_display_hooks(struct drm_i915_private 
*dev_priv)
intel_dpll_init_clock_hook(dev_priv);
 
if (DISPLAY_VER(dev_priv) >= 9) {
-   dev_priv->display.get_pipe_config = hsw_get_pipe_config;
-   dev_priv->display.crtc_enable = hsw_crtc_enable;
-   dev_priv->display.crtc_disable = hsw_crtc_disable;
+   dev_priv->display = _display_funcs;
} else if (HAS_DDI(dev_priv)) {
-   dev_priv->display.get_pipe_config = hsw_get_pipe_config;
-   

[Intel-gfx] [PATCH 21/24] drm/i915: drop unused function ptr and comments.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

There was some excess comments and an unused vtbl ptr.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0f4de0461fe6..5ddb434c1f10 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -409,13 +409,6 @@ struct drm_i915_display_funcs {
void (*crtc_disable)(struct intel_atomic_state *state,
 struct intel_crtc *crtc);
void (*commit_modeset_enables)(struct intel_atomic_state *state);
-   void (*commit_modeset_disables)(struct intel_atomic_state *state);
-
-   /* clock updates for mode set */
-   /* cursor updates */
-   /* render clock increase/decrease */
-   /* display clock increase/decrease */
-   /* pll clock increase/decrease */
 };
 
 
-- 
2.30.2



[Intel-gfx] [PATCH 20/24] drm/i915: constify the cdclk vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

This is a bit of a twisty one since each platform is slightly
different, so might take some more review care.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 300 ++---
 drivers/gpu/drm/i915/i915_drv.h|   2 +-
 2 files changed, 206 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index cf0a865df596..ecb28e8f1eb6 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -62,32 +62,32 @@
 void intel_cdclk_get_cdclk(struct drm_i915_private *dev_priv,
   struct intel_cdclk_config *cdclk_config)
 {
-   dev_priv->cdclk_funcs.get_cdclk(dev_priv, cdclk_config);
+   dev_priv->cdclk_funcs->get_cdclk(dev_priv, cdclk_config);
 }
 
 int intel_cdclk_bw_calc_min_cdclk(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   return dev_priv->cdclk_funcs.bw_calc_min_cdclk(state);
+   return dev_priv->cdclk_funcs->bw_calc_min_cdclk(state);
 }
 
 static void intel_cdclk_set_cdclk(struct drm_i915_private *dev_priv,
  const struct intel_cdclk_config *cdclk_config,
  enum pipe pipe)
 {
-   dev_priv->cdclk_funcs.set_cdclk(dev_priv, cdclk_config, pipe);
+   dev_priv->cdclk_funcs->set_cdclk(dev_priv, cdclk_config, pipe);
 }
 
 static int intel_cdclk_modeset_calc_cdclk(struct drm_i915_private *dev_priv,
  struct intel_cdclk_state 
*cdclk_config)
 {
-   return dev_priv->cdclk_funcs.modeset_calc_cdclk(cdclk_config);
+   return dev_priv->cdclk_funcs->modeset_calc_cdclk(cdclk_config);
 }
 
 static u8 intel_cdclk_calc_voltage_level(struct drm_i915_private *dev_priv,
 int cdclk)
 {
-   return dev_priv->cdclk_funcs.calc_voltage_level(cdclk);
+   return dev_priv->cdclk_funcs->calc_voltage_level(cdclk);
 }
 
 static void fixed_133mhz_get_cdclk(struct drm_i915_private *dev_priv,
@@ -1963,7 +1963,7 @@ static void intel_set_cdclk(struct drm_i915_private 
*dev_priv,
if (!intel_cdclk_changed(_priv->cdclk.hw, cdclk_config))
return;
 
-   if (drm_WARN_ON_ONCE(_priv->drm, !dev_priv->cdclk_funcs.set_cdclk))
+   if (drm_WARN_ON_ONCE(_priv->drm, !dev_priv->cdclk_funcs->set_cdclk))
return;
 
intel_dump_cdclk_config(cdclk_config, "Changing CDCLK to");
@@ -2884,6 +2884,157 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
return freq;
 }
 
+static struct intel_cdclk_funcs tgl_cdclk_funcs = {
+   .get_cdclk = bxt_get_cdclk,
+   .set_cdclk = bxt_set_cdclk,
+   .bw_calc_min_cdclk = skl_bw_calc_min_cdclk,
+   .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+   .calc_voltage_level = tgl_calc_voltage_level,
+};
+
+static struct intel_cdclk_funcs ehl_cdclk_funcs = {
+   .get_cdclk = bxt_get_cdclk,
+   .set_cdclk = bxt_set_cdclk,
+   .bw_calc_min_cdclk = skl_bw_calc_min_cdclk,
+   .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+   .calc_voltage_level = ehl_calc_voltage_level,
+};
+
+static struct intel_cdclk_funcs icl_cdclk_funcs = {
+   .get_cdclk = bxt_get_cdclk,
+   .set_cdclk = bxt_set_cdclk,
+   .bw_calc_min_cdclk = skl_bw_calc_min_cdclk,
+   .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+   .calc_voltage_level = icl_calc_voltage_level,
+};
+
+static struct intel_cdclk_funcs bxt_cdclk_funcs = {
+   .get_cdclk = bxt_get_cdclk,
+   .set_cdclk = bxt_set_cdclk,
+   .bw_calc_min_cdclk = skl_bw_calc_min_cdclk,
+   .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+   .calc_voltage_level = bxt_calc_voltage_level,
+};
+
+static struct intel_cdclk_funcs skl_cdclk_funcs = {
+   .get_cdclk = skl_get_cdclk,
+   .set_cdclk = skl_set_cdclk,
+   .bw_calc_min_cdclk = skl_bw_calc_min_cdclk,
+   .modeset_calc_cdclk = skl_modeset_calc_cdclk,
+};
+
+static struct intel_cdclk_funcs bdw_cdclk_funcs = {
+   .get_cdclk = bdw_get_cdclk,
+   .set_cdclk = bdw_set_cdclk,
+   .bw_calc_min_cdclk = intel_bw_calc_min_cdclk,
+   .modeset_calc_cdclk = bdw_modeset_calc_cdclk,
+};
+
+static struct intel_cdclk_funcs chv_cdclk_funcs = {
+   .get_cdclk = vlv_get_cdclk,
+   .set_cdclk = chv_set_cdclk,
+   .bw_calc_min_cdclk = intel_bw_calc_min_cdclk,
+   .modeset_calc_cdclk = vlv_modeset_calc_cdclk,
+};
+
+static struct intel_cdclk_funcs vlv_cdclk_funcs = {
+   .get_cdclk = vlv_get_cdclk,
+   .set_cdclk = vlv_set_cdclk,
+   .bw_calc_min_cdclk = intel_bw_calc_min_cdclk,
+   .modeset_calc_cdclk = vlv_modeset_calc_cdclk,
+};
+
+static struct intel_cdclk_funcs hsw_cdclk_funcs = {
+   .get_cdclk = hsw_get_cdclk,
+   .bw_calc_min_cdclk = intel_bw_calc_min_cdclk,
+ 

[Intel-gfx] [PATCH 19/24] drm/i915: constify the dpll clock vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

Most the dpll vtable into read-only memory.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c |  6 +--
 drivers/gpu/drm/i915/display/intel_dpll.c| 48 
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 3 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 37d40ab4049c..d6c051dbfaf3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6834,10 +6834,10 @@ static int intel_crtc_atomic_check(struct 
intel_atomic_state *state,
crtc_state->update_wm_post = true;
 
if (mode_changed && crtc_state->hw.enable &&
-   dev_priv->dpll_funcs.crtc_compute_clock &&
+   dev_priv->dpll_funcs &&
!crtc_state->bigjoiner_slave &&
!drm_WARN_ON(_priv->drm, crtc_state->shared_dpll)) {
-   ret = dev_priv->dpll_funcs.crtc_compute_clock(crtc_state);
+   ret = dev_priv->dpll_funcs->crtc_compute_clock(crtc_state);
if (ret)
return ret;
}
@@ -8864,7 +8864,7 @@ static void intel_modeset_clear_plls(struct 
intel_atomic_state *state)
struct intel_crtc *crtc;
int i;
 
-   if (!dev_priv->dpll_funcs.crtc_compute_clock)
+   if (!dev_priv->dpll_funcs)
return;
 
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 7811f19acb6a..784e3ee658b5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1365,25 +1365,57 @@ static int i8xx_crtc_compute_clock(struct 
intel_crtc_state *crtc_state)
return 0;
 }
 
+static const struct intel_dpll_funcs hsw_dpll_funcs = {
+   .crtc_compute_clock = hsw_crtc_compute_clock,
+};
+
+static const struct intel_dpll_funcs ilk_dpll_funcs = {
+   .crtc_compute_clock = ilk_crtc_compute_clock,
+};
+
+static const struct intel_dpll_funcs chv_dpll_funcs = {
+   .crtc_compute_clock = chv_crtc_compute_clock,
+};
+
+static const struct intel_dpll_funcs vlv_dpll_funcs = {
+   .crtc_compute_clock = vlv_crtc_compute_clock,
+};
+
+static const struct intel_dpll_funcs g4x_dpll_funcs = {
+   .crtc_compute_clock = g4x_crtc_compute_clock,
+};
+
+static const struct intel_dpll_funcs pnv_dpll_funcs = {
+   .crtc_compute_clock = pnv_crtc_compute_clock,
+};
+
+static const struct intel_dpll_funcs i9xx_dpll_funcs = {
+   .crtc_compute_clock = i9xx_crtc_compute_clock,
+};
+
+static const struct intel_dpll_funcs i8xx_dpll_funcs = {
+   .crtc_compute_clock = i8xx_crtc_compute_clock,
+};
+
 void
 intel_dpll_init_clock_hook(struct drm_i915_private *dev_priv)
 {
if (DISPLAY_VER(dev_priv) >= 9 || HAS_DDI(dev_priv))
-   dev_priv->dpll_funcs.crtc_compute_clock = 
hsw_crtc_compute_clock;
+   dev_priv->dpll_funcs = _dpll_funcs;
else if (HAS_PCH_SPLIT(dev_priv))
-   dev_priv->dpll_funcs.crtc_compute_clock = 
ilk_crtc_compute_clock;
+   dev_priv->dpll_funcs = _dpll_funcs;
else if (IS_CHERRYVIEW(dev_priv))
-   dev_priv->dpll_funcs.crtc_compute_clock = 
chv_crtc_compute_clock;
+   dev_priv->dpll_funcs = _dpll_funcs;
else if (IS_VALLEYVIEW(dev_priv))
-   dev_priv->dpll_funcs.crtc_compute_clock = 
vlv_crtc_compute_clock;
+   dev_priv->dpll_funcs = _dpll_funcs;
else if (IS_G4X(dev_priv))
-   dev_priv->dpll_funcs.crtc_compute_clock = 
g4x_crtc_compute_clock;
+   dev_priv->dpll_funcs = _dpll_funcs;
else if (IS_PINEVIEW(dev_priv))
-   dev_priv->dpll_funcs.crtc_compute_clock = 
pnv_crtc_compute_clock;
+   dev_priv->dpll_funcs = _dpll_funcs;
else if (DISPLAY_VER(dev_priv) != 2)
-   dev_priv->dpll_funcs.crtc_compute_clock = 
i9xx_crtc_compute_clock;
+   dev_priv->dpll_funcs = _dpll_funcs;
else
-   dev_priv->dpll_funcs.crtc_compute_clock = 
i8xx_crtc_compute_clock;
+   dev_priv->dpll_funcs = _dpll_funcs;
 }
 
 static bool i9xx_has_pps(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 25d79e9df783..0ae643362e15 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -994,7 +994,7 @@ struct drm_i915_private {
const struct intel_fdi_funcs *fdi_funcs;
 
/* display pll funcs */
-   struct intel_dpll_funcs dpll_funcs;
+   const struct intel_dpll_funcs *dpll_funcs;
 
/* Display functions */
struct drm_i915_display_funcs display;
-- 
2.30.2



[Intel-gfx] [PATCH 18/24] drm/i915: constify the audio function vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

Move the functions into read-only tables.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 43 ++
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 2 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index bf96d1529775..03e8c05a74f6 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -848,10 +848,10 @@ void intel_audio_codec_enable(struct intel_encoder 
*encoder,
 
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
 
-   if (dev_priv->audio_funcs.audio_codec_enable)
-   dev_priv->audio_funcs.audio_codec_enable(encoder,
-crtc_state,
-conn_state);
+   if (dev_priv->audio_funcs)
+   dev_priv->audio_funcs->audio_codec_enable(encoder,
+ crtc_state,
+ conn_state);
 
mutex_lock(_priv->av_mutex);
encoder->audio_connector = connector;
@@ -893,10 +893,10 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
 
-   if (dev_priv->audio_funcs.audio_codec_disable)
-   dev_priv->audio_funcs.audio_codec_disable(encoder,
- old_crtc_state,
- old_conn_state);
+   if (dev_priv->audio_funcs)
+   dev_priv->audio_funcs->audio_codec_disable(encoder,
+  old_crtc_state,
+  old_conn_state);
 
mutex_lock(_priv->av_mutex);
encoder->audio_connector = NULL;
@@ -915,6 +915,21 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
intel_lpe_audio_notify(dev_priv, pipe, port, NULL, 0, false);
 }
 
+static const struct intel_audio_funcs g4x_audio_funcs = {
+   .audio_codec_enable = g4x_audio_codec_enable,
+   .audio_codec_disable = g4x_audio_codec_disable,
+};
+
+static const struct intel_audio_funcs ilk_audio_funcs = {
+   .audio_codec_enable = ilk_audio_codec_enable,
+   .audio_codec_disable = ilk_audio_codec_disable,
+};
+
+static const struct intel_audio_funcs hsw_audio_funcs = {
+   .audio_codec_enable = hsw_audio_codec_enable,
+   .audio_codec_disable = hsw_audio_codec_disable,
+};
+
 /**
  * intel_init_audio_hooks - Set up chip specific audio hooks
  * @dev_priv: device private
@@ -922,17 +937,13 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
 void intel_init_audio_hooks(struct drm_i915_private *dev_priv)
 {
if (IS_G4X(dev_priv)) {
-   dev_priv->audio_funcs.audio_codec_enable = 
g4x_audio_codec_enable;
-   dev_priv->audio_funcs.audio_codec_disable = 
g4x_audio_codec_disable;
+   dev_priv->audio_funcs = _audio_funcs;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   dev_priv->audio_funcs.audio_codec_enable = 
ilk_audio_codec_enable;
-   dev_priv->audio_funcs.audio_codec_disable = 
ilk_audio_codec_disable;
+   dev_priv->audio_funcs = _audio_funcs;
} else if (IS_HASWELL(dev_priv) || DISPLAY_VER(dev_priv) >= 8) {
-   dev_priv->audio_funcs.audio_codec_enable = 
hsw_audio_codec_enable;
-   dev_priv->audio_funcs.audio_codec_disable = 
hsw_audio_codec_disable;
+   dev_priv->audio_funcs = _audio_funcs;
} else if (HAS_PCH_SPLIT(dev_priv)) {
-   dev_priv->audio_funcs.audio_codec_enable = 
ilk_audio_codec_enable;
-   dev_priv->audio_funcs.audio_codec_disable = 
ilk_audio_codec_disable;
+   dev_priv->audio_funcs = _audio_funcs;
}
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ddd921a0c141..25d79e9df783 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1003,7 +1003,7 @@ struct drm_i915_private {
const struct intel_color_funcs *color_funcs;
 
/* Display internal audio functions */
-   struct intel_audio_funcs audio_funcs;
+   const struct intel_audio_funcs *audio_funcs;
 
/* Display CDCLK functions */
struct intel_cdclk_funcs cdclk_funcs;
-- 
2.30.2



[Intel-gfx] [PATCH 17/24] drm/i915: constify color function vtable.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

This clarifies quite well what functions get used on what platforms
instead of having to decipher the old tree.

v2: fixed IVB mistake (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_color.c | 138 ++---
 drivers/gpu/drm/i915/i915_drv.h|   2 +-
 2 files changed, 93 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index ed79075158dd..f5923f1c38bd 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1137,14 +1137,14 @@ void intel_color_load_luts(const struct 
intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 
-   dev_priv->color_funcs.load_luts(crtc_state);
+   dev_priv->color_funcs->load_luts(crtc_state);
 }
 
 void intel_color_commit(const struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 
-   dev_priv->color_funcs.color_commit(crtc_state);
+   dev_priv->color_funcs->color_commit(crtc_state);
 }
 
 static bool intel_can_preload_luts(const struct intel_crtc_state 
*new_crtc_state)
@@ -1200,15 +1200,15 @@ int intel_color_check(struct intel_crtc_state 
*crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 
-   return dev_priv->color_funcs.color_check(crtc_state);
+   return dev_priv->color_funcs->color_check(crtc_state);
 }
 
 void intel_color_get_config(struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 
-   if (dev_priv->color_funcs.read_luts)
-   dev_priv->color_funcs.read_luts(crtc_state);
+   if (dev_priv->color_funcs->read_luts)
+   dev_priv->color_funcs->read_luts(crtc_state);
 }
 
 static bool need_plane_update(struct intel_plane *plane,
@@ -2092,6 +2092,76 @@ static void icl_read_luts(struct intel_crtc_state 
*crtc_state)
}
 }
 
+static const struct intel_color_funcs chv_color_funcs = {
+   .color_check = chv_color_check,
+   .color_commit = i9xx_color_commit,
+   .load_luts = chv_load_luts,
+   .read_luts = chv_read_luts,
+};
+
+static const struct intel_color_funcs i965_color_funcs = {
+   .color_check = i9xx_color_check,
+   .color_commit = i9xx_color_commit,
+   .load_luts = i965_load_luts,
+   .read_luts = i965_read_luts,
+};
+
+static const struct intel_color_funcs i9xx_color_funcs = {
+   .color_check = i9xx_color_check,
+   .color_commit = i9xx_color_commit,
+   .load_luts = i9xx_load_luts,
+   .read_luts = i9xx_read_luts,
+};
+
+static const struct intel_color_funcs icl_color_funcs = {
+   .color_check = icl_color_check,
+   .color_commit = skl_color_commit,
+   .load_luts = icl_load_luts,
+   .read_luts = icl_read_luts,
+};
+
+static const struct intel_color_funcs glk_color_funcs = {
+   .color_check = glk_color_check,
+   .color_commit = skl_color_commit,
+   .load_luts = glk_load_luts,
+   .read_luts = glk_read_luts,
+};
+
+static const struct intel_color_funcs skl_color_funcs = {
+   .color_check = ivb_color_check,
+   .color_commit = skl_color_commit,
+   .load_luts = bdw_load_luts,
+   .read_luts = NULL,
+};
+
+static const struct intel_color_funcs bdw_color_funcs = {
+   .color_check = ivb_color_check,
+   .color_commit = hsw_color_commit,
+   .load_luts = bdw_load_luts,
+   .read_luts = NULL,
+};
+
+static const struct intel_color_funcs hsw_color_funcs = {
+   .color_check = ivb_color_check,
+   .color_commit = hsw_color_commit,
+   .load_luts = ivb_load_luts,
+   .read_luts = NULL,
+};
+
+static const struct intel_color_funcs ivb_color_funcs = {
+   .color_check = ivb_color_check,
+   .color_commit = ilk_color_commit,
+   .load_luts = ivb_load_luts,
+   .read_luts = NULL,
+};
+
+static const struct intel_color_funcs ilk_color_funcs = {
+   .color_check = ilk_color_check,
+   .color_commit = ilk_color_commit,
+   .load_luts = ilk_load_luts,
+   .read_luts = ilk_read_luts,
+};
+
 void intel_color_init(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -2101,52 +2171,28 @@ void intel_color_init(struct intel_crtc *crtc)
 
if (HAS_GMCH(dev_priv)) {
if (IS_CHERRYVIEW(dev_priv)) {
-   dev_priv->color_funcs.color_check = chv_color_check;
-   dev_priv->color_funcs.color_commit = i9xx_color_commit;
-   dev_priv->color_funcs.load_luts = chv_load_luts;
-   dev_priv->color_funcs.read_luts = chv_read_luts;
+   dev_priv->color_funcs = _color_funcs;
} else if 

[Intel-gfx] [PATCH 16/24] drm/i915: constify hotplug function vtable.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

Use a macro to avoid mistakes, this type of macro is only used
in a couple of places.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_hotplug.c |  4 +--
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_irq.c  | 28 +++-
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 05f76aba4f8a..3c1cec953b42 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -215,8 +215,8 @@ intel_hpd_irq_storm_switch_to_polling(struct 
drm_i915_private *dev_priv)
 
 static void intel_hpd_irq_setup(struct drm_i915_private *i915)
 {
-   if (i915->display_irqs_enabled && i915->hotplug_funcs.hpd_irq_setup)
-   i915->hotplug_funcs.hpd_irq_setup(i915);
+   if (i915->display_irqs_enabled && i915->hotplug_funcs->hpd_irq_setup)
+   i915->hotplug_funcs->hpd_irq_setup(i915);
 }
 
 static void intel_hpd_irq_storm_reenable_work(struct work_struct *work)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd0abc89b5dd..0e8592445804 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -988,7 +988,7 @@ struct drm_i915_private {
struct drm_i915_wm_disp_funcs wm_disp;
 
/* irq display functions */
-   struct intel_hotplug_funcs hotplug_funcs;
+   const struct intel_hotplug_funcs *hotplug_funcs;
 
/* fdi display functions */
const struct intel_fdi_funcs *fdi_funcs;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c35065f8f429..77680bca46ee 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4345,6 +4345,20 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
return ret;
 }
 
+#define HPD_FUNCS(platform) \
+static const struct intel_hotplug_funcs platform##_hpd_funcs = { \
+   .hpd_irq_setup = platform##_hpd_irq_setup,   \
+}
+
+HPD_FUNCS(i915);
+HPD_FUNCS(dg1);
+HPD_FUNCS(gen11);
+HPD_FUNCS(bxt);
+HPD_FUNCS(icp);
+HPD_FUNCS(spt);
+HPD_FUNCS(ilk);
+#undef HPD_FUNCS
+
 /**
  * intel_irq_init - initializes irq support
  * @dev_priv: i915 device instance
@@ -4395,20 +4409,20 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
 
if (HAS_GMCH(dev_priv)) {
if (I915_HAS_HOTPLUG(dev_priv))
-   dev_priv->hotplug_funcs.hpd_irq_setup = 
i915_hpd_irq_setup;
+   dev_priv->hotplug_funcs = _hpd_funcs;
} else {
if (HAS_PCH_DG1(dev_priv))
-   dev_priv->hotplug_funcs.hpd_irq_setup = 
dg1_hpd_irq_setup;
+   dev_priv->hotplug_funcs = _hpd_funcs;
else if (DISPLAY_VER(dev_priv) >= 11)
-   dev_priv->hotplug_funcs.hpd_irq_setup = 
gen11_hpd_irq_setup;
+   dev_priv->hotplug_funcs = _hpd_funcs;
else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
-   dev_priv->hotplug_funcs.hpd_irq_setup = 
bxt_hpd_irq_setup;
+   dev_priv->hotplug_funcs = _hpd_funcs;
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
-   dev_priv->hotplug_funcs.hpd_irq_setup = 
icp_hpd_irq_setup;
+   dev_priv->hotplug_funcs = _hpd_funcs;
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
-   dev_priv->hotplug_funcs.hpd_irq_setup = 
spt_hpd_irq_setup;
+   dev_priv->hotplug_funcs = _hpd_funcs;
else
-   dev_priv->hotplug_funcs.hpd_irq_setup = 
ilk_hpd_irq_setup;
+   dev_priv->hotplug_funcs = _hpd_funcs;
}
 }
 
-- 
2.30.2



[Intel-gfx] [PATCH 15/24] drm/i915: constify fdi link training vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

Put the vtable into ro memory.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_fdi.c | 20 
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c 
b/drivers/gpu/drm/i915/display/intel_fdi.c
index f828bebe8962..af01d1fa761e 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -15,7 +15,7 @@ void intel_fdi_link_train(struct intel_crtc *crtc,
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 
-   dev_priv->fdi_funcs.fdi_link_train(crtc, crtc_state);
+   dev_priv->fdi_funcs->fdi_link_train(crtc, crtc_state);
 }
 
 /* units of 100MHz */
@@ -1013,15 +1013,27 @@ void lpt_fdi_program_mphy(struct drm_i915_private 
*dev_priv)
intel_sbi_write(dev_priv, 0x21EC, tmp, SBI_MPHY);
 }
 
+static const struct intel_fdi_funcs ilk_funcs = {
+   .fdi_link_train = ilk_fdi_link_train,
+};
+
+static const struct intel_fdi_funcs gen6_funcs = {
+   .fdi_link_train = gen6_fdi_link_train,
+};
+
+static const struct intel_fdi_funcs ivb_funcs = {
+   .fdi_link_train = ivb_manual_fdi_link_train,
+};
+
 void
 intel_fdi_init_hook(struct drm_i915_private *dev_priv)
 {
if (IS_IRONLAKE(dev_priv)) {
-   dev_priv->fdi_funcs.fdi_link_train = ilk_fdi_link_train;
+   dev_priv->fdi_funcs = _funcs;
} else if (IS_SANDYBRIDGE(dev_priv)) {
-   dev_priv->fdi_funcs.fdi_link_train = gen6_fdi_link_train;
+   dev_priv->fdi_funcs = _funcs;
} else if (IS_IVYBRIDGE(dev_priv)) {
/* FIXME: detect B0+ stepping and use auto training */
-   dev_priv->fdi_funcs.fdi_link_train = ivb_manual_fdi_link_train;
+   dev_priv->fdi_funcs = _funcs;
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef62b2df0e82..cd0abc89b5dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -991,7 +991,7 @@ struct drm_i915_private {
struct intel_hotplug_funcs hotplug_funcs;
 
/* fdi display functions */
-   struct intel_fdi_funcs fdi_funcs;
+   const struct intel_fdi_funcs *fdi_funcs;
 
/* display pll funcs */
struct intel_dpll_funcs dpll_funcs;
-- 
2.30.2



[Intel-gfx] [PATCH 14/24] drm/i915: split the dpll clock compute out from display vtable.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

this single function might be possible to merge later, but
for now it's simple to just split it out.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c |  6 +++---
 drivers/gpu/drm/i915/display/intel_dpll.c| 16 
 drivers/gpu/drm/i915/i915_drv.h  |  8 +++-
 3 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index df3b5b393c5f..37d40ab4049c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6834,10 +6834,10 @@ static int intel_crtc_atomic_check(struct 
intel_atomic_state *state,
crtc_state->update_wm_post = true;
 
if (mode_changed && crtc_state->hw.enable &&
-   dev_priv->display.crtc_compute_clock &&
+   dev_priv->dpll_funcs.crtc_compute_clock &&
!crtc_state->bigjoiner_slave &&
!drm_WARN_ON(_priv->drm, crtc_state->shared_dpll)) {
-   ret = dev_priv->display.crtc_compute_clock(crtc_state);
+   ret = dev_priv->dpll_funcs.crtc_compute_clock(crtc_state);
if (ret)
return ret;
}
@@ -8864,7 +8864,7 @@ static void intel_modeset_clear_plls(struct 
intel_atomic_state *state)
struct intel_crtc *crtc;
int i;
 
-   if (!dev_priv->display.crtc_compute_clock)
+   if (!dev_priv->dpll_funcs.crtc_compute_clock)
return;
 
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 487d8721ecf8..7811f19acb6a 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1369,21 +1369,21 @@ void
 intel_dpll_init_clock_hook(struct drm_i915_private *dev_priv)
 {
if (DISPLAY_VER(dev_priv) >= 9 || HAS_DDI(dev_priv))
-   dev_priv->display.crtc_compute_clock = hsw_crtc_compute_clock;
+   dev_priv->dpll_funcs.crtc_compute_clock = 
hsw_crtc_compute_clock;
else if (HAS_PCH_SPLIT(dev_priv))
-   dev_priv->display.crtc_compute_clock = ilk_crtc_compute_clock;
+   dev_priv->dpll_funcs.crtc_compute_clock = 
ilk_crtc_compute_clock;
else if (IS_CHERRYVIEW(dev_priv))
-   dev_priv->display.crtc_compute_clock = chv_crtc_compute_clock;
+   dev_priv->dpll_funcs.crtc_compute_clock = 
chv_crtc_compute_clock;
else if (IS_VALLEYVIEW(dev_priv))
-   dev_priv->display.crtc_compute_clock = vlv_crtc_compute_clock;
+   dev_priv->dpll_funcs.crtc_compute_clock = 
vlv_crtc_compute_clock;
else if (IS_G4X(dev_priv))
-   dev_priv->display.crtc_compute_clock = g4x_crtc_compute_clock;
+   dev_priv->dpll_funcs.crtc_compute_clock = 
g4x_crtc_compute_clock;
else if (IS_PINEVIEW(dev_priv))
-   dev_priv->display.crtc_compute_clock = pnv_crtc_compute_clock;
+   dev_priv->dpll_funcs.crtc_compute_clock = 
pnv_crtc_compute_clock;
else if (DISPLAY_VER(dev_priv) != 2)
-   dev_priv->display.crtc_compute_clock = i9xx_crtc_compute_clock;
+   dev_priv->dpll_funcs.crtc_compute_clock = 
i9xx_crtc_compute_clock;
else
-   dev_priv->display.crtc_compute_clock = i8xx_crtc_compute_clock;
+   dev_priv->dpll_funcs.crtc_compute_clock = 
i8xx_crtc_compute_clock;
 }
 
 static bool i9xx_has_pps(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7004b1a068e1..ef62b2df0e82 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -393,6 +393,10 @@ struct intel_fdi_funcs {
   const struct intel_crtc_state *crtc_state);
 };
 
+struct intel_dpll_funcs {
+   int (*crtc_compute_clock)(struct intel_crtc_state *crtc_state);
+};
+
 struct drm_i915_display_funcs {
/* Returns the active state of the crtc, and if the crtc is active,
 * fills out the pipe-config with the hw state. */
@@ -400,7 +404,6 @@ struct drm_i915_display_funcs {
struct intel_crtc_state *);
void (*get_initial_plane_config)(struct intel_crtc *,
 struct intel_initial_plane_config *);
-   int (*crtc_compute_clock)(struct intel_crtc_state *crtc_state);
void (*crtc_enable)(struct intel_atomic_state *state,
struct intel_crtc *crtc);
void (*crtc_disable)(struct intel_atomic_state *state,
@@ -990,6 +993,9 @@ struct drm_i915_private {
/* fdi display functions */
struct intel_fdi_funcs fdi_funcs;
 
+   /* display pll funcs */
+   struct intel_dpll_funcs dpll_funcs;
+

[Intel-gfx] [PATCH 13/24] drm/i915: split fdi link training from display vtable.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

It may make sense to merge this with display again later,
however the fdi use of the vtable is limited to only a
few generations.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_fdi.c |  8 
 drivers/gpu/drm/i915/i915_drv.h  | 11 ---
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c 
b/drivers/gpu/drm/i915/display/intel_fdi.c
index d20669e53663..f828bebe8962 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -15,7 +15,7 @@ void intel_fdi_link_train(struct intel_crtc *crtc,
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 
-   dev_priv->display.fdi_link_train(crtc, crtc_state);
+   dev_priv->fdi_funcs.fdi_link_train(crtc, crtc_state);
 }
 
 /* units of 100MHz */
@@ -1017,11 +1017,11 @@ void
 intel_fdi_init_hook(struct drm_i915_private *dev_priv)
 {
if (IS_IRONLAKE(dev_priv)) {
-   dev_priv->display.fdi_link_train = ilk_fdi_link_train;
+   dev_priv->fdi_funcs.fdi_link_train = ilk_fdi_link_train;
} else if (IS_SANDYBRIDGE(dev_priv)) {
-   dev_priv->display.fdi_link_train = gen6_fdi_link_train;
+   dev_priv->fdi_funcs.fdi_link_train = gen6_fdi_link_train;
} else if (IS_IVYBRIDGE(dev_priv)) {
/* FIXME: detect B0+ stepping and use auto training */
-   dev_priv->display.fdi_link_train = ivb_manual_fdi_link_train;
+   dev_priv->fdi_funcs.fdi_link_train = ivb_manual_fdi_link_train;
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e00979130f0a..7004b1a068e1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -388,6 +388,11 @@ struct intel_hotplug_funcs {
void (*hpd_irq_setup)(struct drm_i915_private *dev_priv);
 };
 
+struct intel_fdi_funcs {
+   void (*fdi_link_train)(struct intel_crtc *crtc,
+  const struct intel_crtc_state *crtc_state);
+};
+
 struct drm_i915_display_funcs {
/* Returns the active state of the crtc, and if the crtc is active,
 * fills out the pipe-config with the hw state. */
@@ -403,9 +408,6 @@ struct drm_i915_display_funcs {
void (*commit_modeset_enables)(struct intel_atomic_state *state);
void (*commit_modeset_disables)(struct intel_atomic_state *state);
 
-   void (*fdi_link_train)(struct intel_crtc *crtc,
-  const struct intel_crtc_state *crtc_state);
-
/* clock updates for mode set */
/* cursor updates */
/* render clock increase/decrease */
@@ -985,6 +987,9 @@ struct drm_i915_private {
/* irq display functions */
struct intel_hotplug_funcs hotplug_funcs;
 
+   /* fdi display functions */
+   struct intel_fdi_funcs fdi_funcs;
+
/* Display functions */
struct drm_i915_display_funcs display;
 
-- 
2.30.2



[Intel-gfx] [PATCH 12/24] drm/i915: split irq hotplug function from display vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

This provide a service from irq to display, so make it separate

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_hotplug.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  9 -
 drivers/gpu/drm/i915/i915_irq.c  | 14 +++---
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 47c85ac97c87..05f76aba4f8a 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -215,8 +215,8 @@ intel_hpd_irq_storm_switch_to_polling(struct 
drm_i915_private *dev_priv)
 
 static void intel_hpd_irq_setup(struct drm_i915_private *i915)
 {
-   if (i915->display_irqs_enabled && i915->display.hpd_irq_setup)
-   i915->display.hpd_irq_setup(i915);
+   if (i915->display_irqs_enabled && i915->hotplug_funcs.hpd_irq_setup)
+   i915->hotplug_funcs.hpd_irq_setup(i915);
 }
 
 static void intel_hpd_irq_storm_reenable_work(struct work_struct *work)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 373e840c3dd9..e00979130f0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -384,6 +384,10 @@ struct intel_cdclk_funcs {
u8 (*calc_voltage_level)(int cdclk);
 };
 
+struct intel_hotplug_funcs {
+   void (*hpd_irq_setup)(struct drm_i915_private *dev_priv);
+};
+
 struct drm_i915_display_funcs {
/* Returns the active state of the crtc, and if the crtc is active,
 * fills out the pipe-config with the hw state. */
@@ -401,7 +405,7 @@ struct drm_i915_display_funcs {
 
void (*fdi_link_train)(struct intel_crtc *crtc,
   const struct intel_crtc_state *crtc_state);
-   void (*hpd_irq_setup)(struct drm_i915_private *dev_priv);
+
/* clock updates for mode set */
/* cursor updates */
/* render clock increase/decrease */
@@ -978,6 +982,9 @@ struct drm_i915_private {
/* pm display functions */
struct drm_i915_wm_disp_funcs wm_disp;
 
+   /* irq display functions */
+   struct intel_hotplug_funcs hotplug_funcs;
+
/* Display functions */
struct drm_i915_display_funcs display;
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0a1681384c84..c35065f8f429 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4395,20 +4395,20 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
 
if (HAS_GMCH(dev_priv)) {
if (I915_HAS_HOTPLUG(dev_priv))
-   dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
+   dev_priv->hotplug_funcs.hpd_irq_setup = 
i915_hpd_irq_setup;
} else {
if (HAS_PCH_DG1(dev_priv))
-   dev_priv->display.hpd_irq_setup = dg1_hpd_irq_setup;
+   dev_priv->hotplug_funcs.hpd_irq_setup = 
dg1_hpd_irq_setup;
else if (DISPLAY_VER(dev_priv) >= 11)
-   dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
+   dev_priv->hotplug_funcs.hpd_irq_setup = 
gen11_hpd_irq_setup;
else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
-   dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
+   dev_priv->hotplug_funcs.hpd_irq_setup = 
bxt_hpd_irq_setup;
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
-   dev_priv->display.hpd_irq_setup = icp_hpd_irq_setup;
+   dev_priv->hotplug_funcs.hpd_irq_setup = 
icp_hpd_irq_setup;
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
-   dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
+   dev_priv->hotplug_funcs.hpd_irq_setup = 
spt_hpd_irq_setup;
else
-   dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
+   dev_priv->hotplug_funcs.hpd_irq_setup = 
ilk_hpd_irq_setup;
}
 }
 
-- 
2.30.2



[Intel-gfx] [PATCH 11/24] drm/i915: split cdclk functions from display vtable.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

This moves all the cdclk related functions into their own vtable.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 142 ++---
 drivers/gpu/drm/i915/i915_drv.h|   8 +-
 2 files changed, 78 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index ff01fe9be35c..cf0a865df596 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -62,32 +62,32 @@
 void intel_cdclk_get_cdclk(struct drm_i915_private *dev_priv,
   struct intel_cdclk_config *cdclk_config)
 {
-   dev_priv->display.get_cdclk(dev_priv, cdclk_config);
+   dev_priv->cdclk_funcs.get_cdclk(dev_priv, cdclk_config);
 }
 
 int intel_cdclk_bw_calc_min_cdclk(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   return dev_priv->display.bw_calc_min_cdclk(state);
+   return dev_priv->cdclk_funcs.bw_calc_min_cdclk(state);
 }
 
 static void intel_cdclk_set_cdclk(struct drm_i915_private *dev_priv,
  const struct intel_cdclk_config *cdclk_config,
  enum pipe pipe)
 {
-   dev_priv->display.set_cdclk(dev_priv, cdclk_config, pipe);
+   dev_priv->cdclk_funcs.set_cdclk(dev_priv, cdclk_config, pipe);
 }
 
 static int intel_cdclk_modeset_calc_cdclk(struct drm_i915_private *dev_priv,
  struct intel_cdclk_state 
*cdclk_config)
 {
-   return dev_priv->display.modeset_calc_cdclk(cdclk_config);
+   return dev_priv->cdclk_funcs.modeset_calc_cdclk(cdclk_config);
 }
 
 static u8 intel_cdclk_calc_voltage_level(struct drm_i915_private *dev_priv,
 int cdclk)
 {
-   return dev_priv->display.calc_voltage_level(cdclk);
+   return dev_priv->cdclk_funcs.calc_voltage_level(cdclk);
 }
 
 static void fixed_133mhz_get_cdclk(struct drm_i915_private *dev_priv,
@@ -1963,7 +1963,7 @@ static void intel_set_cdclk(struct drm_i915_private 
*dev_priv,
if (!intel_cdclk_changed(_priv->cdclk.hw, cdclk_config))
return;
 
-   if (drm_WARN_ON_ONCE(_priv->drm, !dev_priv->display.set_cdclk))
+   if (drm_WARN_ON_ONCE(_priv->drm, !dev_priv->cdclk_funcs.set_cdclk))
return;
 
intel_dump_cdclk_config(cdclk_config, "Changing CDCLK to");
@@ -2891,119 +2891,119 @@ u32 intel_read_rawclk(struct drm_i915_private 
*dev_priv)
 void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
 {
if (IS_DG2(dev_priv)) {
-   dev_priv->display.set_cdclk = bxt_set_cdclk;
-   dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
-   dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
-   dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
+   dev_priv->cdclk_funcs.set_cdclk = bxt_set_cdclk;
+   dev_priv->cdclk_funcs.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
+   dev_priv->cdclk_funcs.modeset_calc_cdclk = 
bxt_modeset_calc_cdclk;
+   dev_priv->cdclk_funcs.calc_voltage_level = 
tgl_calc_voltage_level;
dev_priv->cdclk.table = dg2_cdclk_table;
} else if (IS_ALDERLAKE_P(dev_priv)) {
-   dev_priv->display.set_cdclk = bxt_set_cdclk;
-   dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
-   dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
-   dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
+   dev_priv->cdclk_funcs.set_cdclk = bxt_set_cdclk;
+   dev_priv->cdclk_funcs.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
+   dev_priv->cdclk_funcs.modeset_calc_cdclk = 
bxt_modeset_calc_cdclk;
+   dev_priv->cdclk_funcs.calc_voltage_level = 
tgl_calc_voltage_level;
/* Wa_22011320316:adl-p[a0] */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
dev_priv->cdclk.table = adlp_a_step_cdclk_table;
else
dev_priv->cdclk.table = adlp_cdclk_table;
} else if (IS_ROCKETLAKE(dev_priv)) {
-   dev_priv->display.set_cdclk = bxt_set_cdclk;
-   dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
-   dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
-   dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
+   dev_priv->cdclk_funcs.set_cdclk = bxt_set_cdclk;
+   dev_priv->cdclk_funcs.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
+   dev_priv->cdclk_funcs.modeset_calc_cdclk = 
bxt_modeset_calc_cdclk;
+   dev_priv->cdclk_funcs.calc_voltage_level = 
tgl_calc_voltage_level;
 

[Intel-gfx] [PATCH 10/24] drm/i915: split audio functions from display vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

These are only used internally in the audio code

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 24 +++---
 drivers/gpu/drm/i915/i915_drv.h| 19 +++--
 2 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 4e0f96bf6158..bf96d1529775 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -848,8 +848,8 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
 
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
 
-   if (dev_priv->display.audio_codec_enable)
-   dev_priv->display.audio_codec_enable(encoder,
+   if (dev_priv->audio_funcs.audio_codec_enable)
+   dev_priv->audio_funcs.audio_codec_enable(encoder,
 crtc_state,
 conn_state);
 
@@ -893,8 +893,8 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
 
-   if (dev_priv->display.audio_codec_disable)
-   dev_priv->display.audio_codec_disable(encoder,
+   if (dev_priv->audio_funcs.audio_codec_disable)
+   dev_priv->audio_funcs.audio_codec_disable(encoder,
  old_crtc_state,
  old_conn_state);
 
@@ -922,17 +922,17 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
 void intel_init_audio_hooks(struct drm_i915_private *dev_priv)
 {
if (IS_G4X(dev_priv)) {
-   dev_priv->display.audio_codec_enable = g4x_audio_codec_enable;
-   dev_priv->display.audio_codec_disable = g4x_audio_codec_disable;
+   dev_priv->audio_funcs.audio_codec_enable = 
g4x_audio_codec_enable;
+   dev_priv->audio_funcs.audio_codec_disable = 
g4x_audio_codec_disable;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
-   dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
+   dev_priv->audio_funcs.audio_codec_enable = 
ilk_audio_codec_enable;
+   dev_priv->audio_funcs.audio_codec_disable = 
ilk_audio_codec_disable;
} else if (IS_HASWELL(dev_priv) || DISPLAY_VER(dev_priv) >= 8) {
-   dev_priv->display.audio_codec_enable = hsw_audio_codec_enable;
-   dev_priv->display.audio_codec_disable = hsw_audio_codec_disable;
+   dev_priv->audio_funcs.audio_codec_enable = 
hsw_audio_codec_enable;
+   dev_priv->audio_funcs.audio_codec_disable = 
hsw_audio_codec_disable;
} else if (HAS_PCH_SPLIT(dev_priv)) {
-   dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
-   dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
+   dev_priv->audio_funcs.audio_codec_enable = 
ilk_audio_codec_enable;
+   dev_priv->audio_funcs.audio_codec_disable = 
ilk_audio_codec_disable;
}
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04b2c710e16c..35488822837b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -364,6 +364,15 @@ struct intel_color_funcs {
void (*read_luts)(struct intel_crtc_state *crtc_state);
 };
 
+struct intel_audio_funcs {
+   void (*audio_codec_enable)(struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state 
*conn_state);
+   void (*audio_codec_disable)(struct intel_encoder *encoder,
+   const struct intel_crtc_state 
*old_crtc_state,
+   const struct drm_connector_state 
*old_conn_state);
+};
+
 struct drm_i915_display_funcs {
void (*get_cdclk)(struct drm_i915_private *dev_priv,
  struct intel_cdclk_config *cdclk_config);
@@ -386,12 +395,7 @@ struct drm_i915_display_funcs {
 struct intel_crtc *crtc);
void (*commit_modeset_enables)(struct intel_atomic_state *state);
void (*commit_modeset_disables)(struct intel_atomic_state *state);
-   void (*audio_codec_enable)(struct intel_encoder *encoder,
-  const struct intel_crtc_state *crtc_state,
-  const struct drm_connector_state 
*conn_state);
-   void (*audio_codec_disable)(struct intel_encoder *encoder,
-   const struct intel_crtc_state 
*old_crtc_state,
- 

[Intel-gfx] [PATCH 09/24] drm/i915: split color functions from display vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

These are only used internally in the color module

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_color.c | 64 +++---
 drivers/gpu/drm/i915/i915_drv.h| 39 +++--
 2 files changed, 54 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index afcb4bf3826c..ed79075158dd 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1137,14 +1137,14 @@ void intel_color_load_luts(const struct 
intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 
-   dev_priv->display.load_luts(crtc_state);
+   dev_priv->color_funcs.load_luts(crtc_state);
 }
 
 void intel_color_commit(const struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 
-   dev_priv->display.color_commit(crtc_state);
+   dev_priv->color_funcs.color_commit(crtc_state);
 }
 
 static bool intel_can_preload_luts(const struct intel_crtc_state 
*new_crtc_state)
@@ -1200,15 +1200,15 @@ int intel_color_check(struct intel_crtc_state 
*crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 
-   return dev_priv->display.color_check(crtc_state);
+   return dev_priv->color_funcs.color_check(crtc_state);
 }
 
 void intel_color_get_config(struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
 
-   if (dev_priv->display.read_luts)
-   dev_priv->display.read_luts(crtc_state);
+   if (dev_priv->color_funcs.read_luts)
+   dev_priv->color_funcs.read_luts(crtc_state);
 }
 
 static bool need_plane_update(struct intel_plane *plane,
@@ -2101,51 +2101,51 @@ void intel_color_init(struct intel_crtc *crtc)
 
if (HAS_GMCH(dev_priv)) {
if (IS_CHERRYVIEW(dev_priv)) {
-   dev_priv->display.color_check = chv_color_check;
-   dev_priv->display.color_commit = i9xx_color_commit;
-   dev_priv->display.load_luts = chv_load_luts;
-   dev_priv->display.read_luts = chv_read_luts;
+   dev_priv->color_funcs.color_check = chv_color_check;
+   dev_priv->color_funcs.color_commit = i9xx_color_commit;
+   dev_priv->color_funcs.load_luts = chv_load_luts;
+   dev_priv->color_funcs.read_luts = chv_read_luts;
} else if (DISPLAY_VER(dev_priv) >= 4) {
-   dev_priv->display.color_check = i9xx_color_check;
-   dev_priv->display.color_commit = i9xx_color_commit;
-   dev_priv->display.load_luts = i965_load_luts;
-   dev_priv->display.read_luts = i965_read_luts;
+   dev_priv->color_funcs.color_check = i9xx_color_check;
+   dev_priv->color_funcs.color_commit = i9xx_color_commit;
+   dev_priv->color_funcs.load_luts = i965_load_luts;
+   dev_priv->color_funcs.read_luts = i965_read_luts;
} else {
-   dev_priv->display.color_check = i9xx_color_check;
-   dev_priv->display.color_commit = i9xx_color_commit;
-   dev_priv->display.load_luts = i9xx_load_luts;
-   dev_priv->display.read_luts = i9xx_read_luts;
+   dev_priv->color_funcs.color_check = i9xx_color_check;
+   dev_priv->color_funcs.color_commit = i9xx_color_commit;
+   dev_priv->color_funcs.load_luts = i9xx_load_luts;
+   dev_priv->color_funcs.read_luts = i9xx_read_luts;
}
} else {
if (DISPLAY_VER(dev_priv) >= 11)
-   dev_priv->display.color_check = icl_color_check;
+   dev_priv->color_funcs.color_check = icl_color_check;
else if (DISPLAY_VER(dev_priv) >= 10)
-   dev_priv->display.color_check = glk_color_check;
+   dev_priv->color_funcs.color_check = glk_color_check;
else if (DISPLAY_VER(dev_priv) >= 7)
-   dev_priv->display.color_check = ivb_color_check;
+   dev_priv->color_funcs.color_check = ivb_color_check;
else
-   dev_priv->display.color_check = ilk_color_check;
+   dev_priv->color_funcs.color_check = ilk_color_check;
 
if (DISPLAY_VER(dev_priv) >= 9)
-   dev_priv->display.color_commit = skl_color_commit;
+   dev_priv->color_funcs.color_commit = skl_color_commit;
else if 

[Intel-gfx] [PATCH 08/24] drm/i915: split watermark vfuncs from display vtable.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

These are the watermark api between display and pm.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 34 -
 drivers/gpu/drm/i915/i915_drv.h  | 24 
 drivers/gpu/drm/i915/intel_pm.c  | 40 ++--
 3 files changed, 53 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index c810e4d4a0b1..df3b5b393c5f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -162,16 +162,16 @@ static void intel_modeset_setup_hw_state(struct 
drm_device *dev,
  */
 static void intel_update_watermarks(struct drm_i915_private *dev_priv)
 {
-   if (dev_priv->display.update_wm)
-   dev_priv->display.update_wm(dev_priv);
+   if (dev_priv->wm_disp.update_wm)
+   dev_priv->wm_disp.update_wm(dev_priv);
 }
 
 static int intel_compute_pipe_wm(struct intel_atomic_state *state,
 struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->display.compute_pipe_wm)
-   return dev_priv->display.compute_pipe_wm(state, crtc);
+   if (dev_priv->wm_disp.compute_pipe_wm)
+   return dev_priv->wm_disp.compute_pipe_wm(state, crtc);
return 0;
 }
 
@@ -179,20 +179,20 @@ static int intel_compute_intermediate_wm(struct 
intel_atomic_state *state,
 struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (!dev_priv->display.compute_intermediate_wm)
+   if (!dev_priv->wm_disp.compute_intermediate_wm)
return 0;
if (drm_WARN_ON(_priv->drm,
-   !dev_priv->display.compute_pipe_wm))
+   !dev_priv->wm_disp.compute_pipe_wm))
return 0;
-   return dev_priv->display.compute_intermediate_wm(state, crtc);
+   return dev_priv->wm_disp.compute_intermediate_wm(state, crtc);
 }
 
 static bool intel_initial_watermarks(struct intel_atomic_state *state,
 struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->display.initial_watermarks) {
-   dev_priv->display.initial_watermarks(state, crtc);
+   if (dev_priv->wm_disp.initial_watermarks) {
+   dev_priv->wm_disp.initial_watermarks(state, crtc);
return true;
}
return false;
@@ -202,23 +202,23 @@ static void intel_atomic_update_watermarks(struct 
intel_atomic_state *state,
   struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->display.atomic_update_watermarks)
-   dev_priv->display.atomic_update_watermarks(state, crtc);
+   if (dev_priv->wm_disp.atomic_update_watermarks)
+   dev_priv->wm_disp.atomic_update_watermarks(state, crtc);
 }
 
 static void intel_optimize_watermarks(struct intel_atomic_state *state,
  struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->display.optimize_watermarks)
-   dev_priv->display.optimize_watermarks(state, crtc);
+   if (dev_priv->wm_disp.optimize_watermarks)
+   dev_priv->wm_disp.optimize_watermarks(state, crtc);
 }
 
 static int intel_compute_global_watermarks(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   if (dev_priv->display.compute_global_watermarks)
-   return dev_priv->display.compute_global_watermarks(state);
+   if (dev_priv->wm_disp.compute_global_watermarks)
+   return dev_priv->wm_disp.compute_global_watermarks(state);
return 0;
 }
 
@@ -3744,7 +3744,7 @@ static void i9xx_crtc_disable(struct intel_atomic_state 
*state,
if (DISPLAY_VER(dev_priv) != 2)
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
 
-   if (!dev_priv->display.initial_watermarks)
+   if (!dev_priv->wm_disp.initial_watermarks)
intel_update_watermarks(dev_priv);
 
/* clock the pipe down to 640x480@60 to potentially save power */
@@ -11405,7 +11405,7 @@ static void sanitize_watermarks(struct drm_i915_private 
*dev_priv)
int i;
 
/* Only supported on platforms that use atomic watermark design */
-   if (!dev_priv->display.optimize_watermarks)
+   if (!dev_priv->wm_disp.optimize_watermarks)
return;
 
state = drm_atomic_state_alloc(_priv->drm);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 

[Intel-gfx] [PATCH 07/24] drm/i915: split clock gating init from display vtable

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

This function is only used inside intel_pm.c

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h |  9 ++-
 drivers/gpu/drm/i915/intel_pm.c | 48 -
 2 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90e2f44e2deb..b429298f23ee 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -323,6 +323,11 @@ struct intel_crtc;
 struct intel_limit;
 struct dpll;
 
+/* functions used internal in intel_pm.c */
+struct drm_i915_clock_gating_funcs {
+   void (*init_clock_gating)(struct drm_i915_private *dev_priv);
+};
+
 struct drm_i915_display_funcs {
void (*get_cdclk)(struct drm_i915_private *dev_priv,
  struct intel_cdclk_config *cdclk_config);
@@ -365,7 +370,6 @@ struct drm_i915_display_funcs {
const struct drm_connector_state 
*old_conn_state);
void (*fdi_link_train)(struct intel_crtc *crtc,
   const struct intel_crtc_state *crtc_state);
-   void (*init_clock_gating)(struct drm_i915_private *dev_priv);
void (*hpd_irq_setup)(struct drm_i915_private *dev_priv);
/* clock updates for mode set */
/* cursor updates */
@@ -954,6 +958,9 @@ struct drm_i915_private {
/* unbound hipri wq for page flips/plane updates */
struct workqueue_struct *flip_wq;
 
+   /* pm private clock gating functions */
+   struct drm_i915_clock_gating_funcs clock_gating_funcs;
+
/* Display functions */
struct drm_i915_display_funcs display;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 11c9df62391d..34d6faee8969 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7869,7 +7869,7 @@ static void i830_init_clock_gating(struct 
drm_i915_private *dev_priv)
 
 void intel_init_clock_gating(struct drm_i915_private *dev_priv)
 {
-   dev_priv->display.init_clock_gating(dev_priv);
+   dev_priv->clock_gating_funcs.init_clock_gating(dev_priv);
 }
 
 void intel_suspend_hw(struct drm_i915_private *dev_priv)
@@ -7896,52 +7896,52 @@ static void nop_init_clock_gating(struct 
drm_i915_private *dev_priv)
 void intel_init_clock_gating_hooks(struct drm_i915_private *dev_priv)
 {
if (IS_ALDERLAKE_P(dev_priv))
-   dev_priv->display.init_clock_gating = adlp_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
adlp_init_clock_gating;
else if (IS_DG1(dev_priv))
-   dev_priv->display.init_clock_gating = dg1_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
dg1_init_clock_gating;
else if (GRAPHICS_VER(dev_priv) == 12)
-   dev_priv->display.init_clock_gating = gen12lp_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
gen12lp_init_clock_gating;
else if (GRAPHICS_VER(dev_priv) == 11)
-   dev_priv->display.init_clock_gating = icl_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
icl_init_clock_gating;
else if (IS_COFFEELAKE(dev_priv) || IS_COMETLAKE(dev_priv))
-   dev_priv->display.init_clock_gating = cfl_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
cfl_init_clock_gating;
else if (IS_SKYLAKE(dev_priv))
-   dev_priv->display.init_clock_gating = skl_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
skl_init_clock_gating;
else if (IS_KABYLAKE(dev_priv))
-   dev_priv->display.init_clock_gating = kbl_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
kbl_init_clock_gating;
else if (IS_BROXTON(dev_priv))
-   dev_priv->display.init_clock_gating = bxt_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
bxt_init_clock_gating;
else if (IS_GEMINILAKE(dev_priv))
-   dev_priv->display.init_clock_gating = glk_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
glk_init_clock_gating;
else if (IS_BROADWELL(dev_priv))
-   dev_priv->display.init_clock_gating = bdw_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
bdw_init_clock_gating;
else if (IS_CHERRYVIEW(dev_priv))
-   dev_priv->display.init_clock_gating = chv_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
chv_init_clock_gating;
else if (IS_HASWELL(dev_priv))
-   dev_priv->display.init_clock_gating = hsw_init_clock_gating;
+   dev_priv->clock_gating_funcs.init_clock_gating = 
hsw_init_clock_gating;
else if 

[Intel-gfx] [PATCH 06/24] drm/i915/display: add intel_fdi_link_train wrapper.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

This wraps the fdi link training vfunc to make it clearer.

Suggested by Jani.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 +-
 drivers/gpu/drm/i915/display/intel_fdi.c | 8 
 drivers/gpu/drm/i915/display/intel_fdi.h | 2 ++
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 839954195ffc..c810e4d4a0b1 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2166,7 +2166,7 @@ static void ilk_pch_enable(const struct 
intel_atomic_state *state,
assert_pch_transcoder_disabled(dev_priv, pipe);
 
/* For PCH output, training FDI link */
-   dev_priv->display.fdi_link_train(crtc, crtc_state);
+   intel_fdi_link_train(crtc, crtc_state);
 
/* We need to program the right clock selection before writing the pixel
 * mutliplier into the DPLL. */
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c 
b/drivers/gpu/drm/i915/display/intel_fdi.c
index 96ff12ad0873..d20669e53663 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -10,6 +10,14 @@
 #include "intel_fdi.h"
 #include "intel_sideband.h"
 
+void intel_fdi_link_train(struct intel_crtc *crtc,
+ const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+   dev_priv->display.fdi_link_train(crtc, crtc_state);
+}
+
 /* units of 100MHz */
 static int pipe_required_fdi_lanes(struct intel_crtc_state *crtc_state)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.h 
b/drivers/gpu/drm/i915/display/intel_fdi.h
index 60acf2133145..61cb216a09f5 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.h
+++ b/drivers/gpu/drm/i915/display/intel_fdi.h
@@ -26,4 +26,6 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
 void intel_fdi_pll_freq_update(struct drm_i915_private *i915);
 void lpt_fdi_program_mphy(struct drm_i915_private *i915);
 
+void intel_fdi_link_train(struct intel_crtc *crtc,
+ const struct intel_crtc_state *crtc_state);
 #endif
-- 
2.30.2



[Intel-gfx] [PATCH 05/24] drm/i915: add wrappers around cdclk vtable funcs.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

This adds wrappers around all the vtable callers so they are in
one place.

Suggested by Jani.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c| 47 +++
 drivers/gpu/drm/i915/display/intel_cdclk.h|  4 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
 .../drm/i915/display/intel_display_power.c|  2 +-
 4 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 3a1cdb3937aa..ff01fe9be35c 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -59,6 +59,37 @@
  * dividers can be programmed correctly.
  */
 
+void intel_cdclk_get_cdclk(struct drm_i915_private *dev_priv,
+  struct intel_cdclk_config *cdclk_config)
+{
+   dev_priv->display.get_cdclk(dev_priv, cdclk_config);
+}
+
+int intel_cdclk_bw_calc_min_cdclk(struct intel_atomic_state *state)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   return dev_priv->display.bw_calc_min_cdclk(state);
+}
+
+static void intel_cdclk_set_cdclk(struct drm_i915_private *dev_priv,
+ const struct intel_cdclk_config *cdclk_config,
+ enum pipe pipe)
+{
+   dev_priv->display.set_cdclk(dev_priv, cdclk_config, pipe);
+}
+
+static int intel_cdclk_modeset_calc_cdclk(struct drm_i915_private *dev_priv,
+ struct intel_cdclk_state 
*cdclk_config)
+{
+   return dev_priv->display.modeset_calc_cdclk(cdclk_config);
+}
+
+static u8 intel_cdclk_calc_voltage_level(struct drm_i915_private *dev_priv,
+int cdclk)
+{
+   return dev_priv->display.calc_voltage_level(cdclk);
+}
+
 static void fixed_133mhz_get_cdclk(struct drm_i915_private *dev_priv,
   struct intel_cdclk_config *cdclk_config)
 {
@@ -1466,7 +1497,7 @@ static void bxt_get_cdclk(struct drm_i915_private 
*dev_priv,
 * at least what the CDCLK frequency requires.
 */
cdclk_config->voltage_level =
-   dev_priv->display.calc_voltage_level(cdclk_config->cdclk);
+   intel_cdclk_calc_voltage_level(dev_priv, cdclk_config->cdclk);
 }
 
 static void bxt_de_pll_disable(struct drm_i915_private *dev_priv)
@@ -1777,7 +1808,7 @@ static void bxt_cdclk_init_hw(struct drm_i915_private 
*dev_priv)
cdclk_config.cdclk = bxt_calc_cdclk(dev_priv, 0);
cdclk_config.vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk_config.cdclk);
cdclk_config.voltage_level =
-   dev_priv->display.calc_voltage_level(cdclk_config.cdclk);
+   intel_cdclk_calc_voltage_level(dev_priv, cdclk_config.cdclk);
 
bxt_set_cdclk(dev_priv, _config, INVALID_PIPE);
 }
@@ -1789,7 +1820,7 @@ static void bxt_cdclk_uninit_hw(struct drm_i915_private 
*dev_priv)
cdclk_config.cdclk = cdclk_config.bypass;
cdclk_config.vco = 0;
cdclk_config.voltage_level =
-   dev_priv->display.calc_voltage_level(cdclk_config.cdclk);
+   intel_cdclk_calc_voltage_level(dev_priv, cdclk_config.cdclk);
 
bxt_set_cdclk(dev_priv, _config, INVALID_PIPE);
 }
@@ -1956,7 +1987,7 @@ static void intel_set_cdclk(struct drm_i915_private 
*dev_priv,
 _priv->gmbus_mutex);
}
 
-   dev_priv->display.set_cdclk(dev_priv, cdclk_config, pipe);
+   intel_cdclk_set_cdclk(dev_priv, cdclk_config, pipe);
 
for_each_intel_dp(_priv->drm, encoder) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
@@ -2422,7 +2453,7 @@ static int bxt_modeset_calc_cdclk(struct 
intel_cdclk_state *cdclk_state)
cdclk_state->logical.cdclk = cdclk;
cdclk_state->logical.voltage_level =
max_t(int, min_voltage_level,
- dev_priv->display.calc_voltage_level(cdclk));
+ intel_cdclk_calc_voltage_level(dev_priv, cdclk));
 
if (!cdclk_state->active_pipes) {
cdclk = bxt_calc_cdclk(dev_priv, cdclk_state->force_min_cdclk);
@@ -2431,7 +2462,7 @@ static int bxt_modeset_calc_cdclk(struct 
intel_cdclk_state *cdclk_state)
cdclk_state->actual.vco = vco;
cdclk_state->actual.cdclk = cdclk;
cdclk_state->actual.voltage_level =
-   dev_priv->display.calc_voltage_level(cdclk);
+   intel_cdclk_calc_voltage_level(dev_priv, cdclk);
} else {
cdclk_state->actual = cdclk_state->logical;
}
@@ -2523,7 +2554,7 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state 
*state)
new_cdclk_state->active_pipes =
intel_calc_active_pipes(state, old_cdclk_state->active_pipes);
 
-   ret = 

[Intel-gfx] [PATCH 04/24] drm/i915/wm: provide wrappers around watermark vfuncs calls (v3)

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

This moves one wrapper from the pm->display side, and creates
wrappers for all the others, this should simplify things later.

One thing to note is that the code checks the existance of some
of these ptrs, so the wrappers are a bit complicated by that.

Suggested by Jani.

v2: fixup warnings in wrong place error.

v3 by Jani: fix intel_compute_global_watermarks() return value check

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 186 ---
 drivers/gpu/drm/i915/intel_pm.c  |  39 
 drivers/gpu/drm/i915/intel_pm.h  |   1 -
 3 files changed, 124 insertions(+), 102 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 566a7d2feb1a..1c5c8834b333 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -126,6 +126,102 @@ static void ilk_pfit_enable(const struct intel_crtc_state 
*crtc_state);
 static void intel_modeset_setup_hw_state(struct drm_device *dev,
 struct drm_modeset_acquire_ctx *ctx);
 
+
+/**
+ * intel_update_watermarks - update FIFO watermark values based on current 
modes
+ * @dev_priv: i915 device
+ *
+ * Calculate watermark values for the various WM regs based on current mode
+ * and plane configuration.
+ *
+ * There are several cases to deal with here:
+ *   - normal (i.e. non-self-refresh)
+ *   - self-refresh (SR) mode
+ *   - lines are large relative to FIFO size (buffer can hold up to 2)
+ *   - lines are small relative to FIFO size (buffer can hold more than 2
+ * lines), so need to account for TLB latency
+ *
+ *   The normal calculation is:
+ * watermark = dotclock * bytes per pixel * latency
+ *   where latency is platform & configuration dependent (we assume pessimal
+ *   values here).
+ *
+ *   The SR calculation is:
+ * watermark = (trunc(latency/line time)+1) * surface width *
+ *   bytes per pixel
+ *   where
+ * line time = htotal / dotclock
+ * surface width = hdisplay for normal plane and 64 for cursor
+ *   and latency is assumed to be high, as above.
+ *
+ * The final value programmed to the register should always be rounded up,
+ * and include an extra 2 entries to account for clock crossings.
+ *
+ * We don't use the sprite, so we can ignore that.  And on Crestline we have
+ * to set the non-SR watermarks to 8.
+ */
+static void intel_update_watermarks(struct drm_i915_private *dev_priv)
+{
+   if (dev_priv->display.update_wm)
+   dev_priv->display.update_wm(dev_priv);
+}
+
+static int intel_compute_pipe_wm(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.compute_pipe_wm)
+   return dev_priv->display.compute_pipe_wm(state, crtc);
+   return 0;
+}
+
+static int intel_compute_intermediate_wm(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (!dev_priv->display.compute_intermediate_wm)
+   return 0;
+   if (drm_WARN_ON(_priv->drm,
+   !dev_priv->display.compute_pipe_wm))
+   return 0;
+   return dev_priv->display.compute_intermediate_wm(state, crtc);
+}
+
+static bool intel_initial_watermarks(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.initial_watermarks) {
+   dev_priv->display.initial_watermarks(state, crtc);
+   return true;
+   }
+   return false;
+}
+
+static void intel_atomic_update_watermarks(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.atomic_update_watermarks)
+   dev_priv->display.atomic_update_watermarks(state, crtc);
+}
+
+static void intel_optimize_watermarks(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.optimize_watermarks)
+   dev_priv->display.optimize_watermarks(state, crtc);
+}
+
+static int intel_compute_global_watermarks(struct intel_atomic_state *state)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   if (dev_priv->display.compute_global_watermarks)
+   return dev_priv->display.compute_global_watermarks(state);
+   return 0;
+}
+
 /* returns HPLL frequency in kHz */
 int vlv_get_hpll_vco(struct 

[Intel-gfx] [PATCH 03/24] drm/i915: make update_wm take a dev_priv.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

The crtc was never being used here.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 10 +-
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 20 +++-
 drivers/gpu/drm/i915/intel_pm.h  |  2 +-
 4 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f27c294beb92..566a7d2feb1a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2383,7 +2383,7 @@ static void intel_post_plane_update(struct 
intel_atomic_state *state,
intel_frontbuffer_flip(dev_priv, new_crtc_state->fb_bits);
 
if (new_crtc_state->update_wm_post && new_crtc_state->hw.active)
-   intel_update_watermarks(crtc);
+   intel_update_watermarks(dev_priv);
 
if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
hsw_enable_ips(new_crtc_state);
@@ -2540,7 +2540,7 @@ static void intel_pre_plane_update(struct 
intel_atomic_state *state,
if (dev_priv->display.initial_watermarks)
dev_priv->display.initial_watermarks(state, crtc);
else if (new_crtc_state->update_wm_pre)
-   intel_update_watermarks(crtc);
+   intel_update_watermarks(dev_priv);
}
 
/*
@@ -3587,7 +3587,7 @@ static void i9xx_crtc_enable(struct intel_atomic_state 
*state,
if (dev_priv->display.initial_watermarks)
dev_priv->display.initial_watermarks(state, crtc);
else
-   intel_update_watermarks(crtc);
+   intel_update_watermarks(dev_priv);
intel_enable_transcoder(new_crtc_state);
 
intel_crtc_vblank_on(new_crtc_state);
@@ -3654,7 +3654,7 @@ static void i9xx_crtc_disable(struct intel_atomic_state 
*state,
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
 
if (!dev_priv->display.initial_watermarks)
-   intel_update_watermarks(crtc);
+   intel_update_watermarks(dev_priv);
 
/* clock the pipe down to 640x480@60 to potentially save power */
if (IS_I830(dev_priv))
@@ -3730,7 +3730,7 @@ static void intel_crtc_disable_noatomic(struct intel_crtc 
*crtc,
encoder->base.crtc = NULL;
 
intel_fbc_disable(crtc);
-   intel_update_watermarks(crtc);
+   intel_update_watermarks(dev_priv);
intel_disable_shared_dpll(crtc_state);
 
intel_display_power_put_all_in_set(dev_priv, 
>enabled_power_domains);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db0aa5bb4d18..90e2f44e2deb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -341,7 +341,7 @@ struct drm_i915_display_funcs {
void (*optimize_watermarks)(struct intel_atomic_state *state,
struct intel_crtc *crtc);
int (*compute_global_watermarks)(struct intel_atomic_state *state);
-   void (*update_wm)(struct intel_crtc *crtc);
+   void (*update_wm)(struct drm_i915_private *dev_priv);
int (*modeset_calc_cdclk)(struct intel_cdclk_state *state);
u8 (*calc_voltage_level)(int cdclk);
/* Returns the active state of the crtc, and if the crtc is active,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0e0309733c79..226f456cde3a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -881,9 +881,8 @@ static struct intel_crtc *single_enabled_crtc(struct 
drm_i915_private *dev_priv)
return enabled;
 }
 
-static void pnv_update_wm(struct intel_crtc *unused_crtc)
+static void pnv_update_wm(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(unused_crtc->base.dev);
struct intel_crtc *crtc;
const struct cxsr_latency *latency;
u32 reg;
@@ -2248,9 +2247,8 @@ static void vlv_optimize_watermarks(struct 
intel_atomic_state *state,
mutex_unlock(_priv->wm.wm_mutex);
 }
 
-static void i965_update_wm(struct intel_crtc *unused_crtc)
+static void i965_update_wm(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(unused_crtc->base.dev);
struct intel_crtc *crtc;
int srwm = 1;
int cursor_sr = 16;
@@ -2324,9 +2322,8 @@ static void i965_update_wm(struct intel_crtc *unused_crtc)
 
 #undef FW_WM
 
-static void i9xx_update_wm(struct intel_crtc *unused_crtc)
+static void i9xx_update_wm(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(unused_crtc->base.dev);
const struct intel_watermark_params *wm_info;
u32 fwater_lo;
u32 fwater_hi;
@@ -2476,9 +2473,8 @@ 

[Intel-gfx] [PATCH 02/24] drm/i915/pm: drop get_fifo_size vfunc.

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

The i845_update_wm code was always calling the i845 variant,
and the i9xx_update_wm had only a choice between i830 and i9xx
paths, hardly worth the vfunc overhead.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 --
 drivers/gpu/drm/i915/intel_pm.c | 20 +++-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 804c2a470e94..db0aa5bb4d18 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -330,8 +330,6 @@ struct drm_i915_display_funcs {
  const struct intel_cdclk_config *cdclk_config,
  enum pipe pipe);
int (*bw_calc_min_cdclk)(struct intel_atomic_state *state);
-   int (*get_fifo_size)(struct drm_i915_private *dev_priv,
-enum i9xx_plane_id i9xx_plane);
int (*compute_pipe_wm)(struct intel_atomic_state *state,
   struct intel_crtc *crtc);
int (*compute_intermediate_wm)(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 97b68bbbc689..0e0309733c79 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2342,7 +2342,10 @@ static void i9xx_update_wm(struct intel_crtc 
*unused_crtc)
else
wm_info = _a_wm_info;
 
-   fifo_size = dev_priv->display.get_fifo_size(dev_priv, PLANE_A);
+   if (DISPLAY_VER(dev_priv) == 2)
+   fifo_size = i830_get_fifo_size(dev_priv, PLANE_A);
+   else
+   fifo_size = i9xx_get_fifo_size(dev_priv, PLANE_A);
crtc = intel_get_crtc_for_plane(dev_priv, PLANE_A);
if (intel_crtc_active(crtc)) {
const struct drm_display_mode *pipe_mode =
@@ -2369,7 +2372,10 @@ static void i9xx_update_wm(struct intel_crtc 
*unused_crtc)
if (DISPLAY_VER(dev_priv) == 2)
wm_info = _bc_wm_info;
 
-   fifo_size = dev_priv->display.get_fifo_size(dev_priv, PLANE_B);
+   if (DISPLAY_VER(dev_priv) == 2)
+   fifo_size = i830_get_fifo_size(dev_priv, PLANE_B);
+   else
+   fifo_size = i9xx_get_fifo_size(dev_priv, PLANE_B);
crtc = intel_get_crtc_for_plane(dev_priv, PLANE_B);
if (intel_crtc_active(crtc)) {
const struct drm_display_mode *pipe_mode =
@@ -2485,7 +2491,7 @@ static void i845_update_wm(struct intel_crtc *unused_crtc)
pipe_mode = >config->hw.pipe_mode;
planea_wm = intel_calculate_wm(pipe_mode->crtc_clock,
   _wm_info,
-  
dev_priv->display.get_fifo_size(dev_priv, PLANE_A),
+  i845_get_fifo_size(dev_priv, PLANE_A),
   4, pessimal_latency_ns);
fwater_lo = intel_uncore_read(_priv->uncore, FW_BLC) & ~0xfff;
fwater_lo |= (3<<8) | planea_wm;
@@ -8052,15 +8058,11 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
dev_priv->display.update_wm = i965_update_wm;
} else if (DISPLAY_VER(dev_priv) == 3) {
dev_priv->display.update_wm = i9xx_update_wm;
-   dev_priv->display.get_fifo_size = i9xx_get_fifo_size;
} else if (DISPLAY_VER(dev_priv) == 2) {
-   if (INTEL_NUM_PIPES(dev_priv) == 1) {
+   if (INTEL_NUM_PIPES(dev_priv) == 1)
dev_priv->display.update_wm = i845_update_wm;
-   dev_priv->display.get_fifo_size = i845_get_fifo_size;
-   } else {
+   else
dev_priv->display.update_wm = i9xx_update_wm;
-   dev_priv->display.get_fifo_size = i830_get_fifo_size;
-   }
} else {
drm_err(_priv->drm,
"unexpected fall-through in %s\n", __func__);
-- 
2.30.2



[Intel-gfx] [PATCH 01/24] drm/i915/uncore: split the fw get function into separate vfunc

2021-09-28 Thread Jani Nikula
From: Dave Airlie 

constify it while here. drop the put function since it was never
overloaded and always has done the same thing, no point in
indirecting it for show.

Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_uncore.c | 70 -
 drivers/gpu/drm/i915/intel_uncore.h |  7 +--
 2 files changed, 43 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 678a99de07fe..aee572af8052 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -36,6 +36,12 @@
 
 #define __raw_posting_read(...) ((void)__raw_uncore_read32(__VA_ARGS__))
 
+static void
+fw_domains_get(struct intel_uncore *uncore, enum forcewake_domains fw_domains)
+{
+   uncore->fw_get_funcs->force_wake_get(uncore, fw_domains);
+}
+
 void
 intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug)
 {
@@ -248,7 +254,7 @@ fw_domain_put(const struct intel_uncore_forcewake_domain *d)
 }
 
 static void
-fw_domains_get(struct intel_uncore *uncore, enum forcewake_domains fw_domains)
+fw_domains_get_normal(struct intel_uncore *uncore, enum forcewake_domains 
fw_domains)
 {
struct intel_uncore_forcewake_domain *d;
unsigned int tmp;
@@ -396,7 +402,7 @@ intel_uncore_fw_release_timer(struct hrtimer *timer)
 
GEM_BUG_ON(!domain->wake_count);
if (--domain->wake_count == 0)
-   uncore->funcs.force_wake_put(uncore, domain->mask);
+   fw_domains_put(uncore, domain->mask);
 
spin_unlock_irqrestore(>lock, irqflags);
 
@@ -454,7 +460,7 @@ intel_uncore_forcewake_reset(struct intel_uncore *uncore)
 
fw = uncore->fw_domains_active;
if (fw)
-   uncore->funcs.force_wake_put(uncore, fw);
+   fw_domains_put(uncore, fw);
 
fw_domains_reset(uncore, uncore->fw_domains);
assert_forcewakes_inactive(uncore);
@@ -562,7 +568,7 @@ static void forcewake_early_sanitize(struct intel_uncore 
*uncore,
intel_uncore_forcewake_reset(uncore);
if (restore_forcewake) {
spin_lock_irq(>lock);
-   uncore->funcs.force_wake_get(uncore, restore_forcewake);
+   fw_domains_get(uncore, restore_forcewake);
 
if (intel_uncore_has_fifo(uncore))
uncore->fifo_count = fifo_free_entries(uncore);
@@ -623,7 +629,7 @@ static void __intel_uncore_forcewake_get(struct 
intel_uncore *uncore,
}
 
if (fw_domains)
-   uncore->funcs.force_wake_get(uncore, fw_domains);
+   fw_domains_get(uncore, fw_domains);
 }
 
 /**
@@ -644,7 +650,7 @@ void intel_uncore_forcewake_get(struct intel_uncore *uncore,
 {
unsigned long irqflags;
 
-   if (!uncore->funcs.force_wake_get)
+   if (!uncore->fw_get_funcs)
return;
 
assert_rpm_wakelock_held(uncore->rpm);
@@ -711,7 +717,7 @@ void intel_uncore_forcewake_get__locked(struct intel_uncore 
*uncore,
 {
lockdep_assert_held(>lock);
 
-   if (!uncore->funcs.force_wake_get)
+   if (!uncore->fw_get_funcs)
return;
 
__intel_uncore_forcewake_get(uncore, fw_domains);
@@ -733,7 +739,7 @@ static void __intel_uncore_forcewake_put(struct 
intel_uncore *uncore,
continue;
}
 
-   uncore->funcs.force_wake_put(uncore, domain->mask);
+   fw_domains_put(uncore, domain->mask);
}
 }
 
@@ -750,7 +756,7 @@ void intel_uncore_forcewake_put(struct intel_uncore *uncore,
 {
unsigned long irqflags;
 
-   if (!uncore->funcs.force_wake_put)
+   if (!uncore->fw_get_funcs)
return;
 
spin_lock_irqsave(>lock, irqflags);
@@ -769,7 +775,7 @@ void intel_uncore_forcewake_flush(struct intel_uncore 
*uncore,
struct intel_uncore_forcewake_domain *domain;
unsigned int tmp;
 
-   if (!uncore->funcs.force_wake_put)
+   if (!uncore->fw_get_funcs)
return;
 
fw_domains &= uncore->fw_domains;
@@ -793,7 +799,7 @@ void intel_uncore_forcewake_put__locked(struct intel_uncore 
*uncore,
 {
lockdep_assert_held(>lock);
 
-   if (!uncore->funcs.force_wake_put)
+   if (!uncore->fw_get_funcs)
return;
 
__intel_uncore_forcewake_put(uncore, fw_domains);
@@ -801,7 +807,7 @@ void intel_uncore_forcewake_put__locked(struct intel_uncore 
*uncore,
 
 void assert_forcewakes_inactive(struct intel_uncore *uncore)
 {
-   if (!uncore->funcs.force_wake_get)
+   if (!uncore->fw_get_funcs)
return;
 
drm_WARN(>i915->drm, uncore->fw_domains_active,
@@ -818,7 +824,7 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM))
return;
 
-   if (!uncore->funcs.force_wake_get)
+   if (!uncore->fw_get_funcs)

[Intel-gfx] [PATCH 00/24] i915/display: split and constify vtable, again

2021-09-28 Thread Jani Nikula
I must have read the series several times over without spotting the
issue, but finally figured it out with the help of [1].

Return value and check added to intel_compute_global_watermarks() in
patch 4, and a couple of patches rebased. Seems so obvious now...

Fingers crossed.

BR,
Jani.

[1] 
https://patchwork.freedesktop.org/patch/msgid/20210928223241.22149-1-jani.nik...@intel.com

Cc: Dave Airlie 

Dave Airlie (24):
  drm/i915/uncore: split the fw get function into separate vfunc
  drm/i915/pm: drop get_fifo_size vfunc.
  drm/i915: make update_wm take a dev_priv.
  drm/i915/wm: provide wrappers around watermark vfuncs calls (v3)
  drm/i915: add wrappers around cdclk vtable funcs.
  drm/i915/display: add intel_fdi_link_train wrapper.
  drm/i915: split clock gating init from display vtable
  drm/i915: split watermark vfuncs from display vtable.
  drm/i915: split color functions from display vtable
  drm/i915: split audio functions from display vtable
  drm/i915: split cdclk functions from display vtable.
  drm/i915: split irq hotplug function from display vtable
  drm/i915: split fdi link training from display vtable.
  drm/i915: split the dpll clock compute out from display vtable.
  drm/i915: constify fdi link training vtable
  drm/i915: constify hotplug function vtable.
  drm/i915: constify color function vtable.
  drm/i915: constify the audio function vtable
  drm/i915: constify the dpll clock vtable
  drm/i915: constify the cdclk vtable
  drm/i915: drop unused function ptr and comments.
  drm/i915: constify display function vtable
  drm/i915: constify clock gating init vtable.
  drm/i915: constify display wm vtable

 drivers/gpu/drm/i915/display/intel_audio.c|  43 ++-
 drivers/gpu/drm/i915/display/intel_cdclk.c| 337 +-
 drivers/gpu/drm/i915/display/intel_cdclk.h|   4 +-
 drivers/gpu/drm/i915/display/intel_color.c| 138 ---
 drivers/gpu/drm/i915/display/intel_display.c  | 289 +--
 .../drm/i915/display/intel_display_power.c|   2 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |  48 ++-
 drivers/gpu/drm/i915/display/intel_fdi.c  |  26 +-
 drivers/gpu/drm/i915/display/intel_fdi.h  |   2 +
 drivers/gpu/drm/i915/display/intel_hotplug.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h   | 124 ---
 drivers/gpu/drm/i915/i915_irq.c   |  28 +-
 drivers/gpu/drm/i915/intel_pm.c   | 231 ++--
 drivers/gpu/drm/i915/intel_pm.h   |   1 -
 drivers/gpu/drm/i915/intel_uncore.c   |  70 ++--
 drivers/gpu/drm/i915/intel_uncore.h   |   7 +-
 16 files changed, 888 insertions(+), 466 deletions(-)

-- 
2.30.2



Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

2021-09-28 Thread Matthew Brost
On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
> > mid BB. To safely enable preemption at the BB boundary, a handshake
> > between to parent and child is needed. This is implemented via custom
> > emit_bb_start & emit_fini_breadcrumb functions and enabled via by
> via by -> by
> 
> > default if a context is configured by set parallel extension.
> I tend to agree with Tvrtko that this should probably be an opt in change.
> Is there a flags word passed in when creating the context?
> 

I don't disagree but the uAPI in this series is where we landed. It has
been acked all by the relevant parties in the RFC, ported to our
internal tree, and the media UMD has been updated / posted. Concerns
with the uAPI should've been raised in the RFC phase, not now. I really
don't feel like changing this uAPI another time.

> Also, it's not just a change in pre-emption behaviour but a change in
> synchronisation too, right? Previously, if you had a whole bunch of back to
> back submissions then one child could run ahead of another and/or the
> parent. After this change, there is a forced regroup at the end of each
> batch. So while one could end sooner/later than the others, they can't ever
> get an entire batch (or more) ahead or behind. Or was that synchronisation
> already in there through other means anyway?
> 

Yes, each parent / child sync at the of each batch - this is the only
way safely insert preemption points. Without this the GuC could attempt
a preemption and hang the batches.

> > 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_context.c   |   2 +-
> >   drivers/gpu/drm/i915/gt/intel_context_types.h |   3 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   2 +-
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 +-
> >   4 files changed, 287 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 5615be32879c..2de62649e275 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct 
> > intel_context *parent,
> > GEM_BUG_ON(intel_context_is_child(child));
> > GEM_BUG_ON(intel_context_is_parent(child));
> > -   parent->guc_number_children++;
> > +   child->guc_child_index = parent->guc_number_children++;
> > list_add_tail(>guc_child_link,
> >   >guc_child_list);
> > child->parent = parent;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index 713d85b0b364..727f91e7f7c2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -246,6 +246,9 @@ struct intel_context {
> > /** @guc_number_children: number of children if parent */
> > u8 guc_number_children;
> > +   /** @guc_child_index: index into guc_child_list if child */
> > +   u8 guc_child_index;
> > +
> > /**
> >  * @parent_page: page in context used by parent for work queue,
> >  * work queue descriptor
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > index 6cd26dc060d1..9f61cfa5566a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > @@ -188,7 +188,7 @@ struct guc_process_desc {
> > u32 wq_status;
> > u32 engine_presence;
> > u32 priority;
> > -   u32 reserved[30];
> > +   u32 reserved[36];
> What is this extra space for? All the extra storage is grabbed from after
> the end of this structure, isn't it?
> 

This is the size of process descriptor in the GuC spec. Even though this
is unused space we really don't want the child go / join memory using
anything within the process descriptor.

> >   } __packed;
> >   #define CONTEXT_REGISTRATION_FLAG_KMD BIT(0)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 91330525330d..1a18f99bf12a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -11,6 +11,7 @@
> >   #include "gt/intel_context.h"
> >   #include "gt/intel_engine_pm.h"
> >   #include "gt/intel_engine_heartbeat.h"
> > +#include "gt/intel_gpu_commands.h"
> >   #include "gt/intel_gt.h"
> >   #include "gt/intel_gt_irq.h"
> >   #include "gt/intel_gt_pm.h"
> > @@ -366,10 +367,14 @@ static struct i915_priolist *to_priolist(struct 
> > rb_node *rb)
> >   /*
> >* When using multi-lrc submission an extra page in the context state is
> > - * reserved for the process descriptor and work queue.
> > + * reserved for 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Stop force enabling pipe bottom color gammma/csc

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Stop force enabling pipe bottom color gammma/csc
URL   : https://patchwork.freedesktop.org/series/95171/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655_full -> Patchwork_21179_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  NOTRUN -> [DMESG-WARN][2] ([i915#180]) +2 similar 
issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][3] ([fdo#109314])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-iclb8/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_ctx_persistence@smoketest:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-snb2/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-tglb8/igt@gem_...@unwedge-stress.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-tglb1/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][7] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-apl8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-kbl7/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2849])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@no-bsd:
- shard-tglb: NOTRUN -> [SKIP][12] ([fdo#109283])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-tglb5/igt@gem_exec_par...@no-bsd.html

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

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-apl1/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_softpin@allocator-evict-all-engines:
- shard-glk:  [PASS][16] -> [FAIL][17] ([i915#4171])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-glk7/igt@gem_soft...@allocator-evict-all-engines.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-glk6/igt@gem_soft...@allocator-evict-all-engines.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-apl2/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@input-checking:
- shard-snb:  NOTRUN -> [DMESG-WARN][19] ([i915#3002])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-snb5/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@unsync-overlap:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#3297])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-iclb8/igt@gem_userptr_bl...@unsync-overlap.html

  * igt@gem_userptr_blits@vma-merge:
- shard-apl:  NOTRUN -> [FAIL][21] ([i915#3318])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/shard-apl2/igt@gem_userptr_bl...@vma-merge.html

  * igt@gen7_exec_parse@basic-allocation:
- shard-glk:  NOTRUN -> [SKIP][22] ([fdo#109271]) +33 similar issues
   [22]: 

[Intel-gfx] [PATCH] drm/locking: add backtrace for locking contended locks without backoff

2021-09-28 Thread Jani Nikula
If drm_modeset_lock() returns -EDEADLK, the caller is supposed to drop
all currently held locks using drm_modeset_backoff(). Failing to do so
will result in warnings and backtraces on the paths trying to lock a
contended lock. Add support for optionally printing the backtrace on the
path that hit the deadlock and didn't gracefully handle the situation.

For example, the patch [1] inadvertently dropped the return value check
and error return on replacing calc_watermark_data() with
intel_compute_global_watermarks(). The backtraces on the subsequent
locking paths hitting WARN_ON(ctx->contended) were unhelpful, but adding
the backtrace to the deadlock path produced this helpful printout:

<7> [98.002465] drm_modeset_lock attempting to lock a contended lock without 
backoff:
   drm_modeset_lock+0x107/0x130
   drm_atomic_get_plane_state+0x76/0x150
   skl_compute_wm+0x251d/0x2b20 [i915]
   intel_atomic_check+0x1942/0x29e0 [i915]
   drm_atomic_check_only+0x554/0x910
   drm_atomic_nonblocking_commit+0xe/0x50
   drm_mode_atomic_ioctl+0x8c2/0xab0
   drm_ioctl_kernel+0xac/0x140

Add new CONFIG_DRM_DEBUG_MODESET_LOCK to enable modeset lock debugging
with stack depot and trace.

[1] https://lore.kernel.org/r/20210924114741.15940-4-jani.nik...@intel.com

Cc: Daniel Vetter 
Cc: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/Kconfig| 13 
 drivers/gpu/drm/drm_modeset_lock.c | 49 --
 include/drm/drm_modeset_lock.h |  8 +
 3 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b17e231ca6f7..7334975c788b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -100,6 +100,19 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
   This has the potential to use a lot of memory and print some very
   large kernel messages. If in doubt, say "N".
 
+config DRM_DEBUG_MODESET_LOCK
+   bool "Enable backtrace history for lock contention"
+   depends on STACKTRACE_SUPPORT
+   select STACKDEPOT
+   depends on EXPERT
+   help
+ Enable debug tracing of failures to gracefully handle drm modeset lock
+ contention. A history of each drm modeset lock path hitting -EDEADLK
+ will be saved until gracefully handled, and the backtrace will be
+ printed when attempting to lock a contended lock.
+
+ If in doubt, say "N".
+
 config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index bf8a6e823a15..4d32b61fa1fd 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * DOC: kms locking
@@ -77,6 +78,45 @@
 
 static DEFINE_WW_CLASS(crtc_ww_class);
 
+#if IS_ENABLED(CONFIG_DRM_DEBUG_MODESET_LOCK)
+static noinline depot_stack_handle_t __stack_depot_save(void)
+{
+   unsigned long entries[8];
+   unsigned int n;
+
+   n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
+
+   return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
+}
+
+static void __stack_depot_print(depot_stack_handle_t stack_depot)
+{
+   struct drm_printer p = drm_debug_printer("drm_modeset_lock");
+   unsigned long *entries;
+   unsigned int nr_entries;
+   char *buf;
+
+   buf = kmalloc(PAGE_SIZE, GFP_NOWAIT | __GFP_NOWARN);
+   if (!buf)
+   return;
+
+   nr_entries = stack_depot_fetch(stack_depot, );
+   stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 2);
+
+   drm_printf(, "attempting to lock a contended lock without 
backoff:\n%s", buf);
+
+   kfree(buf);
+}
+#else /* CONFIG_DRM_DEBUG_MODESET_LOCK */
+static depot_stack_handle_t __stack_depot_save(void)
+{
+   return 0;
+}
+static void __stack_depot_print(depot_stack_handle_t stack_depot)
+{
+}
+#endif /* CONFIG_DRM_DEBUG_MODESET_LOCK */
+
 /**
  * drm_modeset_lock_all - take all modeset locks
  * @dev: DRM device
@@ -225,7 +265,9 @@ EXPORT_SYMBOL(drm_modeset_acquire_fini);
  */
 void drm_modeset_drop_locks(struct drm_modeset_acquire_ctx *ctx)
 {
-   WARN_ON(ctx->contended);
+   if (WARN_ON(ctx->contended))
+   __stack_depot_print(ctx->stack_depot);
+
while (!list_empty(>locked)) {
struct drm_modeset_lock *lock;
 
@@ -243,7 +285,8 @@ static inline int modeset_lock(struct drm_modeset_lock 
*lock,
 {
int ret;
 
-   WARN_ON(ctx->contended);
+   if (WARN_ON(ctx->contended))
+   __stack_depot_print(ctx->stack_depot);
 
if (ctx->trylock_only) {
lockdep_assert_held(>ww_ctx);
@@ -274,6 +317,7 @@ static inline int modeset_lock(struct drm_modeset_lock 
*lock,
ret = 0;
} else if (ret == -EDEADLK) {
ctx->contended = lock;
+   ctx->stack_depot = 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DP per-lane drive settings prep work (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/i915: DP per-lane drive settings prep work (rev2)
URL   : https://patchwork.freedesktop.org/series/95122/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655 -> Patchwork_21181


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][9] ([i915#2927] / [i915#3428]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [FAIL][11] ([i915#1161]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Warnings 

  * igt@kms_chamelium@vga-hpd-fast:
- fi-kbl-7500u:   [{ABORT}][13] ([i915#1814]) -> [SKIP][14] 
([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21181/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (45 -> 37)
--

  Additional (1): fi-kbl-soraka 
  Missing(9): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-hsw-4200u fi-bsw-cyan 
bat-adlp-4 fi-ctg-p8600 bat-jsl-2 bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10655 -> Patchwork_21181

  CI-20190529: 20190529
  CI_DRM_10655: 88d6ecae86a7bb32e8bf2bd233f7f9f9c8bd7abc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6226: 18278534c085c35adcf62f158a8d5356e5496f8d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21181: 9a8086f736c623ddda0622f2195b5fbff4bd629e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9a8086f736c6 drm/i915: Allow per-lane drive settings with LTTPRs
c2a69b618c76 

Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

2021-09-28 Thread John Harrison

On 8/20/2021 15:44, Matthew Brost wrote:

For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functions and enabled via by

via by -> by


default if a context is configured by set parallel extension.
I tend to agree with Tvrtko that this should probably be an opt in 
change. Is there a flags word passed in when creating the context?


Also, it's not just a change in pre-emption behaviour but a change in 
synchronisation too, right? Previously, if you had a whole bunch of back 
to back submissions then one child could run ahead of another and/or the 
parent. After this change, there is a forced regroup at the end of each 
batch. So while one could end sooner/later than the others, they can't 
ever get an entire batch (or more) ahead or behind. Or was that 
synchronisation already in there through other means anyway?




Signed-off-by: Matthew Brost 
---
  drivers/gpu/drm/i915/gt/intel_context.c   |   2 +-
  drivers/gpu/drm/i915/gt/intel_context_types.h |   3 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   2 +-
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 283 +-
  4 files changed, 287 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5615be32879c..2de62649e275 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -561,7 +561,7 @@ void intel_context_bind_parent_child(struct intel_context 
*parent,
GEM_BUG_ON(intel_context_is_child(child));
GEM_BUG_ON(intel_context_is_parent(child));
  
-	parent->guc_number_children++;

+   child->guc_child_index = parent->guc_number_children++;
list_add_tail(>guc_child_link,
  >guc_child_list);
child->parent = parent;
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 713d85b0b364..727f91e7f7c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -246,6 +246,9 @@ struct intel_context {
/** @guc_number_children: number of children if parent */
u8 guc_number_children;
  
+		/** @guc_child_index: index into guc_child_list if child */

+   u8 guc_child_index;
+
/**
 * @parent_page: page in context used by parent for work queue,
 * work queue descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 6cd26dc060d1..9f61cfa5566a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -188,7 +188,7 @@ struct guc_process_desc {
u32 wq_status;
u32 engine_presence;
u32 priority;
-   u32 reserved[30];
+   u32 reserved[36];
What is this extra space for? All the extra storage is grabbed from 
after the end of this structure, isn't it?



  } __packed;
  
  #define CONTEXT_REGISTRATION_FLAG_KMD	BIT(0)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 91330525330d..1a18f99bf12a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -11,6 +11,7 @@
  #include "gt/intel_context.h"
  #include "gt/intel_engine_pm.h"
  #include "gt/intel_engine_heartbeat.h"
+#include "gt/intel_gpu_commands.h"
  #include "gt/intel_gt.h"
  #include "gt/intel_gt_irq.h"
  #include "gt/intel_gt_pm.h"
@@ -366,10 +367,14 @@ static struct i915_priolist *to_priolist(struct rb_node 
*rb)
  
  /*

   * When using multi-lrc submission an extra page in the context state is
- * reserved for the process descriptor and work queue.
+ * reserved for the process descriptor, work queue, and preempt BB boundary
+ * handshake between the parent + childlren contexts.
   *
   * The layout of this page is below:
   * 0  guc_process_desc
+ * + sizeof(struct guc_process_desc)   child go
+ * + CACHELINE_BYTES   child join ...
+ * + CACHELINE_BYTES ...
Would be better written as '[num_children]' instead of '...' to make it 
clear it is a per child array.


Also, maybe create a struct for this to get rid of the magic '+1's and 
'BYTES / sizeof' constructs in the functions below.



   * ...unused
   * PAGE_SIZE / 2  work queue start
   * ...work queue
@@ -1785,6 +1790,30 @@ static int deregister_context(struct intel_context *ce, 
u32 guc_id, bool loop)
return __guc_action_deregister_context(guc, guc_id, loop);
  }
  
+static inline void 

Re: [Intel-gfx] [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined

2021-09-28 Thread Zuo, Jerry
[AMD Official Use Only]

> -Original Message-
> From: Harry Wentland 
> Sent: September 28, 2021 1:08 PM
> To: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org; Zuo, Jerry 
> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ;
> nat...@kernel.org; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> manasi.d.nav...@intel.com; Koenig, Christian ;
> Pan, Xinhui ; s...@canb.auug.org.au; linux-
> n...@vger.kernel.org; airl...@gmail.com; daniel.vet...@ffwll.ch; Wentland,
> Harry 
> Subject: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not
> already defined
>
> [Why]
> For some reason we're defining DP 2.0 definitions inside our driver. Now that
> patches to introduce relevant definitions are slated to be merged into drm-
> next this is causing conflicts.
>
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
> ./include/drm/drm_dp_helper.h:1322:9: error:
> 'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined [-
> Werror,-Wmacro-redefined]
> ^
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note:
> previous definition is here
> ^
> 1 error generated.
>
> v2: Add one missing endif
>
> [How]
> Guard all display driver defines with #ifndef for now. Once we pull in the new
> definitions into amd-staging-drm-next we will follow up and drop definitions
> from our driver and provide follow-up header updates for any addition DP
> 2.0 definitions required by our driver.
>
> Signed-off-by: Harry Wentland 

Reviewed-by: Fangzhi Zuo 

> ---
>  drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54
> ++--
>  1 file changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> index a5e798b5da79..9de86ff5ef1b 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
> @@ -860,28 +860,72 @@ struct psr_caps {
>  };
>
>  #if defined(CONFIG_DRM_AMD_DC_DCN)
> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
>  #define DP_MAIN_LINK_CHANNEL_CODING_CAP  0x006
> +#endif
> +#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
>  #define DP_SINK_VIDEO_FALLBACK_FORMATS   0x020
> +#endif
> +#ifndef DP_FEC_CAPABILITY_1
>  #define DP_FEC_CAPABILITY_1  0x091
> +#endif
> +#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
>  #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0A3
> +#endif
> +#ifndef DP_DSC_CONFIGURATION
>  #define DP_DSC_CONFIGURATION 0x161
> +#endif
> +#ifndef DP_PHY_SQUARE_PATTERN
>  #define DP_PHY_SQUARE_PATTERN0x249
> +#endif
> +#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
>  #define DP_128b_132b_SUPPORTED_LINK_RATES0x2215
> +#endif
> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>  #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>   0x2216
> +#endif
> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
>  #define DP_TEST_264BIT_CUSTOM_PATTERN_7_00X2230
> +#endif
> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
>  #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256
>   0X2250
> +#endif
> +#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
>  #define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260
> +#endif
> +#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
>  #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
>   0x2270
> -# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK   (1 <<
> 0)
> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
>   (0b111 << 1)
> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT  1
> -# define DP_DSC_DECODER_COUNT_MASK   (0b111 << 5)
> -# define DP_DSC_DECODER_COUNT_SHIFT  5
> +#endif
> +#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
> +#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK(1 <<
> 0)
> +#endif
> +#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
> +#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
>   (0b111 << 1)
> +#endif
> +#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
> +#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT   1
> +#endif
> +#ifndef DP_DSC_DECODER_COUNT_MASK
> +#define DP_DSC_DECODER_COUNT_MASK(0b111 << 5)
> +#endif
> +#ifndef DP_DSC_DECODER_COUNT_SHIFT
> +#define DP_DSC_DECODER_COUNT_SHIFT   5
> +#endif
> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
>  #define DP_MAIN_LINK_CHANNEL_CODING_SET  0x108
> +#endif
> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
>  #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
> +#endif
> +#ifndef DP_PHY_REPEATER_128b_132b_RATES
>  #define DP_PHY_REPEATER_128b_132b_RATES
>   0xF0007
> +#endif
> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
>  #define 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: DP per-lane drive settings prep work (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/i915: DP per-lane drive settings prep work (rev2)
URL   : https://patchwork.freedesktop.org/series/95122/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: DP per-lane drive settings prep work (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/i915: DP per-lane drive settings prep work (rev2)
URL   : https://patchwork.freedesktop.org/series/95122/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
be9a7b3627c4 drm/i915: s/ddi_translations/trans/
-:1808: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#1808: FILE: drivers/gpu/drm/i915/display/intel_snps_phy.c:73:
+   val |= REG_FIELD_PREP(SNPS_PHY_TX_EQ_PRE, 
trans->entries[level].snps.snps_pre_cursor);

-:1809: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#1809: FILE: drivers/gpu/drm/i915/display/intel_snps_phy.c:74:
+   val |= REG_FIELD_PREP(SNPS_PHY_TX_EQ_POST, 
trans->entries[level].snps.snps_post_cursor);

total: 0 errors, 2 warnings, 0 checks, 1677 lines checked
dd4dc5015d60 drm/i915: Generalize .set_signal_levels()
f023061edeec drm/i915: Nuke usless .set_signal_levels() wrappers
5d68ca04076a drm/i915: De-wrapper bxt_ddi_phy_set_signal_levels()
e1c952fcbe3d drm/i915: Hoover the level>=n_entries WARN into intel_ddi_level()
4e0e5a259061 drm/i915: Nuke intel_ddi_hdmi_num_entries()
21dff7c1cf74 drm/i915: Pass the lane to intel_ddi_level()
c2a69b618c76 drm/i915: Prepare link training for per-lane drive settings
9a8086f736c6 drm/i915: Allow per-lane drive settings with LTTPRs




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/amd/display: Only define DP 2.0 symbols if not already defined (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/amd/display: Only define DP 2.0 symbols if not already defined 
(rev2)
URL   : https://patchwork.freedesktop.org/series/95164/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655 -> Patchwork_21180


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][9] ([i915#2927] / [i915#3428]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [FAIL][11] ([i915#1161]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Warnings 

  * igt@kms_chamelium@vga-hpd-fast:
- fi-kbl-7500u:   [{ABORT}][13] ([i915#1814]) -> [SKIP][14] 
([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21180/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (45 -> 37)
--

  Additional (1): fi-kbl-soraka 
  Missing(9): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-hsw-4200u fi-bsw-cyan 
bat-adlp-4 fi-ctg-p8600 bat-jsl-2 bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10655 -> Patchwork_21180

  CI-20190529: 20190529
  CI_DRM_10655: 88d6ecae86a7bb32e8bf2bd233f7f9f9c8bd7abc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6226: 18278534c085c35adcf62f158a8d5356e5496f8d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21180: 5ad853d0cb0d51c38ff1ac5936876e3158fe89ee @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5ad853d0cb0d drm/amd/display: Only define DP 2.0 symbols if not 

Re: [Intel-gfx] [Freedreno] [PATCH v2 13/13] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers

2021-09-28 Thread abhinavk

On 2021-09-28 11:02, Sean Paul wrote:
On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org 
wrote:

On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul 
>
> This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> helpers.
>
> Cc: Stephen Boyd 
> Signed-off-by: Sean Paul 
> Link:
> 
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
> #v1
>
> Changes in v2:
> -Squash [1] into this patch with the following changes (Stephen)
>   -Update the sc7180 dtsi file
>   -Remove resource names and just use index (Stephen)
>


> [1]
> 
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-14-s...@poorly.run
> ---


/snip


> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 904535eda0c4..98731fd262d6 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -109,6 +109,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
>dp/dp_ctrl.o \
>dp/dp_display.o \
>dp/dp_drm.o \
> +  dp/dp_hdcp.o \
>dp/dp_hpd.o \
>dp/dp_link.o \
>dp/dp_panel.o \
> diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> b/drivers/gpu/drm/msm/dp/dp_debug.c
> index 2f6247e80e9d..de16fca8782a 100644
> --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> +++ b/drivers/gpu/drm/msm/dp/dp_debug.c


/snip


> +static ssize_t dp_hdcp_key_write(struct file *file, const char __user
> *ubuf,
> +   size_t len, loff_t *offp)
> +{
> +  char *input_buffer;
> +  int ret = 0;
> +  struct dp_debug_private *debug = file->private_data;
> +  struct drm_device *dev;
> +
> +  dev = debug->drm_dev;
> +
> +  if (len != (DRM_HDCP_KSV_LEN + DP_HDCP_NUM_KEYS * DP_HDCP_KEY_LEN))
> +  return -EINVAL;
> +
> +  if (!debug->hdcp)
> +  return -ENOENT;
> +
> +  input_buffer = memdup_user_nul(ubuf, len);
> +  if (IS_ERR(input_buffer))
> +  return PTR_ERR(input_buffer);
> +
> +  ret = dp_hdcp_ingest_key(debug->hdcp, input_buffer, len);
> +
> +  kfree(input_buffer);
> +  if (ret < 0) {
> +  DRM_ERROR("Could not ingest HDCP key, ret=%d\n", ret);
> +  return ret;
> +  }
> +
> +  *offp += len;
> +  return len;
> +}

It seems like the HDCP keys written using debugfs, just for my
understanding,
are you storing this in some secure partition and the usermode reads 
from it

and writes them here?



We have not sorted out the userspace side of HDCP enablement yet, so it 
remains
to be seen whether the keys will be injected via debugfs/firmware 
file/property.


/snip


> +static int dp_connector_atomic_check(struct drm_connector *connector,
> +   struct drm_atomic_state *state)
> +{
> +  struct drm_connector_state *conn_state;
> +  struct dp_connector_state *dp_state;
> +
> +  conn_state = drm_atomic_get_new_connector_state(state, connector);
> +  dp_state = to_dp_connector_state(conn_state);
> +
> +  dp_state->hdcp_transition = drm_hdcp_atomic_check(connector, state);

I have a general question related to the transition flag and overall 
tying

the HDCP
enable and authentication to the commit.
So lets say there is a case where the driver needs to disable HDCP. It 
could

be due
to link integrity failure OR some other error condition which usermode 
is

not aware of.
In that case, we will set this hdcp_transition to true but in the next
commit we will
actually do the authentication. What if usermode doesnt issue a new 
frame?
This question arises because currently the link intergrity check is 
done

using SW polling
in the previous patchset. But as I had commented there, this occurs in 
HW

for us.
I dont see that isr itself in this patchset. So wanted to understand 
if

thats part of this
approach to still tie it with commit.

So if we go with the HW polling based approach which is the preferred
method, we need to
untie this from the commit.



In the case of error, the worker will detect it and try to 
re-authenticate. If
the re-authentication is successful, userspace will continue to be 
unaware and
everything will keep working. If re-authentication is unsuccessful, the 
worker

will update the property value and issue a uevent to userspace. So HDCP
enablement is only tied to commits when the property value is changing 
as a

result of userspace.

Regarding SW vs HW link checks, I don't think there's any difference in 
efficacy
between them. If HW can be relied on to issue an interrupt in failure 
cases, a

follow-up set allowing for this seems like a great idea.



Thanks for the explanation. Yes, from our experience it has been pretty 
reliable to
issue signal integrity failures. We already had the isr based approach 
downstream
and would prefer to keep it that way based on our experience of it 
firing reliably.
We can still keep the SW polling code but it should come into effect 
only if HW polling

is not supported / preferred.


> +
> +  return 0;
> +}


/snip


> +static int dp_hdcp_load_keys(struct drm_connector *connector)
> +{
> +  struct dp_hdcp 

Re: [Intel-gfx] [Freedreno] [PATCH v2 04/13] drm/hdcp: Expand HDCP helper library for enable/disable/check

2021-09-28 Thread abhinavk

Hi Sean

On 2021-09-28 10:33, Sean Paul wrote:
On Tue, Sep 21, 2021 at 04:34:59PM -0700, abhin...@codeaurora.org 
wrote:

On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul 
>
> This patch expands upon the HDCP helper library to manage HDCP
> enable, disable, and check.
>
> Previous to this patch, the majority of the state management and sink
> interaction is tucked inside the Intel driver with the understanding
> that once a new platform supported HDCP we could make good decisions
> about what should be centralized. With the addition of HDCP support
> for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
> authentication, key exchange, and link checks to the HDCP helper.
>
> In terms of functionality, this migration is 1:1 with the Intel driver,
> however things are laid out a bit differently than with intel_hdcp.c,
> which is why this is a separate patch from the i915 transition to the
> helper. On i915, the "shim" vtable is used to account for HDMI vs. DP
> vs. DP-MST differences whereas the helper library uses a LUT to
> account for the register offsets and a remote read function to route
> the messages. On i915, storing the sink information in the source is
> done inline whereas now we use the new drm_hdcp_helper_funcs vtable
> to store and fetch information to/from source hw. Finally, instead of
> calling enable/disable directly from the driver, we'll leave that
> decision to the helper and by calling drm_hdcp_helper_atomic_commit()
> from the driver. All told, this will centralize the protocol and state
> handling in the helper, ensuring we collect all of our bugs^Wlogic
> in one place.
>
> Signed-off-by: Sean Paul 
> Link:
> 
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-5-s...@poorly.run
> #v1
>
> Changes in v2:
> -Fixed set-but-unused variable identified by 0-day
> ---
>  drivers/gpu/drm/drm_hdcp.c | 1103 
>  include/drm/drm_hdcp.h |  191 +++
>  2 files changed, 1294 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index 742313ce8f6f..47c6e6923a76 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c


/snip


> +static void drm_hdcp_helper_check_work(struct work_struct *work)
> +{
> +  struct drm_hdcp_helper_data *data =
> container_of(to_delayed_work(work),
> +   struct 
drm_hdcp_helper_data,
> +   check_work);
> +  unsigned long check_link_interval;
> +

Does this SW polling for Ri' mismatch need to be done even if the HW 
is

capable of doing it
on its own?
MSM HDCP 1x HW can periodically check Ri' mismatches and issue an 
interrupt

if there is a mismatch.
In that case this SW polling is not needed. So maybe check if the HW
supports polling and if so
skip this SW polling?



One could certainly change this to be HW driven. There is also an 
interrupt on
Intel for DP links which [re]schedules link check in the interrupt 
handler,
something similar could be done for msm. Note that even on these Intel 
links
which support the CP interrupt, the worker still runs on the normal 
cadence. I
haven't considered relying solely on the interrupt since I want to be 
sure we

didn't miss anything.

Sean


I think we should have the support for HW polling added. From our 
experience,
it has been pretty reliable for us and has a pretty consistent cadence 
in alignment
with the spec. I dont quite understand why we should have both in 
chipsets capable
of HW polling and am bit surprised if SW polling will catch something 
which HW

polling and the subsequent interrupt has missed.




> +  mutex_lock(>mutex);
> +  if (data->value != DRM_MODE_CONTENT_PROTECTION_ENABLED)
> +  goto out_data_mutex;
> +
> +  drm_hdcp_helper_driver_lock(data);
> +
> +  if (data->enabled_type == DRM_MODE_HDCP_CONTENT_TYPE1) {
> +  if (drm_hdcp_hdcp2_check_link(data))
> +  goto out;
> +  check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
> +  } else {
> +  if (drm_hdcp_hdcp1_check_link(data))
> +  goto out;
> +  check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
> +  }
> +  schedule_delayed_work(>check_work, check_link_interval);
> +
> +out:
> +  drm_hdcp_helper_driver_unlock(data);
> +out_data_mutex:
> +  mutex_unlock(>mutex);
> +}


/snip


Re: [Intel-gfx] [Freedreno] [PATCH v2 00/13] drm/hdcp: Pull HDCP auth/exchange/check into helpers

2021-09-28 Thread abhinavk

On 2021-09-28 11:06, Sean Paul wrote:
On Tue, Sep 21, 2021 at 07:30:29PM -0700, abhin...@codeaurora.org 
wrote:

Hi Sean

On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul 
>
> Hello again,
> This is the second version of the HDCP helper patchset. See version 1
> here: https://patchwork.freedesktop.org/series/94623/
>
> In this second version, I've fixed up the oopsies exposed by 0-day and
> yamllint and incorporated early review feedback from the dt/dts reviews.
>
> Please take a look,
>
> Sean

One question overall on the series:

1) Regarding validation, did you run any secure video to check the
transitions?


Yep, the transitions look good, no visual artifacts.
Unplug/replug/suspend/resume all seem to be behaving as expected.


2) Is running HDCP 1x compliance also part of the validation efforts?


If Qualcomm has the ability to run validation, I'd be very keen to get 
some

help in that regard.


Thanks for letting us know. To assist with (2) we will have to work with 
you on some logistics.

Will sync up on IRC further on how to go about this.



Sean



Thanks

Abhinav

>
> Sean Paul (13):
>   drm/hdcp: Add drm_hdcp_atomic_check()
>   drm/hdcp: Avoid changing crtc state in hdcp atomic check
>   drm/hdcp: Update property value on content type and user changes
>   drm/hdcp: Expand HDCP helper library for enable/disable/check
>   drm/i915/hdcp: Consolidate HDCP setup/state cache
>   drm/i915/hdcp: Retain hdcp_capable return codes
>   drm/i915/hdcp: Use HDCP helpers for i915
>   drm/msm/dpu_kms: Re-order dpu includes
>   drm/msm/dpu: Remove useless checks in dpu_encoder
>   drm/msm/dpu: Remove encoder->enable() hack
>   drm/msm/dp: Re-order dp_audio_put in deinit_sub_modules
>   dt-bindings: msm/dp: Add bindings for HDCP registers
>   drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
>
>  .../bindings/display/msm/dp-controller.yaml   |7 +-
>  arch/arm64/boot/dts/qcom/sc7180.dtsi  |4 +-
>  drivers/gpu/drm/drm_hdcp.c| 1197 -
>  drivers/gpu/drm/i915/display/intel_atomic.c   |7 +-
>  drivers/gpu/drm/i915/display/intel_ddi.c  |   29 +-
>  .../drm/i915/display/intel_display_debugfs.c  |   11 +-
>  .../drm/i915/display/intel_display_types.h|   58 +-
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  345 ++---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   17 +-
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 1011 +++---
>  drivers/gpu/drm/i915/display/intel_hdcp.h |   35 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  256 ++--
>  drivers/gpu/drm/msm/Makefile  |1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |   17 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   30 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |2 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |4 -
>  drivers/gpu/drm/msm/dp/dp_debug.c |   49 +-
>  drivers/gpu/drm/msm/dp/dp_debug.h |6 +-
>  drivers/gpu/drm/msm/dp/dp_display.c   |   47 +-
>  drivers/gpu/drm/msm/dp/dp_display.h   |5 +
>  drivers/gpu/drm/msm/dp/dp_drm.c   |   68 +-
>  drivers/gpu/drm/msm/dp/dp_drm.h   |5 +
>  drivers/gpu/drm/msm/dp/dp_hdcp.c  |  433 ++
>  drivers/gpu/drm/msm/dp/dp_hdcp.h  |   27 +
>  drivers/gpu/drm/msm/dp/dp_parser.c|   22 +-
>  drivers/gpu/drm/msm/dp/dp_parser.h|4 +
>  drivers/gpu/drm/msm/dp/dp_reg.h   |   44 +-
>  drivers/gpu/drm/msm/msm_atomic.c  |   15 +
>  include/drm/drm_hdcp.h|  194 +++
>  30 files changed, 2561 insertions(+), 1389 deletions(-)
>  create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c
>  create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h


[Intel-gfx] [PATCH v2 8/9] drm/i915: Prepare link training for per-lane drive settings

2021-09-28 Thread Ville Syrjala
From: Ville Syrjälä 

Adjust the link training code to accommodate per-lane drive settings,
if supported by the platform. Actually enabling this will involve
some changes to each platform's .set_signal_level() implementation,
so for the moment all supported platforms will keep using the current
codepath that just uses the same drive settings for all the lanes.

v2: Fix min() vs. max() fumble

Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_dp_link_training.c | 68 +--
 1 file changed, 49 insertions(+), 19 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 d52929855cd0..5452f777afac 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -301,21 +301,33 @@ static u8 intel_dp_phy_preemph_max(struct intel_dp 
*intel_dp,
return preemph_max;
 }
 
-void
-intel_dp_get_adjust_train(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state,
- enum drm_dp_phy dp_phy,
- const u8 link_status[DP_LINK_STATUS_SIZE])
+static bool has_per_lane_signal_levels(struct drm_i915_private *i915,
+  enum drm_dp_phy dp_phy)
+{
+   return false;
+}
+
+static u8 intel_dp_get_lane_adjust_train(struct intel_dp *intel_dp,
+const struct intel_crtc_state 
*crtc_state,
+enum drm_dp_phy dp_phy,
+const u8 
link_status[DP_LINK_STATUS_SIZE],
+int lane)
 {
u8 v = 0;
u8 p = 0;
-   int lane;
u8 voltage_max;
u8 preemph_max;
 
-   for (lane = 0; lane < crtc_state->lane_count; lane++) {
-   v = max(v, drm_dp_get_adjust_request_voltage(link_status, 
lane));
-   p = max(p, drm_dp_get_adjust_request_pre_emphasis(link_status, 
lane));
+   if (has_per_lane_signal_levels(dp_to_i915(intel_dp), dp_phy)) {
+   lane = min(lane, crtc_state->lane_count - 1);
+
+   v = drm_dp_get_adjust_request_voltage(link_status, lane);
+   p = drm_dp_get_adjust_request_pre_emphasis(link_status, lane);
+   } else {
+   for (lane = 0; lane < crtc_state->lane_count; lane++) {
+   v = max(v, 
drm_dp_get_adjust_request_voltage(link_status, lane));
+   p = max(p, 
drm_dp_get_adjust_request_pre_emphasis(link_status, lane));
+   }
}
 
preemph_max = intel_dp_phy_preemph_max(intel_dp, dp_phy);
@@ -328,8 +340,21 @@ intel_dp_get_adjust_train(struct intel_dp *intel_dp,
if (v >= voltage_max)
v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
 
+   return v | p;
+}
+
+void
+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ enum drm_dp_phy dp_phy,
+ const u8 link_status[DP_LINK_STATUS_SIZE])
+{
+   int lane;
+
for (lane = 0; lane < 4; lane++)
-   intel_dp->train_set[lane] = v | p;
+   intel_dp->train_set[lane] =
+   intel_dp_get_lane_adjust_train(intel_dp, crtc_state,
+  dp_phy, link_status, 
lane);
 }
 
 static int intel_dp_training_pattern_set_reg(struct intel_dp *intel_dp,
@@ -400,17 +425,22 @@ void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
 {
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   u8 train_set = intel_dp->train_set[0];
char phy_name[10];
+   int lane;
 
-   drm_dbg_kms(_priv->drm, "Using vswing level %d%s, pre-emphasis 
level %d%s, at %s\n",
-   train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
-   train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : "",
-   (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) >>
-   DP_TRAIN_PRE_EMPHASIS_SHIFT,
-   train_set & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ?
-   " (max)" : "",
-   intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name)));
+   for (lane = 0; lane < crtc_state->lane_count; lane++) {
+   u8 train_set = intel_dp->train_set[lane];
+
+   drm_dbg_kms(_priv->drm, "[ENCODER:%d:%s] %s lane %d, vswing 
level %d%s, pre-emphasis level %d%s\n",
+   encoder->base.base.id, encoder->base.name,
+   intel_dp_phy_name(dp_phy, phy_name, 
sizeof(phy_name)),
+   lane, train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
+   train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : 
"",
+   

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/amd/display: Only define DP 2.0 symbols if not already defined (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/amd/display: Only define DP 2.0 symbols if not already defined 
(rev2)
URL   : https://patchwork.freedesktop.org/series/95164/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/amd/display: Only define DP 2.0 symbols if not already defined (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/amd/display: Only define DP 2.0 symbols if not already defined 
(rev2)
URL   : https://patchwork.freedesktop.org/series/95164/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5ad853d0cb0d drm/amd/display: Only define DP 2.0 symbols if not already defined
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#14: 
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:

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




[Intel-gfx] [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined

2021-09-28 Thread Harry Wentland
[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.

In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
./include/drm/drm_dp_helper.h:1322:9: error: 
'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined 
[-Werror,-Wmacro-redefined]
^
./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note: previous 
definition is here
^
1 error generated.

v2: Add one missing endif

[How]
Guard all display driver defines with #ifndef for now. Once we pull
in the new definitions into amd-staging-drm-next we will follow
up and drop definitions from our driver and provide follow-up
header updates for any addition DP 2.0 definitions required
by our driver.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54 ++--
 1 file changed, 49 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index a5e798b5da79..9de86ff5ef1b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -860,28 +860,72 @@ struct psr_caps {
 };
 
 #if defined(CONFIG_DRM_AMD_DC_DCN)
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
 #define DP_MAIN_LINK_CHANNEL_CODING_CAP0x006
+#endif
+#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
 #define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
+#endif
+#ifndef DP_FEC_CAPABILITY_1
 #define DP_FEC_CAPABILITY_10x091
+#endif
+#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
 #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0A3
+#endif
+#ifndef DP_DSC_CONFIGURATION
 #define DP_DSC_CONFIGURATION   0x161
+#endif
+#ifndef DP_PHY_SQUARE_PATTERN
 #define DP_PHY_SQUARE_PATTERN  0x249
+#endif
+#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
 #define DP_128b_132b_SUPPORTED_LINK_RATES  0x2215
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL  0x2216
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
 #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0  0X2230
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
 #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256  0X2250
+#endif
+#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
 #define DP_DSC_SUPPORT_AND_DECODER_COUNT   0x2260
+#endif
+#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
 #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0   0x2270
-# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1
-# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
-# define DP_DSC_DECODER_COUNT_SHIFT5
+#endif
+#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
+#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK  (1 << 0)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK  (0b111 << 1)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
+#endif
+#ifndef DP_DSC_DECODER_COUNT_MASK
+#define DP_DSC_DECODER_COUNT_MASK  (0b111 << 5)
+#endif
+#ifndef DP_DSC_DECODER_COUNT_SHIFT
+#define DP_DSC_DECODER_COUNT_SHIFT 5
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
 #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER   0xF0006
+#endif
+#ifndef DP_PHY_REPEATER_128b_132b_RATES
 #define DP_PHY_REPEATER_128b_132b_RATES0xF0007
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER10xF0022
+#endif
+#ifndef DP_INTRA_HOP_AUX_REPLY_INDICATION
 #define DP_INTRA_HOP_AUX_REPLY_INDICATION  (1 << 3)
+#endif
 /* TODO - Use DRM header to replace above once available */
 
 union dp_main_line_channel_coding_cap {
-- 
2.33.0



[Intel-gfx] ✓ Fi.CI.IGT: success for drm/amd/display: Only define DP 2.0 symbols if not already defined

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/amd/display: Only define DP 2.0 symbols if not already defined
URL   : https://patchwork.freedesktop.org/series/95164/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655_full -> Patchwork_21178_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][2] ([fdo#109314])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-iclb7/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_ctx_persistence@smoketest:
- shard-iclb: [PASS][3] -> [FAIL][4] ([i915#2896])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb2/igt@gem_ctx_persiste...@smoketest.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-iclb4/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-tglb8/igt@gem_...@unwedge-stress.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-tglb5/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb1/igt@gem_...@unwedge-stress.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-iclb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-kbl4/igt@gem_exec_f...@basic-deadline.html
- shard-apl:  NOTRUN -> [FAIL][11] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-apl8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_params@dr1-dirt:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#118] / 
[i915#95]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-glk5/igt@gem_exec_par...@dr1-dirt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-glk7/igt@gem_exec_par...@dr1-dirt.html

  * igt@gem_exec_params@no-bsd:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109283])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-tglb8/igt@gem_exec_par...@no-bsd.html

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

  * igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb:  [PASS][21] -> [DMESG-FAIL][22] ([i915#4123])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-snb2/igt@gem_pp...@blt-vs-render-ctxn.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-snb7/igt@gem_pp...@blt-vs-render-ctxn.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][23] ([i915#2658])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-kbl3/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@input-checking:
- shard-snb:  NOTRUN -> [DMESG-WARN][24] ([i915#3002])
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/shard-snb2/igt@gem_userptr_bl...@input-checking.html

  * 

Re: [Intel-gfx] [PATCH 2/3] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

2021-09-28 Thread Lyude Paul
On Tue, 2021-09-28 at 13:00 -0700, Doug Anderson wrote:
> Hi,
> 
> 
> I'm not sure I understand the comment above. You say "enabled/disabled
> via PWM" and that doesn't make sense w/ my mental model. Normally I
> think of a PWM allowing you to adjust the brightness and there being a
> separate GPIO that's in charge of enable/disable. To some extent you

Oops - you're completely right, it is a GPIO pin and I got myself
confused since in i915 I'm the chipset-specific callbacks for turning
the panel on are intertwined with the PWM callbacks.

> could think of a PWM as being "disabled" when its duty cycle is 0%,
> but usually there's separate "enable" logic that really has nothing to
> do with the PWM itself.
> 
> In general, it seems like the options are:
> 
> 1. DPCD controls PWM and the "enable" logic.
> 
> 2. DPCD controls PWM but requires an external "enable" GPIO.
> 
> 3. We require an external PWM but DPCD controls the "enable" logic.
> 
> Maybe you need a second "capability" to describe whether the client of
> your code knows how to control an enable GPIO? ...or perhaps better
> you don't need a capability and you can just assume that if the client
> needs to set an "enable" GPIO that it will do so. That would match how
> things work today. AKA:
> 
> a) Client calls the AUX backlight code to "enable"
> 
> b) AUX backlight code will set the "enable" bit if supported.
> 
> c) Client will set the "enable" GPIO if it knows about one.
> 
> Presumably only one of b) or c) will actually do something. If neither
> does something then this panel simply isn't compatible with this
> board.

I will definitely take note from this explanation and rewrite some of
the helper docs I'm updating to reflect this, thank you!

Being that I think panel drivers are basically the only other user of
this driver, if you think this is the way to go I'm OK with this. My
original reasoning for having a cap for this was worrying about the ARM
drivers handling this, along with potentially changing backlight
behavior in nouveau. I'm realizing now though that those are probably
problems for nouveau and not the helper, and I could probably avoid
hitting any issues by just adding some additional DPCD checks for GPIO
enabling/PWM passthrough in nouveau itself.

So I'll drop the cap in the next respin of this
> 
> 
> > +/**
> > + * drm_edp_backlight_supported() - Check an eDP DPCD for VESA backlight
> > support
> > + * @aux: The AUX channel, only used for debug logging
> > + * @edp_dpcd: The DPCD to check
> > + * @caps: The backlight capabilities this driver supports
> > + *
> > + * Returns: %True if @edp_dpcd indicates that VESA backlight controls are
> > supported, %false
> > + * otherwise
> > + */
> > +bool drm_edp_backlight_supported(struct drm_dp_aux *aux,
> > +    const u8
> > edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE],
> > +    enum drm_edp_backlight_driver_caps caps)
> > +{
> > +   if (!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP))
> > +   return false;
> > +
> > +   if (!(caps & DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM) &&
> > +   (!(edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) ||
> > +    !(edp_dpcd[2] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))) {
> 
> Elsewhere you match DP_EDP_BACKLIGHT_AUX_ENABLE_CAP against
> edp_dpcd[1]. Here you match against [2]. Are you sure that's correct?

absolutely not! thank you for catching this

> 
> 
> >  /*
> >   * DisplayPort AUX channel
> >   */
> > @@ -2200,7 +2182,11 @@ drm_dp_has_quirk(const struct drm_dp_desc *desc,
> > enum drm_dp_quirk quirk)
> >   * @pwm_freq_pre_divider: The PWM frequency pre-divider value being used
> > for this backlight, if any
> >   * @max: The maximum backlight level that may be set
> >   * @lsb_reg_used: Do we also write values to the
> > DP_EDP_BACKLIGHT_BRIGHTNESS_LSB register?
> > - * @aux_enable: Does the panel support the AUX enable cap?
> > + * @aux_enable: Does the panel support the AUX enable cap? Always %false
> > when the driver doesn't
> > + * support %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM
> 
> Why is aux_enable always false if it doesn't support
> DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM? It doesn't seem like the code
> enforces this and I'm not sure why it would. Am I confused?

This was mainly just to keep the behavior identical for drivers that
didn't support controlling backlights like this, but re: the response I
wrote up above I think we can just totally drop the caps.

> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat



Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-28 at 23:38 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 11:29:49PM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 23:08 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 11:02:37PM +0300, Souza, Jose wrote:
> > > > On Tue, 2021-09-28 at 22:55 +0300, Imre Deak wrote:
> > > > > On Tue, Sep 28, 2021 at 10:45:50PM +0300, Souza, Jose wrote:
> > > > > > > > [...]
> > > > > > > > Would not be possible to use TC_PORT_DISCONNECTED when really
> > > > > > > > disconnected and dropping the use of TC_PORT_TBT_ALT for it?
> > > > > > > 
> > > > > > > TC_PORT_DISCONNECTED is the state when the PHY ownership is not 
> > > > > > > held and
> > > > > > > we don't hold any power domains.
> > > > > > > 
> > > > > > > TC_PORT_TBT_ALT is the state when the PHY ownership is not held 
> > > > > > > (like
> > > > > > > above), and we hold the power domain needed to block TC-cold.
> > > > > > 
> > > > > > Swapping it would make modes names do what their names intend to.
> > > > > > 
> > > > > > Up to the point that we only had TBT, TC alt and legacy it was fine 
> > > > > > to
> > > > > > keep into TBT mode when disconnected but now with a disconnected 
> > > > > > state
> > > > > > it do not make sense to keep it in TBT mode when disconnected.
> > > > > > 
> > > > > > Or you rename it to TC_PORT_UNKNOWN, as it sets to
> > > > > > TC_PORT_DISCONNECTED mode during tc_init() and when going to 
> > > > > > suspend.
> > > > > 
> > > > > Not sure what you mean, because what you describe is what actually
> > > > > happens. From all states icl_tc_phy_disconnect() will change to
> > > > > the disconnected state, which is the state at init time and during
> > > > > suspend or after unloading the driver.
> > > > 
> > > > I'm talking about the state when system is up without anything
> > > > connected to the port, after icl_tc_phy_disconnect() sets
> > > > dig_port->tc_mode = TC_PORT_DISCONNECTED, icl_tc_phy_connect() goes
> > > > and set it back to TC_PORT_TBT_ALT.
> > > 
> > > Yes, when the port is locked we are in one of TBT-alt, DP-alt or legacy
> > > mode. These are the only modes that make sense for an AUX transfer or a
> > > modeset, for which the lock was taken.
> > 
> > Okay at the end of the series mode goes to TC_PORT_DISCONNECTED if no
> > reference is held.
> 
> Yes.

With the warn_on fixed:

Reviewed-by: José Roberto de Souza 

> 
> --Imre



Re: [Intel-gfx] [PATCH 13/13] drm/i915/tc: Fix system hang on ADL-P during TypeC PHY disconnect

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> The PHY ownership release->AUX PW disable steps during a modeset
> disable->PHY disconnect sequence can hang the system if the PHY
> disconnect happens after disabling the PHY's PLL. The spec doesn't
> require a specific order for these two steps, so this issue is still
> being root caused by HW/FW teams. Until that is found, let's make
> sure the disconnect happens before the PLL is disabled, and do this on
> all platforms for consistency.
> 
> Cc: José Roberto de Souza 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 99b66c2852e53..dc52b76bd57e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -813,6 +813,12 @@ void intel_tc_port_put_link(struct intel_digital_port 
> *dig_port)
>   intel_tc_port_lock(dig_port);
>   --dig_port->tc_link_refcount;
>   intel_tc_port_unlock(dig_port);
> +
> + /*
> +  * Disconnecting the PHY after the PHY's PLL gets disabled may
> +  * hang the system on ADL-P, so disconnect the PHY here synchronously.
> +  */

Please at to the comment that this is temporary while HW/FW teaams root cause 
it.

With that:
Reviewed-by: José Roberto de Souza 

> + intel_tc_port_flush_work(dig_port);
>  }
>  
>  static bool



Re: [Intel-gfx] [PATCH 12/13] drm/i915/tc: Drop extra TC cold blocking from intel_tc_port_connected()

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> After the previous patch the driver holds a power domain blocking
> TC-cold whenever the port is locked, so we can remove the extra blocking
> around the lock/unlock sequence.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 3fefd00e04685..99b66c2852e53 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -719,16 +719,12 @@ bool intel_tc_port_connected(struct intel_encoder 
> *encoder)
>  {
>   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
>   bool is_connected;
> - enum intel_display_power_domain domain;
> - intel_wakeref_t tc_cold_wref;
>  
>   intel_tc_port_lock(dig_port);
> - tc_cold_wref = tc_cold_block(dig_port, );
>  
>   is_connected = tc_port_live_status_mask(dig_port) &
>  BIT(dig_port->tc_mode);
>  
> - tc_cold_unblock(dig_port, domain, tc_cold_wref);
>   intel_tc_port_unlock(dig_port);
>  
>   return is_connected;



Re: [Intel-gfx] [PATCH 11/13] drm/i915/tc: Fix TypeC PHY connect/disconnect logic on ADL-P

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> So far TC-cold was blocked only for the duration of TypeC mode resets.
> The DP-alt and legacy modes require TC-cold to be blocked also whenever
> the port is in use (AUX transfers, enable modeset), and this was ensured
> by the held PHY ownership flag. On ADL-P this doesn't work, since the
> PHY ownership flag is in a register backed by the PW#2 power well.
> Whenever this power well is disabled the ownership flag is cleared by
> the HW under the driver.
> 
> The only way to cleanly release and re-acquire the PHY ownership flag
> and also allow for power saving (by disabling the display power wells
> and reaching DC5/6 states) is to hold the TC-cold blocking power domains
> while the PHY is connected and disconnect/reconnect the PHY on-demand
> around AUX transfers and modeset enable/disables. Let's do that,
> disconnecting a PHY with a 1 sec delay after it becomes idle. For
> consistency do this on all platforms and TypeC modes.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  7 +-
>  .../drm/i915/display/intel_display_types.h|  1 +
>  drivers/gpu/drm/i915/display/intel_tc.c   | 87 +++
>  drivers/gpu/drm/i915/display/intel_tc.h   |  2 +-
>  4 files changed, 60 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index b9194d6a4dfe7..b509d5f2d5f0e 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4019,8 +4019,11 @@ static void intel_ddi_encoder_destroy(struct 
> drm_encoder *encoder)
>  {
>   struct drm_i915_private *i915 = to_i915(encoder->dev);
>   struct intel_digital_port *dig_port = 
> enc_to_dig_port(to_intel_encoder(encoder));
> + enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
>  
>   intel_dp_encoder_flush_work(encoder);
> + if (intel_phy_is_tc(i915, phy))
> + intel_tc_port_flush_work(dig_port);
>   intel_display_power_flush_work(i915);
>  
>   drm_encoder_cleanup(encoder);
> @@ -4445,7 +4448,7 @@ static void intel_ddi_encoder_suspend(struct 
> intel_encoder *encoder)
>   if (!intel_phy_is_tc(i915, phy))
>   return;
>  
> - intel_tc_port_disconnect_phy(dig_port);
> + intel_tc_port_flush_work(dig_port);
>  }
>  
>  static void intel_ddi_encoder_shutdown(struct intel_encoder *encoder)
> @@ -4460,7 +4463,7 @@ static void intel_ddi_encoder_shutdown(struct 
> intel_encoder *encoder)
>   if (!intel_phy_is_tc(i915, phy))
>   return;
>  
> - intel_tc_port_disconnect_phy(dig_port);
> + intel_tc_port_flush_work(dig_port);
>  }
>  
>  #define port_tc_name(port) ((port) - PORT_TC1 + '1')
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 08a73ffded957..53509f6ae3d10 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1667,6 +1667,7 @@ struct intel_digital_port {
>   struct mutex tc_lock;   /* protects the TypeC port mode */
>   intel_wakeref_t tc_lock_wakeref;
>   enum intel_display_power_domain tc_lock_power_domain;
> + struct delayed_work tc_disconnect_phy_work;
>   int tc_link_refcount;
>   bool tc_legacy_port:1;
>   char tc_port_name[8];
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 8d799cf7ccefd..3fefd00e04685 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -645,6 +645,13 @@ static void intel_tc_port_update_mode(struct 
> intel_digital_port *dig_port,
>  
>   intel_tc_port_reset_mode(dig_port, required_lanes, force_disconnect);
>  
> + /* Get power domain matching the new mode after reset. */
> + tc_cold_unblock(dig_port, dig_port->tc_lock_power_domain,
> + fetch_and_zero(_port->tc_lock_wakeref));
> + if (dig_port->tc_mode != TC_PORT_DISCONNECTED)
> + dig_port->tc_lock_wakeref = tc_cold_block(dig_port,
> +   
> _port->tc_lock_power_domain);
> +
>   tc_cold_unblock(dig_port, domain, wref);
>  }
>  
> @@ -672,6 +679,7 @@ void intel_tc_port_sanitize(struct intel_digital_port 
> *dig_port)
>   active_links = to_intel_crtc(encoder->base.crtc)->active;
>  
>   drm_WARN_ON(>drm, dig_port->tc_mode != TC_PORT_DISCONNECTED);
> + drm_WARN_ON(>drm, dig_port->tc_lock_wakeref);
>   if (active_links) {
>   enum intel_display_power_domain domain;
>   intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port, );
> @@ -684,6 +692,9 @@ void intel_tc_port_sanitize(struct intel_digital_port 
> *dig_port)
>   

Re: [Intel-gfx] [PATCH 10/13] drm/i915/icl/tc: Remove the ICL special casing during TC-cold blocking

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-28 at 13:52 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 01:02:21AM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> > > While a TypeC port mode is locked a DISPLAY_CORE power domain reference
> > > is held, which implies a runtime PM ref. By removing the ICL !legacy
> > > port special casing, a TC_COLD_OFF power domain reference will be taken
> > > for such ports, which also translates to a runtime PM ref on that
> > > platform. A follow-up change will stop holding the DISPLAY_CORE power
> > > domain while the port is locked.
> > 
> > This should be squashed to 'drm/i915/tc: Refactor TC-cold
> > block/unblock helpers' otherwise domain is not initialized for this
> > case.
> 
> domain is always only valid with a non-zero wakeref, so no need to init
> domain if the returned wakeref is zero.

Reviewed-by: José Roberto de Souza 

> 
> > > Cc: José Roberto de Souza 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_tc.c | 6 --
> > >  1 file changed, 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > index b2a3d297bfc19..8d799cf7ccefd 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > @@ -71,9 +71,6 @@ tc_cold_block_in_mode(struct intel_digital_port 
> > > *dig_port, enum tc_port_mode mod
> > >  {
> > >   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > >  
> > > - if (DISPLAY_VER(i915) == 11 && !dig_port->tc_legacy_port)
> > > - return 0;
> > > -
> > >   *domain = tc_cold_get_power_domain(dig_port, mode);
> > >  
> > >   return intel_display_power_get(i915, *domain);
> > > @@ -108,9 +105,6 @@ assert_tc_cold_blocked(struct intel_digital_port 
> > > *dig_port)
> > >   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > >   bool enabled;
> > >  
> > > - if (DISPLAY_VER(i915) == 11 && !dig_port->tc_legacy_port)
> > > - return;
> > > -
> > >   enabled = intel_display_power_is_enabled(i915,
> > >
> > > tc_cold_get_power_domain(dig_port,
> > > 
> > > dig_port->tc_mode));
> > 



Re: [Intel-gfx] [PATCH 22/27] drm/i915/guc: Add basic GuC multi-lrc selftest

2021-09-28 Thread John Harrison

On 8/20/2021 15:44, Matthew Brost wrote:

Add very basic (single submission) multi-lrc selftest.

Signed-off-by: Matthew Brost 
---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |   1 +
  .../drm/i915/gt/uc/selftest_guc_multi_lrc.c   | 180 ++
  .../drm/i915/selftests/i915_live_selftests.h  |   1 +
  3 files changed, 182 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 2554d0eb4afd..91330525330d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3924,4 +3924,5 @@ bool intel_guc_virtual_engine_has_heartbeat(const struct 
intel_engine_cs *ve)
  
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)

  #include "selftest_guc.c"
+#include "selftest_guc_multi_lrc.c"
  #endif
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c 
b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
new file mode 100644
index ..dacfc5dfadd6
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright �� 2019 Intel Corporation
+ */
+
+#include "selftests/igt_spinner.h"
+#include "selftests/igt_reset.h"
+#include "selftests/intel_scheduler_helpers.h"
+#include "gt/intel_engine_heartbeat.h"
+#include "gem/selftests/mock_context.h"
+
+static void logical_sort(struct intel_engine_cs **engines, int num_engines)
+{
+   struct intel_engine_cs *sorted[MAX_ENGINE_INSTANCE + 1];
+   int i, j;
+
+   for (i = 0; i < num_engines; ++i)
+   for (j = 0; j < MAX_ENGINE_INSTANCE + 1; ++j) {
+   if (engines[j]->logical_mask & BIT(i)) {
+   sorted[i] = engines[j];
+   break;
+   }
+   }
+
+   memcpy(*engines, *sorted,
+  sizeof(struct intel_engine_cs *) * num_engines);
+}
+
+static struct intel_context *
+multi_lrc_create_parent(struct intel_gt *gt, u8 class,
+   unsigned long flags)
+{
+   struct intel_engine_cs *siblings[MAX_ENGINE_INSTANCE + 1];
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   int i = 0;
+
+   for_each_engine(engine, gt, id) {
+   if (engine->class != class)
+   continue;
+
+   siblings[i++] = engine;
+   }
+
+   if (i <= 1)
+   return ERR_PTR(0);
+
+   logical_sort(siblings, i);
+
+   return intel_engine_create_parallel(siblings, 1, i);
+}
+
+static void multi_lrc_context_unpin(struct intel_context *ce)
+{
+   struct intel_context *child;
+
+   GEM_BUG_ON(!intel_context_is_parent(ce));
+
+   for_each_child(ce, child)
+   intel_context_unpin(child);
+   intel_context_unpin(ce);
+}
+
+static void multi_lrc_context_put(struct intel_context *ce)
+{
+   GEM_BUG_ON(!intel_context_is_parent(ce));
+
+   /*
+* Only the parent gets the creation ref put in the uAPI, the parent
+* itself is responsible for creation ref put on the children.
+*/
+   intel_context_put(ce);
+}
+
+static struct i915_request *
+multi_lrc_nop_request(struct intel_context *ce)
+{
+   struct intel_context *child;
+   struct i915_request *rq, *child_rq;
+   int i = 0;
+
+   GEM_BUG_ON(!intel_context_is_parent(ce));
+
+   rq = intel_context_create_request(ce);
+   if (IS_ERR(rq))
+   return rq;
+
+   i915_request_get(rq);
+   i915_request_add(rq);
+
+   for_each_child(ce, child) {
+   child_rq = intel_context_create_request(child);
+   if (IS_ERR(child_rq))
+   goto child_error;
+
+   if (++i == ce->guc_number_children)
+   set_bit(I915_FENCE_FLAG_SUBMIT_PARALLEL,
+   _rq->fence.flags);
+   i915_request_add(child_rq);
+   }
+
+   return rq;
+
+child_error:
+   i915_request_put(rq);
+
+   return ERR_PTR(-ENOMEM);
+}
+
+static int __intel_guc_multi_lrc_basic(struct intel_gt *gt, unsigned int class)
+{
+   struct intel_context *parent;
+   struct i915_request *rq;
+   int ret;
+
+   parent = multi_lrc_create_parent(gt, class, 0);
+   if (IS_ERR(parent)) {
+   pr_err("Failed creating contexts: %ld", PTR_ERR(parent));
+   return PTR_ERR(parent);
+   } else if (!parent) {
+   pr_debug("Not enough engines in class: %d",
+VIDEO_DECODE_CLASS);

Should be 'class'.

With that fixed:
Reviewed-by: John Harrison 


+   return 0;
+   }
+
+   rq = multi_lrc_nop_request(parent);
+   if (IS_ERR(rq)) {
+   ret = PTR_ERR(rq);
+   pr_err("Failed creating requests: %d", ret);
+   goto out;
+   

Re: [Intel-gfx] [PATCH] drm/i915: Tile F plane format support

2021-09-28 Thread Ville Syrjälä
On Tue, Sep 28, 2021 at 11:36:51PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, Sep 28, 2021 at 10:02:34PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote:
> > > On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote:
> > > > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote:
> > > > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote:
> > > > > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote:
> > > > > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy 
> > > > > > > wrote:
> > > > > > > > TileF(Tile4 in bspec) format is 4K tile organized into
> > > > > > > > 64B subtiles with same basic shape as for legacy TileY
> > > > > > > > which will be supported by Display13.
> > > > > > > 
> > > > > > > Why we still haven't done the F->tile64 rename?
> > > > > > >
> > > > > > > This is the last chance to fix this before we bake 
> > > > > > > this into the uapi and are stuck with a name that doesn't
> > > > > > > match the spec and will just confuse everyone.
> > > > > > 
> > > > > > I think you're confusing the formats here.  The bspec uses both 
> > > > > > terms
> > > > > > "TileF" and "Tile4" for the same format in different places.  
> > > > > > There's a
> > > > > > completely different format that's referred to as both "TileS" and
> > > > > > "Tile64" in the bspec that we don't use at the moment.  So tile64
> > > > > > wouldn't be a correct rename, but tile4 could be.
> > > > > 
> > > > > Right, tile64 is the macro tile variant I think. So like Ys
> > > > > which we never bothered implementing, so I guess we''l not bother
> > > > > with tile64 either.
> > > > > 
> > > > > > 
> > > > > > In general Tile4 is much more common in the bspec than TileF is 
> > > > > > (TileF
> > > > > > terminology is mostly found in the media sections).  And bspec 
> > > > > > 44917 is
> > > > > > the most authoritative bspec page on the subject, and it refers to 
> > > > > > it as
> > > > > > Tile4, so I agree that switching over "Tile4" would probably be a 
> > > > > > good
> > > > > > move.
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > ...
> > > > > > > > diff --git a/include/uapi/drm/i915_drm.h 
> > > > > > > > b/include/uapi/drm/i915_drm.h
> > > > > > > > index bde5860b3686..d7dc421c6134 100644
> > > > > > > > --- a/include/uapi/drm/i915_drm.h
> > > > > > > > +++ b/include/uapi/drm/i915_drm.h
> > > > > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching {
> > > > > > > >  #define I915_TILING_NONE   0
> > > > > > > >  #define I915_TILING_X  1
> > > > > > > >  #define I915_TILING_Y  2
> > > > > > > > -#define I915_TILING_LAST   I915_TILING_Y
> > > > > > > > +#define I915_TILING_F  3
> > > > > > > > +#define I915_TILING_LAST   I915_TILING_F
> > > > > > > 
> > > > > > > fences...
> > > > > > 
> > > > > > Recognizing TileF/Tile4 separately from TileY is important to code
> > > > > > outside of display as well.  There are blitter instructions that 
> > > > > > require
> > > > > > different settings for TileY vs Tile4/F so if we drop the tracking 
> > > > > > of
> > > > > > this as a unique tiling type, it will break the blitting/copying and
> > > > > > some of the upcoming local memory support for Xe_HP-based platforms.
> > > > > 
> > > > > These are uapi definitions for set_tiling(). You are not meant to add
> > > > > anything there. Just like we didn't add anything for Yf.
> > > > 
> > > > Yeah, I think that's the real problem --- we define some values here in
> > > > the uapi header, but we also wind up using the same set of values for
> > > > driver-internal non-uapi purposes too rather than having a separate enum
> > > > (containing a superset of the uapi values) that can be used for those
> > > > other things.  Display code can use FB modifiers for some things, but
> > > > core/lmem code needs a way to refer to Tile4 and such and doesn't have a
> > > > good way to do that today.
> > > > 
> > > > I think most (all?) of the non-display code that's relying on a
> > > > definition of I915_TILING_F is in various selftests that are still being
> > > > prepared for upstreaming, so maybe there's a better way to handle the
> > > > selection of possible formats specifically in the selftest code itself.
> > > > That's really the only area of the kernel code that should need to be
> > > > aware of the specific internal layout of various buffers.
> > > 
> > > So I will proceed with the renaming at least.
> > > 
> > > Ville, suppose, I still need part of fencing related code?
> > 
> > Nah. Just nuke it all. Someone will have to fix whatever self test is
> > abusing the uapi definitions though.
> > 
> > A local #define should suffice if nothing else is deemed appropriate.
> > IIRC igt also has a local definition like this for Yf. We should
> > perhaps rename those to some igt specific namespace as well...
> 
> As Matt mentioned, removing I915_TILING_F completely is going to break

Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Imre Deak
On Tue, Sep 28, 2021 at 11:29:49PM +0300, Souza, Jose wrote:
> On Tue, 2021-09-28 at 23:08 +0300, Imre Deak wrote:
> > On Tue, Sep 28, 2021 at 11:02:37PM +0300, Souza, Jose wrote:
> > > On Tue, 2021-09-28 at 22:55 +0300, Imre Deak wrote:
> > > > On Tue, Sep 28, 2021 at 10:45:50PM +0300, Souza, Jose wrote:
> > > > > > > [...]
> > > > > > > Would not be possible to use TC_PORT_DISCONNECTED when really
> > > > > > > disconnected and dropping the use of TC_PORT_TBT_ALT for it?
> > > > > > 
> > > > > > TC_PORT_DISCONNECTED is the state when the PHY ownership is not 
> > > > > > held and
> > > > > > we don't hold any power domains.
> > > > > > 
> > > > > > TC_PORT_TBT_ALT is the state when the PHY ownership is not held 
> > > > > > (like
> > > > > > above), and we hold the power domain needed to block TC-cold.
> > > > > 
> > > > > Swapping it would make modes names do what their names intend to.
> > > > > 
> > > > > Up to the point that we only had TBT, TC alt and legacy it was fine to
> > > > > keep into TBT mode when disconnected but now with a disconnected state
> > > > > it do not make sense to keep it in TBT mode when disconnected.
> > > > > 
> > > > > Or you rename it to TC_PORT_UNKNOWN, as it sets to
> > > > > TC_PORT_DISCONNECTED mode during tc_init() and when going to suspend.
> > > > 
> > > > Not sure what you mean, because what you describe is what actually
> > > > happens. From all states icl_tc_phy_disconnect() will change to
> > > > the disconnected state, which is the state at init time and during
> > > > suspend or after unloading the driver.
> > > 
> > > I'm talking about the state when system is up without anything
> > > connected to the port, after icl_tc_phy_disconnect() sets
> > > dig_port->tc_mode = TC_PORT_DISCONNECTED, icl_tc_phy_connect() goes
> > > and set it back to TC_PORT_TBT_ALT.
> > 
> > Yes, when the port is locked we are in one of TBT-alt, DP-alt or legacy
> > mode. These are the only modes that make sense for an AUX transfer or a
> > modeset, for which the lock was taken.
> 
> Okay at the end of the series mode goes to TC_PORT_DISCONNECTED if no
> reference is held.

Yes.

--Imre


Re: [Intel-gfx] [PATCH] drm/i915: Tile F plane format support

2021-09-28 Thread Lisovskiy, Stanislav
On Tue, Sep 28, 2021 at 10:02:34PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote:
> > On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote:
> > > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote:
> > > > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote:
> > > > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote:
> > > > > > > TileF(Tile4 in bspec) format is 4K tile organized into
> > > > > > > 64B subtiles with same basic shape as for legacy TileY
> > > > > > > which will be supported by Display13.
> > > > > > 
> > > > > > Why we still haven't done the F->tile64 rename?
> > > > > >
> > > > > > This is the last chance to fix this before we bake 
> > > > > > this into the uapi and are stuck with a name that doesn't
> > > > > > match the spec and will just confuse everyone.
> > > > > 
> > > > > I think you're confusing the formats here.  The bspec uses both terms
> > > > > "TileF" and "Tile4" for the same format in different places.  There's 
> > > > > a
> > > > > completely different format that's referred to as both "TileS" and
> > > > > "Tile64" in the bspec that we don't use at the moment.  So tile64
> > > > > wouldn't be a correct rename, but tile4 could be.
> > > > 
> > > > Right, tile64 is the macro tile variant I think. So like Ys
> > > > which we never bothered implementing, so I guess we''l not bother
> > > > with tile64 either.
> > > > 
> > > > > 
> > > > > In general Tile4 is much more common in the bspec than TileF is (TileF
> > > > > terminology is mostly found in the media sections).  And bspec 44917 
> > > > > is
> > > > > the most authoritative bspec page on the subject, and it refers to it 
> > > > > as
> > > > > Tile4, so I agree that switching over "Tile4" would probably be a good
> > > > > move.
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > ...
> > > > > > > diff --git a/include/uapi/drm/i915_drm.h 
> > > > > > > b/include/uapi/drm/i915_drm.h
> > > > > > > index bde5860b3686..d7dc421c6134 100644
> > > > > > > --- a/include/uapi/drm/i915_drm.h
> > > > > > > +++ b/include/uapi/drm/i915_drm.h
> > > > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching {
> > > > > > >  #define I915_TILING_NONE 0
> > > > > > >  #define I915_TILING_X1
> > > > > > >  #define I915_TILING_Y2
> > > > > > > -#define I915_TILING_LAST I915_TILING_Y
> > > > > > > +#define I915_TILING_F3
> > > > > > > +#define I915_TILING_LAST I915_TILING_F
> > > > > > 
> > > > > > fences...
> > > > > 
> > > > > Recognizing TileF/Tile4 separately from TileY is important to code
> > > > > outside of display as well.  There are blitter instructions that 
> > > > > require
> > > > > different settings for TileY vs Tile4/F so if we drop the tracking of
> > > > > this as a unique tiling type, it will break the blitting/copying and
> > > > > some of the upcoming local memory support for Xe_HP-based platforms.
> > > > 
> > > > These are uapi definitions for set_tiling(). You are not meant to add
> > > > anything there. Just like we didn't add anything for Yf.
> > > 
> > > Yeah, I think that's the real problem --- we define some values here in
> > > the uapi header, but we also wind up using the same set of values for
> > > driver-internal non-uapi purposes too rather than having a separate enum
> > > (containing a superset of the uapi values) that can be used for those
> > > other things.  Display code can use FB modifiers for some things, but
> > > core/lmem code needs a way to refer to Tile4 and such and doesn't have a
> > > good way to do that today.
> > > 
> > > I think most (all?) of the non-display code that's relying on a
> > > definition of I915_TILING_F is in various selftests that are still being
> > > prepared for upstreaming, so maybe there's a better way to handle the
> > > selection of possible formats specifically in the selftest code itself.
> > > That's really the only area of the kernel code that should need to be
> > > aware of the specific internal layout of various buffers.
> > 
> > So I will proceed with the renaming at least.
> > 
> > Ville, suppose, I still need part of fencing related code?
> 
> Nah. Just nuke it all. Someone will have to fix whatever self test is
> abusing the uapi definitions though.
> 
> A local #define should suffice if nothing else is deemed appropriate.
> IIRC igt also has a local definition like this for Yf. We should
> perhaps rename those to some igt specific namespace as well...

As Matt mentioned, removing I915_TILING_F completely is going to break
way more than selftest, but also blitter/copy and local mem support.
In fact I remember, I had to add part of those in order to get some
tests working, another part was added by somebody else, so not even
sure how much other stuff its going to break.

Sounds like a bit too much for simple upstreaming of the patch, we
already had 

Re: [Intel-gfx] [PATCH 09/13] drm/i915/tc: Avoid using legacy AUX PW in TBT mode

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> For the ADL-P TBT mode the spec doesn't require blocking TC-cold by
> using the legacy AUX power domain. To avoid the timeouts that this would
> cause during PHY disconnect/reconnect sequences (which will be more
> frequent after a follow-up change) use the TC_COLD_OFF power domain in
> TBT mode on all platforms. On TGL this power domain blocks TC-cold via a
> PUNIT command, while on other platforms the domain just takes a runtime
> PM reference.
> 
> If the HPD live status indicates that the port mode needs to be reset
> - for instance after switching from TBT to a DP-alt sink - still take
> the AUX domain, since the IOM firmware handshake requires this.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 55 -
>  1 file changed, 36 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 24d2dc2e19a7d..b2a3d297bfc19 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -59,10 +59,10 @@ bool intel_tc_cold_requires_aux_pw(struct 
> intel_digital_port *dig_port)
>  static enum intel_display_power_domain
>  tc_cold_get_power_domain(struct intel_digital_port *dig_port, enum 
> tc_port_mode mode)
>  {
> - if (intel_tc_cold_requires_aux_pw(dig_port))
> - return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
> - else
> + if (mode == TC_PORT_TBT_ALT || !intel_tc_cold_requires_aux_pw(dig_port))
>   return POWER_DOMAIN_TC_COLD_OFF;
> +
> + return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
>  }
>  
>  static intel_wakeref_t
> @@ -624,6 +624,36 @@ static void intel_tc_port_reset_mode(struct 
> intel_digital_port *dig_port,
>   tc_port_mode_name(dig_port->tc_mode));
>  }
>  
> +static bool intel_tc_port_needs_reset(struct intel_digital_port *dig_port)
> +{
> + return intel_tc_port_get_target_mode(dig_port) != dig_port->tc_mode;
> +}
> +
> +static void intel_tc_port_update_mode(struct intel_digital_port *dig_port,
> +   int required_lanes, bool force_disconnect)
> +{
> + enum intel_display_power_domain domain;
> + intel_wakeref_t wref;
> + bool needs_reset = force_disconnect;
> +
> + if (!needs_reset) {
> + /* Get power domain required to check the hotplug live status. 
> */
> + wref = tc_cold_block(dig_port, );
> + needs_reset = intel_tc_port_needs_reset(dig_port);
> + tc_cold_unblock(dig_port, domain, wref);
> + }
> +
> + if (!needs_reset)
> + return;
> +
> + /* Get power domain required for resetting the mode. */
> + wref = tc_cold_block_in_mode(dig_port, TC_PORT_DISCONNECTED, );
> +
> + intel_tc_port_reset_mode(dig_port, required_lanes, force_disconnect);
> +
> + tc_cold_unblock(dig_port, domain, wref);
> +}
> +
>  static void
>  intel_tc_port_link_init_refcount(struct intel_digital_port *dig_port,
>int refcount)
> @@ -670,11 +700,6 @@ void intel_tc_port_sanitize(struct intel_digital_port 
> *dig_port)
>   mutex_unlock(_port->tc_lock);
>  }
>  
> -static bool intel_tc_port_needs_reset(struct intel_digital_port *dig_port)
> -{
> - return intel_tc_port_get_target_mode(dig_port) != dig_port->tc_mode;
> -}
> -
>  /*
>   * The type-C ports are different because even when they are connected, they 
> may
>   * not be available/usable by the graphics driver: see the comment on
> @@ -714,18 +739,10 @@ static void __intel_tc_port_lock(struct 
> intel_digital_port *dig_port,
>  
>   mutex_lock(_port->tc_lock);
>  
> - if (!dig_port->tc_link_refcount) {
> - enum intel_display_power_domain domain;
> - intel_wakeref_t tc_cold_wref;
>  
> - tc_cold_wref = tc_cold_block(dig_port, );
> -
> - if (force_disconnect || intel_tc_port_needs_reset(dig_port))
> - intel_tc_port_reset_mode(dig_port, required_lanes,
> -  force_disconnect);
> -
> - tc_cold_unblock(dig_port, domain, tc_cold_wref);
> - }
> + if (!dig_port->tc_link_refcount)
> + intel_tc_port_update_mode(dig_port, required_lanes,
> +   force_disconnect);
>  
>   drm_WARN_ON(>drm, dig_port->tc_mode == TC_PORT_DISCONNECTED);
>   drm_WARN_ON(>drm, dig_port->tc_mode != TC_PORT_TBT_ALT &&



Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-28 at 23:08 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 11:02:37PM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 22:55 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 10:45:50PM +0300, Souza, Jose wrote:
> > > > > > [...]
> > > > > > Would not be possible to use TC_PORT_DISCONNECTED when really
> > > > > > disconnected and dropping the use of TC_PORT_TBT_ALT for it?
> > > > > 
> > > > > TC_PORT_DISCONNECTED is the state when the PHY ownership is not held 
> > > > > and
> > > > > we don't hold any power domains.
> > > > > 
> > > > > TC_PORT_TBT_ALT is the state when the PHY ownership is not held (like
> > > > > above), and we hold the power domain needed to block TC-cold.
> > > > 
> > > > Swapping it would make modes names do what their names intend to.
> > > > 
> > > > Up to the point that we only had TBT, TC alt and legacy it was fine to
> > > > keep into TBT mode when disconnected but now with a disconnected state
> > > > it do not make sense to keep it in TBT mode when disconnected.
> > > > 
> > > > Or you rename it to TC_PORT_UNKNOWN, as it sets to
> > > > TC_PORT_DISCONNECTED mode during tc_init() and when going to suspend.
> > > 
> > > Not sure what you mean, because what you describe is what actually
> > > happens. From all states icl_tc_phy_disconnect() will change to
> > > the disconnected state, which is the state at init time and during
> > > suspend or after unloading the driver.
> > 
> > I'm talking about the state when system is up without anything
> > connected to the port, after icl_tc_phy_disconnect() sets
> > dig_port->tc_mode = TC_PORT_DISCONNECTED, icl_tc_phy_connect() goes
> > and set it back to TC_PORT_TBT_ALT.
> 
> Yes, when the port is locked we are in one of TBT-alt, DP-alt or legacy
> mode. These are the only modes that make sense for an AUX transfer or a
> modeset, for which the lock was taken.

Okay at the end of the series mode goes to TC_PORT_DISCONNECTED if no reference 
is held.

> 
> --Imre



[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers 
(rev2)
URL   : https://patchwork.freedesktop.org/series/95127/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655_full -> Patchwork_21177_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-skl:  [PASS][2] -> [INCOMPLETE][3] ([i915#146] / [i915#198])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-skl5/igt@gem_ctx_isolation@preservation...@vecs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-skl6/igt@gem_ctx_isolation@preservation...@vecs0.html

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][4] ([fdo#109314])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-iclb1/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_ctx_persistence@smoketest:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-snb7/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#3070])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb5/igt@gem_...@in-flight-contexts-10ms.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-iclb5/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb1/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-iclb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][10] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-apl2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  NOTRUN -> [FAIL][13] ([i915#2842]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-kbl3/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2849])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@no-bsd:
- shard-tglb: NOTRUN -> [SKIP][16] ([fdo#109283])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-tglb3/igt@gem_exec_par...@no-bsd.html

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

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

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#644])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-glk1/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3323])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-apl1/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@unsync-overlap:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#3297])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/shard-iclb1/igt@gem_userptr_bl...@unsync-overlap.html

  * igt@gem_userptr_blits@vma-merge:
- shard-apl:  NOTRUN -> [FAIL][23] ([i915#3318])
   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop force enabling pipe bottom color gammma/csc

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Stop force enabling pipe bottom color gammma/csc
URL   : https://patchwork.freedesktop.org/series/95171/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655 -> Patchwork_21179


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][9] ([i915#2927] / [i915#3428]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [FAIL][11] ([i915#1161]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Warnings 

  * igt@kms_chamelium@vga-hpd-fast:
- fi-kbl-7500u:   [{ABORT}][13] ([i915#1814]) -> [SKIP][14] 
([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21179/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (45 -> 37)
--

  Additional (1): fi-kbl-soraka 
  Missing(9): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-hsw-4200u fi-bsw-cyan 
bat-adlp-4 fi-ctg-p8600 bat-jsl-2 bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10655 -> Patchwork_21179

  CI-20190529: 20190529
  CI_DRM_10655: 88d6ecae86a7bb32e8bf2bd233f7f9f9c8bd7abc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6226: 18278534c085c35adcf62f158a8d5356e5496f8d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21179: 85c809e6b48ca9629fb8e9b61cad6040529e7940 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

85c809e6b48c drm/i915: Stop force enabling pipe bottom color gammma/csc

== Logs 

Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Imre Deak
On Tue, Sep 28, 2021 at 11:02:37PM +0300, Souza, Jose wrote:
> On Tue, 2021-09-28 at 22:55 +0300, Imre Deak wrote:
> > On Tue, Sep 28, 2021 at 10:45:50PM +0300, Souza, Jose wrote:
> > > > > [...]
> > > > > Would not be possible to use TC_PORT_DISCONNECTED when really
> > > > > disconnected and dropping the use of TC_PORT_TBT_ALT for it?
> > > > 
> > > > TC_PORT_DISCONNECTED is the state when the PHY ownership is not held and
> > > > we don't hold any power domains.
> > > > 
> > > > TC_PORT_TBT_ALT is the state when the PHY ownership is not held (like
> > > > above), and we hold the power domain needed to block TC-cold.
> > > 
> > > Swapping it would make modes names do what their names intend to.
> > > 
> > > Up to the point that we only had TBT, TC alt and legacy it was fine to
> > > keep into TBT mode when disconnected but now with a disconnected state
> > > it do not make sense to keep it in TBT mode when disconnected.
> > > 
> > > Or you rename it to TC_PORT_UNKNOWN, as it sets to
> > > TC_PORT_DISCONNECTED mode during tc_init() and when going to suspend.
> > 
> > Not sure what you mean, because what you describe is what actually
> > happens. From all states icl_tc_phy_disconnect() will change to
> > the disconnected state, which is the state at init time and during
> > suspend or after unloading the driver.
> 
> I'm talking about the state when system is up without anything
> connected to the port, after icl_tc_phy_disconnect() sets
> dig_port->tc_mode = TC_PORT_DISCONNECTED, icl_tc_phy_connect() goes
> and set it back to TC_PORT_TBT_ALT.

Yes, when the port is locked we are in one of TBT-alt, DP-alt or legacy
mode. These are the only modes that make sense for an AUX transfer or a
modeset, for which the lock was taken.

--Imre


Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-28 at 22:55 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 10:45:50PM +0300, Souza, Jose wrote:
> > > > [...]
> > > > Would not be possible to use TC_PORT_DISCONNECTED when really
> > > > disconnected and dropping the use of TC_PORT_TBT_ALT for it?
> > > 
> > > TC_PORT_DISCONNECTED is the state when the PHY ownership is not held and
> > > we don't hold any power domains.
> > > 
> > > TC_PORT_TBT_ALT is the state when the PHY ownership is not held (like
> > > above), and we hold the power domain needed to block TC-cold.
> > 
> > Swapping it would make modes names do what their names intend to.
> > 
> > Up to the point that we only had TBT, TC alt and legacy it was fine to
> > keep into TBT mode when disconnected but now with a disconnected state
> > it do not make sense to keep it in TBT mode when disconnected.
> > 
> > Or you rename it to TC_PORT_UNKNOWN, as it sets to
> > TC_PORT_DISCONNECTED mode during tc_init() and when going to suspend.
> 
> Not sure what you mean, because what you describe is what actually
> happens. From all states icl_tc_phy_disconnect() will change to
> the disconnected state, which is the state at init time and during
> suspend or after unloading the driver.

I'm talking about the state when system is up without anything connected to the 
port, after icl_tc_phy_disconnect() sets dig_port->tc_mode =
TC_PORT_DISCONNECTED, icl_tc_phy_connect() goes and set it back to 
TC_PORT_TBT_ALT.


> 
> --Imre



Re: [Intel-gfx] [PATCH 2/3] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

2021-09-28 Thread Doug Anderson
Hi,

On Mon, Sep 27, 2021 at 1:12 PM Lyude Paul  wrote:
>
> @@ -3305,11 +3313,10 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
>   * @bl: Backlight capability info from drm_edp_backlight_init()
>   *
>   * This function handles disabling DPCD backlight controls on a panel over 
> AUX. Note that some
> - * panels have backlights that are enabled/disabled by other means, despite 
> having their brightness
> - * values controlled through DPCD. On such panels 
> _edp_backlight_info.aux_enable will be set to
> - * %false, this function will become a no-op (and we will skip updating
> - * %DP_EDP_DISPLAY_CONTROL_REGISTER), and the driver must take care to 
> perform it's own
> - * implementation specific step for disabling the backlight.
> + * panels have backlights that are enabled/disabled via PWM. On such panels
> + * _edp_backlight_info.aux_enable will be set to %false, this function 
> will become a no-op (and
> + * we will skip updating %DP_EDP_DISPLAY_CONTROL_REGISTER), and the driver 
> must handle disabling the
> + * backlight via PWM.

I'm not sure I understand the comment above. You say "enabled/disabled
via PWM" and that doesn't make sense w/ my mental model. Normally I
think of a PWM allowing you to adjust the brightness and there being a
separate GPIO that's in charge of enable/disable. To some extent you
could think of a PWM as being "disabled" when its duty cycle is 0%,
but usually there's separate "enable" logic that really has nothing to
do with the PWM itself.

In general, it seems like the options are:

1. DPCD controls PWM and the "enable" logic.

2. DPCD controls PWM but requires an external "enable" GPIO.

3. We require an external PWM but DPCD controls the "enable" logic.

Maybe you need a second "capability" to describe whether the client of
your code knows how to control an enable GPIO? ...or perhaps better
you don't need a capability and you can just assume that if the client
needs to set an "enable" GPIO that it will do so. That would match how
things work today. AKA:

a) Client calls the AUX backlight code to "enable"

b) AUX backlight code will set the "enable" bit if supported.

c) Client will set the "enable" GPIO if it knows about one.

Presumably only one of b) or c) will actually do something. If neither
does something then this panel simply isn't compatible with this
board.


> +/**
> + * drm_edp_backlight_supported() - Check an eDP DPCD for VESA backlight 
> support
> + * @aux: The AUX channel, only used for debug logging
> + * @edp_dpcd: The DPCD to check
> + * @caps: The backlight capabilities this driver supports
> + *
> + * Returns: %True if @edp_dpcd indicates that VESA backlight controls are 
> supported, %false
> + * otherwise
> + */
> +bool drm_edp_backlight_supported(struct drm_dp_aux *aux,
> +const u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE],
> +enum drm_edp_backlight_driver_caps caps)
> +{
> +   if (!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP))
> +   return false;
> +
> +   if (!(caps & DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM) &&
> +   (!(edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) ||
> +!(edp_dpcd[2] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))) {

Elsewhere you match DP_EDP_BACKLIGHT_AUX_ENABLE_CAP against
edp_dpcd[1]. Here you match against [2]. Are you sure that's correct?


>  /*
>   * DisplayPort AUX channel
>   */
> @@ -2200,7 +2182,11 @@ drm_dp_has_quirk(const struct drm_dp_desc *desc, enum 
> drm_dp_quirk quirk)
>   * @pwm_freq_pre_divider: The PWM frequency pre-divider value being used for 
> this backlight, if any
>   * @max: The maximum backlight level that may be set
>   * @lsb_reg_used: Do we also write values to the 
> DP_EDP_BACKLIGHT_BRIGHTNESS_LSB register?
> - * @aux_enable: Does the panel support the AUX enable cap?
> + * @aux_enable: Does the panel support the AUX enable cap? Always %false 
> when the driver doesn't
> + * support %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM

Why is aux_enable always false if it doesn't support
DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM? It doesn't seem like the code
enforces this and I'm not sure why it would. Am I confused?


Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Imre Deak
On Tue, Sep 28, 2021 at 10:45:50PM +0300, Souza, Jose wrote:
> > > [...]
> > > Would not be possible to use TC_PORT_DISCONNECTED when really
> > > disconnected and dropping the use of TC_PORT_TBT_ALT for it?
> > 
> > TC_PORT_DISCONNECTED is the state when the PHY ownership is not held and
> > we don't hold any power domains.
> > 
> > TC_PORT_TBT_ALT is the state when the PHY ownership is not held (like
> > above), and we hold the power domain needed to block TC-cold.
> 
> Swapping it would make modes names do what their names intend to.
> 
> Up to the point that we only had TBT, TC alt and legacy it was fine to
> keep into TBT mode when disconnected but now with a disconnected state
> it do not make sense to keep it in TBT mode when disconnected.
> 
> Or you rename it to TC_PORT_UNKNOWN, as it sets to
> TC_PORT_DISCONNECTED mode during tc_init() and when going to suspend.

Not sure what you mean, because what you describe is what actually
happens. From all states icl_tc_phy_disconnect() will change to
the disconnected state, which is the state at init time and during
suspend or after unloading the driver.

--Imre


Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-28 at 22:34 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 10:18:25PM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 00:46 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 12:16:45AM +0300, Souza, Jose wrote:
> > > > On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> > > > > A follow-up change will start to disconnect/re-connect PHYs around AUX
> > > > > transfers and modeset enable/disables. To prepare for that add a new
> > > > > TypeC PHY disconnected mode, to help tracking the TC-cold blocking 
> > > > > power
> > > > > domain status (no power domain in disconnected state, mode dependent
> > > > > power domain in connected state).
> > > > > 
> > > > > Cc: José Roberto de Souza 
> > > > > Signed-off-by: Imre Deak 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_display.h |  1 +
> > > > >  drivers/gpu/drm/i915/display/intel_tc.c  | 26 
> > > > > ++--
> > > > >  2 files changed, 19 insertions(+), 8 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> > > > > b/drivers/gpu/drm/i915/display/intel_display.h
> > > > > index d425ee77aad71..87b96fed5e0ba 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.h
> > > > > @@ -270,6 +270,7 @@ enum tc_port {
> > > > >  };
> > > > >  
> > > > >  enum tc_port_mode {
> > > > > + TC_PORT_DISCONNECTED,
> > > > >   TC_PORT_TBT_ALT,
> > > > >   TC_PORT_DP_ALT,
> > > > >   TC_PORT_LEGACY,
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> > > > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > > index aa4c1e5e0c002..77b16a7c43466 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > > @@ -12,13 +12,14 @@
> > > > >  static const char *tc_port_mode_name(enum tc_port_mode mode)
> > > > >  {
> > > > >   static const char * const names[] = {
> > > > > + [TC_PORT_DISCONNECTED] = "disconnected",
> > > > >   [TC_PORT_TBT_ALT] = "tbt-alt",
> > > > >   [TC_PORT_DP_ALT] = "dp-alt",
> > > > >   [TC_PORT_LEGACY] = "legacy",
> > > > >   };
> > > > >  
> > > > >   if (WARN_ON(mode >= ARRAY_SIZE(names)))
> > > > > - mode = TC_PORT_TBT_ALT;
> > > > > + mode = TC_PORT_DISCONNECTED;
> > > > >  
> > > > >   return names[mode];
> > > > >  }
> > > > > @@ -513,10 +514,11 @@ static void icl_tc_phy_disconnect(struct 
> > > > > intel_digital_port *dig_port)
> > > > >   case TC_PORT_LEGACY:
> > > > >   case TC_PORT_DP_ALT:
> > > > >   tc_phy_take_ownership(dig_port, false);
> > > > > - dig_port->tc_mode = TC_PORT_TBT_ALT;
> > > > > - break;
> > > > > + fallthrough;
> > > > >   case TC_PORT_TBT_ALT:
> > > > > - /* Nothing to do, we stay in TBT-alt mode */
> > > > > + dig_port->tc_mode = TC_PORT_DISCONNECTED;
> > > > > + fallthrough;
> > > > > + case TC_PORT_DISCONNECTED:
> > > > >   break;
> > > > >   default:
> > > > >   MISSING_CASE(dig_port->tc_mode);
> > > > > @@ -621,31 +623,34 @@ void intel_tc_port_sanitize(struct 
> > > > > intel_digital_port *dig_port)
> > > > >  {
> > > > >   struct drm_i915_private *i915 = 
> > > > > to_i915(dig_port->base.base.dev);
> > > > >   struct intel_encoder *encoder = _port->base;
> > > > > - intel_wakeref_t tc_cold_wref;
> > > > >   int active_links = 0;
> > > > >  
> > > > >   mutex_lock(_port->tc_lock);
> > > > > - tc_cold_wref = tc_cold_block(dig_port);
> > > > >  
> > > > > - dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
> > > > >   if (dig_port->dp.is_mst)
> > > > >   active_links = 
> > > > > intel_dp_mst_encoder_active_links(dig_port);
> > > > >   else if (encoder->base.crtc)
> > > > >   active_links = 
> > > > > to_intel_crtc(encoder->base.crtc)->active;
> > > > >  
> > > > > + drm_WARN_ON(>drm, dig_port->tc_mode != 
> > > > > TC_PORT_DISCONNECTED);
> > > > >   if (active_links) {
> > > > > + intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port);
> > > > > +
> > > > > + dig_port->tc_mode = 
> > > > > intel_tc_port_get_current_mode(dig_port);
> > > > > +
> > > > >   if (!icl_tc_phy_is_connected(dig_port))
> > > > >   drm_dbg_kms(>drm,
> > > > >   "Port %s: PHY disconnected with %d 
> > > > > active link(s)\n",
> > > > >   dig_port->tc_port_name, 
> > > > > active_links);
> > > > >   intel_tc_port_link_init_refcount(dig_port, 
> > > > > active_links);
> > > > > +
> > > > > + tc_cold_unblock(dig_port, tc_cold_wref);
> > > > >   }
> > > > >  
> > > > >   drm_dbg_kms(>drm, "Port %s: sanitize mode (%s)\n",
> > > > >   

Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Imre Deak
On Tue, Sep 28, 2021 at 10:18:25PM +0300, Souza, Jose wrote:
> On Tue, 2021-09-28 at 00:46 +0300, Imre Deak wrote:
> > On Tue, Sep 28, 2021 at 12:16:45AM +0300, Souza, Jose wrote:
> > > On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> > > > A follow-up change will start to disconnect/re-connect PHYs around AUX
> > > > transfers and modeset enable/disables. To prepare for that add a new
> > > > TypeC PHY disconnected mode, to help tracking the TC-cold blocking power
> > > > domain status (no power domain in disconnected state, mode dependent
> > > > power domain in connected state).
> > > > 
> > > > Cc: José Roberto de Souza 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_display.h |  1 +
> > > >  drivers/gpu/drm/i915/display/intel_tc.c  | 26 ++--
> > > >  2 files changed, 19 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> > > > b/drivers/gpu/drm/i915/display/intel_display.h
> > > > index d425ee77aad71..87b96fed5e0ba 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.h
> > > > @@ -270,6 +270,7 @@ enum tc_port {
> > > >  };
> > > >  
> > > >  enum tc_port_mode {
> > > > +   TC_PORT_DISCONNECTED,
> > > > TC_PORT_TBT_ALT,
> > > > TC_PORT_DP_ALT,
> > > > TC_PORT_LEGACY,
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> > > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > index aa4c1e5e0c002..77b16a7c43466 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > @@ -12,13 +12,14 @@
> > > >  static const char *tc_port_mode_name(enum tc_port_mode mode)
> > > >  {
> > > > static const char * const names[] = {
> > > > +   [TC_PORT_DISCONNECTED] = "disconnected",
> > > > [TC_PORT_TBT_ALT] = "tbt-alt",
> > > > [TC_PORT_DP_ALT] = "dp-alt",
> > > > [TC_PORT_LEGACY] = "legacy",
> > > > };
> > > >  
> > > > if (WARN_ON(mode >= ARRAY_SIZE(names)))
> > > > -   mode = TC_PORT_TBT_ALT;
> > > > +   mode = TC_PORT_DISCONNECTED;
> > > >  
> > > > return names[mode];
> > > >  }
> > > > @@ -513,10 +514,11 @@ static void icl_tc_phy_disconnect(struct 
> > > > intel_digital_port *dig_port)
> > > > case TC_PORT_LEGACY:
> > > > case TC_PORT_DP_ALT:
> > > > tc_phy_take_ownership(dig_port, false);
> > > > -   dig_port->tc_mode = TC_PORT_TBT_ALT;
> > > > -   break;
> > > > +   fallthrough;
> > > > case TC_PORT_TBT_ALT:
> > > > -   /* Nothing to do, we stay in TBT-alt mode */
> > > > +   dig_port->tc_mode = TC_PORT_DISCONNECTED;
> > > > +   fallthrough;
> > > > +   case TC_PORT_DISCONNECTED:
> > > > break;
> > > > default:
> > > > MISSING_CASE(dig_port->tc_mode);
> > > > @@ -621,31 +623,34 @@ void intel_tc_port_sanitize(struct 
> > > > intel_digital_port *dig_port)
> > > >  {
> > > > struct drm_i915_private *i915 = 
> > > > to_i915(dig_port->base.base.dev);
> > > > struct intel_encoder *encoder = _port->base;
> > > > -   intel_wakeref_t tc_cold_wref;
> > > > int active_links = 0;
> > > >  
> > > > mutex_lock(_port->tc_lock);
> > > > -   tc_cold_wref = tc_cold_block(dig_port);
> > > >  
> > > > -   dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
> > > > if (dig_port->dp.is_mst)
> > > > active_links = 
> > > > intel_dp_mst_encoder_active_links(dig_port);
> > > > else if (encoder->base.crtc)
> > > > active_links = 
> > > > to_intel_crtc(encoder->base.crtc)->active;
> > > >  
> > > > +   drm_WARN_ON(>drm, dig_port->tc_mode != 
> > > > TC_PORT_DISCONNECTED);
> > > > if (active_links) {
> > > > +   intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port);
> > > > +
> > > > +   dig_port->tc_mode = 
> > > > intel_tc_port_get_current_mode(dig_port);
> > > > +
> > > > if (!icl_tc_phy_is_connected(dig_port))
> > > > drm_dbg_kms(>drm,
> > > > "Port %s: PHY disconnected with %d 
> > > > active link(s)\n",
> > > > dig_port->tc_port_name, 
> > > > active_links);
> > > > intel_tc_port_link_init_refcount(dig_port, 
> > > > active_links);
> > > > +
> > > > +   tc_cold_unblock(dig_port, tc_cold_wref);
> > > > }
> > > >  
> > > > drm_dbg_kms(>drm, "Port %s: sanitize mode (%s)\n",
> > > > dig_port->tc_port_name,
> > > > tc_port_mode_name(dig_port->tc_mode));
> > > >  
> > > > -   tc_cold_unblock(dig_port, tc_cold_wref);
> > > > 

Re: [Intel-gfx] [PATCH v3] drm/dp: Add Additional DP2 Headers

2021-09-28 Thread Harry Wentland
On 2021-09-27 15:23, Fangzhi Zuo wrote:
> Include FEC, DSC, Link Training related headers.
> 
> Change since v2
> - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT
> 
> Signed-off-by: Fangzhi Zuo 

Reviewed-by: Harry Wentland 

Harry

> ---
> This patch is based on top of the other DP2.0 work in
> "drm/dp: add LTTPR DP 2.0 DPCD addresses"
> ---
>  include/drm/drm_dp_helper.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 1d5b3dbb6e56..a1df35aa6e68 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -453,6 +453,7 @@ struct drm_panel;
>  # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
>  # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
>  # define DP_FEC_BIT_ERROR_COUNT_CAP  (1 << 3)
> +#define DP_FEC_CAPABILITY_1  0x091   /* 2.0 */
>  
>  /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
>  #define DP_PCON_DSC_ENCODER_CAP_SIZE0xC  /* 0x9E - 0x92 */
> @@ -537,6 +538,9 @@ struct drm_panel;
>  #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1  0x0a1
>  #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2
>  
> +/* DFP Capability Extension */
> +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0a3   /* 2.0 */
> +
>  /* Link Configuration */
>  #define  DP_LINK_BW_SET  0x100
>  # define DP_LINK_RATE_TABLE  0x00/* eDP 1.4 */
> @@ -688,6 +692,7 @@ struct drm_panel;
>  
>  #define DP_DSC_ENABLE   0x160   /* DP 1.4 */
>  # define DP_DECOMPRESSION_EN(1 << 0)
> +#define DP_DSC_CONFIGURATION 0x161   /* DP 2.0 */
>  
>  #define DP_PSR_EN_CFG0x170   /* XXX 1.2? */
>  # define DP_PSR_ENABLE   BIT(0)
> @@ -743,6 +748,7 @@ struct drm_panel;
>  # define DP_RECEIVE_PORT_0_STATUS(1 << 0)
>  # define DP_RECEIVE_PORT_1_STATUS(1 << 1)
>  # define DP_STREAM_REGENERATION_STATUS  (1 << 2) /* 2.0 */
> +# define DP_INTRA_HOP_AUX_REPLY_INDICATION   (1 << 3) /* 2.0 */
>  
>  #define DP_ADJUST_REQUEST_LANE0_10x206
>  #define DP_ADJUST_REQUEST_LANE2_30x207
> @@ -865,6 +871,8 @@ struct drm_panel;
>  # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
>  # define DP_PHY_TEST_PATTERN_CP2520 0x5
>  
> +#define DP_PHY_SQUARE_PATTERN0x249
> +
>  #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
>  #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
>  #define  DP_TEST_80BIT_CUSTOM_PATTERN_15_8   0x251
> @@ -1109,6 +1117,18 @@ struct drm_panel;
>  #define DP_128B132B_TRAINING_AUX_RD_INTERVAL   0x2216 /* 2.0 */
>  # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f
>  
> +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_00x2230
> +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_2560x2250
> +
> +/* DSC Extended Capability Branch Total DSC Resources */
> +#define DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT 0x2260  /* 2.0 */
> +# define DP_DSC_DECODER_COUNT_MASK   (0b111 << 5)
> +# define DP_DSC_DECODER_COUNT_SHIFT  5
> +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270  /* 2.0 */
> +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK   (1 << 0)
> +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK   (0b111 << 1)
> +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT  1
> +
>  /* Protocol Converter Extension */
>  /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
>  #define DP_CEC_TUNNELING_CAPABILITY0x3000
> 



Re: [Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

2021-09-28 Thread Souza, Jose
On Tue, 2021-09-28 at 00:46 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 12:16:45AM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> > > A follow-up change will start to disconnect/re-connect PHYs around AUX
> > > transfers and modeset enable/disables. To prepare for that add a new
> > > TypeC PHY disconnected mode, to help tracking the TC-cold blocking power
> > > domain status (no power domain in disconnected state, mode dependent
> > > power domain in connected state).
> > > 
> > > Cc: José Roberto de Souza 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.h |  1 +
> > >  drivers/gpu/drm/i915/display/intel_tc.c  | 26 ++--
> > >  2 files changed, 19 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> > > b/drivers/gpu/drm/i915/display/intel_display.h
> > > index d425ee77aad71..87b96fed5e0ba 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.h
> > > @@ -270,6 +270,7 @@ enum tc_port {
> > >  };
> > >  
> > >  enum tc_port_mode {
> > > + TC_PORT_DISCONNECTED,
> > >   TC_PORT_TBT_ALT,
> > >   TC_PORT_DP_ALT,
> > >   TC_PORT_LEGACY,
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > index aa4c1e5e0c002..77b16a7c43466 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > @@ -12,13 +12,14 @@
> > >  static const char *tc_port_mode_name(enum tc_port_mode mode)
> > >  {
> > >   static const char * const names[] = {
> > > + [TC_PORT_DISCONNECTED] = "disconnected",
> > >   [TC_PORT_TBT_ALT] = "tbt-alt",
> > >   [TC_PORT_DP_ALT] = "dp-alt",
> > >   [TC_PORT_LEGACY] = "legacy",
> > >   };
> > >  
> > >   if (WARN_ON(mode >= ARRAY_SIZE(names)))
> > > - mode = TC_PORT_TBT_ALT;
> > > + mode = TC_PORT_DISCONNECTED;
> > >  
> > >   return names[mode];
> > >  }
> > > @@ -513,10 +514,11 @@ static void icl_tc_phy_disconnect(struct 
> > > intel_digital_port *dig_port)
> > >   case TC_PORT_LEGACY:
> > >   case TC_PORT_DP_ALT:
> > >   tc_phy_take_ownership(dig_port, false);
> > > - dig_port->tc_mode = TC_PORT_TBT_ALT;
> > > - break;
> > > + fallthrough;
> > >   case TC_PORT_TBT_ALT:
> > > - /* Nothing to do, we stay in TBT-alt mode */
> > > + dig_port->tc_mode = TC_PORT_DISCONNECTED;
> > > + fallthrough;
> > > + case TC_PORT_DISCONNECTED:
> > >   break;
> > >   default:
> > >   MISSING_CASE(dig_port->tc_mode);
> > > @@ -621,31 +623,34 @@ void intel_tc_port_sanitize(struct 
> > > intel_digital_port *dig_port)
> > >  {
> > >   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > >   struct intel_encoder *encoder = _port->base;
> > > - intel_wakeref_t tc_cold_wref;
> > >   int active_links = 0;
> > >  
> > >   mutex_lock(_port->tc_lock);
> > > - tc_cold_wref = tc_cold_block(dig_port);
> > >  
> > > - dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
> > >   if (dig_port->dp.is_mst)
> > >   active_links = intel_dp_mst_encoder_active_links(dig_port);
> > >   else if (encoder->base.crtc)
> > >   active_links = to_intel_crtc(encoder->base.crtc)->active;
> > >  
> > > + drm_WARN_ON(>drm, dig_port->tc_mode != TC_PORT_DISCONNECTED);
> > >   if (active_links) {
> > > + intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port);
> > > +
> > > + dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
> > > +
> > >   if (!icl_tc_phy_is_connected(dig_port))
> > >   drm_dbg_kms(>drm,
> > >   "Port %s: PHY disconnected with %d active 
> > > link(s)\n",
> > >   dig_port->tc_port_name, active_links);
> > >   intel_tc_port_link_init_refcount(dig_port, active_links);
> > > +
> > > + tc_cold_unblock(dig_port, tc_cold_wref);
> > >   }
> > >  
> > >   drm_dbg_kms(>drm, "Port %s: sanitize mode (%s)\n",
> > >   dig_port->tc_port_name,
> > >   tc_port_mode_name(dig_port->tc_mode));
> > >  
> > > - tc_cold_unblock(dig_port, tc_cold_wref);
> > >   mutex_unlock(_port->tc_lock);
> > >  }
> > >  
> > > @@ -704,6 +709,10 @@ static void __intel_tc_port_lock(struct 
> > > intel_digital_port *dig_port,
> > >   tc_cold_unblock(dig_port, tc_cold_wref);
> > >   }
> > >  
> > > + drm_WARN_ON(>drm, dig_port->tc_mode == TC_PORT_DISCONNECTED);
> > 
> > This warning will be printed everytime it goes to suspend, other than that 
> > lgtm.
> 
> By the end of the patchset this shouldn't warn. But yes, for bisect to
> work this should've been added only in patch 11, I'll move it there.

Would not be possible to use TC_PORT_DISCONNECTED when really disconnected and 
dropping the use of TC_PORT_TBT_ALT for it?

Further patches 

Re: [Intel-gfx] refactor the i915 GVT support

2021-09-28 Thread Jason Gunthorpe
On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:

> Yes. I was thinking of the possibility of putting off some work later so 
> that we don't need to make a lot of changes. GVT-g needs to take a 
> snapshot of GPU registers as the initial virtual states for other vGPUs, 
> which requires the initialization happens at a certain early time of 
> initialization of i915. I was thinking maybe we can take other patches 
> from Christoph like "de-virtualize*" except this one because currently 
> we have to maintain a TEST-ONLY patch on our tree to prevent i915 built 
> as kernel module.

How about just capture these registers in the main module/device and
not try so hard to isolate it to the gvt stuff?

Jason


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/amd/display: Only define DP 2.0 symbols if not already defined

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/amd/display: Only define DP 2.0 symbols if not already defined
URL   : https://patchwork.freedesktop.org/series/95164/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655 -> Patchwork_21178


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271]) +8 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

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

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][10] ([i915#3921]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][12] ([i915#2927] / [i915#3428]) -> 
[PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [FAIL][14] ([i915#1161]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Warnings 

  * igt@kms_chamelium@vga-hpd-fast:
- fi-kbl-7500u:   [{ABORT}][16] ([i915#1814]) -> [SKIP][17] 
([fdo#109271])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21178/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (45 -> 37)
--

  

Re: [Intel-gfx] [PATCH] drm/i915: Tile F plane format support

2021-09-28 Thread Ville Syrjälä
On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote:
> On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote:
> > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote:
> > > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote:
> > > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote:
> > > > > > TileF(Tile4 in bspec) format is 4K tile organized into
> > > > > > 64B subtiles with same basic shape as for legacy TileY
> > > > > > which will be supported by Display13.
> > > > > 
> > > > > Why we still haven't done the F->tile64 rename?
> > > > >
> > > > > This is the last chance to fix this before we bake 
> > > > > this into the uapi and are stuck with a name that doesn't
> > > > > match the spec and will just confuse everyone.
> > > > 
> > > > I think you're confusing the formats here.  The bspec uses both terms
> > > > "TileF" and "Tile4" for the same format in different places.  There's a
> > > > completely different format that's referred to as both "TileS" and
> > > > "Tile64" in the bspec that we don't use at the moment.  So tile64
> > > > wouldn't be a correct rename, but tile4 could be.
> > > 
> > > Right, tile64 is the macro tile variant I think. So like Ys
> > > which we never bothered implementing, so I guess we''l not bother
> > > with tile64 either.
> > > 
> > > > 
> > > > In general Tile4 is much more common in the bspec than TileF is (TileF
> > > > terminology is mostly found in the media sections).  And bspec 44917 is
> > > > the most authoritative bspec page on the subject, and it refers to it as
> > > > Tile4, so I agree that switching over "Tile4" would probably be a good
> > > > move.
> > > > 
> > > > > 
> > > > > > 
> > > > ...
> > > > > > diff --git a/include/uapi/drm/i915_drm.h 
> > > > > > b/include/uapi/drm/i915_drm.h
> > > > > > index bde5860b3686..d7dc421c6134 100644
> > > > > > --- a/include/uapi/drm/i915_drm.h
> > > > > > +++ b/include/uapi/drm/i915_drm.h
> > > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching {
> > > > > >  #define I915_TILING_NONE   0
> > > > > >  #define I915_TILING_X  1
> > > > > >  #define I915_TILING_Y  2
> > > > > > -#define I915_TILING_LAST   I915_TILING_Y
> > > > > > +#define I915_TILING_F  3
> > > > > > +#define I915_TILING_LAST   I915_TILING_F
> > > > > 
> > > > > fences...
> > > > 
> > > > Recognizing TileF/Tile4 separately from TileY is important to code
> > > > outside of display as well.  There are blitter instructions that require
> > > > different settings for TileY vs Tile4/F so if we drop the tracking of
> > > > this as a unique tiling type, it will break the blitting/copying and
> > > > some of the upcoming local memory support for Xe_HP-based platforms.
> > > 
> > > These are uapi definitions for set_tiling(). You are not meant to add
> > > anything there. Just like we didn't add anything for Yf.
> > 
> > Yeah, I think that's the real problem --- we define some values here in
> > the uapi header, but we also wind up using the same set of values for
> > driver-internal non-uapi purposes too rather than having a separate enum
> > (containing a superset of the uapi values) that can be used for those
> > other things.  Display code can use FB modifiers for some things, but
> > core/lmem code needs a way to refer to Tile4 and such and doesn't have a
> > good way to do that today.
> > 
> > I think most (all?) of the non-display code that's relying on a
> > definition of I915_TILING_F is in various selftests that are still being
> > prepared for upstreaming, so maybe there's a better way to handle the
> > selection of possible formats specifically in the selftest code itself.
> > That's really the only area of the kernel code that should need to be
> > aware of the specific internal layout of various buffers.
> 
> So I will proceed with the renaming at least.
> 
> Ville, suppose, I still need part of fencing related code?

Nah. Just nuke it all. Someone will have to fix whatever self test is
abusing the uapi definitions though.

A local #define should suffice if nothing else is deemed appropriate.
IIRC igt also has a local definition like this for Yf. We should
perhaps rename those to some igt specific namespace as well...

-- 
Ville Syrjälä
Intel


[Intel-gfx] [PATCH] drm/i915: Stop force enabling pipe bottom color gammma/csc

2021-09-28 Thread Ville Syrjala
From: Ville Syrjälä 

While sanitizing the hardware state we're currently forcing
the pipe bottom color legacy csc/gamma bits on. That is not a
good idea as BIOSen are likely to leave gabage in the LUTs and
so doing this causes ugly visual glitches if and when the
planes covering the background get disabled. This was exactly
the case on this Dell Precision 5560 tgl laptop.

On icl+ we don't normally even use these legacy bits
anymore and instead use their GAMMA_MODE counterparts.
On earlier platforms the bits are used, but we still
shouldn't force them on without knowing what's in the LUT.

So two options, get rid of the whole thing, or do what
intel_color_commit() does to make sure the bottom color state
matches whatever out hardware readout produced. I chose the
latter since it'll match what happens on older platforms when
the primary plane gets turned off. In fact let's just call
intel_color_commit(). It'll also do some CSC programming but
since we don't have readout for that it'll actually just set
to all zeros. So in the unlikely case of CSC actually being
enabld by the BIOS we'll end up with all black until the first
atomic commit happens.

Still not totally sure what we should do about color management
features here in general. Probably the safest  thing would be to
force everything off exactly at the same time when we disable
the primary plane as there is no guarantees that whatever the
LUTs/CSCs contain make any sense whatsoever without the
specific pixel data in the BIOS fb. And if we preserve the
primary plane then we should disable the color management
features exactly when the primary plane fb contents first
changes since the new content assumes more or less no
transformations. But of course synchronizing front buffer
rendering with anything else is a bit hard...

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3534
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f27c294beb92..17ce51576ed2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11991,13 +11991,8 @@ static void intel_sanitize_crtc(struct intel_crtc 
*crtc,
intel_plane_disable_noatomic(crtc, plane);
}
 
-   /*
-* Disable any background color set by the BIOS, but enable the
-* gamma and CSC to match how we program our planes.
-*/
-   if (DISPLAY_VER(dev_priv) >= 9)
-   intel_de_write(dev_priv, SKL_BOTTOM_COLOR(crtc->pipe),
-  SKL_BOTTOM_COLOR_GAMMA_ENABLE | 
SKL_BOTTOM_COLOR_CSC_ENABLE);
+   /* Disable any background color/etc. set by the BIOS */
+   intel_color_commit(crtc_state);
}
 
/* Adjust the state of the output pipe according to whether we
-- 
2.32.0



[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/amd/display: Only define DP 2.0 symbols if not already defined

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/amd/display: Only define DP 2.0 symbols if not already defined
URL   : https://patchwork.freedesktop.org/series/95164/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
- 
- 
- 
- 
- 
- 
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xf0006 /* 2.0 */
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xf0006 /* 2.0 */
- #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xf0006 /* 2.0 */
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition
-./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: this was the 
original definition

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/amd/display: Only define DP 2.0 symbols if not already defined

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/amd/display: Only define DP 2.0 symbols if not already defined
URL   : https://patchwork.freedesktop.org/series/95164/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b1d56d1bac26 drm/amd/display: Only define DP 2.0 symbols if not already defined
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#14: 
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:

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




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers 
(rev2)
URL   : https://patchwork.freedesktop.org/series/95127/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10655 -> Patchwork_21177


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u:   NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#533])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][6] ([i915#2927] / [i915#3428]) -> 
[PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [FAIL][8] ([i915#1161]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Warnings 

  * igt@kms_chamelium@vga-hpd-fast:
- fi-kbl-7500u:   [{ABORT}][10] ([i915#1814]) -> [SKIP][11] 
([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10655/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21177/fi-kbl-7500u/igt@kms_chamel...@vga-hpd-fast.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#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3918]: https://gitlab.freedesktop.org/drm/intel/issues/3918
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (45 -> 36)
--

  Missing(9): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-hsw-4200u fi-bsw-cyan 
bat-adlp-4 fi-ctg-p8600 bat-jsl-2 bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10655 -> Patchwork_21177

  CI-20190529: 20190529
  CI_DRM_10655: 88d6ecae86a7bb32e8bf2bd233f7f9f9c8bd7abc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6226: 18278534c085c35adcf62f158a8d5356e5496f8d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21177: 3c5e277697eb86404bf92875cb0340281a96c386 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

3c5e277697eb drm/i915: Clarify probing order in 
intel_dp_aux_init_backlight_funcs()
207bda259e79 drm/dp, drm/i915: Add support for VESA backlights using PWM for 
brightness control
016d198e4728 drm/i915: Add support for panels with VESA backlights with PWM 
enable/disable

== Logs ==

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


Re: [Intel-gfx] [Freedreno] [PATCH v2 00/13] drm/hdcp: Pull HDCP auth/exchange/check into helpers

2021-09-28 Thread Sean Paul
On Tue, Sep 21, 2021 at 07:30:29PM -0700, abhin...@codeaurora.org wrote:
> Hi Sean
> 
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul 
> > 
> > Hello again,
> > This is the second version of the HDCP helper patchset. See version 1
> > here: https://patchwork.freedesktop.org/series/94623/
> > 
> > In this second version, I've fixed up the oopsies exposed by 0-day and
> > yamllint and incorporated early review feedback from the dt/dts reviews.
> > 
> > Please take a look,
> > 
> > Sean
> 
> One question overall on the series:
> 
> 1) Regarding validation, did you run any secure video to check the
> transitions?

Yep, the transitions look good, no visual artifacts.
Unplug/replug/suspend/resume all seem to be behaving as expected.

> 2) Is running HDCP 1x compliance also part of the validation efforts?

If Qualcomm has the ability to run validation, I'd be very keen to get some
help in that regard.

Sean

> 
> Thanks
> 
> Abhinav
> 
> > 
> > Sean Paul (13):
> >   drm/hdcp: Add drm_hdcp_atomic_check()
> >   drm/hdcp: Avoid changing crtc state in hdcp atomic check
> >   drm/hdcp: Update property value on content type and user changes
> >   drm/hdcp: Expand HDCP helper library for enable/disable/check
> >   drm/i915/hdcp: Consolidate HDCP setup/state cache
> >   drm/i915/hdcp: Retain hdcp_capable return codes
> >   drm/i915/hdcp: Use HDCP helpers for i915
> >   drm/msm/dpu_kms: Re-order dpu includes
> >   drm/msm/dpu: Remove useless checks in dpu_encoder
> >   drm/msm/dpu: Remove encoder->enable() hack
> >   drm/msm/dp: Re-order dp_audio_put in deinit_sub_modules
> >   dt-bindings: msm/dp: Add bindings for HDCP registers
> >   drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
> > 
> >  .../bindings/display/msm/dp-controller.yaml   |7 +-
> >  arch/arm64/boot/dts/qcom/sc7180.dtsi  |4 +-
> >  drivers/gpu/drm/drm_hdcp.c| 1197 -
> >  drivers/gpu/drm/i915/display/intel_atomic.c   |7 +-
> >  drivers/gpu/drm/i915/display/intel_ddi.c  |   29 +-
> >  .../drm/i915/display/intel_display_debugfs.c  |   11 +-
> >  .../drm/i915/display/intel_display_types.h|   58 +-
> >  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  345 ++---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   17 +-
> >  drivers/gpu/drm/i915/display/intel_hdcp.c | 1011 +++---
> >  drivers/gpu/drm/i915/display/intel_hdcp.h |   35 +-
> >  drivers/gpu/drm/i915/display/intel_hdmi.c |  256 ++--
> >  drivers/gpu/drm/msm/Makefile  |1 +
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |   17 +-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   30 +-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |2 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |4 -
> >  drivers/gpu/drm/msm/dp/dp_debug.c |   49 +-
> >  drivers/gpu/drm/msm/dp/dp_debug.h |6 +-
> >  drivers/gpu/drm/msm/dp/dp_display.c   |   47 +-
> >  drivers/gpu/drm/msm/dp/dp_display.h   |5 +
> >  drivers/gpu/drm/msm/dp/dp_drm.c   |   68 +-
> >  drivers/gpu/drm/msm/dp/dp_drm.h   |5 +
> >  drivers/gpu/drm/msm/dp/dp_hdcp.c  |  433 ++
> >  drivers/gpu/drm/msm/dp/dp_hdcp.h  |   27 +
> >  drivers/gpu/drm/msm/dp/dp_parser.c|   22 +-
> >  drivers/gpu/drm/msm/dp/dp_parser.h|4 +
> >  drivers/gpu/drm/msm/dp/dp_reg.h   |   44 +-
> >  drivers/gpu/drm/msm/msm_atomic.c  |   15 +
> >  include/drm/drm_hdcp.h|  194 +++
> >  30 files changed, 2561 insertions(+), 1389 deletions(-)
> >  create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c
> >  create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h

-- 
Sean Paul, Software Engineer, Google / Chromium OS


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers 
(rev2)
URL   : https://patchwork.freedesktop.org/series/95127/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER 0xF0006
+ #define 

Re: [Intel-gfx] [Freedreno] [PATCH v2 13/13] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers

2021-09-28 Thread Sean Paul
On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul 
> > 
> > This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> > helpers.
> > 
> > Cc: Stephen Boyd 
> > Signed-off-by: Sean Paul 
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
> > #v1
> > 
> > Changes in v2:
> > -Squash [1] into this patch with the following changes (Stephen)
> >   -Update the sc7180 dtsi file
> >   -Remove resource names and just use index (Stephen)
> > 
> 
> 
> > [1]
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-14-s...@poorly.run
> > ---

/snip

> > diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> > index 904535eda0c4..98731fd262d6 100644
> > --- a/drivers/gpu/drm/msm/Makefile
> > +++ b/drivers/gpu/drm/msm/Makefile
> > @@ -109,6 +109,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
> > dp/dp_ctrl.o \
> > dp/dp_display.o \
> > dp/dp_drm.o \
> > +   dp/dp_hdcp.o \
> > dp/dp_hpd.o \
> > dp/dp_link.o \
> > dp/dp_panel.o \
> > diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> > b/drivers/gpu/drm/msm/dp/dp_debug.c
> > index 2f6247e80e9d..de16fca8782a 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_debug.c

/snip

> > +static ssize_t dp_hdcp_key_write(struct file *file, const char __user
> > *ubuf,
> > +size_t len, loff_t *offp)
> > +{
> > +   char *input_buffer;
> > +   int ret = 0;
> > +   struct dp_debug_private *debug = file->private_data;
> > +   struct drm_device *dev;
> > +
> > +   dev = debug->drm_dev;
> > +
> > +   if (len != (DRM_HDCP_KSV_LEN + DP_HDCP_NUM_KEYS * DP_HDCP_KEY_LEN))
> > +   return -EINVAL;
> > +
> > +   if (!debug->hdcp)
> > +   return -ENOENT;
> > +
> > +   input_buffer = memdup_user_nul(ubuf, len);
> > +   if (IS_ERR(input_buffer))
> > +   return PTR_ERR(input_buffer);
> > +
> > +   ret = dp_hdcp_ingest_key(debug->hdcp, input_buffer, len);
> > +
> > +   kfree(input_buffer);
> > +   if (ret < 0) {
> > +   DRM_ERROR("Could not ingest HDCP key, ret=%d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   *offp += len;
> > +   return len;
> > +}
> 
> It seems like the HDCP keys written using debugfs, just for my
> understanding,
> are you storing this in some secure partition and the usermode reads from it
> and writes them here?
> 

We have not sorted out the userspace side of HDCP enablement yet, so it remains
to be seen whether the keys will be injected via debugfs/firmware file/property.

/snip

> > +static int dp_connector_atomic_check(struct drm_connector *connector,
> > +struct drm_atomic_state *state)
> > +{
> > +   struct drm_connector_state *conn_state;
> > +   struct dp_connector_state *dp_state;
> > +
> > +   conn_state = drm_atomic_get_new_connector_state(state, connector);
> > +   dp_state = to_dp_connector_state(conn_state);
> > +
> > +   dp_state->hdcp_transition = drm_hdcp_atomic_check(connector, state);
> 
> I have a general question related to the transition flag and overall tying
> the HDCP
> enable and authentication to the commit.
> So lets say there is a case where the driver needs to disable HDCP. It could
> be due
> to link integrity failure OR some other error condition which usermode is
> not aware of.
> In that case, we will set this hdcp_transition to true but in the next
> commit we will
> actually do the authentication. What if usermode doesnt issue a new frame?
> This question arises because currently the link intergrity check is done
> using SW polling
> in the previous patchset. But as I had commented there, this occurs in HW
> for us.
> I dont see that isr itself in this patchset. So wanted to understand if
> thats part of this
> approach to still tie it with commit.
> 
> So if we go with the HW polling based approach which is the preferred
> method, we need to
> untie this from the commit.
> 

In the case of error, the worker will detect it and try to re-authenticate. If
the re-authentication is successful, userspace will continue to be unaware and
everything will keep working. If re-authentication is unsuccessful, the worker
will update the property value and issue a uevent to userspace. So HDCP
enablement is only tied to commits when the property value is changing as a
result of userspace.

Regarding SW vs HW link checks, I don't think there's any difference in efficacy
between them. If HW can be relied on to issue an interrupt in failure cases, a
follow-up set allowing for this seems like a great idea.

> > +
> > +   return 0;
> > +}

/snip

> > +static int dp_hdcp_load_keys(struct drm_connector *connector)
> > +{
> > +   struct dp_hdcp *hdcp = dp_display_connector_to_hdcp(connector);
> > +   struct dp_hdcp_key *key;
> > +   int i, ret = 0;
> > +
> > +   mutex_lock(>key_lock);
> > +
> > +   key = hdcp->key;
> > +
> > +  

Re: [Intel-gfx] [Freedreno] [PATCH v2 04/13] drm/hdcp: Expand HDCP helper library for enable/disable/check

2021-09-28 Thread Sean Paul
On Tue, Sep 21, 2021 at 04:34:59PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul 
> > 
> > This patch expands upon the HDCP helper library to manage HDCP
> > enable, disable, and check.
> > 
> > Previous to this patch, the majority of the state management and sink
> > interaction is tucked inside the Intel driver with the understanding
> > that once a new platform supported HDCP we could make good decisions
> > about what should be centralized. With the addition of HDCP support
> > for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
> > authentication, key exchange, and link checks to the HDCP helper.
> > 
> > In terms of functionality, this migration is 1:1 with the Intel driver,
> > however things are laid out a bit differently than with intel_hdcp.c,
> > which is why this is a separate patch from the i915 transition to the
> > helper. On i915, the "shim" vtable is used to account for HDMI vs. DP
> > vs. DP-MST differences whereas the helper library uses a LUT to
> > account for the register offsets and a remote read function to route
> > the messages. On i915, storing the sink information in the source is
> > done inline whereas now we use the new drm_hdcp_helper_funcs vtable
> > to store and fetch information to/from source hw. Finally, instead of
> > calling enable/disable directly from the driver, we'll leave that
> > decision to the helper and by calling drm_hdcp_helper_atomic_commit()
> > from the driver. All told, this will centralize the protocol and state
> > handling in the helper, ensuring we collect all of our bugs^Wlogic
> > in one place.
> > 
> > Signed-off-by: Sean Paul 
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-5-s...@poorly.run
> > #v1
> > 
> > Changes in v2:
> > -Fixed set-but-unused variable identified by 0-day
> > ---
> >  drivers/gpu/drm/drm_hdcp.c | 1103 
> >  include/drm/drm_hdcp.h |  191 +++
> >  2 files changed, 1294 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> > index 742313ce8f6f..47c6e6923a76 100644
> > --- a/drivers/gpu/drm/drm_hdcp.c
> > +++ b/drivers/gpu/drm/drm_hdcp.c

/snip

> > +static void drm_hdcp_helper_check_work(struct work_struct *work)
> > +{
> > +   struct drm_hdcp_helper_data *data =
> > container_of(to_delayed_work(work),
> > +struct 
> > drm_hdcp_helper_data,
> > +check_work);
> > +   unsigned long check_link_interval;
> > +
> 
> Does this SW polling for Ri' mismatch need to be done even if the HW is
> capable of doing it
> on its own?
> MSM HDCP 1x HW can periodically check Ri' mismatches and issue an interrupt
> if there is a mismatch.
> In that case this SW polling is not needed. So maybe check if the HW
> supports polling and if so
> skip this SW polling?
> 

One could certainly change this to be HW driven. There is also an interrupt on
Intel for DP links which [re]schedules link check in the interrupt handler,
something similar could be done for msm. Note that even on these Intel links
which support the CP interrupt, the worker still runs on the normal cadence. I
haven't considered relying solely on the interrupt since I want to be sure we
didn't miss anything.

Sean

> > +   mutex_lock(>mutex);
> > +   if (data->value != DRM_MODE_CONTENT_PROTECTION_ENABLED)
> > +   goto out_data_mutex;
> > +
> > +   drm_hdcp_helper_driver_lock(data);
> > +
> > +   if (data->enabled_type == DRM_MODE_HDCP_CONTENT_TYPE1) {
> > +   if (drm_hdcp_hdcp2_check_link(data))
> > +   goto out;
> > +   check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
> > +   } else {
> > +   if (drm_hdcp_hdcp1_check_link(data))
> > +   goto out;
> > +   check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
> > +   }
> > +   schedule_delayed_work(>check_work, check_link_interval);
> > +
> > +out:
> > +   drm_hdcp_helper_driver_unlock(data);
> > +out_data_mutex:
> > +   mutex_unlock(>mutex);
> > +}

/snip

-- 
Sean Paul, Software Engineer, Google / Chromium OS


[Intel-gfx] [PATCH v3] drm/dp: Add Additional DP2 Headers

2021-09-28 Thread Fangzhi Zuo
Include FEC, DSC, Link Training related headers.

Change since v2
- Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT

Signed-off-by: Fangzhi Zuo 
---
This patch is based on top of the other DP2.0 work in
"drm/dp: add LTTPR DP 2.0 DPCD addresses"
---
 include/drm/drm_dp_helper.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1d5b3dbb6e56..a1df35aa6e68 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -453,6 +453,7 @@ struct drm_panel;
 # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
 # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
 # define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3)
+#define DP_FEC_CAPABILITY_10x091   /* 2.0 */
 
 /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
 #define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */
@@ -537,6 +538,9 @@ struct drm_panel;
 #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1  0x0a1
 #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2
 
+/* DFP Capability Extension */
+#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0a3   /* 2.0 */
+
 /* Link Configuration */
 #defineDP_LINK_BW_SET  0x100
 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */
@@ -688,6 +692,7 @@ struct drm_panel;
 
 #define DP_DSC_ENABLE   0x160   /* DP 1.4 */
 # define DP_DECOMPRESSION_EN(1 << 0)
+#define DP_DSC_CONFIGURATION   0x161   /* DP 2.0 */
 
 #define DP_PSR_EN_CFG  0x170   /* XXX 1.2? */
 # define DP_PSR_ENABLE BIT(0)
@@ -743,6 +748,7 @@ struct drm_panel;
 # define DP_RECEIVE_PORT_0_STATUS  (1 << 0)
 # define DP_RECEIVE_PORT_1_STATUS  (1 << 1)
 # define DP_STREAM_REGENERATION_STATUS  (1 << 2) /* 2.0 */
+# define DP_INTRA_HOP_AUX_REPLY_INDICATION (1 << 3) /* 2.0 */
 
 #define DP_ADJUST_REQUEST_LANE0_1  0x206
 #define DP_ADJUST_REQUEST_LANE2_3  0x207
@@ -865,6 +871,8 @@ struct drm_panel;
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
 # define DP_PHY_TEST_PATTERN_CP2520 0x5
 
+#define DP_PHY_SQUARE_PATTERN  0x249
+
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
 #defineDP_TEST_80BIT_CUSTOM_PATTERN_15_8   0x251
@@ -1109,6 +1117,18 @@ struct drm_panel;
 #define DP_128B132B_TRAINING_AUX_RD_INTERVAL   0x2216 /* 2.0 */
 # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f
 
+#define DP_TEST_264BIT_CUSTOM_PATTERN_7_0  0x2230
+#define DP_TEST_264BIT_CUSTOM_PATTERN_263_256  0x2250
+
+/* DSC Extended Capability Branch Total DSC Resources */
+#define DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT   0x2260  /* 2.0 */
+# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
+# define DP_DSC_DECODER_COUNT_SHIFT5
+#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0   0x2270  /* 2.0 */
+# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
+# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
+# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1
+
 /* Protocol Converter Extension */
 /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
 #define DP_CEC_TUNNELING_CAPABILITY0x3000
-- 
2.25.1



[Intel-gfx] ✓ Fi.CI.IGT: success for refactor the i915 GVT support (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: refactor the i915 GVT support (rev2)
URL   : https://patchwork.freedesktop.org/series/93816/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10654_full -> Patchwork_21176_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-3x:
- shard-glk:  NOTRUN -> [SKIP][1] ([fdo#109271]) +39 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-glk3/igt@feature_discov...@display-3x.html

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-snb7/igt@gem_cre...@create-massive.html
- shard-tglb: NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-tglb6/igt@gem_cre...@create-massive.html

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

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  NOTRUN -> [DMESG-WARN][5] ([i915#180])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-kbl6/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  NOTRUN -> [FAIL][6] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-glk3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10654/shard-kbl1/igt@gem_exec_fair@basic-none-...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-kbl1/igt@gem_exec_fair@basic-none-...@rcs0.html

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

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][11] ([i915#2658])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-apl6/igt@gem_pr...@exhaustion.html

  * igt@gen9_exec_parse@batch-zero-length:
- shard-tglb: NOTRUN -> [SKIP][12] ([i915#2856])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-tglb5/igt@gen9_exec_pa...@batch-zero-length.html

  * igt@i915_module_load@reload:
- shard-skl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10654/shard-skl6/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-skl7/igt@i915_module_l...@reload.html

  * igt@i915_pm_sseu@full-enable:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109288])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-tglb7/igt@i915_pm_s...@full-enable.html

  * igt@kms_addfb_basic@invalid-smem-bo-on-discrete:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#3826])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-tglb5/igt@kms_addfb_ba...@invalid-smem-bo-on-discrete.html

  * igt@kms_atomic@plane-primary-overlay-mutable-zpos:
- shard-tglb: NOTRUN -> [SKIP][17] ([i915#404])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-tglb5/igt@kms_ato...@plane-primary-overlay-mutable-zpos.html

  * igt@kms_big_fb@linear-64bpp-rotate-90:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#111614])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-tglb3/igt@kms_big...@linear-64bpp-rotate-90.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-glk:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3777])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-glk3/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-kbl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3777]) +1 
similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21176/shard-kbl6/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#111615])
   [21]: 

Re: [Intel-gfx] refactor the i915 GVT support

2021-09-28 Thread Wang, Zhi A
On 9/28/21 2:00 PM, Luis Chamberlain wrote:
> On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
>> Hey guys:
>>
>> After some investigation, I found the root cause this problem ("i915"
>> module loading will be stuck with Christoph's refactor patches), which
>> can be reproduced by building both i915 and kvmgt as kernel module and
>> the loading i915.
> Thanks for looking into this!
>
>> The root cause is: in Linux kernel loading, before a kernel module
>> loading is finished, its symbols can not be reached by other module when
>> resolving the symbols (even they can be found in /proc/kallsyms).
>> Because the status of the kernel module is MODULE_STATE_COMING and
>> resolve_symbol() from another kernel module will check this and return a
>> -EBUSY.
> Well, it would seem that way but...
>
>> In this case, before i915 loading is finished, the requested module
>> "kvmgt" cannot reach the symbols in module i915. Thus it kept waiting
>> and left message like below in the dmesg:
>>
>> [  644.152021] kvmgt: gave up waiting for init of module i915.
>> [  644.152039] kvmgt: Unknown symbol i915_gem_object_set_to_cpu_domain
>> (err -16)
>> [  674.871409] kvmgt: gave up waiting for init of module i915.
>> [  674.871427] kvmgt: Unknown symbol intel_ring_begin (err -16)
>> [  705.590586] kvmgt: gave up waiting for init of module i915.
>> [  705.590604] kvmgt: Unknown symbol i915_vma_move_to_active (err -16)
>> [  736.310230] kvmgt: gave up waiting for init of module i915.
>> [  736.310248] kvmgt: Unknown symbol shmem_unpin_map (err -16)
>> ...
>>
>> The error message is from execution path below:
>>
>> kernel/module.c:
>>
>> [i915 module loading] ->
>> request_module("kvmgt")->[modprobe]->init_module("kvmgt")->load_module()->simplify_symbols()->resolve_symbol_wait():
>>
>> static const struct kernel_symbol *
>> resolve_symbol_wait(struct module *mod,
>>               const struct load_info *info,
>>               const char *name)
>> {
>>       const struct kernel_symbol *ksym;
>>       char owner[MODULE_NAME_LEN];
>>
>>       if (wait_event_interruptible_timeout(module_wq,
>>               !IS_ERR(ksym = resolve_symbol(mod, info, name, owner))
>>               || PTR_ERR(ksym) != -EBUSY,
>>                        30 * HZ) <= 0) {
>>           pr_warn("%s: gave up waiting for init of module %s.\n",
>>               mod->name, owner);
>>
>> }
> Commit 9bea7f23952d5 ("module: fix bne2 "gave up waiting for init of
> module libcrc32c") is worth reviewing. It dealt with a similar issue,
> and in particular it addressed the issue with -EBUSY being returned
> by ref_module().
>
> And so, in theory that case should be dealt with in resolve_symbol_wait()
> already. And so can you try this just to verify something:
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 40ec9a030eec..98f87cbb37de 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1459,7 +1459,7 @@ resolve_symbol_wait(struct module *mod,
>   if (wait_event_interruptible_timeout(module_wq,
>   !IS_ERR(ksym = resolve_symbol(mod, info, name, owner))
>   || PTR_ERR(ksym) != -EBUSY,
> -  30 * HZ) <= 0) {
> +  160 * HZ) <= 0) {
>   pr_warn("%s: gave up waiting for init of module %s.\n",
>   mod->name, owner);
>   }
>
Hi Luis:

Thanks so much for the reply and patch.:)

I am afraid that this patch wouldn't work in this case as the 
request_module("kvmgt") happens in the init_module of i915. Before the 
initialization path is finished in i915, the i915 symbols are not 
available to be referenced. Unfortunately, It's matter of sequence, not 
of delay. :(

>> code:
>> https://github.com/intel/gvt-linux/blob/bd950a66c7919d7121d2530f30984351534a96dc/kernel/module.c#L1452
>>
>> In resolve_symbol_wait(), it calls resolve_symbol() to resolve the
>> symbols in "i915". In resolve_symbol() -> ref_module() ->
>> strong_try_module_get(), it will check the status of the module which
>> owns the symbol.
>>
>> static inline int strong_try_module_get(struct module *mod)
>> {
>>       BUG_ON(mod && mod->state == MODULE_STATE_UNFORMED);
>>       if (mod && mod->state == MODULE_STATE_COMING)
>>           return -EBUSY;
>>       if (try_module_get(mod))
>>           return 0;
>>       else
>>           return -ENOENT;
>> }
>>
>> code:https://github.com/intel/gvt-linux/blob/bd950a66c7919d7121d2530f30984351534a96dc/kernel/module.c#L318
>>
>> But unfortunately, this execution path begins in i915 module loading, at
>> this time, the status of kernel module "i915" is MODULE_STATE_COMING
>> until loading of "kvmgt" is finished. Thus a -EBUSY is always returned
>> when kernel is trying to resolve symbols for "kvmgt".
>>
>>
>> This patch below might need re-work:
> If the above test patch still fails, well.. that might be telling of
> another issue which is perhaps difficult to see at first glance. If
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for refactor the i915 GVT support (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: refactor the i915 GVT support (rev2)
URL   : https://patchwork.freedesktop.org/series/93816/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10654 -> Patchwork_21176


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (45 -> 35)
--

  Missing(10): fi-kbl-soraka fi-ilk-m540 bat-adls-5 fi-hsw-4200u 
fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 fi-tgl-y bat-jsl-2 bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10654 -> Patchwork_21176

  CI-20190529: 20190529
  CI_DRM_10654: 7006e15e0a109ce092026c4b576fe8a206e8b756 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6224: 2f4e6430a97f04284d1cafb1479e7c1b0b2d596a @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21176: 6ed5d9205804044b34a03ffb8f235fa101689f17 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6ed5d9205804 refactor the i915 GVT support

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for refactor the i915 GVT support (rev2)

2021-09-28 Thread Patchwork
== Series Details ==

Series: refactor the i915 GVT support (rev2)
URL   : https://patchwork.freedesktop.org/series/93816/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6ed5d9205804 refactor the i915 GVT support
-:48: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#48: 
> request_module("kvmgt")->[modprobe]->init_module("kvmgt")->load_module()->simplify_symbols()->resolve_symbol_wait():

-:67: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'Commit 9bea7f23952d ("module: fix bne2 
"gave up waiting for init of module libcrc32c"")'
#67: 
Commit 9bea7f23952d5 ("module: fix bne2 "gave up waiting for init of
module libcrc32c") is worth reviewing. It dealt with a similar issue,

-:185: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

total: 2 errors, 1 warnings, 0 checks, 8 lines checked




[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp: Add Additional DP2 Headers (rev3)

2021-09-28 Thread Patchwork
== Series Details ==

Series: drm/dp: Add Additional DP2 Headers (rev3)
URL   : https://patchwork.freedesktop.org/series/95104/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10654_full -> Patchwork_21175_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-3x:
- shard-glk:  NOTRUN -> [SKIP][1] ([fdo#109271]) +39 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-glk8/igt@feature_discov...@display-3x.html

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-snb2/igt@gem_cre...@create-massive.html
- shard-tglb: NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-tglb3/igt@gem_cre...@create-massive.html

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

  * igt@gem_eio@in-flight-1us:
- shard-skl:  [PASS][5] -> [TIMEOUT][6] ([i915#3063])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10654/shard-skl7/igt@gem_...@in-flight-1us.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-skl5/igt@gem_...@in-flight-1us.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  NOTRUN -> [FAIL][7] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-glk8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][8] ([fdo#109271]) +17 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10654/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html

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

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][12] ([i915#2658]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-apl6/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3323])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-apl1/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][14] -> [DMESG-WARN][15] ([i915#1436] / 
[i915#716])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10654/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-glk2/igt@gen9_exec_pa...@allowed-all.html

  * igt@gen9_exec_parse@batch-zero-length:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#2856])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-tglb1/igt@gen9_exec_pa...@batch-zero-length.html

  * igt@i915_pm_sseu@full-enable:
- shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109288])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-tglb7/igt@i915_pm_s...@full-enable.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  [PASS][18] -> [INCOMPLETE][19] ([i915#3921])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10654/shard-snb5/igt@i915_selftest@l...@hangcheck.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-snb6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@fence-restore-untiled:
- shard-apl:  [PASS][20] -> [DMESG-WARN][21] ([i915#180])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10654/shard-apl7/igt@i915_susp...@fence-restore-untiled.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-apl8/igt@i915_susp...@fence-restore-untiled.html

  * igt@kms_addfb_basic@invalid-smem-bo-on-discrete:
- shard-tglb: NOTRUN -> [SKIP][22] ([i915#3826])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21175/shard-tglb1/igt@kms_addfb_ba...@invalid-smem-bo-on-discrete.html

  * igt@kms_atomic@plane-primary-overlay-mutable-zpos:
- shard-tglb:   

Re: [Intel-gfx] [PATCH V6] drm/i915/gen11: Disable cursor clock gating in HDR mode

2021-09-28 Thread Ville Syrjälä
On Mon, Sep 27, 2021 at 03:32:40PM +0530, Tejas Upadhyay wrote:
> Display underrun in HDR mode when cursor is enabled.
> RTL fix will be implemented CLKGATE_DIS_PSL_A bit 28-46520h.
> As per W/A 1604331009, Disable cursor clock gating in HDR mode.
> 
> Bspec : 33451
> 
> Changes since V5:
>   - replace intel_de_read with intel_de_rmw - Jani
> Changes since V4:
> - Added WA needed check - Ville
> - Replace BIT with REG_BIT - Ville
> - Add WA enable/disable support back which was added in V1 - Ville
> Changes since V3:
> - Disable WA when not in HDR mode or cursor plane not active - Ville
> - Extract required args from crtc_state - Ville
> - Create HDR mode API using bdw_set_pipemisc ref - Ville
> - Tested with HDR video as well full setmode, WA applies and disables
> Changes since V2:
> - Made it general gen11 WA
> - Removed WA needed check
> - Added cursor plane active check
> - Once WA enable, software will not disable
> Changes since V1:
> - Modified way CLKGATE_DIS_PSL bit 28 was modified
> 
> Signed-off-by: Tejas Upadhyay 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 31 
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f27c294beb92..e6ccc986bf27 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -214,6 +214,14 @@ icl_wa_scalerclkgating(struct drm_i915_private 
> *dev_priv, enum pipe pipe,
>  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
> ~DPFR_GATING_DIS);
>  }
>  
> +/* Wa_1604331009:icl,jsl,ehl */
> +static void
> +icl_wa_cursorclkgating(struct drm_i915_private *dev_priv, enum pipe pipe,
> +bool enable)
> +{
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe), CURSOR_GATING_DIS, enable 
> ? CURSOR_GATING_DIS : 0);

Checkapatch complained about the long line. Trivial to fix here.

> +}
> +
>  static bool
>  is_trans_port_sync_slave(const struct intel_crtc_state *crtc_state)
>  {
> @@ -2356,6 +2364,19 @@ static bool needs_scalerclk_wa(const struct 
> intel_crtc_state *crtc_state)
>   return false;
>  }
>  
> +static bool needs_cursorclk_wa(const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> +
> + /* Wa_1604331009:icl,jsl,ehl */
> + if (is_hdr_mode(crtc_state) &&
> + crtc_state->active_planes & BIT(PLANE_CURSOR) &&
> + DISPLAY_VER(dev_priv) == 11)
> + return true;
> +
> + return false;
> +}
> +
>  static bool planes_enabling(const struct intel_crtc_state *old_crtc_state,
>   const struct intel_crtc_state *new_crtc_state)
>  {
> @@ -2398,6 +2419,11 @@ static void intel_post_plane_update(struct 
> intel_atomic_state *state,
>   if (needs_scalerclk_wa(old_crtc_state) &&
>   !needs_scalerclk_wa(new_crtc_state))
>   icl_wa_scalerclkgating(dev_priv, pipe, false);
> +
> + if (needs_cursorclk_wa(old_crtc_state) &&
> + !needs_cursorclk_wa(new_crtc_state))
> + icl_wa_cursorclkgating(dev_priv, pipe, false);
> +

Stray newline.

>  }
>  
>  static void intel_crtc_enable_flip_done(struct intel_atomic_state *state,
> @@ -2494,6 +2520,11 @@ static void intel_pre_plane_update(struct 
> intel_atomic_state *state,
>   needs_scalerclk_wa(new_crtc_state))
>   icl_wa_scalerclkgating(dev_priv, pipe, true);
>  
> + /* Wa_1604331009:icl,jsl,ehl */
> + if (!needs_cursorclk_wa(old_crtc_state) &&
> + needs_cursorclk_wa(new_crtc_state))
> + icl_wa_cursorclkgating(dev_priv, pipe, true);
> +
>   /*
>* Vblank time updates from the shadow to live plane control register
>* are blocked if the memory self-refresh mode is active at that
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ef594df039db..7b3eed5b4e42 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4272,6 +4272,7 @@ enum {
>  #define   DPF_GATING_DIS (1 << 10)
>  #define   DPF_RAM_GATING_DIS (1 << 9)
>  #define   DPFR_GATING_DIS(1 << 8)
> +#define   CURSOR_GATING_DIS  REG_BIT(28)

Please keep the bits in order.

Otherwise lgtm
Reviewed-by: Ville Syrjälä 

>  
>  #define CLKGATE_DIS_PSL(pipe) \
>   _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B)
> -- 
> 2.31.1

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] refactor the i915 GVT support

2021-09-28 Thread Luis Chamberlain
On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
> Hey guys:
> 
> After some investigation, I found the root cause this problem ("i915" 
> module loading will be stuck with Christoph's refactor patches), which 
> can be reproduced by building both i915 and kvmgt as kernel module and 
> the loading i915.

Thanks for looking into this!

> The root cause is: in Linux kernel loading, before a kernel module 
> loading is finished, its symbols can not be reached by other module when 
> resolving the symbols (even they can be found in /proc/kallsyms). 
> Because the status of the kernel module is MODULE_STATE_COMING and 
> resolve_symbol() from another kernel module will check this and return a 
> -EBUSY.

Well, it would seem that way but...

> In this case, before i915 loading is finished, the requested module 
> "kvmgt" cannot reach the symbols in module i915. Thus it kept waiting 
> and left message like below in the dmesg:
> 
> [  644.152021] kvmgt: gave up waiting for init of module i915.
> [  644.152039] kvmgt: Unknown symbol i915_gem_object_set_to_cpu_domain 
> (err -16)
> [  674.871409] kvmgt: gave up waiting for init of module i915.
> [  674.871427] kvmgt: Unknown symbol intel_ring_begin (err -16)
> [  705.590586] kvmgt: gave up waiting for init of module i915.
> [  705.590604] kvmgt: Unknown symbol i915_vma_move_to_active (err -16)
> [  736.310230] kvmgt: gave up waiting for init of module i915.
> [  736.310248] kvmgt: Unknown symbol shmem_unpin_map (err -16)
> ...
> 
> The error message is from execution path below:
> 
> kernel/module.c:
> 
> [i915 module loading] -> 
> request_module("kvmgt")->[modprobe]->init_module("kvmgt")->load_module()->simplify_symbols()->resolve_symbol_wait():
> 
> static const struct kernel_symbol *
> resolve_symbol_wait(struct module *mod,
>              const struct load_info *info,
>              const char *name)
> {
>      const struct kernel_symbol *ksym;
>      char owner[MODULE_NAME_LEN];
> 
>      if (wait_event_interruptible_timeout(module_wq,
>              !IS_ERR(ksym = resolve_symbol(mod, info, name, owner))
>              || PTR_ERR(ksym) != -EBUSY,
>                       30 * HZ) <= 0) {
>          pr_warn("%s: gave up waiting for init of module %s.\n",
>              mod->name, owner);
> 
> }

Commit 9bea7f23952d5 ("module: fix bne2 "gave up waiting for init of
module libcrc32c") is worth reviewing. It dealt with a similar issue,
and in particular it addressed the issue with -EBUSY being returned
by ref_module().

And so, in theory that case should be dealt with in resolve_symbol_wait()
already. And so can you try this just to verify something:

diff --git a/kernel/module.c b/kernel/module.c
index 40ec9a030eec..98f87cbb37de 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1459,7 +1459,7 @@ resolve_symbol_wait(struct module *mod,
if (wait_event_interruptible_timeout(module_wq,
!IS_ERR(ksym = resolve_symbol(mod, info, name, owner))
|| PTR_ERR(ksym) != -EBUSY,
-30 * HZ) <= 0) {
+160 * HZ) <= 0) {
pr_warn("%s: gave up waiting for init of module %s.\n",
mod->name, owner);
}

> code: 
> https://github.com/intel/gvt-linux/blob/bd950a66c7919d7121d2530f30984351534a96dc/kernel/module.c#L1452
> 
> In resolve_symbol_wait(), it calls resolve_symbol() to resolve the 
> symbols in "i915". In resolve_symbol() -> ref_module() -> 
> strong_try_module_get(), it will check the status of the module which 
> owns the symbol.
> 
> static inline int strong_try_module_get(struct module *mod)
> {
>      BUG_ON(mod && mod->state == MODULE_STATE_UNFORMED);
>      if (mod && mod->state == MODULE_STATE_COMING)
>          return -EBUSY;
>      if (try_module_get(mod))
>          return 0;
>      else
>          return -ENOENT;
> }
> 
> code:https://github.com/intel/gvt-linux/blob/bd950a66c7919d7121d2530f30984351534a96dc/kernel/module.c#L318
> 
> But unfortunately, this execution path begins in i915 module loading, at 
> this time, the status of kernel module "i915" is MODULE_STATE_COMING 
> until loading of "kvmgt" is finished. Thus a -EBUSY is always returned 
> when kernel is trying to resolve symbols for "kvmgt".
>
> 
> This patch below might need re-work:

If the above test patch still fails, well.. that might be telling of
another issue which is perhaps difficult to see at first glance. If
resolve_symbol_wait() won't succeed until request_module("kvmgt")
completes and if this means having kvmgt's init routine complete, that
could end up in some longer chain or in the worst case a sort of
circular dependency which is only implicated by module loading. It'd be
really odd... but I cannot rule it out.

This is one reason I hinted that you should strive to not do much on a
module's init. If you can punt work off for later that's best.

  Luis

> 
> Author: Christoph Hellwig 
> 

  1   2   >