Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use the correct bpp when validating "4:2:0 only" modes

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915: Use the correct bpp when
> validating "4:2:0 only" modes
> 
> From: Ville Syrjälä 
> 
> When validating a "YCbCr 4:2:0 only" mode we must take into account the
> fact that we're going to be outputting YCbCr
> 4:2:0 or 4:4:4 (when a DP->HDMI protocol converter is doing the 4:2:0
> downsampling). For YCbCr 4:4:4 the minimum output bpc is 8, for YCbCr 4:2:0
> it'll be half that. The currently hardcoded 6bpc is only correct for RGB 
> 4:4:4,
> which we will never use with these kinds of modes. Figure out what we're
> going to output and use the correct min bpp value to validate whether the
> link has sufficient bandwidth.
> 
> Signed-off-by: Ville Syrjälä 
Looks good to me.
Reviewed-by: Vandita Kulkarni 

Thanks,
Vandita
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 55 +++--
>  1 file changed, 33 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index aa4801a8123d..54a4b81ea3ff 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -608,6 +608,37 @@ intel_dp_output_format(struct drm_connector
> *connector,
>   return INTEL_OUTPUT_FORMAT_YCBCR420;
>  }
> 
> +int intel_dp_min_bpp(enum intel_output_format output_format) {
> + if (output_format == INTEL_OUTPUT_FORMAT_RGB)
> + return 6 * 3;
> + else
> + return 8 * 3;
> +}
> +
> +static int intel_dp_output_bpp(enum intel_output_format output_format,
> +int bpp) {
> + /*
> +  * bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> +  * format of the number of bytes per pixel will be half the number
> +  * of bytes of RGB pixel.
> +  */
> + if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + bpp /= 2;
> +
> + return bpp;
> +}
> +
> +static int
> +intel_dp_mode_min_output_bpp(struct drm_connector *connector,
> +  const struct drm_display_mode *mode) {
> + enum intel_output_format output_format =
> + intel_dp_output_format(connector, mode);
> +
> + return intel_dp_output_bpp(output_format,
> +intel_dp_min_bpp(output_format)); }
> +
>  static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
> int hdisplay)
>  {
> @@ -687,7 +718,8 @@ intel_dp_mode_valid(struct drm_connector
> *connector,
>   max_lanes = intel_dp_max_lane_count(intel_dp);
> 
>   max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> - mode_rate = intel_dp_link_required(target_clock, 18);
> + mode_rate = intel_dp_link_required(target_clock,
> +
> intel_dp_mode_min_output_bpp(connector, mode));
> 
>   if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
>   return MODE_H_ILLEGAL;
> @@ -2111,19 +2143,6 @@ intel_dp_adjust_compliance_config(struct
> intel_dp *intel_dp,
>   }
>  }
> 
> -static int intel_dp_output_bpp(enum intel_output_format output_format,
> int bpp) -{
> - /*
> -  * bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> -  * format of the number of bytes per pixel will be half the number
> -  * of bytes of RGB pixel.
> -  */
> - if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> - bpp /= 2;
> -
> - return bpp;
> -}
> -
>  /* Optimize link config in order: max bpp, min clock, min lanes */  static 
> int
> intel_dp_compute_link_config_wide(struct intel_dp *intel_dp, @@ -2346,14
> +2365,6 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
>   return 0;
>  }
> 
> -int intel_dp_min_bpp(enum intel_output_format output_format) -{
> - if (output_format == INTEL_OUTPUT_FORMAT_RGB)
> - return 6 * 3;
> - else
> - return 8 * 3;
> -}
> -
>  static int
>  intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Decouple intel_dp_{min, output}_bpp() from crtc_state

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Decouple intel_dp_{min,
> output}_bpp() from crtc_state
> 
> From: Ville Syrjälä 
> 
> Pass the output_format directly to intel_dp_{min,output}_bpp() rather than
> passing in the crtc_state and digging out the output_format inside the
> functions. This will allow us to reuse the functions for mode validation
> purposes.
> 
> Signed-off-by: Ville Syrjälä 

Looks good to me.
Reviewed-by: Vandita Kulkarni 

Thanks,
Vandita
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 15 ---
>  drivers/gpu/drm/i915/display/intel_dp.h |  3 ++-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  2 +-
>  3 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ad9b8b16fadb..aa4801a8123d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2111,14 +2111,14 @@ intel_dp_adjust_compliance_config(struct
> intel_dp *intel_dp,
>   }
>  }
> 
> -static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, int
> bpp)
> +static int intel_dp_output_bpp(enum intel_output_format output_format,
> +int bpp)
>  {
>   /*
>* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
>* format of the number of bytes per pixel will be half the number
>* of bytes of RGB pixel.
>*/
> - if (crtc_state->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420)
> + if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
>   bpp /= 2;
> 
>   return bpp;
> @@ -2135,7 +2135,7 @@ intel_dp_compute_link_config_wide(struct
> intel_dp *intel_dp,
>   int mode_rate, link_clock, link_avail;
> 
>   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> - int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
> + int output_bpp = intel_dp_output_bpp(pipe_config-
> >output_format,
> +bpp);
> 
>   mode_rate = intel_dp_link_required(adjusted_mode-
> >crtc_clock,
>  output_bpp);
> @@ -2346,9 +2346,9 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
>   return 0;
>  }
> 
> -int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
> +int intel_dp_min_bpp(enum intel_output_format output_format)
>  {
> - if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> + if (output_format == INTEL_OUTPUT_FORMAT_RGB)
>   return 6 * 3;
>   else
>   return 8 * 3;
> @@ -2379,7 +2379,7 @@ intel_dp_compute_link_config(struct
> intel_encoder *encoder,
>   limits.min_lane_count = 1;
>   limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> 
> - limits.min_bpp = intel_dp_min_bpp(pipe_config);
> + limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format);
>   limits.max_bpp = intel_dp_max_bpp(intel_dp, pipe_config);
> 
>   if (intel_dp_is_edp(intel_dp)) {
> @@ -2765,7 +2765,8 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   if (pipe_config->dsc.compression_enable)
>   output_bpp = pipe_config->dsc.compressed_bpp;
>   else
> - output_bpp = intel_dp_output_bpp(pipe_config,
> pipe_config->pipe_bpp);
> + output_bpp = intel_dp_output_bpp(pipe_config-
> >output_format,
> +  pipe_config->pipe_bpp);
> 
>   intel_link_compute_m_n(output_bpp,
>  pipe_config->lane_count,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 08a1c0aa8b94..a9580d1df35b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -10,6 +10,7 @@
> 
>  #include "i915_reg.h"
> 
> +enum intel_output_format;
>  enum pipe;
>  enum port;
>  struct drm_connector_state;
> @@ -35,7 +36,7 @@ void intel_dp_adjust_compliance_config(struct intel_dp
> *intel_dp,
>  struct link_config_limits *limits);  bool
> intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state
> *conn_state); -int intel_dp_min_bpp(const struct intel_crtc_state
> *crtc_state);
> +int intel_dp_min_bpp(enum intel_output_format output_format);
>  bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
>  i915_reg_t dp_reg, enum port port,
>  enum pipe *pipe);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 64d885539e94..6a874b779b1f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -130,7 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Extract intel_dp_output_format()

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/3] drm/i915: Extract intel_dp_output_format()
> 
> From: Ville Syrjälä 
> 
> Refactor the output_format calculation into a helper so that we can reuse it
> for mode validation as well.
> 
> Signed-off-by: Ville Syrjälä 

Looks good to me.
Reviewed-by: Vandita Kulkarni 

Thanks,
Vandita
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 32 +++--
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index bf1e9cf1c0f3..ad9b8b16fadb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -592,6 +592,22 @@ static u8 intel_dp_dsc_get_slice_count(struct
> intel_dp *intel_dp,
>   return 0;
>  }
> 
> +static enum intel_output_format
> +intel_dp_output_format(struct drm_connector *connector,
> +const struct drm_display_mode *mode) {
> + struct intel_dp *intel_dp =
> intel_attached_dp(to_intel_connector(connector));
> + const struct drm_display_info *info = >display_info;
> +
> + if (!drm_mode_is_420_only(info, mode))
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
> + if (intel_dp->dfp.ycbcr_444_to_420)
> + return INTEL_OUTPUT_FORMAT_YCBCR444;
> + else
> + return INTEL_OUTPUT_FORMAT_YCBCR420;
> +}
> +
>  static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
> int hdisplay)
>  {
> @@ -2430,27 +2446,20 @@ intel_dp_compute_link_config(struct
> intel_encoder *encoder,  }
> 
>  static int
> -intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
> -  struct intel_crtc_state *crtc_state,
> +intel_dp_ycbcr420_config(struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)  {
>   struct drm_connector *connector = conn_state->connector;
> - const struct drm_display_info *info = >display_info;
>   const struct drm_display_mode *adjusted_mode =
>   _state->hw.adjusted_mode;
> 
>   if (!connector->ycbcr_420_allowed)
>   return 0;
> 
> - if (!drm_mode_is_420_only(info, adjusted_mode))
> - return 0;
> + crtc_state->output_format = intel_dp_output_format(connector,
> +adjusted_mode);
> 
> - if (intel_dp->dfp.ycbcr_444_to_420) {
> - crtc_state->output_format =
> INTEL_OUTPUT_FORMAT_YCBCR444;
> + if (crtc_state->output_format !=
> INTEL_OUTPUT_FORMAT_YCBCR420)
>   return 0;
> - }
> -
> - crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> 
>   return intel_pch_panel_fitting(crtc_state, conn_state);  } @@ -
> 2710,8 +2719,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   if (lspcon->active)
>   lspcon_ycbcr420_config(_connector->base,
> pipe_config);
>   else
> - ret = intel_dp_ycbcr420_config(intel_dp, pipe_config,
> -conn_state);
> + ret = intel_dp_ycbcr420_config(pipe_config, conn_state);
>   if (ret)
>   return ret;
> 
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/3] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/3] drm/i915/display: Ignore 
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL   : https://patchwork.freedesktop.org/series/81824/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9023_full -> Patchwork_18525_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18525_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18525_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_18525_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen:
- shard-hsw:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-hsw2/igt@kms_cursor_...@pipe-c-cursor-128x42-onscreen.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-hsw2/igt@kms_cursor_...@pipe-c-cursor-128x42-onscreen.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-fds-forked-all:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) 
+1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-glk8/igt@gem_exec_whis...@basic-fds-forked-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-glk3/igt@gem_exec_whis...@basic-fds-forked-all.html

  * igt@gem_userptr_blits@sync-unmap-cycles:
- shard-skl:  [PASS][5] -> [TIMEOUT][6] ([i915#1958] / [i915#2424])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-skl2/igt@gem_userptr_bl...@sync-unmap-cycles.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-skl7/igt@gem_userptr_bl...@sync-unmap-cycles.html

  * igt@i915_module_load@reload:
- shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +3 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-tglb2/igt@i915_module_l...@reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-tglb2/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([i915#96])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-skl5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-skl3/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@2x-wf_vblank-ts-check-interruptible@ab-vga1-hdmi-a1:
- shard-hsw:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-hsw6/igt@kms_flip@2x-wf_vblank-ts-check-interrupti...@ab-vga1-hdmi-a1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-hsw6/igt@kms_flip@2x-wf_vblank-ts-check-interrupti...@ab-vga1-hdmi-a1.html

  * igt@kms_flip@flip-vs-suspend@b-dp1:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-kbl3/igt@kms_flip@flip-vs-susp...@b-dp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-kbl2/igt@kms_flip@flip-vs-susp...@b-dp1.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#2122])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-skl4/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-skl3/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html

  * igt@kms_hdr@bpc-switch-suspend:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-skl8/igt@kms_...@bpc-switch-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/shard-skl1/igt@kms_...@bpc-switch-suspend.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][21] -> [FAIL][22] 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Tweak initial dpcd backlight.enabled value

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Tweak initial dpcd backlight.enabled value
URL   : https://patchwork.freedesktop.org/series/81821/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9023_full -> Patchwork_18524_full


Summary
---

  **WARNING**

  Minor unknown changes coming with Patchwork_18524_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18524_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_18524_full:

### IGT changes ###

 Warnings 

  * igt@i915_pm_rpm@pm-tiling:
- shard-tglb: [DMESG-WARN][1] ([i915#2411]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-tglb3/igt@i915_pm_...@pm-tiling.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-tglb8/igt@i915_pm_...@pm-tiling.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-queues-priority:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-glk8/igt@gem_exec_whis...@basic-queues-priority.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-glk4/igt@gem_exec_whis...@basic-queues-priority.html

  * igt@gem_userptr_blits@sync-unmap-cycles:
- shard-skl:  [PASS][5] -> [TIMEOUT][6] ([i915#1958] / [i915#2424])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-skl2/igt@gem_userptr_bl...@sync-unmap-cycles.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-skl10/igt@gem_userptr_bl...@sync-unmap-cycles.html

  * igt@gem_workarounds@reset-fd:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#1635] / 
[i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-apl4/igt@gem_workarou...@reset-fd.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-apl4/igt@gem_workarou...@reset-fd.html

  * igt@i915_selftest@mock@contexts:
- shard-apl:  [PASS][9] -> [INCOMPLETE][10] ([i915#1635] / 
[i915#2278])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-apl7/igt@i915_selftest@m...@contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-apl3/igt@i915_selftest@m...@contexts.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-skl5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-skl3/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@flip-vs-expired-vblank@b-edp1:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#79])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-skl7/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-edp1:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([i915#198]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-skl1/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-skl9/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html

  * igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +4 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-kbl3/igt@kms_flip@flip-vs-susp...@c-dp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-kbl7/igt@kms_flip@flip-vs-susp...@c-dp1.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#49])
   [21]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/3] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/3] drm/i915/display: Ignore 
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL   : https://patchwork.freedesktop.org/series/81824/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9023 -> Patchwork_18525


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#2203])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  
 Possible fixes 

  * igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95]) 
-> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2:  [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-tgl-y:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  * igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][19] ([i915#2203]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-skl-guc/igt@vgem_ba...@unload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-skl-guc/igt@vgem_ba...@unload.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][22] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18525/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@module-reload:
- fi-tgl-y:   [DMESG-WARN][23] ([i915#2411]) -> [DMESG-WARN][24] 
([i915#1982] / [i915#2411]) +1 similar issue
   [23]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Tweak initial dpcd backlight.enabled value

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Tweak initial dpcd backlight.enabled value
URL   : https://patchwork.freedesktop.org/series/81821/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9023 -> Patchwork_18524


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_flink_basic@double-flink:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-tgl-y/igt@gem_flink_ba...@double-flink.html

  * igt@i915_selftest@live@blt:
- fi-snb-2600:[PASS][3] -> [DMESG-FAIL][4] ([i915#1409])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-snb-2600/igt@i915_selftest@l...@blt.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-snb-2600/igt@i915_selftest@l...@blt.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

  
 Possible fixes 

  * igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) 
-> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-tgl-y:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  * igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][19] ([i915#2203]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-skl-guc/igt@vgem_ba...@unload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-skl-guc/igt@vgem_ba...@unload.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y:   [DMESG-WARN][21] ([i915#2411]) -> [DMESG-WARN][22] 
([i915#1982] / [i915#2411]) +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][23] ([i915#62]) -> [SKIP][24] 
([fdo#109271])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9023/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18524/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][25] ([i915#62] / [i915#92] / 

[Intel-gfx] [PATCH v3 1/3] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch

[José Roberto de Souza]

For platforms without selective fetch this register is reserved so
do not write 0 to it.

Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 8a9d0bdde1bf..4e09ae61d4aa 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -942,7 +942,7 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
intel_de_write(dev_priv, EXITLINE(cpu_transcoder), val);
}
 
-   if (HAS_PSR_HW_TRACKING(dev_priv))
+   if (HAS_PSR_HW_TRACKING(dev_priv) && HAS_PSR2_SEL_FETCH(dev_priv))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1, IGNORE_PSR2_HW_TRACKING,
 dev_priv->psr.psr2_sel_fetch_enabled ?
 IGNORE_PSR2_HW_TRACKING : 0);
-- 
2.28.0

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

[Intel-gfx] [PATCH v3 2/3] drm/i915/display: Check PSR parameter and flag only in state compute phase

[José Roberto de Souza]

Due to the debugfs flag, has_psr2 in CRTC state could have a different
value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
and selective fetch) to be set to not a expected state.

So here only taking in consideration the parameter and debugfs flag
when computing PSR state, this way the CRTC state will also have
the correct state.

intel_psr_fastset_force() was already broken as
intel_psr_compute_config() was already only enabling PSR when
psr_global_enabled() and all other PSR requirements are met.
So some changes was required in this function, now it iterates over
all connectors, if it is a eDP connector and is active force a modeset
in the CRTC driving this connector, what will cause the new PSR state
to be set based on the debugfs flag.

v2:
- end connector iterator in error cases

Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 73 +---
 1 file changed, 41 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 4e09ae61d4aa..02f74b0ddec1 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -91,19 +91,14 @@ static bool psr_global_enabled(struct drm_i915_private 
*i915)
}
 }
 
-static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
-  const struct intel_crtc_state *crtc_state)
+static bool psr2_global_enabled(struct drm_i915_private *dev_priv)
 {
-   /* Cannot enable DSC and PSR2 simultaneously */
-   drm_WARN_ON(_priv->drm, crtc_state->dsc.compression_enable &&
-   crtc_state->has_psr2);
-
switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
case I915_PSR_DEBUG_DISABLE:
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
default:
-   return crtc_state->has_psr2;
+   return true;
}
 }
 
@@ -729,6 +724,11 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
+   if (!psr2_global_enabled(dev_priv)) {
+   drm_dbg_kms(_priv->drm, "PSR2 disabled by flag\n");
+   return false;
+   }
+
/*
 * DSC and PSR2 cannot be enabled simultaneously. If a requested
 * resolution requires DSC to be enabled, priority is given to DSC
@@ -817,8 +817,11 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
if (intel_dp != dev_priv->psr.dp)
return;
 
-   if (!psr_global_enabled(dev_priv))
+   if (!psr_global_enabled(dev_priv)) {
+   drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
return;
+   }
+
/*
 * HSW spec explicitly says PSR is tied to port A.
 * BDW+ platforms have a instance of PSR registers per transcoder but
@@ -959,7 +962,7 @@ static void intel_psr_enable_locked(struct drm_i915_private 
*dev_priv,
 
drm_WARN_ON(_priv->drm, dev_priv->psr.enabled);
 
-   dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
+   dev_priv->psr.psr2_enabled = crtc_state->has_psr2;
dev_priv->psr.busy_frontbuffer_bits = 0;
dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
@@ -1029,15 +1032,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
drm_WARN_ON(_priv->drm, dev_priv->drrs.dp);
 
mutex_lock(_priv->psr.lock);
-
-   if (!psr_global_enabled(dev_priv)) {
-   drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
-   goto unlock;
-   }
-
intel_psr_enable_locked(dev_priv, crtc_state, conn_state);
-
-unlock:
mutex_unlock(_priv->psr.lock);
 }
 
@@ -1222,8 +1217,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
 
mutex_lock(_priv->psr.lock);
 
-   enable = crtc_state->has_psr && psr_global_enabled(dev_priv);
-   psr2_enable = intel_psr2_enabled(dev_priv, crtc_state);
+   enable = crtc_state->has_psr;
+   psr2_enable = crtc_state->has_psr2;
 
if (enable == psr->enabled && psr2_enable == psr->psr2_enabled) {
/* Force a PSR exit when enabling CRC to avoid CRC timeouts */
@@ -1320,11 +1315,12 @@ static bool __psr_wait_for_idle_locked(struct 
drm_i915_private *dev_priv)
 
 static int intel_psr_fastset_force(struct drm_i915_private *dev_priv)
 {
+   struct drm_connector_list_iter conn_iter;
struct drm_device *dev = _priv->drm;
struct drm_modeset_acquire_ctx ctx;
struct drm_atomic_state *state;
-   struct intel_crtc *crtc;
-   int err;
+   struct drm_connector *conn;
+   int err = 0;
 
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -1334,25 +1330,38 @@ static int intel_psr_fastset_force(struct 
drm_i915_private *dev_priv)
  

[Intel-gfx] [PATCH v3 3/3] drm/i915/display: Program PSR2 selective fetch registers

[José Roberto de Souza]

Another step towards PSR2 selective fetch, here programming plane
selective fetch registers and MAN_TRK_CTL enabling selective fetch but
for now it is fetching the whole area of the planes.
The damaged area calculation will come as next and final step.

v2:
- removed warn on when no plane is visible in state
- removed calculations using plane damaged area in
intel_psr2_program_plane_sel_fetch()

v3:
- do not shift 16 positions the plane dst coordinates, only src is shifted

BSpec: 55229
Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c |  10 +-
 drivers/gpu/drm/i915/display/intel_psr.c | 120 ++-
 drivers/gpu/drm/i915/display/intel_psr.h |  10 +-
 drivers/gpu/drm/i915/display/intel_sprite.c  |   3 +
 4 files changed, 134 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..96bc515497c1 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11812,6 +11812,9 @@ static void i9xx_update_cursor(struct intel_plane 
*plane,
if (INTEL_GEN(dev_priv) >= 9)
skl_write_cursor_wm(plane, crtc_state);
 
+   if (!needs_modeset(crtc_state))
+   intel_psr2_program_plane_sel_fetch(plane, crtc_state, 
plane_state, 0);
+
if (plane->cursor.base != base ||
plane->cursor.size != fbc_ctl ||
plane->cursor.cntl != cntl) {
@@ -12823,8 +12826,11 @@ static int intel_crtc_atomic_check(struct 
intel_atomic_state *state,
 
}
 
-   if (!mode_changed)
-   intel_psr2_sel_fetch_update(state, crtc);
+   if (!mode_changed) {
+   ret = intel_psr2_sel_fetch_update(state, crtc);
+   if (ret)
+   return ret;
+   }
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 02f74b0ddec1..deb0523f9f29 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1166,6 +1166,41 @@ static void psr_force_hw_tracking_exit(struct 
drm_i915_private *dev_priv)
intel_psr_exit(dev_priv);
 }
 
+void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
+   const struct intel_crtc_state 
*crtc_state,
+   const struct intel_plane_state 
*plane_state,
+   int color_plane)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   enum pipe pipe = plane->pipe;
+   u32 val;
+
+   if (!crtc_state->enable_psr2_sel_fetch)
+   return;
+
+   /*
+* skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0 for gen11+, so
+* plane_state->ctl is the right value
+*/
+   val = plane_state ? plane_state->ctl : 0;
+   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), val);
+   if (!val || plane->id == PLANE_CURSOR)
+   return;
+
+   val = plane_state->uapi.dst.y1 << 16 | plane_state->uapi.dst.x1;
+   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_POS(pipe, plane->id), val);
+
+   val = plane_state->color_plane[color_plane].y << 16;
+   val |= plane_state->color_plane[color_plane].x;
+   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_OFFSET(pipe, plane->id),
+ val);
+
+   /* Sizes are 0 based */
+   val = ((drm_rect_height(_state->uapi.src) >> 16) - 1) << 16;
+   val |= (drm_rect_width(_state->uapi.src) >> 16) - 1;
+   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe, plane->id), val);
+}
+
 void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state 
*crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -1180,16 +1215,91 @@ void intel_psr2_program_trans_man_trk_ctl(const struct 
intel_crtc_state *crtc_st
   crtc_state->psr2_man_track_ctl);
 }
 
-void intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
-struct intel_crtc *crtc)
+static void psr2_man_trk_ctl_calc(struct intel_crtc_state *crtc_state,
+ struct drm_rect *clip, bool full_update)
+{
+   u32 val = PSR2_MAN_TRK_CTL_ENABLE;
+
+   if (full_update) {
+   val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
+   goto exit;
+   }
+
+   if (clip->y1 == -1)
+   goto exit;
+
+   val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
+   val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 / 4 + 1);
+   val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(DIV_ROUND_UP(clip->y2, 4) + 
1);
+exit:
+   crtc_state->psr2_man_track_ctl = val;
+}
+
+static void clip_area_update(struct drm_rect *overlap_damage_area,
+struct 

[Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

[Sean Paul]

From: Sean Paul 

In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
DPCD control mode"), we fixed the brightness level when DPCD control was
not active to max brightness. This is as good as we can guess since most
backlights go on full when uncontrolled.

However in doing so we changed the semantics of the initial
'backlight.enabled' value. At least on Pixelbooks, they  were relying
on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
boot such that enabled would be false. This causes the device to be
enabled when the brightness is set. Without this, brightness control
doesn't work. So by changing brightness to max, we also flipped enabled
to be true on boot.

To fix this, make enabled a function of brightness and backlight control
mechanism.

Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD control 
mode")
Cc: Lyude Paul 
Cc: Jani Nikula 
Cc: Juha-Pekka Heikkila 
Cc: "Ville Syrjälä" 
Cc: Rodrigo Vivi 
Cc: Kevin Chowski >
Signed-off-by: Sean Paul 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe..036f504ac7db 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
}
 }
 
-/*
- * Read the current backlight value from DPCD register(s) based
- * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
- */
-static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
+static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
-   u8 read_val[2] = { 0x0 };
u8 mode_reg;
-   u16 level = 0;
 
if (drm_dp_dpcd_readb(_dp->aux,
  DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
@@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct 
intel_connector *connector)
drm_dbg_kms(>drm,
"Failed to read the DPCD register 0x%x\n",
DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
-   return 0;
+   return false;
}
 
+   return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
+  DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+}
+
+/*
+ * Read the current backlight value from DPCD register(s) based
+ * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
+ */
+static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 read_val[2] = { 0x0 };
+   u16 level = 0;
+
/*
 * If we're not in DPCD control mode yet, the programmed brightness
 * value is meaningless and we should assume max brightness
 */
-   if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
-   DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
+   if (!intel_dp_aux_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
 
if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
@@ -319,7 +327,8 @@ static int intel_dp_aux_setup_backlight(struct 
intel_connector *connector,
 
panel->backlight.min = 0;
panel->backlight.level = intel_dp_aux_get_backlight(connector);
-   panel->backlight.enabled = panel->backlight.level != 0;
+   panel->backlight.enabled = intel_dp_aux_backlight_dpcd_mode(connector) 
&&
+  panel->backlight.level != 0;
 
return 0;
 }
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use the correct bpp when validating "4:2:0 only" modes

[Navare, Manasi]

On Fri, Sep 18, 2020 at 12:43:35AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> When validating a "YCbCr 4:2:0 only" mode we must take into
> account the fact that we're going to be outputting YCbCr
> 4:2:0 or 4:4:4 (when a DP->HDMI protocol converter is doing
> the 4:2:0 downsampling). For YCbCr 4:4:4 the minimum output
> bpc is 8, for YCbCr 4:2:0 it'll be half that. The currently
> hardcoded 6bpc is only correct for RGB 4:4:4, which we will
> never use with these kinds of modes. Figure out what we're
> going to output and use the correct min bpp value to validate
> whether the link has sufficient bandwidth.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 55 +++--
>  1 file changed, 33 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index aa4801a8123d..54a4b81ea3ff 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -608,6 +608,37 @@ intel_dp_output_format(struct drm_connector *connector,
>   return INTEL_OUTPUT_FORMAT_YCBCR420;
>  }
>  
> +int intel_dp_min_bpp(enum intel_output_format output_format)
> +{
> + if (output_format == INTEL_OUTPUT_FORMAT_RGB)
> + return 6 * 3;
> + else
> + return 8 * 3;
> +}
> +
> +static int intel_dp_output_bpp(enum intel_output_format output_format, int 
> bpp)
> +{
> + /*
> +  * bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> +  * format of the number of bytes per pixel will be half the number
> +  * of bytes of RGB pixel.
> +  */
> + if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + bpp /= 2;
> +
> + return bpp;
> +}
> +
> +static int
> +intel_dp_mode_min_output_bpp(struct drm_connector *connector,
> +  const struct drm_display_mode *mode)
> +{
> + enum intel_output_format output_format =
> + intel_dp_output_format(connector, mode);
> +
> + return intel_dp_output_bpp(output_format, 
> intel_dp_min_bpp(output_format));
> +}
> +
>  static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
> int hdisplay)
>  {
> @@ -687,7 +718,8 @@ intel_dp_mode_valid(struct drm_connector *connector,
>   max_lanes = intel_dp_max_lane_count(intel_dp);
>  
>   max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> - mode_rate = intel_dp_link_required(target_clock, 18);
> + mode_rate = intel_dp_link_required(target_clock,
> +
> intel_dp_mode_min_output_bpp(connector, mode));
>  
>   if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
>   return MODE_H_ILLEGAL;
> @@ -2111,19 +2143,6 @@ intel_dp_adjust_compliance_config(struct intel_dp 
> *intel_dp,
>   }
>  }
>  
> -static int intel_dp_output_bpp(enum intel_output_format output_format, int 
> bpp)
> -{
> - /*
> -  * bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> -  * format of the number of bytes per pixel will be half the number
> -  * of bytes of RGB pixel.
> -  */
> - if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> - bpp /= 2;
> -
> - return bpp;
> -}
> -
>  /* Optimize link config in order: max bpp, min clock, min lanes */
>  static int
>  intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
> @@ -2346,14 +2365,6 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
> *intel_dp,
>   return 0;
>  }
>  
> -int intel_dp_min_bpp(enum intel_output_format output_format)
> -{
> - if (output_format == INTEL_OUTPUT_FORMAT_RGB)
> - return 6 * 3;
> - else
> - return 8 * 3;
> -}
> -
>  static int
>  intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
> -- 
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Decouple intel_dp_{min, output}_bpp() from crtc_state

[Navare, Manasi]

On Fri, Sep 18, 2020 at 12:43:34AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Pass the output_format directly to intel_dp_{min,output}_bpp()
> rather than passing in the crtc_state and digging out the
> output_format inside the functions. This will allow us to reuse
> the functions for mode validation purposes.
> 
> Signed-off-by: Ville Syrjälä 

Looks good

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 15 ---
>  drivers/gpu/drm/i915/display/intel_dp.h |  3 ++-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  2 +-
>  3 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ad9b8b16fadb..aa4801a8123d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2111,14 +2111,14 @@ intel_dp_adjust_compliance_config(struct intel_dp 
> *intel_dp,
>   }
>  }
>  
> -static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, 
> int bpp)
> +static int intel_dp_output_bpp(enum intel_output_format output_format, int 
> bpp)
>  {
>   /*
>* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
>* format of the number of bytes per pixel will be half the number
>* of bytes of RGB pixel.
>*/
> - if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
>   bpp /= 2;
>  
>   return bpp;
> @@ -2135,7 +2135,7 @@ intel_dp_compute_link_config_wide(struct intel_dp 
> *intel_dp,
>   int mode_rate, link_clock, link_avail;
>  
>   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> - int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
> + int output_bpp = 
> intel_dp_output_bpp(pipe_config->output_format, bpp);
>  
>   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
>  output_bpp);
> @@ -2346,9 +2346,9 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
> *intel_dp,
>   return 0;
>  }
>  
> -int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
> +int intel_dp_min_bpp(enum intel_output_format output_format)
>  {
> - if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> + if (output_format == INTEL_OUTPUT_FORMAT_RGB)
>   return 6 * 3;
>   else
>   return 8 * 3;
> @@ -2379,7 +2379,7 @@ intel_dp_compute_link_config(struct intel_encoder 
> *encoder,
>   limits.min_lane_count = 1;
>   limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
>  
> - limits.min_bpp = intel_dp_min_bpp(pipe_config);
> + limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format);
>   limits.max_bpp = intel_dp_max_bpp(intel_dp, pipe_config);
>  
>   if (intel_dp_is_edp(intel_dp)) {
> @@ -2765,7 +2765,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   if (pipe_config->dsc.compression_enable)
>   output_bpp = pipe_config->dsc.compressed_bpp;
>   else
> - output_bpp = intel_dp_output_bpp(pipe_config, 
> pipe_config->pipe_bpp);
> + output_bpp = intel_dp_output_bpp(pipe_config->output_format,
> +  pipe_config->pipe_bpp);
>  
>   intel_link_compute_m_n(output_bpp,
>  pipe_config->lane_count,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 08a1c0aa8b94..a9580d1df35b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -10,6 +10,7 @@
>  
>  #include "i915_reg.h"
>  
> +enum intel_output_format;
>  enum pipe;
>  enum port;
>  struct drm_connector_state;
> @@ -35,7 +36,7 @@ void intel_dp_adjust_compliance_config(struct intel_dp 
> *intel_dp,
>  struct link_config_limits *limits);
>  bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
> -int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state);
> +int intel_dp_min_bpp(enum intel_output_format output_format);
>  bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
>  i915_reg_t dp_reg, enum port port,
>  enum pipe *pipe);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 64d885539e94..6a874b779b1f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -130,7 +130,7 @@ static int intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   limits.min_lane_count =
>   limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
>  
> - limits.min_bpp = 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Extract intel_dp_output_format()

[Navare, Manasi]

On Fri, Sep 18, 2020 at 12:43:33AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Refactor the output_format calculation into a helper so that
> we can reuse it for mode validation as well.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 32 +++--
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index bf1e9cf1c0f3..ad9b8b16fadb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -592,6 +592,22 @@ static u8 intel_dp_dsc_get_slice_count(struct intel_dp 
> *intel_dp,
>   return 0;
>  }
>  
> +static enum intel_output_format
> +intel_dp_output_format(struct drm_connector *connector,
> +const struct drm_display_mode *mode)
> +{
> + struct intel_dp *intel_dp = 
> intel_attached_dp(to_intel_connector(connector));
> + const struct drm_display_info *info = >display_info;
> +
> + if (!drm_mode_is_420_only(info, mode))
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
> + if (intel_dp->dfp.ycbcr_444_to_420)
> + return INTEL_OUTPUT_FORMAT_YCBCR444;
> + else
> + return INTEL_OUTPUT_FORMAT_YCBCR420;
> +}
> +
>  static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
> int hdisplay)
>  {
> @@ -2430,27 +2446,20 @@ intel_dp_compute_link_config(struct intel_encoder 
> *encoder,
>  }
>  
>  static int
> -intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
> -  struct intel_crtc_state *crtc_state,
> +intel_dp_ycbcr420_config(struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)
>  {
>   struct drm_connector *connector = conn_state->connector;
> - const struct drm_display_info *info = >display_info;
>   const struct drm_display_mode *adjusted_mode =
>   _state->hw.adjusted_mode;
>  
>   if (!connector->ycbcr_420_allowed)
>   return 0;
>  
> - if (!drm_mode_is_420_only(info, adjusted_mode))
> - return 0;
> + crtc_state->output_format = intel_dp_output_format(connector, 
> adjusted_mode);

So by default if its not 420_only then we set it to RGB?

Manasi

>  
> - if (intel_dp->dfp.ycbcr_444_to_420) {
> - crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
> + if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
>   return 0;
> - }
> -
> - crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
>  
>   return intel_pch_panel_fitting(crtc_state, conn_state);
>  }
> @@ -2710,8 +2719,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   if (lspcon->active)
>   lspcon_ycbcr420_config(_connector->base, pipe_config);
>   else
> - ret = intel_dp_ycbcr420_config(intel_dp, pipe_config,
> -conn_state);
> + ret = intel_dp_ycbcr420_config(pipe_config, conn_state);
>   if (ret)
>   return ret;
>  
> -- 
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 19/20] drm/i915: Complete the gamma/degamma state checking

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 19/20] drm/i915: Complete the gamma/degamma
> state checking
> 
> From: Ville Syrjälä 
> 
> Add new .gamma_equal() and .degamma_equal() vfuncs to be used by the state
> checker to verify the gamma/degamma LUTs. We need somewhat custom
> behaviour for some platforms due to sometimes swapping the roles of the
> gamma and degamma LUTs (due to RGB limited color range or YCbCr output CSC
> usage). Also glk has a special relationship between the CSC enable bit and the
> degamma LUT so it also needs customized behaviour.
> 
> We could pontially compute the state in a better way to make these state check
> hacks unnecessary, but that's going to require some actual thought so we'll 
> leave
> it for the future.

Like the idea of how the anomalies of various platforms are balanced.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c   | 435 +++
>  drivers/gpu/drm/i915/display/intel_color.h   |  10 +-
>  drivers/gpu/drm/i915/display/intel_display.c |  25 +-
>  drivers/gpu/drm/i915/i915_drv.h  |   7 +
>  4 files changed, 378 insertions(+), 99 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index f714c87d8e42..ca6c6679368c 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1628,26 +1628,71 @@ static int i9xx_gamma_precision(const struct
> intel_crtc_state *crtc_state)
>   }
>  }
> 
> +static bool ilk_crtc_has_degamma(const struct intel_crtc_state
> +*crtc_state) {
> + return crtc_state->gamma_enable &&
> + (crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0; }
> +
>  static bool ilk_crtc_has_gamma(const struct intel_crtc_state *crtc_state)  {
>   return crtc_state->gamma_enable &&
>   (crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) != 0;  }
> 
> +static int ilk_lut_precision(const struct intel_crtc_state *crtc_state)
> +{
> + switch (crtc_state->gamma_mode) {
> + case GAMMA_MODE_MODE_8BIT:
> + return 8;
> + case GAMMA_MODE_MODE_10BIT:
> + return 10;
> + default:
> + MISSING_CASE(crtc_state->gamma_mode);
> + return 0;
> + }
> +}
> +
> +static int ilk_degamma_precision(const struct intel_crtc_state
> +*crtc_state) {
> + if (ilk_crtc_has_degamma(crtc_state))
> + return ilk_lut_precision(crtc_state);
> + else
> + return 0;
> +}
> +
>  static int ilk_gamma_precision(const struct intel_crtc_state *crtc_state)  {
> - if (!ilk_crtc_has_gamma(crtc_state))
> + if (ilk_crtc_has_gamma(crtc_state))
> + return ilk_lut_precision(crtc_state);
> + else
>   return 0;
> +}
> 
> - switch (crtc_state->gamma_mode) {
> - case GAMMA_MODE_MODE_8BIT:
> - return 8;
> - case GAMMA_MODE_MODE_10BIT:
> +static int ivb_degamma_precision(const struct intel_crtc_state
> +*crtc_state) {
> + if (crtc_state->gamma_enable &&
> + crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)
>   return 10;
> - default:
> - MISSING_CASE(crtc_state->gamma_mode);
> + else
> + return ilk_degamma_precision(crtc_state);
> +}
> +
> +static int ivb_gamma_precision(const struct intel_crtc_state
> +*crtc_state) {
> + if (crtc_state->gamma_enable &&
> + crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)
> + return 10;
> + else
> + return ilk_gamma_precision(crtc_state); }
> +
> +static int chv_degamma_precision(const struct intel_crtc_state
> +*crtc_state) {
> + if (crtc_state->cgm_mode & CGM_PIPE_MODE_DEGAMMA)
> + return 14;
> + else
>   return 0;
> - }
>  }
> 
>  static int chv_gamma_precision(const struct intel_crtc_state *crtc_state) @@ 
> -
> 1658,20 +1703,20 @@ static int chv_gamma_precision(const struct
> intel_crtc_state *crtc_state)
>   return i9xx_gamma_precision(crtc_state);  }
> 
> +static int glk_degamma_precision(const struct intel_crtc_state
> +*crtc_state) {
> + if (crtc_state->csc_enable)
> + return 16;
> + else
> + return 0;
> +}
> +
>  static int glk_gamma_precision(const struct intel_crtc_state *crtc_state)  {
> - if (!crtc_state->gamma_enable)
> + if (crtc_state->gamma_enable)
> + return ilk_lut_precision(crtc_state);
> + else
>   return 0;
> -
> - switch (crtc_state->gamma_mode) {
> - case GAMMA_MODE_MODE_8BIT:
> - return 8;
> - case GAMMA_MODE_MODE_10BIT:
> - return 10;
> - default:
> - MISSING_CASE(crtc_state->gamma_mode);
> - return 0;
> - }
>  }
> 
>  static bool 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] drm/i915: Extract intel_dp_output_format()

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Extract intel_dp_output_format()
URL   : https://patchwork.freedesktop.org/series/81815/
State : failure

== Summary ==

Applying: drm/i915: Extract intel_dp_output_format()
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/display/intel_dp.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915: Extract intel_dp_output_format()
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

[Intel-gfx] [PATCH 1/3] drm/i915: Extract intel_dp_output_format()

[Ville Syrjala]

From: Ville Syrjälä 

Refactor the output_format calculation into a helper so that
we can reuse it for mode validation as well.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 32 +++--
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf1e9cf1c0f3..ad9b8b16fadb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -592,6 +592,22 @@ static u8 intel_dp_dsc_get_slice_count(struct intel_dp 
*intel_dp,
return 0;
 }
 
+static enum intel_output_format
+intel_dp_output_format(struct drm_connector *connector,
+  const struct drm_display_mode *mode)
+{
+   struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
+   const struct drm_display_info *info = >display_info;
+
+   if (!drm_mode_is_420_only(info, mode))
+   return INTEL_OUTPUT_FORMAT_RGB;
+
+   if (intel_dp->dfp.ycbcr_444_to_420)
+   return INTEL_OUTPUT_FORMAT_YCBCR444;
+   else
+   return INTEL_OUTPUT_FORMAT_YCBCR420;
+}
+
 static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
  int hdisplay)
 {
@@ -2430,27 +2446,20 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
 }
 
 static int
-intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
-struct intel_crtc_state *crtc_state,
+intel_dp_ycbcr420_config(struct intel_crtc_state *crtc_state,
 const struct drm_connector_state *conn_state)
 {
struct drm_connector *connector = conn_state->connector;
-   const struct drm_display_info *info = >display_info;
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
 
if (!connector->ycbcr_420_allowed)
return 0;
 
-   if (!drm_mode_is_420_only(info, adjusted_mode))
-   return 0;
+   crtc_state->output_format = intel_dp_output_format(connector, 
adjusted_mode);
 
-   if (intel_dp->dfp.ycbcr_444_to_420) {
-   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
+   if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
return 0;
-   }
-
-   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 
return intel_pch_panel_fitting(crtc_state, conn_state);
 }
@@ -2710,8 +2719,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
else
-   ret = intel_dp_ycbcr420_config(intel_dp, pipe_config,
-  conn_state);
+   ret = intel_dp_ycbcr420_config(pipe_config, conn_state);
if (ret)
return ret;
 
-- 
2.26.2

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

[Intel-gfx] [PATCH 2/3] drm/i915: Decouple intel_dp_{min, output}_bpp() from crtc_state

[Ville Syrjala]

From: Ville Syrjälä 

Pass the output_format directly to intel_dp_{min,output}_bpp()
rather than passing in the crtc_state and digging out the
output_format inside the functions. This will allow us to reuse
the functions for mode validation purposes.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 15 ---
 drivers/gpu/drm/i915/display/intel_dp.h |  3 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  2 +-
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index ad9b8b16fadb..aa4801a8123d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2111,14 +2111,14 @@ intel_dp_adjust_compliance_config(struct intel_dp 
*intel_dp,
}
 }
 
-static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, int 
bpp)
+static int intel_dp_output_bpp(enum intel_output_format output_format, int bpp)
 {
/*
 * bpp value was assumed to RGB format. And YCbCr 4:2:0 output
 * format of the number of bytes per pixel will be half the number
 * of bytes of RGB pixel.
 */
-   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
bpp /= 2;
 
return bpp;
@@ -2135,7 +2135,7 @@ intel_dp_compute_link_config_wide(struct intel_dp 
*intel_dp,
int mode_rate, link_clock, link_avail;
 
for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
-   int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
+   int output_bpp = 
intel_dp_output_bpp(pipe_config->output_format, bpp);
 
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
   output_bpp);
@@ -2346,9 +2346,9 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
return 0;
 }
 
-int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
+int intel_dp_min_bpp(enum intel_output_format output_format)
 {
-   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
+   if (output_format == INTEL_OUTPUT_FORMAT_RGB)
return 6 * 3;
else
return 8 * 3;
@@ -2379,7 +2379,7 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
limits.min_lane_count = 1;
limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
 
-   limits.min_bpp = intel_dp_min_bpp(pipe_config);
+   limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format);
limits.max_bpp = intel_dp_max_bpp(intel_dp, pipe_config);
 
if (intel_dp_is_edp(intel_dp)) {
@@ -2765,7 +2765,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (pipe_config->dsc.compression_enable)
output_bpp = pipe_config->dsc.compressed_bpp;
else
-   output_bpp = intel_dp_output_bpp(pipe_config, 
pipe_config->pipe_bpp);
+   output_bpp = intel_dp_output_bpp(pipe_config->output_format,
+pipe_config->pipe_bpp);
 
intel_link_compute_m_n(output_bpp,
   pipe_config->lane_count,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 08a1c0aa8b94..a9580d1df35b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -10,6 +10,7 @@
 
 #include "i915_reg.h"
 
+enum intel_output_format;
 enum pipe;
 enum port;
 struct drm_connector_state;
@@ -35,7 +36,7 @@ void intel_dp_adjust_compliance_config(struct intel_dp 
*intel_dp,
   struct link_config_limits *limits);
 bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
  const struct drm_connector_state *conn_state);
-int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state);
+int intel_dp_min_bpp(enum intel_output_format output_format);
 bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
   i915_reg_t dp_reg, enum port port,
   enum pipe *pipe);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 64d885539e94..6a874b779b1f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -130,7 +130,7 @@ static int intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
limits.min_lane_count =
limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
 
-   limits.min_bpp = intel_dp_min_bpp(pipe_config);
+   limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format);
/*
 * FIXME: If all the streams can't fit into the link with
 * their current pipe_bpp we should reduce pipe_bpp across
-- 
2.26.2

[Intel-gfx] [PATCH 3/3] drm/i915: Use the correct bpp when validating "4:2:0 only" modes

[Ville Syrjala]

From: Ville Syrjälä 

When validating a "YCbCr 4:2:0 only" mode we must take into
account the fact that we're going to be outputting YCbCr
4:2:0 or 4:4:4 (when a DP->HDMI protocol converter is doing
the 4:2:0 downsampling). For YCbCr 4:4:4 the minimum output
bpc is 8, for YCbCr 4:2:0 it'll be half that. The currently
hardcoded 6bpc is only correct for RGB 4:4:4, which we will
never use with these kinds of modes. Figure out what we're
going to output and use the correct min bpp value to validate
whether the link has sufficient bandwidth.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 55 +++--
 1 file changed, 33 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index aa4801a8123d..54a4b81ea3ff 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -608,6 +608,37 @@ intel_dp_output_format(struct drm_connector *connector,
return INTEL_OUTPUT_FORMAT_YCBCR420;
 }
 
+int intel_dp_min_bpp(enum intel_output_format output_format)
+{
+   if (output_format == INTEL_OUTPUT_FORMAT_RGB)
+   return 6 * 3;
+   else
+   return 8 * 3;
+}
+
+static int intel_dp_output_bpp(enum intel_output_format output_format, int bpp)
+{
+   /*
+* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
+* format of the number of bytes per pixel will be half the number
+* of bytes of RGB pixel.
+*/
+   if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   bpp /= 2;
+
+   return bpp;
+}
+
+static int
+intel_dp_mode_min_output_bpp(struct drm_connector *connector,
+const struct drm_display_mode *mode)
+{
+   enum intel_output_format output_format =
+   intel_dp_output_format(connector, mode);
+
+   return intel_dp_output_bpp(output_format, 
intel_dp_min_bpp(output_format));
+}
+
 static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
  int hdisplay)
 {
@@ -687,7 +718,8 @@ intel_dp_mode_valid(struct drm_connector *connector,
max_lanes = intel_dp_max_lane_count(intel_dp);
 
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
-   mode_rate = intel_dp_link_required(target_clock, 18);
+   mode_rate = intel_dp_link_required(target_clock,
+  
intel_dp_mode_min_output_bpp(connector, mode));
 
if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
return MODE_H_ILLEGAL;
@@ -2111,19 +2143,6 @@ intel_dp_adjust_compliance_config(struct intel_dp 
*intel_dp,
}
 }
 
-static int intel_dp_output_bpp(enum intel_output_format output_format, int bpp)
-{
-   /*
-* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
-* format of the number of bytes per pixel will be half the number
-* of bytes of RGB pixel.
-*/
-   if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
-   bpp /= 2;
-
-   return bpp;
-}
-
 /* Optimize link config in order: max bpp, min clock, min lanes */
 static int
 intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
@@ -2346,14 +2365,6 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
return 0;
 }
 
-int intel_dp_min_bpp(enum intel_output_format output_format)
-{
-   if (output_format == INTEL_OUTPUT_FORMAT_RGB)
-   return 6 * 3;
-   else
-   return 8 * 3;
-}
-
 static int
 intel_dp_compute_link_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config,
-- 
2.26.2

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

Re: [Intel-gfx] [PATCH 17/20] drm/i915: Make .read_luts() mandatory

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 17/20] drm/i915: Make .read_luts() mandatory
> 
> From: Ville Syrjälä 
> 
> Every platform now implemnts .read_luts(). Make it not optional.
Nit: Typo in implements.
With this,
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 7f9e26419b56..acf3d152edfe 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1215,8 +1215,7 @@ 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);
> + dev_priv->display.read_luts(crtc_state);
>  }
> 
>  static bool need_plane_update(struct intel_plane *plane,
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 13/20] drm/i915: Add gamma/degamm readout for ivb/hsw

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 13/20] drm/i915: Add gamma/degamm readout for

Typo in degamma.
With this fixed,
Reviewed-by: Uma Shankar 

> ivb/hsw
> 
> From: Ville Syrjälä 
> 
> We now have all the code necessary for gamma/degamma readout on ivb/hsw.
> Plug it all in.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 32 ++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 9f01fb316efa..886f3f0d873a 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1999,6 +1999,37 @@ static struct drm_property_blob
> *ivb_read_lut_10(struct intel_crtc *crtc,
>   return blob;
>  }
> 
> +static void ivb_read_luts(struct intel_crtc_state *crtc_state) {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_property_blob **blob =
> + crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA ?
> + _state->hw.gamma_lut : _state->hw.degamma_lut;
> +
> + if (!crtc_state->gamma_enable)
> + return;
> +
> + switch (crtc_state->gamma_mode) {
> + case GAMMA_MODE_MODE_8BIT:
> + *blob = ilk_read_lut_8(crtc);
> + break;
> + case GAMMA_MODE_MODE_SPLIT:
> + crtc_state->hw.degamma_lut =
> + ivb_read_lut_10(crtc, PAL_PREC_SPLIT_MODE |
> + PAL_PREC_INDEX_VALUE(0));
> + crtc_state->hw.gamma_lut =
> + ivb_read_lut_10(crtc, PAL_PREC_SPLIT_MODE |
> + PAL_PREC_INDEX_VALUE(512));
> + break;
> + case GAMMA_MODE_MODE_10BIT:
> + *blob = ivb_read_lut_10(crtc, PAL_PREC_INDEX_VALUE(0));
> + break;
> + default:
> + MISSING_CASE(crtc_state->gamma_mode);
> + break;
> + }
> +}
> +
>  /* On BDW+ the index auto increment mode actually works */  static struct
> drm_property_blob *bdw_read_lut_10(struct intel_crtc *crtc,
>u32 prec_index)
> @@ -2236,6 +2267,7 @@ void intel_color_init(struct intel_crtc *crtc)
>   dev_priv->display.read_luts = bdw_read_luts;
>   } else if (INTEL_GEN(dev_priv) >= 7) {
>   dev_priv->display.load_luts = ivb_load_luts;
> + dev_priv->display.read_luts = ivb_read_luts;
>   } else {
>   dev_priv->display.load_luts = ilk_load_luts;
>   dev_priv->display.read_luts = ilk_read_luts;
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 18/20] drm/i915: Extract ilk_crtc_has_gamma() & co.

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 18/20] drm/i915: Extract ilk_crtc_has_gamma() & 
> co.
> 
> From: Ville Syrjälä 
> 
> Extract a few helpers to check whether the hw degamma or gamma LUT is
> enabled.

Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 27 --
>  1 file changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index acf3d152edfe..f714c87d8e42 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1628,12 +1628,15 @@ static int i9xx_gamma_precision(const struct
> intel_crtc_state *crtc_state)
>   }
>  }
> 
> +static bool ilk_crtc_has_gamma(const struct intel_crtc_state
> +*crtc_state) {
> + return crtc_state->gamma_enable &&
> + (crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) != 0; }
> +
>  static int ilk_gamma_precision(const struct intel_crtc_state *crtc_state)  {
> - if (!crtc_state->gamma_enable)
> - return 0;
> -
> - if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
> + if (!ilk_crtc_has_gamma(crtc_state))
>   return 0;
> 
>   switch (crtc_state->gamma_mode) {
> @@ -1671,9 +1674,19 @@ static int glk_gamma_precision(const struct
> intel_crtc_state *crtc_state)
>   }
>  }
> 
> +static bool icl_crtc_has_degamma(const struct intel_crtc_state
> +*crtc_state) {
> + return crtc_state->gamma_mode & PRE_CSC_GAMMA_ENABLE; }
> +
> +static bool icl_crtc_has_gamma(const struct intel_crtc_state
> +*crtc_state) {
> + return crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE; }
> +
>  static int icl_gamma_precision(const struct intel_crtc_state *crtc_state)  {
> - if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
> + if (!icl_crtc_has_gamma(crtc_state))
>   return 0;
> 
>   switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
> @@ -2241,10 +2254,10 @@ static void icl_read_luts(struct intel_crtc_state
> *crtc_state)  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> 
> - if (crtc_state->gamma_mode & PRE_CSC_GAMMA_ENABLE)
> + if (icl_crtc_has_degamma(crtc_state))
>   crtc_state->hw.degamma_lut = glk_read_degamma_lut(crtc);
> 
> - if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
> + if (!icl_crtc_has_gamma(crtc_state))
>   return;
> 
>   switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/20] drm/i915: Polish bdw_read_lut_10() a bit

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 12/20] drm/i915: Polish bdw_read_lut_10() a bit
> 
> From: Ville Syrjälä 
> 
> Since bdw_read_lut_10() uses the auto-increment mode we must have an equal
> number of entries in the software LUT and the hardware LUT. WARN if that is
> not the case.

Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index f34257922e4d..9f01fb316efa 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2005,12 +2005,15 @@ static struct drm_property_blob
> *bdw_read_lut_10(struct intel_crtc *crtc,  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   int i, hw_lut_size = ivb_lut_10_size(prec_index);
> + int lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>   enum pipe pipe = crtc->pipe;
>   struct drm_property_blob *blob;
>   struct drm_color_lut *lut;
> 
> + drm_WARN_ON(_priv->drm, lut_size != hw_lut_size);
> +
>   blob = drm_property_create_blob(_priv->drm,
> - sizeof(struct drm_color_lut) *
> hw_lut_size,
> + sizeof(struct drm_color_lut) * lut_size,
>   NULL);
>   if (IS_ERR(blob))
>   return NULL;
> @@ -2020,7 +2023,7 @@ static struct drm_property_blob
> *bdw_read_lut_10(struct intel_crtc *crtc,
>   intel_de_write(dev_priv, PREC_PAL_INDEX(pipe),
>  prec_index | PAL_PREC_AUTO_INCREMENT);
> 
> - for (i = 0; i < hw_lut_size; i++) {
> + for (i = 0; i < lut_size; i++) {
>   u32 val = intel_de_read(dev_priv, PREC_PAL_DATA(pipe));
> 
>   ilk_lut_10_pack([i], val);
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/20] drm/i915: Make ilk_read_luts() capable of degamma readout

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 16/20] drm/i915: Make ilk_read_luts() capable of
> degamma readout
> 
> From: Ville Syrjälä 
> 
> Just like ivb+, ilk/snb can select whether the hw lut acts as gamma or 
> degamma.
> Make the readout cognizant of that fact.

Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 12a41fb4a98c..7f9e26419b56 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1977,19 +1977,19 @@ static struct drm_property_blob
> *ilk_read_lut_10(struct intel_crtc *crtc)  static void ilk_read_luts(struct
> intel_crtc_state *crtc_state)  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_property_blob **blob =
> + crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA ?
> + _state->hw.gamma_lut : _state->hw.degamma_lut;
> 
>   if (!crtc_state->gamma_enable)
>   return;
> 
> - if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
> - return;
> -
>   switch (crtc_state->gamma_mode) {
>   case GAMMA_MODE_MODE_8BIT:
> - crtc_state->hw.gamma_lut = ilk_read_lut_8(crtc);
> + *blob = ilk_read_lut_8(crtc);
>   break;
>   case GAMMA_MODE_MODE_10BIT:
> - crtc_state->hw.gamma_lut = ilk_read_lut_10(crtc);
> + *blob = ilk_read_lut_10(crtc);
>   break;
>   default:
>   MISSING_CASE(crtc_state->gamma_mode);
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/20] drm/i915: Make ilk_load_luts() deal with degamma

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 15/20] drm/i915: Make ilk_load_luts() deal with
> degamma
> 
> From: Ville Syrjälä 
> 
> Make ilk_load_luts() ready for a degamma lut. Currently we never have one, but
> soon we may get one from readout, and I think we may want to change the state
> computation such that we may end up with one even when userspace has simply
> supplied a gamma lut.
> 
> At least the code now follows the path laid out by the ivb/bdw counterpars.

Sounds good.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index d5ce58c3bc11..12a41fb4a98c 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -637,13 +637,15 @@ static void ilk_load_luts(const struct intel_crtc_state
> *crtc_state)  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   const struct drm_property_blob *gamma_lut = crtc_state-
> >hw.gamma_lut;
> + const struct drm_property_blob *degamma_lut = crtc_state-
> >hw.degamma_lut;
> + const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
> 
>   switch (crtc_state->gamma_mode) {
>   case GAMMA_MODE_MODE_8BIT:
> - ilk_load_lut_8(crtc, gamma_lut);
> + ilk_load_lut_8(crtc, blob);
>   break;
>   case GAMMA_MODE_MODE_10BIT:
> - ilk_load_lut_10(crtc, gamma_lut);
> + ilk_load_lut_10(crtc, blob);
>   break;
>   default:
>   MISSING_CASE(crtc_state->gamma_mode);
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 14/20] drm/i915: Replace some gamma_mode ifs with switches

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 14/20] drm/i915: Replace some gamma_mode ifs with
> switches
> 
> From: Ville Syrjälä 
> 
> Since gamma_mode can have more than two values on ilk+ let's use switch
> statemnts when interpreting them.

Nit: Typo in statements
With this fixed,
Reviewed-by: Uma Shankar 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 93 --
>  1 file changed, 70 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 886f3f0d873a..d5ce58c3bc11 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -638,10 +638,17 @@ static void ilk_load_luts(const struct intel_crtc_state
> *crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   const struct drm_property_blob *gamma_lut = crtc_state-
> >hw.gamma_lut;
> 
> - if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
> + switch (crtc_state->gamma_mode) {
> + case GAMMA_MODE_MODE_8BIT:
>   ilk_load_lut_8(crtc, gamma_lut);
> - else
> + break;
> + case GAMMA_MODE_MODE_10BIT:
>   ilk_load_lut_10(crtc, gamma_lut);
> + break;
> + default:
> + MISSING_CASE(crtc_state->gamma_mode);
> + break;
> + }
>  }
> 
>  static int ivb_lut_10_size(u32 prec_index) @@ -745,21 +752,27 @@ static void
> ivb_load_luts(const struct intel_crtc_state *crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   const struct drm_property_blob *gamma_lut = crtc_state-
> >hw.gamma_lut;
>   const struct drm_property_blob *degamma_lut = crtc_state-
> >hw.degamma_lut;
> + const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
> 
> - if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
> - ilk_load_lut_8(crtc, gamma_lut);
> - } else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) {
> + switch (crtc_state->gamma_mode) {
> + case GAMMA_MODE_MODE_8BIT:
> + ilk_load_lut_8(crtc, blob);
> + break;
> + case GAMMA_MODE_MODE_SPLIT:
>   ivb_load_lut_10(crtc, degamma_lut, PAL_PREC_SPLIT_MODE |
>   PAL_PREC_INDEX_VALUE(0));
>   ivb_load_lut_ext_max(crtc_state);
>   ivb_load_lut_10(crtc, gamma_lut, PAL_PREC_SPLIT_MODE |
>   PAL_PREC_INDEX_VALUE(512));
> - } else {
> - const struct drm_property_blob *blob = gamma_lut ?:
> degamma_lut;
> -
> + break;
> + case GAMMA_MODE_MODE_10BIT:
>   ivb_load_lut_10(crtc, blob,
>   PAL_PREC_INDEX_VALUE(0));
>   ivb_load_lut_ext_max(crtc_state);
> + break;
> + default:
> + MISSING_CASE(crtc_state->gamma_mode);
> + break;
>   }
>  }
> 
> @@ -768,21 +781,27 @@ static void bdw_load_luts(const struct intel_crtc_state
> *crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   const struct drm_property_blob *gamma_lut = crtc_state-
> >hw.gamma_lut;
>   const struct drm_property_blob *degamma_lut = crtc_state-
> >hw.degamma_lut;
> + const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
> 
> - if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
> - ilk_load_lut_8(crtc, gamma_lut);
> - } else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) {
> + switch (crtc_state->gamma_mode) {
> + case GAMMA_MODE_MODE_8BIT:
> + ilk_load_lut_8(crtc, blob);
> + break;
> + case GAMMA_MODE_MODE_SPLIT:
>   bdw_load_lut_10(crtc, degamma_lut, PAL_PREC_SPLIT_MODE |
>   PAL_PREC_INDEX_VALUE(0));
>   ivb_load_lut_ext_max(crtc_state);
>   bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_SPLIT_MODE |
>   PAL_PREC_INDEX_VALUE(512));
> - } else {
> - const struct drm_property_blob *blob = gamma_lut ?:
> degamma_lut;
> -
> + break;
> + case GAMMA_MODE_MODE_10BIT:
>   bdw_load_lut_10(crtc, blob,
>   PAL_PREC_INDEX_VALUE(0));
>   ivb_load_lut_ext_max(crtc_state);
> + break;
> + default:
> + MISSING_CASE(crtc_state->gamma_mode);
> + break;
>   }
>  }
> 
> @@ -875,11 +894,17 @@ static void glk_load_luts(const struct intel_crtc_state
> *crtc_state)
>   else
>   glk_load_degamma_lut_linear(crtc_state);
> 
> - if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
> + switch (crtc_state->gamma_mode) {
> + case GAMMA_MODE_MODE_8BIT:
> 

Re: [Intel-gfx] [PATCH 11/20] drm/i915: Do degamma+gamma readout in bdw+ split gamma mode

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 11/20] drm/i915: Do degamma+gamma readout in
> bdw+ split gamma mode
> 
> From: Ville Syrjälä 
> 
> Read out both gamma and degamma when usng the split gamma mode on

s/usng/using
With this,
Reviewed-by: Uma Shankar 

> bdw+. We can't use the auto increment mode to iterate the LUTs since we want
> to read out less entries than what we stuff into the software LUT.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 52 +-
>  1 file changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 5742ac1af862..f34257922e4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1959,6 +1959,46 @@ static void ilk_read_luts(struct intel_crtc_state
> *crtc_state)
>   crtc_state->hw.gamma_lut = ilk_read_lut_10(crtc);  }
> 
> +/*
> + * IVB/HSW Bspec / PAL_PREC_INDEX:
> + * "Restriction : Index auto increment mode is not
> + *  supported and must not be enabled."
> + */
> +static struct drm_property_blob *ivb_read_lut_10(struct intel_crtc *crtc,
> +  u32 prec_index)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + int i, hw_lut_size = ivb_lut_10_size(prec_index);
> + int lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
> + enum pipe pipe = crtc->pipe;
> + struct drm_property_blob *blob;
> + struct drm_color_lut *lut;/
> +
> + blob = drm_property_create_blob(_priv->drm,
> + sizeof(struct drm_color_lut) * lut_size,
> + NULL);
> + if (IS_ERR(blob))
> + return NULL;
> +
> + lut = blob->data;
> +
> + for (i = 0; i < lut_size; i++) {
> + /* We discard half the user entries in split gamma mode */
> + int index = DIV_ROUND_UP(i * (hw_lut_size - 1), lut_size - 1);
> + u32 val;
> +
> + intel_de_write(dev_priv, PREC_PAL_INDEX(pipe),
> +prec_index + index);
> + val = intel_de_read(dev_priv, PREC_PAL_DATA(pipe));
> +
> + ilk_lut_10_pack([i], val);
> + }
> +
> + intel_de_write(dev_priv, PREC_PAL_INDEX(pipe), 0);
> +
> + return blob;
> +}
> +
>  /* On BDW+ the index auto increment mode actually works */  static struct
> drm_property_blob *bdw_read_lut_10(struct intel_crtc *crtc,
>u32 prec_index)
> @@ -2006,7 +2046,17 @@ static void bdw_read_luts(struct intel_crtc_state
> *crtc_state)
>   *blob = ilk_read_lut_8(crtc);
>   break;
>   case GAMMA_MODE_MODE_SPLIT:
> - /* FIXME */
> + /*
> +  * Can't use bdw_read_lut_10() with its auto-increment
> +  * mode here since we want to generate 1024 entry
> +  * software LUTs from the 512 entry hardware LUTs.
> +  */
> + crtc_state->hw.degamma_lut =
> + ivb_read_lut_10(crtc, PAL_PREC_SPLIT_MODE |
> + PAL_PREC_INDEX_VALUE(0));
> + crtc_state->hw.gamma_lut =
> + ivb_read_lut_10(crtc, PAL_PREC_SPLIT_MODE |
> + PAL_PREC_INDEX_VALUE(512));
>   break;
>   case GAMMA_MODE_MODE_10BIT:
>   *blob = bdw_read_lut_10(crtc, PAL_PREC_INDEX_VALUE(0));
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/20] drm/i915: Add gamma/degamma readout for bdw+

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 10/20] drm/i915: Add gamma/degamma readout for
> bdw+
> 
> From: Ville Syrjälä 
> 
> Read out the gamme/degamma LUT on bdw+. Not entirely complete as we need

s/gamme/gamma
With this,
Reviewed-by: Uma Shankar 

> a bit more special sauce to handle the split gamma mode.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 27 ++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 6842f5c0356d..5742ac1af862 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1991,6 +1991,32 @@ static struct drm_property_blob
> *bdw_read_lut_10(struct intel_crtc *crtc,
>   return blob;
>  }
> 
> +static void bdw_read_luts(struct intel_crtc_state *crtc_state) {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_property_blob **blob =
> + crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA ?
> + _state->hw.gamma_lut : _state->hw.degamma_lut;
> +
> + if (!crtc_state->gamma_enable)
> + return;
> +
> + switch (crtc_state->gamma_mode) {
> + case GAMMA_MODE_MODE_8BIT:
> + *blob = ilk_read_lut_8(crtc);
> + break;
> + case GAMMA_MODE_MODE_SPLIT:
> + /* FIXME */
> + break;
> + case GAMMA_MODE_MODE_10BIT:
> + *blob = bdw_read_lut_10(crtc, PAL_PREC_INDEX_VALUE(0));
> + break;
> + default:
> + MISSING_CASE(crtc_state->gamma_mode);
> + break;
> + }
> +}
> +
>  static struct drm_property_blob *glk_read_degamma_lut(struct intel_crtc 
> *crtc)
> {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -2154,6
> +2180,7 @@ void intel_color_init(struct intel_crtc *crtc)
>   dev_priv->display.read_luts = glk_read_luts;
>   } else if (INTEL_GEN(dev_priv) >= 8) {
>   dev_priv->display.load_luts = bdw_load_luts;
> + dev_priv->display.read_luts = bdw_read_luts;
>   } else if (INTEL_GEN(dev_priv) >= 7) {
>   dev_priv->display.load_luts = ivb_load_luts;
>   } else {
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Ville Syrjälä]

On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > interpretation and 1 that use MSB.
> 
> "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> is cleared to 0, only the 8 MSB of the brightness control value can be
> controlled.
> (See Note below.)
> Assigned bits are allocated to the MSB of the enabled register
> combination."
> 
> I think that's pretty clear the assigned bits are supposed to be
> msb aligned.

I guess there's some email issues happening, but just to clarify:

When the spec says MSB in caps here it clearly means
"most significant-bit(s)" since otherwise "8 MSB" would not make
any sense in the context of a 2 byte value.

Granted the spec is crap here since "Table 1-1: Acronyms and
Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).

Also I can't imagine anyone would allocate the bits starting
from the lsb when the whole thing is clearly supposed to be a
16bit big endian integer. So with >8 assigned bits you'd end
up with crazy stuff like this:

[ 7 ... 0 ][7   ...   0]
[ 8 MSB   ][][N LSB]

so you couldn't even treat the value as a regular big endian
thing. Instead, if you squint a bit, it now looks like a funky
little endian value. So we're deep into some mixed endian land
where nothing makes sense anymore.

Anyways I think the code should simply do this to match the spec:
u16 value = brightness << (16 - num_assigned_bits);
val[0] = value >> 8;
val[1] = value & 0xff;


> 
> > 
> > 
> > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski  wrote:
> > >
> > > Apologies for being too vague. To be as precise I can be, here is the
> > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > your other question, the code I tested against is indeed including the
> > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > message): our current top-of-tree for our 5.4 branch includes the
> > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > is exactly the change which breaks my Pixelbook model: prior to the
> > > change, the max_brightness was hard-coded to 0x and the math
> > > worked out that it didn't matter that the hardware cared about the MSB
> > > despite the driver code caring about the LSB.
> > >
> > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > need a quirk at least for some laptop. Reading through the copy of the
> > > datasheet I have, it wasn't clear to me which was the correct
> > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > kernel code (caring about LSB) being the correct interpretation. I
> > > believe we have other chromebooks which do rely on LSB functionality,
> > > so unless we can find more examples of laptops wanting MSB it
> > > currently looks like Pixelbook is the outlier.
> > >
> > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > >  wrote:
> > > >
> > > > On Thu, 17 Sep 2020, Kevin Chowski  wrote:
> > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > interpretting these backlight bits from the most-significant side of 
> > > > > the
> > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > assumes the peripheral cares about the least-significant bits.
> > > > >
> > > > > Testing was done from within Chrome OS's build environment when the
> > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > Pixelbook); for the record:
> > > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > >   ./update_kernel.sh --remote=$IP
> > > > >
> > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to 
> > > > > verify
> > > > > that the registers were being set according to what the actual 
> > > > > hardware
> > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > this patch.
> > > >
> > > > It's unclear to me what kernel version this is against, and what you've
> > > > actually tested.
> > > >
> > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > DPCD aux max backlight calculations")?
> > > >
> > > > I just want to make sure you've tested with all the relevant fixes
> > > > before adding quirks.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > >
> > > > > Signed-off-by: Kevin Chowski 
> > > > > ---
> > > > >
> > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 
> > > > > +++
> > > > >  

Re: [Intel-gfx] [PATCH 09/20] drm/i915: Read out CHV CGM degamma

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 09/20] drm/i915: Read out CHV CGM degamma
> 
> From: Ville Syrjälä 
> 
> Since CHV has the dedicate CGM degamma unit readout is trivial.
> Just do it.

Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 36 ++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 437cc56925ab..6842f5c0356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1030,6 +1030,13 @@ static u32 chv_cgm_degamma_udw(const struct
> drm_color_lut *color)
>   return drm_color_lut_extract(color->red, 14);  }
> 
> +static void chv_cgm_degamma_pack(struct drm_color_lut *entry, u32 ldw,
> +u32 udw) {
> + entry->green =
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_GREEN_MASK, ldw),
> 14);
> + entry->blue =
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_BLUE_MASK, ldw),
> 14);
> + entry->red =
> +intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_RED_MASK, udw),
> +14); }
> +
>  static void chv_load_cgm_degamma(struct intel_crtc *crtc,
>const struct drm_property_blob *blob)  { @@ -
> 1821,6 +1828,32 @@ static void i965_read_luts(struct intel_crtc_state
> *crtc_state)
>   crtc_state->hw.gamma_lut = i965_read_lut_10p6(crtc);  }
> 
> +static struct drm_property_blob *chv_read_cgm_degamma(struct intel_crtc
> +*crtc) {
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + int i, lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> + enum pipe pipe = crtc->pipe;
> + struct drm_property_blob *blob;
> + struct drm_color_lut *lut;
> +
> + blob = drm_property_create_blob(_priv->drm,
> + sizeof(struct drm_color_lut) * lut_size,
> + NULL);
> + if (IS_ERR(blob))
> + return NULL;
> +
> + lut = blob->data;
> +
> + for (i = 0; i < lut_size; i++) {
> + u32 ldw = intel_de_read(dev_priv, CGM_PIPE_DEGAMMA(pipe, i,
> 0));
> + u32 udw = intel_de_read(dev_priv, CGM_PIPE_DEGAMMA(pipe, i,
> 1));
> +
> + chv_cgm_degamma_pack([i], ldw, udw);
> + }
> +
> + return blob;
> +}
> +
>  static struct drm_property_blob *chv_read_cgm_gamma(struct intel_crtc *crtc)
> {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1851,6
> +1884,9 @@ static void chv_read_luts(struct intel_crtc_state *crtc_state)  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> 
> + if (crtc_state->cgm_mode & CGM_PIPE_MODE_DEGAMMA)
> + crtc_state->hw.degamma_lut = chv_read_cgm_degamma(crtc);
> +
>   if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
>   crtc_state->hw.gamma_lut = chv_read_cgm_gamma(crtc);
>   else
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/20] drm/i915: Add glk+ degamma readout

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 08/20] drm/i915: Add glk+ degamma readout
> 
> From: Ville Syrjälä 
> 
> Read out the degamma LUT on glk+. No state cheker as of yet since it requires
> dealing with he glk csc vs. degamma mess.

s/he/the
With this,
Reviewed-by: Uma Shankar 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 44 ++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 260bbbd5bbf2..437cc56925ab 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1955,10 +1955,51 @@ static struct drm_property_blob
> *bdw_read_lut_10(struct intel_crtc *crtc,
>   return blob;
>  }
> 
> +static struct drm_property_blob *glk_read_degamma_lut(struct intel_crtc
> +*crtc) {
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + int i, lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> + enum pipe pipe = crtc->pipe;
> + struct drm_property_blob *blob;
> + struct drm_color_lut *lut;
> +
> + blob = drm_property_create_blob(_priv->drm,
> + sizeof(struct drm_color_lut) * lut_size,
> + NULL);
> + if (IS_ERR(blob))
> + return NULL;
> +
> + lut = blob->data;
> +
> + /*
> +  * When setting the auto-increment bit, the hardware seems to
> +  * ignore the index bits, so we need to reset it to index 0
> +  * separately.
> +  */
> + intel_de_write(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
> + intel_de_write(dev_priv, PRE_CSC_GAMC_INDEX(pipe),
> +PRE_CSC_GAMC_AUTO_INCREMENT);
> +
> + for (i = 0; i < lut_size; i++) {
> + u32 val = intel_de_read(dev_priv, PRE_CSC_GAMC_DATA(pipe));
> +
> + lut[i].red = val;
> + lut[i].green = val;
> + lut[i].blue = val;
> + }
> +
> + intel_de_write(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
> +
> + return blob;
> +}
> +
>  static void glk_read_luts(struct intel_crtc_state *crtc_state)  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> 
> + if (crtc_state->csc_enable)
> + crtc_state->hw.degamma_lut = glk_read_degamma_lut(crtc);
> +
>   if (!crtc_state->gamma_enable)
>   return;
> 
> @@ -2010,6 +2051,9 @@ static void icl_read_luts(struct intel_crtc_state
> *crtc_state)  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> 
> + if (crtc_state->gamma_mode & PRE_CSC_GAMMA_ENABLE)
> + crtc_state->hw.degamma_lut = glk_read_degamma_lut(crtc);
> +
>   if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
>   return;
> 
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/20] drm/i915: Relocate CHV CGM gamma masks

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 07/20] drm/i915: Relocate CHV CGM gamma masks
> 
> From: Ville Syrjälä 
> 
> CGM_PIPE_GAMMA_RED_MASK & co. are misplaced. Move then below the
> relevant register. And while at it add the degamma counterparts.

Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b9607ac3620d..428ef06b8084 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10999,14 +10999,17 @@ enum skl_power_gate {
>  #define _CGM_PIPE_A_CSC_COEFF67  (VLV_DISPLAY_BASE + 0x6790C)
>  #define _CGM_PIPE_A_CSC_COEFF8   (VLV_DISPLAY_BASE + 0x67910)
>  #define _CGM_PIPE_A_DEGAMMA  (VLV_DISPLAY_BASE + 0x66000)
> +#define   CGM_PIPE_DEGAMMA_RED_MASK  REG_GENMASK(13, 0)
> +#define   CGM_PIPE_DEGAMMA_GREEN_MASKREG_GENMASK(29, 16)
> +#define   CGM_PIPE_DEGAMMA_BLUE_MASK REG_GENMASK(13, 0)
>  #define _CGM_PIPE_A_GAMMA(VLV_DISPLAY_BASE + 0x67000)
> +#define   CGM_PIPE_GAMMA_RED_MASKREG_GENMASK(9, 0)
> +#define   CGM_PIPE_GAMMA_GREEN_MASK  REG_GENMASK(25, 16)
> +#define   CGM_PIPE_GAMMA_BLUE_MASK   REG_GENMASK(9, 0)
>  #define _CGM_PIPE_A_MODE (VLV_DISPLAY_BASE + 0x67A00)
>  #define   CGM_PIPE_MODE_GAMMA(1 << 2)
>  #define   CGM_PIPE_MODE_CSC  (1 << 1)
>  #define   CGM_PIPE_MODE_DEGAMMA  (1 << 0)
> -#define   CGM_PIPE_GAMMA_RED_MASK   REG_GENMASK(9, 0)
> -#define   CGM_PIPE_GAMMA_GREEN_MASK REG_GENMASK(25, 16)
> -#define   CGM_PIPE_GAMMA_BLUE_MASK  REG_GENMASK(9, 0)
> 
>  #define _CGM_PIPE_B_CSC_COEFF01  (VLV_DISPLAY_BASE + 0x69900)
>  #define _CGM_PIPE_B_CSC_COEFF23  (VLV_DISPLAY_BASE + 0x69904)
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Introduce quirk for shifting eDP brightness.

[Patchwork]

== Series Details ==

Series: i915: Introduce quirk for shifting eDP brightness.
URL   : https://patchwork.freedesktop.org/series/81809/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9022_full -> Patchwork_18521_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18521_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18521_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_18521_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@2x-plain-flip-interruptible:
- shard-hsw:  NOTRUN -> [INCOMPLETE][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-hsw4/igt@kms_f...@2x-plain-flip-interruptible.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_create@forked:
- shard-glk:  [PASS][2] -> [DMESG-WARN][3] ([i915#118] / [i915#95])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-glk6/igt@gem_exec_cre...@forked.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-glk4/igt@gem_exec_cre...@forked.html

  * igt@gem_exec_reloc@basic-many-active@vcs0:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#2389])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-glk6/igt@gem_exec_reloc@basic-many-act...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-glk4/igt@gem_exec_reloc@basic-many-act...@vcs0.html

  * igt@gem_mmap_offset@blt-coherency:
- shard-apl:  [PASS][6] -> [FAIL][7] ([i915#1635])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-apl7/igt@gem_mmap_off...@blt-coherency.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-apl2/igt@gem_mmap_off...@blt-coherency.html

  * igt@gem_userptr_blits@sync-unmap-cycles:
- shard-skl:  [PASS][8] -> [TIMEOUT][9] ([i915#1958] / [i915#2424])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-skl5/igt@gem_userptr_bl...@sync-unmap-cycles.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-skl6/igt@gem_userptr_bl...@sync-unmap-cycles.html

  * igt@i915_pm_rpm@fences-dpms:
- shard-apl:  [PASS][10] -> [DMESG-WARN][11] ([i915#1635] / 
[i915#1982])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-apl8/igt@i915_pm_...@fences-dpms.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-apl7/igt@i915_pm_...@fences-dpms.html

  * igt@i915_selftest@mock@contexts:
- shard-apl:  [PASS][12] -> [INCOMPLETE][13] ([i915#1635] / 
[i915#2278])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-apl6/igt@i915_selftest@m...@contexts.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-apl3/igt@i915_selftest@m...@contexts.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- shard-skl:  [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) +4 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-skl9/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-skl9/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl:  [PASS][16] -> [FAIL][17] ([i915#2346])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-skl8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_flip@2x-flip-vs-blocking-wf-vblank@ab-vga1-hdmi-a1:
- shard-hsw:  [PASS][18] -> [DMESG-WARN][19] ([i915#1982])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-hsw8/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-hsw6/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#79])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html

  * 

Re: [Intel-gfx] [PATCH 06/20] drm/i915: Shuffle chv_cgm_gamma_pack() around a bit

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/20] drm/i915: Shuffle chv_cgm_gamma_pack()
> around a bit
> 
> From: Ville Syrjälä 
> 
> Move chv_cgm_gamma_pack() next to the other CGM gamma functions.
> Right now it's stuck in the middle of the CGM degamma functions.

Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 37a4fede7bc0..260bbbd5bbf2 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1030,13 +1030,6 @@ static u32 chv_cgm_degamma_udw(const struct
> drm_color_lut *color)
>   return drm_color_lut_extract(color->red, 14);  }
> 
> -static void chv_cgm_gamma_pack(struct drm_color_lut *entry, u32 ldw, u32
> udw) -{
> - entry->green =
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, ldw),
> 10);
> - entry->blue =
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, ldw), 10);
> - entry->red =
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, udw), 10);
> -}
> -
>  static void chv_load_cgm_degamma(struct intel_crtc *crtc,
>const struct drm_property_blob *blob)  { @@ -
> 1064,6 +1057,13 @@ static u32 chv_cgm_gamma_udw(const struct
> drm_color_lut *color)
>   return drm_color_lut_extract(color->red, 10);  }
> 
> +static void chv_cgm_gamma_pack(struct drm_color_lut *entry, u32 ldw,
> +u32 udw) {
> + entry->green =
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, ldw),
> 10);
> + entry->blue =
> intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, ldw), 10);
> + entry->red =
> +intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, udw),
> 10);
> +}
> +
>  static void chv_load_cgm_gamma(struct intel_crtc *crtc,
>  const struct drm_property_blob *blob)  {
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

[Jacob Keller]

On 9/9/2020 1:55 PM, Keith Busch wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
>> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
>> index eea0f453cfb6..8aac5bc60f4c 100644
>> --- a/crypto/tcrypt.c
>> +++ b/crypto/tcrypt.c
>> @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32 
>> mask, int m, u32 num_mb)
>>  test_hash_speed("streebog512", sec,
>>  generic_hash_speed_template);
>>  if (mode > 300 && mode < 400) break;
>> -fallthrough;
>> +break;
>>  case 399:
>>  break;
> 
> Just imho, this change makes the preceding 'if' look even more
> pointless. Maybe the fallthrough was a deliberate choice? Not that my
> opinion matters here as I don't know this module, but it looked a bit
> odd to me.
> 

Yea this does look very odd..
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/20] drm/i915: Reset glk degamma index after programming/readout

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/20] drm/i915: Reset glk degamma index after
> programming/readout
> 
> From: Ville Syrjälä 
> 
> Just for some extra consistency let's reset the glk degamma LUT index back to > 0
> after we're dong trawling the LUT.

We do set this to 0 in the beginning, but I think good to leave in a clean 
state.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 77c103a86a30..37a4fede7bc0 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -818,12 +818,14 @@ static void glk_load_degamma_lut(const struct
> intel_crtc_state *crtc_state)
>* as compared to just 16 to achieve this.
>*/
>   intel_de_write(dev_priv, PRE_CSC_GAMC_DATA(pipe),
> -lut[i].green);
> +lut[i].green);
>   }
> 
>   /* Clamp values > 1.0. */
>   while (i++ < 35)
>   intel_de_write(dev_priv, PRE_CSC_GAMC_DATA(pipe), 1 << 16);
> +
> + intel_de_write(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
>  }
> 
>  static void glk_load_degamma_lut_linear(const struct intel_crtc_state
> *crtc_state) @@ -851,6 +853,8 @@ static void
> glk_load_degamma_lut_linear(const struct intel_crtc_state *crtc_stat
>   /* Clamp values > 1.0. */
>   while (i++ < 35)
>   intel_de_write(dev_priv, PRE_CSC_GAMC_DATA(pipe), 1 << 16);
> +
> + intel_de_write(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
>  }
> 
>  static void glk_load_luts(const struct intel_crtc_state *crtc_state)
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/20] drm/i915: s/glk_read_lut_10/bdw_read_lut_10/

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/20] drm/i915:
> s/glk_read_lut_10/bdw_read_lut_10/
> 
> From: Ville Syrjälä 
> 
> glk_read_lut_10() works just find for all bdw+ platforms, so rename it.

Reviewed-by: Uma Shankar 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 945bb03bdd4d..77c103a86a30 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1919,7 +1919,8 @@ static void ilk_read_luts(struct intel_crtc_state
> *crtc_state)
>   crtc_state->hw.gamma_lut = ilk_read_lut_10(crtc);  }
> 
> -static struct drm_property_blob *glk_read_lut_10(struct intel_crtc *crtc,
> +/* On BDW+ the index auto increment mode actually works */ static
> +struct drm_property_blob *bdw_read_lut_10(struct intel_crtc *crtc,
>u32 prec_index)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1960,7
> +1961,7 @@ static void glk_read_luts(struct intel_crtc_state *crtc_state)
>   if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
>   crtc_state->hw.gamma_lut = ilk_read_lut_8(crtc);
>   else
> - crtc_state->hw.gamma_lut = glk_read_lut_10(crtc,
> PAL_PREC_INDEX_VALUE(0));
> + crtc_state->hw.gamma_lut = bdw_read_lut_10(crtc,
> +PAL_PREC_INDEX_VALUE(0));
>  }
> 
>  static struct drm_property_blob *
> @@ -2016,7 +2017,7 @@ static void icl_read_luts(struct intel_crtc_state
> *crtc_state)
>   crtc_state->hw.gamma_lut = icl_read_lut_multi_segment(crtc);
>   break;
>   default:
> - crtc_state->hw.gamma_lut = glk_read_lut_10(crtc,
> PAL_PREC_INDEX_VALUE(0));
> + crtc_state->hw.gamma_lut = bdw_read_lut_10(crtc,
> +PAL_PREC_INDEX_VALUE(0));
>   }
>  }
> 
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/20] drm/i915: Include the LUT sizes in the state dump

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 03/20] drm/i915: Include the LUT sizes in the 
> state
> dump
> 
> From: Ville Syrjälä 
> 
> Dump the sizes of the software LUTs in the state dump. Makes it a bit easier 
> to
> see which is is present without having to decode it from the gamma_mode and

Nitpick: Drop an extra "is"
With this,
Reviewed-by: Uma Shankar 

> other bits of state.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c36379cf07fc..9279df7757fc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13131,6 +13131,12 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
>   pipe_config->csc_mode, pipe_config->gamma_mode,
>   pipe_config->gamma_enable, pipe_config-
> >csc_enable);
> 
> + drm_dbg_kms(_priv->drm, "degamma lut: %d entries, gamma lut:
> %d entries\n",
> + pipe_config->hw.degamma_lut ?
> + drm_color_lut_size(pipe_config->hw.degamma_lut) : 0,
> + pipe_config->hw.gamma_lut ?
> + drm_color_lut_size(pipe_config->hw.gamma_lut) : 0);
> +
>  dump_planes:
>   if (!state)
>   return;
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/20] drm/i915: Move MST master transcoder dump earlier

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 02/20] drm/i915: Move MST master transcoder dump
> earlier
> 
> From: Ville Syrjälä 
> 
> Move the MST master transcoder dump next to the other transcoder bits.

Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ae0af452d776..c36379cf07fc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13031,6 +13031,9 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
>   transcoder_name(pipe_config->cpu_transcoder),
>   pipe_config->pipe_bpp, pipe_config->dither);
> 
> + drm_dbg_kms(_priv->drm, "MST master transcoder: %s\n",
> + transcoder_name(pipe_config->mst_master_transcoder));
> +
>   drm_dbg_kms(_priv->drm,
>   "port sync: master transcoder: %s, slave transcoder bitmask 
> =
> 0x%x\n",
>   transcoder_name(pipe_config->master_transcoder),
> @@ -13128,9 +13131,6 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
>   pipe_config->csc_mode, pipe_config->gamma_mode,
>   pipe_config->gamma_enable, pipe_config-
> >csc_enable);
> 
> - drm_dbg_kms(_priv->drm, "MST master transcoder: %s\n",
> - transcoder_name(pipe_config->mst_master_transcoder));
> -
>  dump_planes:
>   if (!state)
>   return;
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/20] drm/i915: Fix state checker hw.active/hw.enable readout

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 01/20] drm/i915: Fix state checker
> hw.active/hw.enable readout
> 
> From: Ville Syrjälä 
> 
> Previously intel_dump_pipe_config() used to dump the full crtc state whether 
> or
> not the crtc was logically enabled or not. As that meant occasionally dumping
> confusing stale garbage I changed it to check whether the crtc is logically 
> enabled
> or not. However I did not realize that the state checker readout code does not
> populate crtc_state.hw.{active,enabled}. Hence the state checker dump would
> only give us a full dump of the sw state but not the hw state. Fix that by
> populating those bits of the hw state as well.

Looks good.
Reviewed-by: Uma Shankar 

> Fixes: 10d75f5428fd ("drm/i915: Fix plane state dumps")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 729ec6e0d43a..ae0af452d776 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14244,7 +14244,6 @@ verify_crtc_state(struct intel_crtc *crtc,
>   struct intel_encoder *encoder;
>   struct intel_crtc_state *pipe_config = old_crtc_state;
>   struct drm_atomic_state *state = old_crtc_state->uapi.state;
> - bool active;
> 
>   __drm_atomic_helper_crtc_destroy_state(_crtc_state->uapi);
>   intel_crtc_free_hw_state(old_crtc_state);
> @@ -14254,16 +14253,19 @@ verify_crtc_state(struct intel_crtc *crtc,
>   drm_dbg_kms(_priv->drm, "[CRTC:%d:%s]\n", crtc->base.base.id,
>   crtc->base.name);
> 
> - active = dev_priv->display.get_pipe_config(crtc, pipe_config);
> + pipe_config->hw.enable = new_crtc_state->hw.enable;
> +
> + pipe_config->hw.active =
> + dev_priv->display.get_pipe_config(crtc, pipe_config);
> 
>   /* we keep both pipes enabled on 830 */
> - if (IS_I830(dev_priv))
> - active = new_crtc_state->hw.active;
> + if (IS_I830(dev_priv) && pipe_config->hw.active)
> + pipe_config->hw.active = new_crtc_state->hw.active;
> 
> - I915_STATE_WARN(new_crtc_state->hw.active != active,
> + I915_STATE_WARN(new_crtc_state->hw.active != pipe_config->hw.active,
>   "crtc active state doesn't match with hw state "
>   "(expected %i, found %i)\n",
> - new_crtc_state->hw.active, active);
> + new_crtc_state->hw.active, pipe_config->hw.active);
> 
>   I915_STATE_WARN(crtc->active != new_crtc_state->hw.active,
>   "transitional active state does not match atomic hw 
> state
> "
> @@ -14272,6 +14274,7 @@ verify_crtc_state(struct intel_crtc *crtc,
> 
>   for_each_encoder_on_crtc(dev, >base, encoder) {
>   enum pipe pipe;
> + bool active;
> 
>   active = encoder->get_hw_state(encoder, );
>   I915_STATE_WARN(active != new_crtc_state->hw.active,
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce a ww transaction utility (rev2)

[Patchwork]

== Series Details ==

Series: Introduce a ww transaction utility (rev2)
URL   : https://patchwork.freedesktop.org/series/81787/
State : failure

== Summary ==

Applying: drm/i915: Break out dma_resv ww locking utilities to separate files
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/gem/i915_gem_object.h).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915: Break out dma_resv ww locking utilities to 
separate files
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

[Intel-gfx] [RFC PATCH v2 2/2] drm/i915: Introduce a i915_gem_do_ww(){} utility

[Intel]

From: Thomas Hellström 

With the huge number of sites where multiple-object locking is
needed in the driver, it becomes difficult to avoid recursive
ww_acquire_ctx initialization, and the function prototypes become
bloated passing the ww_acquire_ctx around. Furthermore it's not
always easy to get the -EDEADLK handling correct and to follow it.

Introduce a i915_gem_do_ww utility that tries to remedy all these problems
by enclosing parts of a ww transaction in the following way:

my_function() {
struct i915_gem_ww_ctx *ww, template;
int err;
bool interruptible = true;

i915_do_ww(ww, , err, interruptible) {
err = ww_transaction_part(ww);
}
return err;
}

The utility will automatically look up an active ww_acquire_ctx if one
is initialized previously in the call chain, and if one found will
forward the -EDEADLK instead of handling it, which takes care of the
recursive initalization. Using the utility also discourages nested ww
unlocking / relocking that is both very fragile and hard to follow.

To look up and register an active ww_acquire_ctx, use a
driver-wide hash table for now. But noting that a task could only have
a single active ww_acqurie_ctx per ww_class, the active CTX is really
task state and a generic version of this utility in the ww_mutex code
could thus probably use a quick lookup from a list in the
struct task_struct.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_gem_ww.c  | 74 -
 drivers/gpu/drm/i915/i915_gem_ww.h  | 56 +-
 drivers/gpu/drm/i915/i915_globals.c |  1 +
 drivers/gpu/drm/i915/i915_globals.h |  1 +
 4 files changed, 130 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_ww.c 
b/drivers/gpu/drm/i915/i915_gem_ww.c
index 3490b72cf613..6247af1dba87 100644
--- a/drivers/gpu/drm/i915/i915_gem_ww.c
+++ b/drivers/gpu/drm/i915/i915_gem_ww.c
@@ -1,10 +1,12 @@
 // SPDX-License-Identifier: MIT
 /*
- * Copyright © 2020 Intel Corporation
+ * Copyright © 2019 Intel Corporation
  */
+#include 
 #include 
 #include 
 #include "i915_gem_ww.h"
+#include "i915_globals.h"
 #include "gem/i915_gem_object.h"
 
 void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ww, bool intr)
@@ -70,3 +72,73 @@ int __must_check i915_gem_ww_ctx_backoff(struct 
i915_gem_ww_ctx *ww)
 
return ret;
 }
+
+static struct rhashtable ww_ht;
+static const struct rhashtable_params ww_params = {
+   .key_len = sizeof(struct task_struct *),
+   .key_offset = offsetof(struct i915_gem_ww_ctx, ctx.task),
+   .head_offset = offsetof(struct i915_gem_ww_ctx, head),
+   .min_size = 128,
+};
+
+static void i915_ww_item_free(void *ptr, void *arg)
+{
+   WARN_ON_ONCE(1);
+}
+
+static void i915_global_ww_exit(void)
+{
+   rhashtable_free_and_destroy(_ht, i915_ww_item_free, NULL);
+}
+
+static void i915_global_ww_shrink(void)
+{
+}
+
+static struct i915_global global = {
+   .shrink = i915_global_ww_shrink,
+   .exit = i915_global_ww_exit,
+};
+
+int __init i915_global_ww_init(void)
+{
+   int ret = rhashtable_init(_ht, _params);
+
+   if (ret)
+   return ret;
+
+   i915_global_register();
+
+   return 0;
+}
+
+void __i915_gem_ww_mark_unused(struct i915_gem_ww_ctx *ww)
+{
+   GEM_WARN_ON(rhashtable_remove_fast(_ht, >head, ww_params));
+}
+
+/**
+ * __i915_gem_ww_locate_or_use - return the task's i915_gem_ww_ctx context
+ * to use.
+ *
+ * @template: The context to use if there was none initialized previously
+ * in the call chain.
+ *
+ * RETURN: The task's i915_gem_ww_ctx context.
+ */
+struct i915_gem_ww_ctx *
+__i915_gem_ww_locate_or_use(struct i915_gem_ww_ctx *template)
+{
+   struct i915_gem_ww_ctx *tmp;
+
+   /* ctx.task is the hash key, so set it first. */
+   template->ctx.task = current;
+
+   /*
+* Ideally we'd just hook the active context to the
+* struct task_struct. But for now use a hash table.
+*/
+   tmp = rhashtable_lookup_get_insert_fast(_ht, >head,
+   ww_params);
+   return tmp;
+}
diff --git a/drivers/gpu/drm/i915/i915_gem_ww.h 
b/drivers/gpu/drm/i915/i915_gem_ww.h
index 94fdf8c5f89b..b844596067c7 100644
--- a/drivers/gpu/drm/i915/i915_gem_ww.h
+++ b/drivers/gpu/drm/i915/i915_gem_ww.h
@@ -6,18 +6,72 @@
 #define __I915_GEM_WW_H__
 
 #include 
+#include 
 #include 
 
 struct i915_gem_ww_ctx {
struct ww_acquire_ctx ctx;
+   struct rhash_head head;
struct list_head obj_list;
struct drm_i915_gem_object *contended;
depot_stack_handle_t contended_bt;
-   bool intr;
+   u32 call_depth;
+   unsigned short intr;
+   unsigned short loop;
 };
 
 void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ctx, bool intr);
 void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ctx);
 int __must_check i915_gem_ww_ctx_backoff(struct i915_gem_ww_ctx *ctx);
 void 

[Intel-gfx] [RFC PATCH v2 0/2] Introduce a ww transaction utility

[Intel]

A ww transaction utility intended to help removing the
obj->mm.lock from the driver and introduce ww transactions
in a robust way.

Patch 1/2 breaks the current i915 utilities out to separate files
Patch 2/2 introduces the ww transaction utility

A similar utility could easily be introduced in the core
ww_mutex code, allowing even for cross-driver ww transactions,
and the template argument could then allow for per-ww-class derived
ww_acquire_mutex types. To facilitate a core implementation, (since we
can never guarantee the contended lock stays alive), we'd need a

void ww_mutex_relax(struct ww_acquire_ctx *)

and its interruptible variant that does the equivalent of
locking and unlocking the contended mutex.

With this driver implementation, we can extend the code to take a
reference on the object containing the contended lock to make sure
it stays alive.

Finally, the drawback of the current implementation is the use of the hash
table and corresponding performance cost, but as mentioned in
patch 2, a core variant could probably do this in a much more
efficient way.

v2: Version 1 of patch 2 was obviously a WIP patch. Fix that.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH v2 1/2] drm/i915: Break out dma_resv ww locking utilities to separate files

[Intel]

From: Thomas Hellström 

As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/Makefile   |  1 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h  |  1 +
 drivers/gpu/drm/i915/gt/intel_renderstate.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 64 --
 drivers/gpu/drm/i915/i915_gem.h | 15 -
 drivers/gpu/drm/i915/i915_gem_ww.c  | 72 +
 drivers/gpu/drm/i915/i915_gem_ww.h  | 23 +++
 7 files changed, 98 insertions(+), 79 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.c
 create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 58d129b5a65a..71503bc26d98 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -45,6 +45,7 @@ i915-y += i915_drv.o \
  i915_switcheroo.o \
  i915_sysfs.o \
  i915_utils.o \
+ i915_gem_ww.o \
  intel_device_info.o \
  intel_dram.o \
  intel_memory_region.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index f084a25c5121..cd64b1fdf53c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -15,6 +15,7 @@
 #include "i915_gem_object_types.h"
 #include "i915_gem_gtt.h"
 #include "i915_vma_types.h"
+#include "i915_gem_ww.h"
 
 void i915_gem_init__objects(struct drm_i915_private *i915);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.h 
b/drivers/gpu/drm/i915/gt/intel_renderstate.h
index 713aa1e86c80..d9db833b873b 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.h
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.h
@@ -26,6 +26,7 @@
 
 #include 
 #include "i915_gem.h"
+#include "i915_gem_ww.h"
 
 struct i915_request;
 struct intel_context;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3f83ac729644..fa1b7861b954 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1365,70 +1365,6 @@ int i915_gem_open(struct drm_i915_private *i915, struct 
drm_file *file)
return ret;
 }
 
-void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ww, bool intr)
-{
-   ww_acquire_init(>ctx, _ww_class);
-   INIT_LIST_HEAD(>obj_list);
-   ww->intr = intr;
-   ww->contended = NULL;
-}
-
-static void i915_gem_ww_ctx_unlock_all(struct i915_gem_ww_ctx *ww)
-{
-   struct drm_i915_gem_object *obj;
-
-   while ((obj = list_first_entry_or_null(>obj_list, struct 
drm_i915_gem_object, obj_link))) {
-   if (WARN_ON(!kref_read(>base.refcount))) {
-   unsigned long *entries;
-   unsigned int nr_entries;
-
-   nr_entries = stack_depot_fetch(obj->bt, );
-   stack_trace_print(entries, nr_entries, 4);
-   }
-
-   obj->bt = 0;
-   list_del(>obj_link);
-   i915_gem_object_unlock(obj);
-   }
-}
-
-void i915_gem_ww_unlock_single(struct drm_i915_gem_object *obj)
-{
-   list_del(>obj_link);
-   i915_gem_object_unlock(obj);
-}
-
-void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ww)
-{
-   i915_gem_ww_ctx_unlock_all(ww);
-   WARN_ON(ww->contended);
-   ww_acquire_fini(>ctx);
-}
-
-int __must_check i915_gem_ww_ctx_backoff(struct i915_gem_ww_ctx *ww)
-{
-   int ret = 0;
-
-   if (WARN_ON(!ww->contended))
-   return -EINVAL;
-
-   i915_gem_ww_ctx_unlock_all(ww);
-   if (ww->intr)
-   ret = 
dma_resv_lock_slow_interruptible(ww->contended->base.resv, >ctx);
-   else
-   dma_resv_lock_slow(ww->contended->base.resv, >ctx);
-
-   if (!ret) {
-   list_add_tail(>contended->obj_link, >obj_list);
-   ww->contended->bt = ww->contended_bt;
-   }
-
-   ww->contended = NULL;
-   ww->contended_bt = 0;
-
-   return ret;
-}
-
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_gem_device.c"
 #include "selftests/i915_gem.c"
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 4d50afab43f2..db0b2835095d 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -27,8 +27,6 @@
 
 #include 
 #include 
-#include 
-#include 
 #include 
 
 #include "i915_utils.h"
@@ -117,17 +115,4 @@ static inline bool __tasklet_is_scheduled(struct 
tasklet_struct *t)
return test_bit(TASKLET_STATE_SCHED, >state);
 }
 
-struct i915_gem_ww_ctx {
-   struct ww_acquire_ctx ctx;
-   struct list_head obj_list;
-   bool intr;
-   struct drm_i915_gem_object *contended;
-   depot_stack_handle_t contended_bt;
-};
-
-void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ctx, bool intr);
-void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/uc: tune down GuC communication enabled/disabled messages

[Patchwork]

== Series Details ==

Series: drm/i915/uc: tune down GuC communication enabled/disabled messages
URL   : https://patchwork.freedesktop.org/series/81808/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9022_full -> Patchwork_18520_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18520_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18520_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_18520_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_endless@dispatch@bcs0:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-iclb4/igt@gem_exec_endless@dispa...@bcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-iclb5/igt@gem_exec_endless@dispa...@bcs0.html

  * igt@gem_exec_suspend@basic-s4-devices:
- shard-hsw:  NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-hsw2/igt@gem_exec_susp...@basic-s4-devices.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-mixed-process@bcs0:
- shard-skl:  [PASS][4] -> [FAIL][5] ([i915#2374])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-skl4/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-glk:  [PASS][6] -> [FAIL][7] ([i915#2389]) +2 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-glk6/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-glk6/igt@gem_exec_reloc@basic-many-act...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][8] -> [SKIP][9] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-tglb8/igt@gem_huc_c...@huc-copy.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_rc6_residency@rc6-fence:
- shard-hsw:  [PASS][10] -> [WARN][11] ([i915#1519])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-fence.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-fence.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#72])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html

  * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2122])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-glk1/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ab-hdmi-a1-hdmi-a2.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl:  [PASS][16] -> [FAIL][17] ([i915#79])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl:  [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +7 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-kbl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/shard-kbl2/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#2122]) +2 similar 
issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/shard-skl3/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html
   [21]: 

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

On Thu, 2020-09-17 at 11:31 -0600, Kevin Chowski wrote:
> Thanks very much for the quick reply, Lyude!
> 
> I'm happy to make the requested changes, but I wanted to clarify before
> falling down the wrong hole: are you suggesting that I move
> the intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to
> the drm_dp_helper.c file?

You don't have to do that yet (although I wouldn't object either way), I was
just mostly implying using drm_dp_has_quirk()
> On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul  wrote:
> > Just an FYI, my plan for some of this eDP backlight code is to move as much
> > of
> > 
> > it into helpers as possible since we need to implement the same interface in
> > 
> > nouveau. We probably can figure out some other solution for handling this
> > quirk
> > 
> > if this isn't possible, but could we maybe use the panel's OUI here and add
> > a
> > 
> > quirk to drm_dp_helper.c instead?
> > 
> > 
> > 
> > On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> > 
> > > We have observed that Google Pixelbook's backlight hardware is
> > 
> > > interpretting these backlight bits from the most-significant side of the
> > 
> > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > 
> > > assumes the peripheral cares about the least-significant bits.
> > 
> > > 
> > 
> > > Testing was done from within Chrome OS's build environment when the
> > 
> > > patch is backported to 5.4 (the version we are newly targeting for the
> > 
> > > Pixelbook); for the record:
> > 
> > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > 
> > >   ./update_kernel.sh --remote=$IP
> > 
> > > 
> > 
> > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > 
> > > that the registers were being set according to what the actual hardware
> > 
> > > expects; I also observe that the backlight is noticeably brighter with
> > 
> > > this patch.
> > 
> > > 
> > 
> > > Signed-off-by: Kevin Chowski 
> > 
> > > ---
> > 
> > > 
> > 
> > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > 
> > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
> > 
> > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > 
> > >  3 files changed, 48 insertions(+)
> > 
> > > 
> > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > 
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > 
> > > index acbd7eb66cbe3..99c98f217356d 100644
> > 
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > 
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > 
> > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > 
> > > intel_connector *connector)
> > 
> > >   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > 
> > >   level = (read_val[0] << 8 | read_val[1]);
> > 
> > >  
> > 
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > 
> > > + if (!drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > 
> > > + _val[0])) {
> > 
> > > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > 
> > > + DP_EDP_PWMGEN_BIT_COUNT);
> > 
> > > + return 0;
> > 
> > > + }
> > 
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> > 
> > > + read_val[0] = read_val[0] & 0x1F;
> > 
> > > + if (read_val[0] > 16) {
> > 
> > > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > 
> > > expected at most 16\n",
> > 
> > > + read_val[0]);
> > 
> > > + return 0;
> > 
> > > + }
> > 
> > > + level >>= 16 - read_val[0];
> > 
> > > + }
> > 
> > > +
> > 
> > >   return level;
> > 
> > >  }
> > 
> > >  
> > 
> > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > 
> > > drm_connector_state *conn_state, u32 lev
> > 
> > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > 
> > >   u8 vals[2] = { 0x0 };
> > 
> > >  
> > 
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > 
> > > + if (!drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > 
> > > + [0])) {
> > 
> > > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > 
> > > Failed to read DPCD register 0x%x\n",
> > 
> > > +   DP_EDP_PWMGEN_BIT_COUNT);
> > 
> > > + return;
> > 
> > > + }
> > 
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> > 
> > > + vals[0] = vals[0] & 0x1F;
> > 
> > > + if (vals[0] > 16) {
> > 
> > > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > 
> > > Invalid DP_EDP_PWNGEN_BIT_COUNT 

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

On Thu, 2020-09-17 at 21:25 +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > interpretation and 1 that use MSB.
> 
> "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> is cleared to 0, only the 8 MSB of the brightness control value can be
> controlled.
> (See Note below.)
> Assigned bits are allocated to the MSB of the enabled register
> combination."
> 
> I think that's pretty clear the assigned bits are supposed to be
> msb aligned.

Are we sure that isn't just referring to the DP_EDP_BACKLIGHT_BRIGHTNESS_MSB
register, as opposed to alignment of the whole value in that register? My
understanding of this was just that if there wasn't a pwmgen bit count
specified, that the backlight level would just be written to
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB and DP_EDP_BACKLIGHT_BRIGHTNESS_LSB would be
ignored. 

Hopefully I'm not misunderstanding Ville, but I don't think so since the current
code we have already follows the understanding I just gave:

vals[0] = level;

/* Write the MSB and/or LSB */
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT) {
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
}

(vals[0] == MSB)
> 
> > 
> > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski  wrote:
> > > Apologies for being too vague. To be as precise I can be, here is the
> > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > your other question, the code I tested against is indeed including the
> > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > message): our current top-of-tree for our 5.4 branch includes the
> > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > is exactly the change which breaks my Pixelbook model: prior to the
> > > change, the max_brightness was hard-coded to 0x and the math
> > > worked out that it didn't matter that the hardware cared about the MSB
> > > despite the driver code caring about the LSB.
> > > 
> > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > need a quirk at least for some laptop. Reading through the copy of the
> > > datasheet I have, it wasn't clear to me which was the correct
> > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > kernel code (caring about LSB) being the correct interpretation. I
> > > believe we have other chromebooks which do rely on LSB functionality,
> > > so unless we can find more examples of laptops wanting MSB it
> > > currently looks like Pixelbook is the outlier.
> > > 
> > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > >  wrote:
> > > > On Thu, 17 Sep 2020, Kevin Chowski  wrote:
> > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > interpretting these backlight bits from the most-significant side of
> > > > > the
> > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > assumes the peripheral cares about the least-significant bits.
> > > > > 
> > > > > Testing was done from within Chrome OS's build environment when the
> > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > Pixelbook); for the record:
> > > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > >   ./update_kernel.sh --remote=$IP
> > > > > 
> > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to
> > > > > verify
> > > > > that the registers were being set according to what the actual
> > > > > hardware
> > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > this patch.
> > > > 
> > > > It's unclear to me what kernel version this is against, and what you've
> > > > actually tested.
> > > > 
> > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > DPCD aux max backlight calculations")?
> > > > 
> > > > I just want to make sure you've tested with all the relevant fixes
> > > > before adding quirks.
> > > > 
> > > > BR,
> > > > Jani.
> > > > 
> > > > > Signed-off-by: Kevin Chowski 
> > > > > ---
> > > > > 
> > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > +++
> > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
> > > > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > > > >  3 files changed, 48 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > 

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Introduce quirk for shifting eDP brightness.

[Patchwork]

== Series Details ==

Series: i915: Introduce quirk for shifting eDP brightness.
URL   : https://patchwork.freedesktop.org/series/81809/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9022 -> Patchwork_18521


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] / 
[i915#95])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- {fi-ehl-1}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-ehl-1/igt@i915_module_l...@reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-ehl-1/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][15] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][17] ([i915#62]) -> [DMESG-FAIL][18] 
([i915#62] / [i915#95])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275:   [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +7 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18521/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html

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

  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating 

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Ville Syrjälä]

On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> The Lyude fde7266fb2f6 change is actually based on Chromium change
> (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> Galaxy Chromebook. So currently we have 2 examples that use LSB
> interpretation and 1 that use MSB.

"If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
is cleared to 0, only the 8 MSB of the brightness control value can be
controlled.
(See Note below.)
Assigned bits are allocated to the MSB of the enabled register
combination."

I think that's pretty clear the assigned bits are supposed to be
msb aligned.

> 
> 
> On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski  wrote:
> >
> > Apologies for being too vague. To be as precise I can be, here is the
> > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > your other question, the code I tested against is indeed including the
> > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > message): our current top-of-tree for our 5.4 branch includes the
> > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > is exactly the change which breaks my Pixelbook model: prior to the
> > change, the max_brightness was hard-coded to 0x and the math
> > worked out that it didn't matter that the hardware cared about the MSB
> > despite the driver code caring about the LSB.
> >
> > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > need a quirk at least for some laptop. Reading through the copy of the
> > datasheet I have, it wasn't clear to me which was the correct
> > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > kernel code (caring about LSB) being the correct interpretation. I
> > believe we have other chromebooks which do rely on LSB functionality,
> > so unless we can find more examples of laptops wanting MSB it
> > currently looks like Pixelbook is the outlier.
> >
> > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> >  wrote:
> > >
> > > On Thu, 17 Sep 2020, Kevin Chowski  wrote:
> > > > We have observed that Google Pixelbook's backlight hardware is
> > > > interpretting these backlight bits from the most-significant side of the
> > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > assumes the peripheral cares about the least-significant bits.
> > > >
> > > > Testing was done from within Chrome OS's build environment when the
> > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > Pixelbook); for the record:
> > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > >   ./update_kernel.sh --remote=$IP
> > > >
> > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > > that the registers were being set according to what the actual hardware
> > > > expects; I also observe that the backlight is noticeably brighter with
> > > > this patch.
> > >
> > > It's unclear to me what kernel version this is against, and what you've
> > > actually tested.
> > >
> > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > DPCD aux max backlight calculations")?
> > >
> > > I just want to make sure you've tested with all the relevant fixes
> > > before adding quirks.
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > Signed-off-by: Kevin Chowski 
> > > > ---
> > > >
> > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
> > > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > > >  3 files changed, 48 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > index acbd7eb66cbe3..99c98f217356d 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct 
> > > > intel_connector *connector)
> > > >   if (intel_dp->edp_dpcd[2] & 
> > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > >   level = (read_val[0] << 8 | read_val[1]);
> > > >
> > > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > + if (!drm_dp_dpcd_readb(_dp->aux, 
> > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > + _val[0])) {
> > > > + DRM_DEBUG_KMS("Failed to read DPCD register 
> > > > 0x%x\n",
> > > > + DP_EDP_PWMGEN_BIT_COUNT);
> > > > + return 0;
> > > > + }
> > > > + // Only bits 4:0 are used, 7:5 are 

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Puthikorn Voravootivat]

The Lyude fde7266fb2f6 change is actually based on Chromium change
(https://crrev.com/c/1650325) that fixes the brightness for Samsung
Galaxy Chromebook. So currently we have 2 examples that use LSB
interpretation and 1 that use MSB.


On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski  wrote:
>
> Apologies for being too vague. To be as precise I can be, here is the
> specific code delta I tested: https://crrev.com/c/2406616 . To answer
> your other question, the code I tested against is indeed including the
> fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> message): our current top-of-tree for our 5.4 branch includes the
> intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> is exactly the change which breaks my Pixelbook model: prior to the
> change, the max_brightness was hard-coded to 0x and the math
> worked out that it didn't matter that the hardware cared about the MSB
> despite the driver code caring about the LSB.
>
> To answer Ville's question: the fde7266fb2f6 change which fixes one
> laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> dug up) and breaks another (Pixelbook); so unfortunately I believe we
> need a quirk at least for some laptop. Reading through the copy of the
> datasheet I have, it wasn't clear to me which was the correct
> interpretation. I'm cc'ing puthik@, who was leaning toward the current
> kernel code (caring about LSB) being the correct interpretation. I
> believe we have other chromebooks which do rely on LSB functionality,
> so unless we can find more examples of laptops wanting MSB it
> currently looks like Pixelbook is the outlier.
>
> On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
>  wrote:
> >
> > On Thu, 17 Sep 2020, Kevin Chowski  wrote:
> > > We have observed that Google Pixelbook's backlight hardware is
> > > interpretting these backlight bits from the most-significant side of the
> > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > assumes the peripheral cares about the least-significant bits.
> > >
> > > Testing was done from within Chrome OS's build environment when the
> > > patch is backported to 5.4 (the version we are newly targeting for the
> > > Pixelbook); for the record:
> > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > >   ./update_kernel.sh --remote=$IP
> > >
> > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > that the registers were being set according to what the actual hardware
> > > expects; I also observe that the backlight is noticeably brighter with
> > > this patch.
> >
> > It's unclear to me what kernel version this is against, and what you've
> > actually tested.
> >
> > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > DPCD aux max backlight calculations")?
> >
> > I just want to make sure you've tested with all the relevant fixes
> > before adding quirks.
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Kevin Chowski 
> > > ---
> > >
> > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
> > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > >  3 files changed, 48 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index acbd7eb66cbe3..99c98f217356d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct 
> > > intel_connector *connector)
> > >   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > >   level = (read_val[0] << 8 | read_val[1]);
> > >
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > + if (!drm_dp_dpcd_readb(_dp->aux, 
> > > DP_EDP_PWMGEN_BIT_COUNT,
> > > + _val[0])) {
> > > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > + DP_EDP_PWMGEN_BIT_COUNT);
> > > + return 0;
> > > + }
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> > > + read_val[0] = read_val[0] & 0x1F;
> > > + if (read_val[0] > 16) {
> > > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 
> > > 0x%X, expected at most 16\n",
> > > + read_val[0]);
> > > + return 0;
> > > + }
> > > + level >>= 16 - read_val[0];
> > > + }
> > > +
> > >   return level;
> > >  }
> > >
> > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct 
> > > drm_connector_state *conn_state, u32 lev
> > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > >   u8 vals[2] = { 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Introduce quirk for shifting eDP brightness.

[Patchwork]

== Series Details ==

Series: i915: Introduce quirk for shifting eDP brightness.
URL   : https://patchwork.freedesktop.org/series/81809/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8c6e983afa60 i915: Introduce quirk for shifting eDP brightness.
-:34: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#34: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:96:
+   if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+   _val[0])) {

-:36: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#36: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:98:
+   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+   DP_EDP_PWMGEN_BIT_COUNT);

-:43: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#43: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:105:
+   DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, 
expected at most 16\n",
+   read_val[0]);

-:58: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#58: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:128:
+   if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+   [0])) {

-:60: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#60: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:130:
+   DRM_DEBUG_KMS("Failed to write aux backlight level: 
Failed to read DPCD register 0x%x\n",
+ DP_EDP_PWMGEN_BIT_COUNT);

-:67: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#67: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:137:
+   DRM_DEBUG_KMS("Failed to write aux backlight level: 
Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
+   vals[0]);

-:115: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#115: FILE: drivers/gpu/drm/i915/i915_drv.h:519:
+#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
^

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


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

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

Apologies for being too vague. To be as precise I can be, here is the
specific code delta I tested: https://crrev.com/c/2406616 . To answer
your other question, the code I tested against is indeed including the
fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
message): our current top-of-tree for our 5.4 branch includes the
intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
is exactly the change which breaks my Pixelbook model: prior to the
change, the max_brightness was hard-coded to 0x and the math
worked out that it didn't matter that the hardware cared about the MSB
despite the driver code caring about the LSB.

To answer Ville's question: the fde7266fb2f6 change which fixes one
laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
dug up) and breaks another (Pixelbook); so unfortunately I believe we
need a quirk at least for some laptop. Reading through the copy of the
datasheet I have, it wasn't clear to me which was the correct
interpretation. I'm cc'ing puthik@, who was leaning toward the current
kernel code (caring about LSB) being the correct interpretation. I
believe we have other chromebooks which do rely on LSB functionality,
so unless we can find more examples of laptops wanting MSB it
currently looks like Pixelbook is the outlier.

On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
 wrote:
>
> On Thu, 17 Sep 2020, Kevin Chowski  wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> >   ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
>
> It's unclear to me what kernel version this is against, and what you've
> actually tested.
>
> Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> DPCD aux max backlight calculations")?
>
> I just want to make sure you've tested with all the relevant fixes
> before adding quirks.
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Kevin Chowski 
> > ---
> >
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
> >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >  3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct 
> > intel_connector *connector)
> >   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> >   level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux, 
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + _val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, 
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> >   return level;
> >  }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct 
> > drm_connector_state *conn_state, u32 lev
> >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >   u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux, 
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + [0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level: 
> > Failed to read DPCD register 0x%x\n",
> > +   DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> > + // Only 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: tune down GuC communication enabled/disabled messages

[Patchwork]

== Series Details ==

Series: drm/i915/uc: tune down GuC communication enabled/disabled messages
URL   : https://patchwork.freedesktop.org/series/81808/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9022 -> Patchwork_18520


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@vgem_basic@unload:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-skl-guc/igt@vgem_ba...@unload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-skl-guc/igt@vgem_ba...@unload.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- {fi-ehl-1}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-ehl-1/igt@i915_module_l...@reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-ehl-1/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][13] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][14] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-kbl-x1275:   [DMESG-WARN][15] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html

  * igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275:   [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +5 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9022/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18520/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html

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

  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (45 -> 40)
--

  Additional (2): fi-tgl-y fi-bwr-2160 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9022 -> Patchwork_18520

  CI-20190529: 20190529
  CI_DRM_9022: 98f98783862873daf2a42c874adfa770f08e6b36 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @ 

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

(resending as plain-text, my last mail was rejected by lots of
addresses for some reason)

Thanks very much for the quick reply, Lyude!

I'm happy to make the requested changes, but I wanted to clarify
before falling down the wrong hole: are you suggesting that I move the
intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to the
drm_dp_helper.c file?

On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul  wrote:
>
> Just an FYI, my plan for some of this eDP backlight code is to move as much of
> it into helpers as possible since we need to implement the same interface in
> nouveau. We probably can figure out some other solution for handling this 
> quirk
> if this isn't possible, but could we maybe use the panel's OUI here and add a
> quirk to drm_dp_helper.c instead?
>
> On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> >   ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
> >
> > Signed-off-by: Kevin Chowski 
> > ---
> >
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
> >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >  3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> >   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> >   level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux, 
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + _val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> >   return level;
> >  }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >   u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux, 
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + [0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > +   DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + vals[0] = vals[0] & 0x1F;
> > + if (vals[0] > 16) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > + vals[0]);
> > + return;
> > + }
> > + level <<= (16 - vals[0]) & 0x;
> > + }
> > +
> >   vals[0] = level;
> >
> >   /* Write the MSB and/or LSB */
> > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > index 46beb155d835f..63b27d49b2864 100644
> > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> > drm_i915_private *i915)
> >   

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

Thanks very much for the quick reply, Lyude!

I'm happy to make the requested changes, but I wanted to clarify before
falling down the wrong hole: are you suggesting that I move
the intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to
the drm_dp_helper.c file?

On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul  wrote:

> Just an FYI, my plan for some of this eDP backlight code is to move as
> much of
> it into helpers as possible since we need to implement the same interface
> in
> nouveau. We probably can figure out some other solution for handling this
> quirk
> if this isn't possible, but could we maybe use the panel's OUI here and
> add a
> quirk to drm_dp_helper.c instead?
>
> On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> >   ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
> >
> > Signed-off-by: Kevin Chowski 
> > ---
> >
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
> >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >  3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> >   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> >   level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux,
> DP_EDP_PWMGEN_BIT_COUNT,
> > + _val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register
> 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT
> 0x%X,
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> >   return level;
> >  }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >   u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux,
> DP_EDP_PWMGEN_BIT_COUNT,
> > + [0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > +   DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + vals[0] = vals[0] & 0x1F;
> > + if (vals[0] > 16) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > + vals[0]);
> > + return;
> > + }
> > + level <<= (16 - vals[0]) & 0x;
> > + }
> > +
> >   vals[0] = level;
> >
> >   /* Write the MSB and/or LSB */
> > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > index 46beb155d835f..63b27d49b2864 100644
> > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> > drm_i915_private *i915)
> >   drm_info(>drm, "Applying Increase DDI Disabled quirk\n");
> >  }
> >
> > +/*
> > + * Some eDP 

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Jani Nikula]

On Thu, 17 Sep 2020, Kevin Chowski  wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the least-significant bits.
>
> Testing was done from within Chrome OS's build environment when the
> patch is backported to 5.4 (the version we are newly targeting for the
> Pixelbook); for the record:
>$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
>   ./update_kernel.sh --remote=$IP
>
> I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> that the registers were being set according to what the actual hardware
> expects; I also observe that the backlight is noticeably brighter with
> this patch.

It's unclear to me what kernel version this is against, and what you've
actually tested.

Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
DPCD aux max backlight calculations")?

I just want to make sure you've tested with all the relevant fixes
before adding quirks.

BR,
Jani.

>
> Signed-off-by: Kevin Chowski 
> ---
>
>  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
>  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  3 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe3..99c98f217356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct 
> intel_connector *connector)
>   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
>   level = (read_val[0] << 8 | read_val[1]);
>  
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + _val[0])) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return 0;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + read_val[0] = read_val[0] & 0x1F;
> + if (read_val[0] > 16) {
> + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, 
> expected at most 16\n",
> + read_val[0]);
> + return 0;
> + }
> + level >>= 16 - read_val[0];
> + }
> +
>   return level;
>  }
>  
> @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct 
> drm_connector_state *conn_state, u32 lev
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   u8 vals[2] = { 0x0 };
>  
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + [0])) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level: 
> Failed to read DPCD register 0x%x\n",
> +   DP_EDP_PWMGEN_BIT_COUNT);
> + return;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + vals[0] = vals[0] & 0x1F;
> + if (vals[0] > 16) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level: 
> Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> + vals[0]);
> + return;
> + }
> + level <<= (16 - vals[0]) & 0x;
> + }
> +
>   vals[0] = level;
>  
>   /* Write the MSB and/or LSB */
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 46beb155d835f..63b27d49b2864 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct 
> drm_i915_private *i915)
>   drm_info(>drm, "Applying Increase DDI Disabled quirk\n");
>  }
>  
> +/*
> + * Some eDP backlight hardware uses the most-significant bits of the 
> brightness
> + * register, so brightness values must be shifted first.
> + */
> +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private 
> *i915)
> +{
> + i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> + DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
>  struct intel_quirk {
>   int device;
>   int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
>   /* ASRock ITX*/
>   { 0x3185, 0x1849, 0x2212, 

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Ville Syrjälä]

On Thu, Sep 17, 2020 at 11:09:06AM -0600, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the least-significant bits.

The spec seems to agree with the msb interpretation. So looks like
the current code is just broken?

> 
> Testing was done from within Chrome OS's build environment when the
> patch is backported to 5.4 (the version we are newly targeting for the
> Pixelbook); for the record:
>$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
>   ./update_kernel.sh --remote=$IP
> 
> I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> that the registers were being set according to what the actual hardware
> expects; I also observe that the backlight is noticeably brighter with
> this patch.
> 
> Signed-off-by: Kevin Chowski 
> ---
> 
>  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
>  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  3 files changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe3..99c98f217356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct 
> intel_connector *connector)
>   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
>   level = (read_val[0] << 8 | read_val[1]);
>  
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + _val[0])) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return 0;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + read_val[0] = read_val[0] & 0x1F;
> + if (read_val[0] > 16) {
> + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, 
> expected at most 16\n",
> + read_val[0]);
> + return 0;
> + }
> + level >>= 16 - read_val[0];
> + }
> +
>   return level;
>  }
>  
> @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct 
> drm_connector_state *conn_state, u32 lev
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   u8 vals[2] = { 0x0 };
>  
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + [0])) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level: 
> Failed to read DPCD register 0x%x\n",
> +   DP_EDP_PWMGEN_BIT_COUNT);
> + return;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + vals[0] = vals[0] & 0x1F;
> + if (vals[0] > 16) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level: 
> Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> + vals[0]);
> + return;
> + }
> + level <<= (16 - vals[0]) & 0x;
> + }
> +
>   vals[0] = level;
>  
>   /* Write the MSB and/or LSB */
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 46beb155d835f..63b27d49b2864 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct 
> drm_i915_private *i915)
>   drm_info(>drm, "Applying Increase DDI Disabled quirk\n");
>  }
>  
> +/*
> + * Some eDP backlight hardware uses the most-significant bits of the 
> brightness
> + * register, so brightness values must be shifted first.
> + */
> +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private 
> *i915)
> +{
> + i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> + DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
>  struct intel_quirk {
>   int device;
>   int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
>   /* ASRock ITX*/
>   { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
>   { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> +
> + /* Google Pixelbook */
> + { 0x591E, 0x8086, 0x2212, 

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

Just an FYI, my plan for some of this eDP backlight code is to move as much of
it into helpers as possible since we need to implement the same interface in
nouveau. We probably can figure out some other solution for handling this quirk
if this isn't possible, but could we maybe use the panel's OUI here and add a
quirk to drm_dp_helper.c instead?

On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the least-significant bits.
> 
> Testing was done from within Chrome OS's build environment when the
> patch is backported to 5.4 (the version we are newly targeting for the
> Pixelbook); for the record:
>$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
>   ./update_kernel.sh --remote=$IP
> 
> I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> that the registers were being set according to what the actual hardware
> expects; I also observe that the backlight is noticeably brighter with
> this patch.
> 
> Signed-off-by: Kevin Chowski 
> ---
> 
>  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
>  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  3 files changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe3..99c98f217356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> intel_connector *connector)
>   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
>   level = (read_val[0] << 8 | read_val[1]);
>  
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + _val[0])) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return 0;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + read_val[0] = read_val[0] & 0x1F;
> + if (read_val[0] > 16) {
> + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> expected at most 16\n",
> + read_val[0]);
> + return 0;
> + }
> + level >>= 16 - read_val[0];
> + }
> +
>   return level;
>  }
>  
> @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> drm_connector_state *conn_state, u32 lev
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   u8 vals[2] = { 0x0 };
>  
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + [0])) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level:
> Failed to read DPCD register 0x%x\n",
> +   DP_EDP_PWMGEN_BIT_COUNT);
> + return;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + vals[0] = vals[0] & 0x1F;
> + if (vals[0] > 16) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level:
> Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> + vals[0]);
> + return;
> + }
> + level <<= (16 - vals[0]) & 0x;
> + }
> +
>   vals[0] = level;
>  
>   /* Write the MSB and/or LSB */
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 46beb155d835f..63b27d49b2864 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> drm_i915_private *i915)
>   drm_info(>drm, "Applying Increase DDI Disabled quirk\n");
>  }
>  
> +/*
> + * Some eDP backlight hardware uses the most-significant bits of the
> brightness
> + * register, so brightness values must be shifted first.
> + */
> +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private
> *i915)
> +{
> + i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> + DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
>  struct intel_quirk {
>   int device;
>   int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
>   /* ASRock ITX*/
>   

[Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

We have observed that Google Pixelbook's backlight hardware is
interpretting these backlight bits from the most-significant side of the
16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
assumes the peripheral cares about the least-significant bits.

Testing was done from within Chrome OS's build environment when the
patch is backported to 5.4 (the version we are newly targeting for the
Pixelbook); for the record:
   $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
  ./update_kernel.sh --remote=$IP

I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
that the registers were being set according to what the actual hardware
expects; I also observe that the backlight is noticeably brighter with
this patch.

Signed-off-by: Kevin Chowski 
---

 .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
 drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 3 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe3..99c98f217356d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector 
*connector)
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
level = (read_val[0] << 8 | read_val[1]);
 
+   if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
+   if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+   _val[0])) {
+   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+   DP_EDP_PWMGEN_BIT_COUNT);
+   return 0;
+   }
+   // Only bits 4:0 are used, 7:5 are reserved.
+   read_val[0] = read_val[0] & 0x1F;
+   if (read_val[0] > 16) {
+   DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, 
expected at most 16\n",
+   read_val[0]);
+   return 0;
+   }
+   level >>= 16 - read_val[0];
+   }
+
return level;
 }
 
@@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct 
drm_connector_state *conn_state, u32 lev
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
 
+   if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
+   if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+   [0])) {
+   DRM_DEBUG_KMS("Failed to write aux backlight level: 
Failed to read DPCD register 0x%x\n",
+ DP_EDP_PWMGEN_BIT_COUNT);
+   return;
+   }
+   // Only bits 4:0 are used, 7:5 are reserved.
+   vals[0] = vals[0] & 0x1F;
+   if (vals[0] > 16) {
+   DRM_DEBUG_KMS("Failed to write aux backlight level: 
Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
+   vals[0]);
+   return;
+   }
+   level <<= (16 - vals[0]) & 0x;
+   }
+
vals[0] = level;
 
/* Write the MSB and/or LSB */
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 46beb155d835f..63b27d49b2864 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct 
drm_i915_private *i915)
drm_info(>drm, "Applying Increase DDI Disabled quirk\n");
 }
 
+/*
+ * Some eDP backlight hardware uses the most-significant bits of the brightness
+ * register, so brightness values must be shifted first.
+ */
+static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
+{
+   i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
+   DRM_INFO("Applying shift eDP backlight brightness quirk\n");
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
/* ASRock ITX*/
{ 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
{ 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
+
+   /* Google Pixelbook */
+   { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
 };
 
 void intel_init_quirks(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4f7f6518945b..cc93bede4fab8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -525,6 +525,7 @@ 

Re: [Intel-gfx] [PATCH] drm/i915/uc: tune down GuC communication enabled/disabled messages

[Ville Syrjälä]

On Thu, Sep 17, 2020 at 07:50:56PM +0300, Jani Nikula wrote:
> The GuC communication enabled/disabled messages are too noisy in info
> level. Convert them from info to debug level, and switch to device based
> logging while at it.
> 
> Reported-by: Karol Herbst 
> Cc: Karol Herbst 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index d6f55f70889d..4e6070e95fe9 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -231,13 +231,15 @@ static int guc_enable_communication(struct intel_guc 
> *guc)
>   intel_guc_ct_event_handler(>ct);
>   spin_unlock_irq(>irq_lock);
>  
> - DRM_INFO("GuC communication enabled\n");
> + drm_dbg(>drm, "GuC communication enabled\n");
>  
>   return 0;
>  }
>  
>  static void guc_disable_communication(struct intel_guc *guc)
>  {
> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> +
>   /*
>* Events generated during or after CT disable are logged by guc in
>* via mmio. Make sure the register is clear before disabling CT since
> @@ -257,7 +259,7 @@ static void guc_disable_communication(struct intel_guc 
> *guc)
>*/
>   guc_get_mmio_msg(guc);
>  
> - DRM_INFO("GuC communication disabled\n");
> + drm_dbg(>drm, "GuC communication disabled\n");
>  }
>  
>  static void __uc_fetch_firmwares(struct intel_uc *uc)
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH] drm/i915/uc: tune down GuC communication enabled/disabled messages

[Jani Nikula]

The GuC communication enabled/disabled messages are too noisy in info
level. Convert them from info to debug level, and switch to device based
logging while at it.

Reported-by: Karol Herbst 
Cc: Karol Herbst 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index d6f55f70889d..4e6070e95fe9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -231,13 +231,15 @@ static int guc_enable_communication(struct intel_guc *guc)
intel_guc_ct_event_handler(>ct);
spin_unlock_irq(>irq_lock);
 
-   DRM_INFO("GuC communication enabled\n");
+   drm_dbg(>drm, "GuC communication enabled\n");
 
return 0;
 }
 
 static void guc_disable_communication(struct intel_guc *guc)
 {
+   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+
/*
 * Events generated during or after CT disable are logged by guc in
 * via mmio. Make sure the register is clear before disabling CT since
@@ -257,7 +259,7 @@ static void guc_disable_communication(struct intel_guc *guc)
 */
guc_get_mmio_msg(guc);
 
-   DRM_INFO("GuC communication disabled\n");
+   drm_dbg(>drm, "GuC communication disabled\n");
 }
 
 static void __uc_fetch_firmwares(struct intel_uc *uc)
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH v5 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation

[Ville Syrjälä]

On Wed, Aug 26, 2020 at 02:24:50PM -0400, Lyude Paul wrote:
> This adds support for querying the maximum clock rate of a downstream
> port on a DisplayPort connection. Generally, downstream ports refer to
> active dongles which can have their own pixel clock limits.
> 
> Note as well, we also start marking the connector as disconnected if we
> can't read the DPCD, since we wouldn't be able to do anything without
> DPCD access anyway.
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Ben Skeggs 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  3 +++
>  drivers/gpu/drm/nouveau/nouveau_dp.c  | 15 +++
>  drivers/gpu/drm/nouveau/nouveau_encoder.h |  1 +
>  3 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 8e1effb10425d..d2141ca16107b 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1258,7 +1258,10 @@ nv50_mstc_detect(struct drm_connector *connector,
>  
>   ret = drm_dp_mst_detect_port(connector, ctx, mstc->port->mgr,
>mstc->port);
> + if (ret != connector_status_connected)
> + goto out;
>  
> +out:
>   pm_runtime_mark_last_busy(connector->dev->dev);
>   pm_runtime_put_autosuspend(connector->dev->dev);
>   return ret;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 005750aeb6d4f..ad852e572cfec 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -61,6 +61,11 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
> *nv_connector,
>   mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
>   }
>  
> + ret = drm_dp_read_downstream_info(aux, dpcd,
> +   outp->dp.downstream_ports);
> + if (ret < 0)
> + return connector_status_disconnected;
> +
>   return connector_status_connected;
>  }
>  
> @@ -176,8 +181,6 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
>  /* TODO:
>   * - Use the minimum possible BPC here, once we add support for the max bpc
>   *   property.
> - * - Validate the mode against downstream port caps (see
> - *   drm_dp_downstream_max_clock())
>   * - Validate against the DP caps advertised by the GPU (we don't check these
>   *   yet)
>   */
> @@ -188,15 +191,19 @@ nv50_dp_mode_valid(struct drm_connector *connector,
>  unsigned *out_clock)
>  {
>   const unsigned min_clock = 25000;
> - unsigned max_clock, clock;
> + unsigned max_clock, ds_clock, clock;
>   enum drm_mode_status ret;
>  
>   if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
>   return MODE_NO_INTERLACE;

I stumbled on this code when applying my big DFP series (sorry that
I forgot to read this while it was on the list).

Anyways, this code appears somewhat confused about the different
clocks.

>  
>   max_clock = outp->dp.link_nr * outp->dp.link_bw;

That I presume is the max symbol rate of the link.

> - clock = mode->clock * (connector->display_info.bpc * 3) / 10;
> + ds_clock = drm_dp_downstream_max_clock(outp->dp.dpcd,
> +outp->dp.downstream_ports);

That is the maximum dotclock (also the max TMDS clock before my DFP
series landed) the DFP supports.

> + if (ds_clock)
> + max_clock = min(max_clock, ds_clock);

max() between the symbol rate and dotclock doesn't really
make sense. One is the amount of symbols (or data in other
words), the other is amount of pixels (which depending on
bpc can result in various amounts of symbols/data).

>  
> + clock = mode->clock * (connector->display_info.bpc * 3) / 10;

I presume this trying to compute the symbol rate we require.
Due to the 8b/10b encoding each 10bit symbol carries 8 bits of
actual data, so the /10 should be /8. IIRC we had this same
bug in i915, but it was fixed years ago.

This is also calculating things based on display_info.bpc which
IIRC is the max bpc the display supports. Using the max may be
overly pessimistic in case a) the driver/hw doesn't even support
bpc that high, b) the driver can dynamically reduce the bpc in
order to fit the mode onto the link. In i915 we take the opposite
approach and just use the min bpc (==6) in mode_valid(). During
modeset we start from the max bpc and keep reducing it until
things fit.


So I suspect what you want here is something like:

max_clock = outp->dp.link_nr * outp->dp.link_bw;
clock = mode->clock * (connector->display_info.bpc * 3) / 8; // or maybe just 
use 6 for bpc
if (clock > max_clock)
reurn CLOCK_HIGH;

ds_clock = drm_dp_downstream_max_dotclock();
if (ds_clock && mode->clock > ds_clock)
return CLOCK_HIGH;

+ a bit more if you want to also deal with the TMDS
clock limits sensibly. That also requires some though
as to which bpc to use. In i915 

Re: [Intel-gfx] [PATCH v2 00/18] drm/i915: Pimp DP DFP handling

[Ville Syrjälä]

On Tue, Sep 08, 2020 at 02:34:24PM -0400, Lyude Paul wrote:
> With the nitpicks addressed (note there were a couple of other spots where we
> wanted to use Return: in the kdocs, but I didn't bother pointing all of them
> out), all but patch 07 is:
> 
> Reviewed-by: Lyude Paul 

Thanks for the review. I fixed up the missing/bad docs and 
pushed the lot to drm-intel-next-queued (with Daniel's irc ack).

PS.
Had to s/drm_dp_downstream_max_clock/drm_dp_downstream_max_dotclock/
in nouveau_dp.c to keep it in a buildable shape. I hope I didn't step
on too many toes with this...

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix the race between the GEM close and debugfs

[Sasha Levin]

Hi

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v5.8.9, v5.4.65, v4.19.145, v4.14.198, 
v4.9.236, v4.4.236.

v5.8.9: Build OK!
v5.4.65: Failed to apply! Possible dependencies:
061489c65ff5 ("drm/i915/dsb: single register write function for DSB.")
11988e393813 ("drm/i915/execlists: Try rearranging breadcrumb flush")
2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
5a90606df7cb ("drm/i915: Replace obj->pin_global with obj->frontbuffer")
67f3b58f3bac ("drm/i915/dsb: DSB context creation.")
8a9a982767b7 ("drm/i915: use a separate context for gpu relocs")
a4e7ccdac38e ("drm/i915: Move context management under GEM")
b27a96ad72fd ("drm/i915/dsb: Indexed register write function for DSB.")
bb120e1171a9 ("drm/i915: Show the logical context ring state on dumping")
c210e85b8f33 ("drm/i915/tgl: Extend MI_SEMAPHORE_WAIT")
d19d71fc2b15 ("drm/i915: Mark i915_request.timeline as a volatile, rcu 
pointer")
e8f6b4952ec5 ("drm/i915/execlists: Flush the post-sync breadcrumb write 
harder")

v4.19.145: Failed to apply! Possible dependencies:
0258404f9d38 ("drm/i915: start moving runtime device info to a separate 
struct")
026844460743 ("drm/i915: Remove intel_context.active_link")
07d805721938 ("drm/i915: Introduce intel_runtime_pm_disable to pair 
intel_runtime_pm_enable")
13f1bfd3b332 ("drm/i915: Make object/vma allocation caches global")
1c71bc565cdb ("drm/i915/perf: simplify configure all context function")
2cc8376fd350 ("drm/i915: rename dev_priv info to __info to avoid usage")
2cd9a689e97b ("drm/i915: Refactor intel_display_set_init_power() logic")
37d7c9cc2eb6 ("drm/i915: Check engine->default_state mapping on module 
load")
55ac5a1614f9 ("drm/i915: Attach the pci match data to the device upon 
creation")
666424abfb86 ("drm/i915/execlists: Use coherent writes into the context 
image")
6dfc4a8f134f ("drm/i915: Verify power domains after enabling them")
722f3de39e03 ("i915/oa: Simplify updating contexts")
900ccf30f9e1 ("drm/i915: Only force GGTT coherency w/a on required 
chipsets")
c4d52feb2c46 ("drm/i915: Move over to intel_context_lookup()")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each 
context in debugfs")
fa9f668141f4 ("drm/i915: Export intel_context_instance()")

v4.14.198: Failed to apply! Possible dependencies:
3bd4073524fa ("drm/i915: Consolidate get_fence with pin_fence")
465c403cb508 ("drm/i915: introduce simple gemfs")
66df1014efba ("drm/i915: Keep a small stash of preallocated WC pages")
67b48040255b ("drm/i915: Assert that the handle->vma lut is empty on object 
close")
73ebd503034c ("drm/i915: make mappable struct resource centric")
7789422665f5 ("drm/i915: make dsm struct resource centric")
82ad6443a55e ("drm/i915/gtt: Rename i915_hw_ppgtt base member")
969b0950a188 ("drm/i915: Add interface to reserve fence registers for vGPU")
a65adaf8a834 ("drm/i915: Track user GTT faulting per-vma")
b4563f595ed4 ("drm/i915: Pin fence for iomap")
e91ef99b9543 ("drm/i915/selftests: Remember to create the fake preempt 
context")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each 
context in debugfs")
f773568b6ff8 ("drm/i915: nuke the duplicated stolen discovery")

v4.9.236: Failed to apply! Possible dependencies:
0e70447605f4 ("drm/i915: Move common code out of i915_gpu_error.c")
1b36595ffb35 ("drm/i915: Show RING registers through debugfs")
28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management")
3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the 
enabled engines")
82ad6443a55e ("drm/i915/gtt: Rename i915_hw_ppgtt base member")
85fd4f58d7ef ("drm/i915: Mark all non-vma being inserted into the address 
spaces")
9c870d03674f ("drm/i915: Use RPM as the barrier for controlling user mmap 
access")
bb6dc8d96b68 ("drm/i915: Implement pread without struct-mutex")
d636951ec01b ("drm/i915: Cleanup instdone collection")
e007b19d7ba7 ("drm/i915: Use the MRU stack search after evicting")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each 
context in debugfs")
f9e613728090 ("drm/i915: Try to print INSTDONE bits for all slice/subslice")

v4.4.236: Failed to apply! Possible dependencies:
1b683729e7ac ("drm/i915: Remove redundant check in i915_gem_obj_to_vma")
1c7f4bca5a6f ("drm/i915: Rename vma->*_list to *_link for consistency")
3272db53136f ("drm/i915: Combine all i915_vma bitfields into a single set 
of flags")
596c5923197b ("drm/i915: Reduce the pointer dance of i915_is_ggtt()")
c1a415e261aa ("drm/i915: Disable shrinker for non-swapped backed objects")
d0710abbcd88 ("drm/i915: Set the map-and-fenceable flag for preallocated 
objects")
   

Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Program PSR2 selective fetch registers

[Mun, Gwan-gyeong]

On Tue, 2020-09-15 at 12:57 -0700, Souza, Jose wrote:
> On Tue, 2020-09-15 at 20:28 +0100, Mun, Gwan-gyeong wrote:
> > On Mon, 2020-09-14 at 13:15 -0700, Souza, Jose wrote:
> > > On Mon, 2020-09-14 at 17:28 +0300, Ville Syrjälä wrote:
> > > > On Mon, Aug 31, 2020 at 06:09:23PM -0700, José Roberto de Souza
> > > > wrote:
> > > > > Another step towards PSR2 selective fetch, here programming
> > > > > plane
> > > > > selective fetch registers and MAN_TRK_CTL enabling selective
> > > > > fetch but
> > > > > for now it is fetching the whole area of the planes.
> > > > > The damaged area calculation will come as next and final
> > > > > step.
> > > > > 
> > > > > BSpec: 55229
> > > > > Cc: Gwan-gyeong Mun <
> > > > > gwan-gyeong@intel.com
> > > > > 
> > > > > Cc: Ville Syrjälä <
> > > > > ville.syrj...@linux.intel.com
> > > > > 
> > > > > Signed-off-by: José Roberto de Souza <
> > > > > jose.so...@intel.com
> > > > > 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_display.c  |  10 +-
> > > > >  .../drm/i915/display/intel_display_types.h|   2 +
> > > > >  drivers/gpu/drm/i915/display/intel_psr.c  | 129
> > > > > +-
> > > > >  drivers/gpu/drm/i915/display/intel_psr.h  |  10 +-
> > > > >  drivers/gpu/drm/i915/display/intel_sprite.c   |   3 +
> > > > >  5 files changed, 145 insertions(+), 9 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index c8b1dd1a9e46..865486e89915 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -11799,6 +11799,9 @@ static void i9xx_update_cursor(struct
> > > > > intel_plane *plane,
> > > > >   if (INTEL_GEN(dev_priv) >= 9)
> > > > >   skl_write_cursor_wm(plane, crtc_state);
> > > > >  
> > > > > + if (!needs_modeset(crtc_state))
> > > > > + intel_psr2_program_plane_sel_fetch(plane,
> > > > > crtc_state,
> > > > > plane_state, 0);
> > > > > +
> > > > >   if (plane->cursor.base != base ||
> > > > >   plane->cursor.size != fbc_ctl ||
> > > > >   plane->cursor.cntl != cntl) {
> > > > > @@ -12810,8 +12813,11 @@ static int
> > > > > intel_crtc_atomic_check(struct intel_atomic_state *state,
> > > > >  
> > > > >   }
> > > > >  
> > > > > - if (!mode_changed)
> > > > > - intel_psr2_sel_fetch_update(state, crtc);
> > > > > + if (!mode_changed) {
> > > > > + ret = intel_psr2_sel_fetch_update(state, crtc);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > + }
> > > > >  
> > > > >   return 0;
> > > > >  }
> > > > > diff --git
> > > > > a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > index 9349b15afff6..2138bb0f1587 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > @@ -586,6 +586,8 @@ struct intel_plane_state {
> > > > >   u32 planar_slave;
> > > > >  
> > > > >   struct drm_intel_sprite_colorkey ckey;
> > > > > +
> > > > > + struct drm_rect psr2_sel_fetch_area;
> > > > >  };
> > > > >  
> > > > >  struct intel_initial_plane_config {
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > index 6698d0209879..b60ea133a527 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > @@ -1173,6 +1173,46 @@ static void
> > > > > psr_force_hw_tracking_exit(struct drm_i915_private *dev_priv)
> > > > >   intel_psr_exit(dev_priv);
> > > > >  }
> > > > >  
> > > > > +void intel_psr2_program_plane_sel_fetch(struct intel_plane
> > > > > *plane,
> > > > > + const struct
> > > > > intel_crtc_state
> > > > > *crtc_state,
> > > > > + const struct
> > > > > intel_plane_state
> > > > > *plane_state,
> > > > > + int color_plane)
> > > > > +{
> > > > > + struct drm_i915_private *dev_priv = to_i915(plane-
> > > > > >base.dev);
> > > > > + const struct drm_rect *clip;
> > > > > + enum pipe pipe = plane->pipe;
> > > > > + u32 val;
> > > > > +
> > > > > + if (!plane_state || !dev_priv-
> > > > > >psr.psr2_sel_fetch_enabled)
> > > > > + return;
> > > > > +
> > > > > + /*
> > > > > +  * skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0
> > > > > for
> > > > > gen11+, so
> > > > > +  * plane_state->ctl is the right value
> > > > > +  */
> > 
> > As per Bspec 50420,  "SEL_FETCH_PLANE_CTL[31]: Selective Fetch
> > Plane
> > Enable bit" should be set.
> > And when "PSR2_MAN_TRK_CTL[1] : SF Partial Frame Enable bit" is
> > enabled
> > selective fetch will be 

Re: [Intel-gfx] [PATCH v2 16/21] drm/vgem: Introduce GEM object functions

[Melissa Wen]

Hi Thomas,

On 09/15, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in vgem. The only exception is gem_prime_mmap,
> which is non-trivial to convert.
> 
> Signed-off-by: Thomas Zimmermann 

Thanks here again.

This drv file is little tumultuous to me.
I mean, I took a while to sort functions in my head.

However, finally, I got it, and the change looks good.

Reviewed-by: Melissa Wen 

> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index cb884c890065..fa54a6d1403d 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -50,6 +50,8 @@
>  #define DRIVER_MAJOR 1
>  #define DRIVER_MINOR 0
>  
> +static const struct drm_gem_object_funcs vgem_gem_object_funcs;
> +
>  static struct vgem_device {
>   struct drm_device drm;
>   struct platform_device *platform;
> @@ -167,6 +169,8 @@ static struct drm_vgem_gem_object 
> *__vgem_gem_create(struct drm_device *dev,
>   if (!obj)
>   return ERR_PTR(-ENOMEM);
>  
> + obj->base.funcs = _gem_object_funcs;
> +
>   ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
>   if (ret) {
>   kfree(obj);
> @@ -401,12 +405,20 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
>   return 0;
>  }
>  
> +static const struct drm_gem_object_funcs vgem_gem_object_funcs = {
> + .free = vgem_gem_free_object,
> + .pin = vgem_prime_pin,
> + .unpin = vgem_prime_unpin,
> + .get_sg_table = vgem_prime_get_sg_table,
> + .vmap = vgem_prime_vmap,
> + .vunmap = vgem_prime_vunmap,
> + .vm_ops = _gem_vm_ops,
> +};
> +
>  static struct drm_driver vgem_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_RENDER,
>   .open   = vgem_open,
>   .postclose  = vgem_postclose,
> - .gem_free_object_unlocked   = vgem_gem_free_object,
> - .gem_vm_ops = _gem_vm_ops,
>   .ioctls = vgem_ioctls,
>   .num_ioctls = ARRAY_SIZE(vgem_ioctls),
>   .fops   = _driver_fops,
> @@ -415,13 +427,8 @@ static struct drm_driver vgem_driver = {
>  
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_pin = vgem_prime_pin,
> - .gem_prime_unpin = vgem_prime_unpin,
>   .gem_prime_import = vgem_prime_import,
>   .gem_prime_import_sg_table = vgem_prime_import_sg_table,
> - .gem_prime_get_sg_table = vgem_prime_get_sg_table,
> - .gem_prime_vmap = vgem_prime_vmap,
> - .gem_prime_vunmap = vgem_prime_vunmap,
>   .gem_prime_mmap = vgem_prime_mmap,
>  
>   .name   = DRIVER_NAME,
> -- 
> 2.28.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

[Daniel Vetter]

On Thu, Jul 30, 2020 at 06:45:14PM +0200, Thomas Hellström (Intel) wrote:
> 
> On 7/30/20 3:17 PM, Daniel Vetter wrote:
> > On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
> >  wrote:
> > > 
> > > On 7/28/20 3:58 PM, Daniel Vetter wrote:
> > > > GPU drivers need this in their shrinkers, to be able to throw out
> > > > mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
> > > > but that loop is resolved by trylocking in shrinkers.
> > > > 
> > > > So full hierarchy is now (ignore some of the other branches we already
> > > > have primed):
> > > > 
> > > > mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
> > > > 
> > > > I hope that's not inconsistent with anything mm or fs does, adding
> > > > relevant people.
> > > > 
> > > Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but
> > > don't allocate any memory AFAICT.
> > > 
> > > Since huge page-table-entry splitting may happen under the i_mmap_lock
> > > from unmap_mapping_range() it might be worth figuring out how new page
> > > directory pages are allocated, though.
> > ofc I'm not an mm expert at all, but I did try to scroll through all
> > i_mmap_lock_write/read callers. Found the following:
> > 
> > - kernel/events/uprobes.c in build_map_info:
> > 
> >  /*
> >   * Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion through
> >   * reclaim. This is optimistic, no harm done if it fails.
> >   */
> > 
> > - I got lost in the hugetlb.c code and couldn't convince myself it's
> > not allocating page directories at various levels with something else
> > than GFP_KERNEL.
> > 
> > So looks like the recursion is clearly there and known, but the
> > hugepage code is too complex and flying over my head.
> > -Daniel
> 
> OK, so I inverted your annotation and ran a memory hog, and got the below
> splat. So clearly your proposed reclaim->i_mmap_lock locking order is an
> already established one.
> 
> So
> 
> Reviewed-by: Thomas Hellström 

No one complaining that this is a terrible idea and two reviews from
people who know stuff, so I went ahead and pushed this to drm-misc-next.

Thanks for taking a look at this.
-Daniel

> 
> 8<-
> 
> [  308.324654] WARNING: possible circular locking dependency detected
> [  308.324655] 5.8.0-rc2+ #16 Not tainted
> [  308.324656] --
> [  308.324657] kswapd0/98 is trying to acquire lock:
> [  308.324658] 92a16f758428 (>i_mmap_rwsem){}-{3:3}, at:
> rmap_walk_file+0x1c0/0x2f0
> [  308.324663]
>    but task is already holding lock:
> [  308.324664] b0960240 (fs_reclaim){+.+.}-{0:0}, at:
> __fs_reclaim_acquire+0x5/0x30
> [  308.324666]
>    which lock already depends on the new lock.
> 
> [  308.324667]
>    the existing dependency chain (in reverse order) is:
> [  308.324667]
>    -> #1 (fs_reclaim){+.+.}-{0:0}:
> [  308.324670]    fs_reclaim_acquire+0x34/0x40
> [  308.324672]    dma_resv_lockdep+0x186/0x224
> [  308.324675]    do_one_initcall+0x5d/0x2c0
> [  308.324676]    kernel_init_freeable+0x222/0x288
> [  308.324678]    kernel_init+0xa/0x107
> [  308.324679]    ret_from_fork+0x1f/0x30
> [  308.324680]
>    -> #0 (>i_mmap_rwsem){}-{3:3}:
> [  308.324682]    __lock_acquire+0x119f/0x1fc0
> [  308.324683]    lock_acquire+0xa4/0x3b0
> [  308.324685]    down_read+0x2d/0x110
> [  308.324686]    rmap_walk_file+0x1c0/0x2f0
> [  308.324687]    page_referenced+0x133/0x150
> [  308.324689]    shrink_active_list+0x142/0x610
> [  308.324690]    balance_pgdat+0x229/0x620
> [  308.324691]    kswapd+0x200/0x470
> [  308.324693]    kthread+0x11f/0x140
> [  308.324694]    ret_from_fork+0x1f/0x30
> [  308.324694]
>    other info that might help us debug this:
> 
> [  308.324695]  Possible unsafe locking scenario:
> 
> [  308.324695]    CPU0    CPU1
> [  308.324696]        
> [  308.324696]   lock(fs_reclaim);
> [  308.324697] lock(>i_mmap_rwsem);
> [  308.324698]    lock(fs_reclaim);
> [  308.324699]   lock(>i_mmap_rwsem);
> [  308.324699]
>     *** DEADLOCK ***
> 
> [  308.324700] 1 lock held by kswapd0/98:
> [  308.324701]  #0: b0960240 (fs_reclaim){+.+.}-{0:0}, at:
> __fs_reclaim_acquire+0x5/0x30
> [  308.324702]
>    stack backtrace:
> [  308.324704] CPU: 1 PID: 98 Comm: kswapd0 Not tainted 5.8.0-rc2+ #16
> [  308.324705] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
> Desktop Reference Platform, BIOS 6.00 07/29/2019
> [  308.324706] Call Trace:
> [  308.324710]  dump_stack+0x92/0xc8
> [  308.324711]  check_noncircular+0x12d/0x150
> [  308.324713]  __lock_acquire+0x119f/0x1fc0
> [  308.324715]  lock_acquire+0xa4/0x3b0
> [  

Re: [Intel-gfx] [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, September 17, 2020 6:08 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; B 
> S,
> Karthik 
> Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode
> 
> On Thu, Sep 17, 2020 at 11:56:44AM +, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Thursday, September 17, 2020 5:01 PM
> > > To: Kulkarni, Vandita 
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > ; B S, Karthik 
> > > Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd
> > > mode
> > >
> > > On Wed, Sep 16, 2020 at 09:45:28PM +0530, Vandita Kulkarni wrote:
> > > > In TE Gate mode or TE NO_GATE mode on every flip we need to set
> > > > the frame update request bit.
> > > > After this  bit is set transcoder hardware will automatically send
> > > > the frame data to the panel in case of TE NO_GATE mode, where it
> > > > sends after it receives the TE event in case of TE_GATE mode.
> > > > Once the frame data is sent to the panel, we see the frame counter
> > > > updating.
> > > >
> > > > v2: Use intel_de_read/write
> > > >
> > > > v3: remove the usage of private_flags
> > > >
> > > > v4: Use icl_dsi in func names if non static,
> > > > fix code formatting issues. (Jani)
> > > >
> > > > Signed-off-by: Vandita Kulkarni 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/icl_dsi.c   | 26
> 
> > > >  drivers/gpu/drm/i915/display/intel_display.c | 10 
> > > >  drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
> > > >  3 files changed, 37 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > index 2789020e20db..7d2abc7f6ba3 100644
> > > > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct
> > > > intel_dsi_host
> > > *host,
> > > > return 0;
> > > >  }
> > > >
> > > > +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state) {
> > > > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > +   u32 tmp, flags;
> > > > +   enum port port;
> > > > +
> > > > +   flags = crtc->mode_flags;
> > > > +
> > > > +   /*
> > > > +* case 1 also covers dual link
> > > > +* In case of dual link, frame update should be set on
> > > > +* DSI_0
> > > > +*/
> > > > +   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > > > +   port = PORT_A;
> > > > +   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > > > +   port = PORT_B;
> > > > +   else
> > > > +   return;
> > > > +
> > > > +   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > > > +   tmp |= DSI_FRAME_UPDATE_REQUEST;
> > > > +   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > > > +
> > > >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > > > *encoder)  {
> > > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > diff
> > > > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index f862403388f6..11a20bf2255f 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -15621,6 +15621,16 @@ static void
> > > > intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > > > intel_set_cdclk_post_plane_update(state);
> > > > }
> > > >
> > > > +   /*
> > > > +* Incase of mipi dsi command mode, we need to set frame update
> > > > +* for every commit
> > > > +*/
> > > > +   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> > > > +   if (INTEL_GEN(dev_priv) >= 11 &&
> > > > +   intel_crtc_has_type(new_crtc_state, 
> > > > INTEL_OUTPUT_DSI))
> > > > +   if (new_crtc_state->hw.active)
> > > > +   icl_dsi_frame_update(new_crtc_state);
> > >
> > > If this is the thing that triggers the update then it should
> > > probably be called at the start of intel_pipe_update_end().
> >
> > I could move it to the end of intel_pipe_update_end, as we need TE to be
> enabled.
> > Because if the frame updates are gated then, the dsi controller will
> > not drive the vblank/ frame start to the display engine until it receives a 
> > TE
> in the presence of the frame update request.
> > And if we are in non gated mode then the dsi controller will
> > immediately drive the vblank/frame strart as soon as it receives the frame
> update request.
> >
> > So is it ok if I move it to the end of pipe_update_end..
> 
> Sounds racy. Though TBH I can't tell whether the 

Re: [Intel-gfx] [PATCH v2 10/18] drm/dp: Add drm_dp_downstream_{min, max}_tmds_clock()

[Ville Syrjälä]

On Tue, Sep 08, 2020 at 02:04:56PM -0400, Lyude Paul wrote:
> On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Add helpers to get the TMDS clock limits for HDMI/DVI downstream
> > facing ports.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 116 
> >  include/drm/drm_dp_helper.h |   6 ++
> >  2 files changed, 122 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 822a30e609ef..f567428f2aef 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -643,6 +643,114 @@ int drm_dp_downstream_max_dotclock(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE],
> >  }
> >  EXPORT_SYMBOL(drm_dp_downstream_max_dotclock);
> >  
> > +/**
> > + * drm_dp_downstream_max_tmds_clock() - extract downstream facing port max
> > TMDS clock
> > + * @dpcd: DisplayPort configuration data
> > + * @port_cap: port capabilities
> > + * @edid: EDID
> > + *
> > + * Returns HDMI/DVI downstream facing port max TMDS clock in kHz on
> > success,
> > + * or 0 if max TMDS clock not defined
> > + */
> > +int drm_dp_downstream_max_tmds_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > +const u8 port_cap[4],
> > +const struct edid *edid)
> > +{
> > +   if (!drm_dp_is_branch(dpcd))
> > +   return 0;
> > +
> > +   if (dpcd[DP_DPCD_REV] < 0x11) {
> > +   switch (dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > DP_DWN_STRM_PORT_TYPE_MASK) {
> > +   case DP_DWN_STRM_PORT_TYPE_TMDS:
> > +   return 165000;
> > +   default:
> > +   return 0;
> > +   }
> > +   }
> > +
> > +   switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> > +   case DP_DS_PORT_TYPE_DP_DUALMODE:
> > +   if (is_edid_digital_input_dp(edid))
> > +   return 0;
> > +   /*
> > +* It's left up to the driver to check the
> > +* DP dual mode adapter's max TMDS clock.
> > +*
> > +* Unfortunatley it looks like branch devices
> > +* may not fordward that the DP dual mode i2c
> > +* access so we just usually get i2c nak :(
> > +*/
> > +   fallthrough;
> > +   case DP_DS_PORT_TYPE_HDMI:
> > +/*
> > + * We should perhaps assume 165 MHz when detailed cap
> > + * info is not available. But looks like many typical
> > + * branch devices fall into that category and so we'd
> > + * probably end up with users complaining that they can't
> > + * get high resolution modes with their favorite dongle.
> > + *
> > + * So let's limit to 300 MHz instead since DPCD 1.4
> > + * HDMI 2.0 DFPs are required to have the detailed cap
> > + * info. So it's more likely we're dealing with a HDMI 1.4
> > + * compatible* device here.
> > + */
> > +   if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> > +   return 30;
> > +   return port_cap[1] * 2500;
> > +   case DP_DS_PORT_TYPE_DVI:
> > +   if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> > +   return 165000;
> > +   /* FIXME what to do about DVI dual link? */
> > +   return port_cap[1] * 2500;
> > +   default:
> > +   return 0;
> > +   }
> > +}
> > +EXPORT_SYMBOL(drm_dp_downstream_max_tmds_clock);
> > +
> > +/**
> > + * drm_dp_downstream_min_tmds_clock() - extract downstream facing port min
> > TMDS clock
> > + * @dpcd: DisplayPort configuration data
> > + * @port_cap: port capabilities
> > + * @edid: EDID
> > + *
> > + * Returns HDMI/DVI downstream facing port min TMDS clock in kHz on
> > success,
> > + * or 0 if max TMDS clock not defined
> 
> s/max/min/
> 
> Also, I would assume if callers are interested in min they're also interested
> in max and vice versa, would it maybe make sense to combine the min/max
> functions here?

Returning multiple things in C requires ugly stuff, so I try to avoid
it.

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

Re: [Intel-gfx] [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode

[Ville Syrjälä]

On Thu, Sep 17, 2020 at 11:56:44AM +, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Ville Syrjälä 
> > Sent: Thursday, September 17, 2020 5:01 PM
> > To: Kulkarni, Vandita 
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; 
> > B S,
> > Karthik 
> > Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode
> > 
> > On Wed, Sep 16, 2020 at 09:45:28PM +0530, Vandita Kulkarni wrote:
> > > In TE Gate mode or TE NO_GATE mode on every flip we need to set the
> > > frame update request bit.
> > > After this  bit is set transcoder hardware will automatically send the
> > > frame data to the panel in case of TE NO_GATE mode, where it sends
> > > after it receives the TE event in case of TE_GATE mode.
> > > Once the frame data is sent to the panel, we see the frame counter
> > > updating.
> > >
> > > v2: Use intel_de_read/write
> > >
> > > v3: remove the usage of private_flags
> > >
> > > v4: Use icl_dsi in func names if non static,
> > > fix code formatting issues. (Jani)
> > >
> > > Signed-off-by: Vandita Kulkarni 
> > > ---
> > >  drivers/gpu/drm/i915/display/icl_dsi.c   | 26 
> > >  drivers/gpu/drm/i915/display/intel_display.c | 10 
> > >  drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
> > >  3 files changed, 37 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > index 2789020e20db..7d2abc7f6ba3 100644
> > > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host
> > *host,
> > >   return 0;
> > >  }
> > >
> > > +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state) {
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > + u32 tmp, flags;
> > > + enum port port;
> > > +
> > > + flags = crtc->mode_flags;
> > > +
> > > + /*
> > > +  * case 1 also covers dual link
> > > +  * In case of dual link, frame update should be set on
> > > +  * DSI_0
> > > +  */
> > > + if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > > + port = PORT_A;
> > > + else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > > + port = PORT_B;
> > > + else
> > > + return;
> > > +
> > > + tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > > + tmp |= DSI_FRAME_UPDATE_REQUEST;
> > > + intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > > +
> > >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > > *encoder)  {
> > >   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > diff
> > > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index f862403388f6..11a20bf2255f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -15621,6 +15621,16 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> > >   intel_set_cdclk_post_plane_update(state);
> > >   }
> > >
> > > + /*
> > > +  * Incase of mipi dsi command mode, we need to set frame update
> > > +  * for every commit
> > > +  */
> > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> > > + if (INTEL_GEN(dev_priv) >= 11 &&
> > > + intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
> > > + if (new_crtc_state->hw.active)
> > > + icl_dsi_frame_update(new_crtc_state);
> > 
> > If this is the thing that triggers the update then it should probably be 
> > called at
> > the start of intel_pipe_update_end().
> 
> I could move it to the end of intel_pipe_update_end, as we need TE to be 
> enabled.
> Because if the frame updates are gated then, the dsi controller will not 
> drive the vblank/ frame start to the display engine
> until it receives a TE in the presence of the frame update request.
> And if we are in non gated mode then the dsi controller will immediately 
> drive the vblank/frame strart as soon as it receives the
> frame update request.
> 
> So is it ok if I move it to the end of pipe_update_end..

Sounds racy. Though TBH I can't tell whether the we'd still fire
off the event at the right time if we kick the update at the start.
Once kicked, is the frame upload going to wait for the TE and then
try to stay ahead of the raster beam?

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Check PSR parameter and flag only in state compute phase

[Ville Syrjälä]

On Tue, Sep 15, 2020 at 07:44:10PM -0700, José Roberto de Souza wrote:
> Due to the debugfs flag, has_psr2 in CRTC state could have a different
> value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
> and selective fetch) to be set to not a expected state.
> 
> So here only taking in consideration the parameter and debugfs flag
> when computing PSR state, this way the CRTC state will also have
> the correct state.
> 
> intel_psr_fastset_force() was already broken as
> intel_psr_compute_config() was already only enabling PSR when
> psr_global_enabled() and all other PSR requirements are met.
> So some changes was required in this function, now it iterates over
> all connectors, if it is a eDP connector and is active force a modeset
> in the CRTC driving this connector, what will cause the new PSR state
> to be set based on the debugfs flag.
> 
> Cc: Gwan-gyeong Mun 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 

Looks sensible.
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 65 ++--
>  1 file changed, 37 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 4e09ae61d4aa..383b66d9f2f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -91,19 +91,14 @@ static bool psr_global_enabled(struct drm_i915_private 
> *i915)
>   }
>  }
>  
> -static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
> -const struct intel_crtc_state *crtc_state)
> +static bool psr2_global_enabled(struct drm_i915_private *dev_priv)
>  {
> - /* Cannot enable DSC and PSR2 simultaneously */
> - drm_WARN_ON(_priv->drm, crtc_state->dsc.compression_enable &&
> - crtc_state->has_psr2);
> -
>   switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
>   case I915_PSR_DEBUG_DISABLE:
>   case I915_PSR_DEBUG_FORCE_PSR1:
>   return false;
>   default:
> - return crtc_state->has_psr2;
> + return true;
>   }
>  }
>  
> @@ -729,6 +724,11 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   return false;
>   }
>  
> + if (!psr2_global_enabled(dev_priv)) {
> + drm_dbg_kms(_priv->drm, "PSR2 disabled by flag\n");
> + return false;
> + }
> +
>   /*
>* DSC and PSR2 cannot be enabled simultaneously. If a requested
>* resolution requires DSC to be enabled, priority is given to DSC
> @@ -817,8 +817,11 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>   if (intel_dp != dev_priv->psr.dp)
>   return;
>  
> - if (!psr_global_enabled(dev_priv))
> + if (!psr_global_enabled(dev_priv)) {
> + drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
>   return;
> + }
> +
>   /*
>* HSW spec explicitly says PSR is tied to port A.
>* BDW+ platforms have a instance of PSR registers per transcoder but
> @@ -959,7 +962,7 @@ static void intel_psr_enable_locked(struct 
> drm_i915_private *dev_priv,
>  
>   drm_WARN_ON(_priv->drm, dev_priv->psr.enabled);
>  
> - dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
> + dev_priv->psr.psr2_enabled = crtc_state->has_psr2;
>   dev_priv->psr.busy_frontbuffer_bits = 0;
>   dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
>   dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
> @@ -1029,15 +1032,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   drm_WARN_ON(_priv->drm, dev_priv->drrs.dp);
>  
>   mutex_lock(_priv->psr.lock);
> -
> - if (!psr_global_enabled(dev_priv)) {
> - drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
> - goto unlock;
> - }
> -
>   intel_psr_enable_locked(dev_priv, crtc_state, conn_state);
> -
> -unlock:
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> @@ -1222,8 +1217,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
>  
>   mutex_lock(_priv->psr.lock);
>  
> - enable = crtc_state->has_psr && psr_global_enabled(dev_priv);
> - psr2_enable = intel_psr2_enabled(dev_priv, crtc_state);
> + enable = crtc_state->has_psr;
> + psr2_enable = crtc_state->has_psr2;
>  
>   if (enable == psr->enabled && psr2_enable == psr->psr2_enabled) {
>   /* Force a PSR exit when enabling CRC to avoid CRC timeouts */
> @@ -1320,10 +1315,11 @@ static bool __psr_wait_for_idle_locked(struct 
> drm_i915_private *dev_priv)
>  
>  static int intel_psr_fastset_force(struct drm_i915_private *dev_priv)
>  {
> + struct drm_connector_list_iter conn_iter;
>   struct drm_device *dev = _priv->drm;
>   struct drm_modeset_acquire_ctx ctx;
>   struct drm_atomic_state *state;
> - struct intel_crtc *crtc;
> + struct drm_connector *conn;
>   int err;
>  
>   

Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.

[Ville Syrjälä]

On Tue, Sep 15, 2020 at 04:03:45PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 10:47:56PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 12:38:57PM -0700, Navare, Manasi wrote:
> > > On Mon, Sep 14, 2020 at 10:17:57PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> > > > > On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > > > > > On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > > > > > > From: Maarten Lankhorst 
> > > > > > > 
> > > > > > > Small changes to intel_dp_mode_valid(), allow listing modes that
> > > > > > > can only be supported in the bigjoiner configuration, which is
> > > > > > > not supported yet.
> > > > > > > 
> > > > > > > eDP does not support bigjoiner, so do not expose bigjoiner only
> > > > > > > modes on the eDP port.
> > > > > > > 
> > > > > > > v5:
> > > > > > > * Increase max plane width to support 8K with bigjoiner (Maarten)
> > > > > > > v4:
> > > > > > > * Rebase (Manasi)
> > > > > > > 
> > > > > > > Changes since v1:
> > > > > > > - Disallow bigjoiner on eDP.
> > > > > > > Changes since v2:
> > > > > > > - Rename intel_dp_downstream_max_dotclock to 
> > > > > > > intel_dp_max_dotclock,
> > > > > > >   and split off the downstream and source checking to its own 
> > > > > > > function.
> > > > > > >   (Ville)
> > > > > > > v3:
> > > > > > > * Rebase (Manasi)
> > > > > > > 
> > > > > > > Signed-off-by: Manasi Navare 
> > > > > > > Signed-off-by: Maarten Lankhorst 
> > > > > > > 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/display/intel_display.c |   2 +-
> > > > > > >  drivers/gpu/drm/i915/display/intel_dp.c  | 119 
> > > > > > > ++-
> > > > > > >  2 files changed, 91 insertions(+), 30 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > index 78cbfefbfa62..3ecb642805a6 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > @@ -17400,7 +17400,7 @@ intel_mode_valid_max_plane_size(struct 
> > > > > > > drm_i915_private *dev_priv,
> > > > > > >* too big for that.
> > > > > > >*/
> > > > > > >   if (INTEL_GEN(dev_priv) >= 11) {
> > > > > > > - plane_width_max = 5120;
> > > > > > > + plane_width_max = 7680;
> > > > > > 
> > > > > > This looks misplaced. Planes do no know whether bigjoiner can be 
> > > > > > used or
> > > > > > not. They should not care in fact. The caller should have that 
> > > > > > knowledge
> > > > > > and can deal with it properly.
> > > > > 
> > > > > Hmm, so the caller of intel_mode_valid_max_plane_size() should check 
> > > > > on the bigjoiner
> > > > > flag and perhaps if bigjoiner is true then increase the 
> > > > > plane_width_max to 7680?
> > > > > 
> > > > > Am still not sure where this should happen? We need to have the plane 
> > > > > max width to be 7680
> > > > > before we prune the 8K mode in intel_mode_valid
> > > > > 
> > > > > Where should this be added according to you?
> > > > 
> > > > Hmm. I guess we do need to put it into this function given the way this
> > > > is structured. However we still can't assume bigjoiner can be used since
> > > > it can't be used on DDI A on icl. So we should probably just pass in a
> > > > bool here to indicate whether bigjoiner can be used or not.
> > > >
> > > 
> > > So in intel_dp_mode_valid() we set bigjoiner = true if not edp and higher 
> > > clock.
> > > I think here we need to do the platform check also, 1. because now we are 
> > > enabling this for TGL+
> > > where big joiner on all pipes. But we should still I think add GEN >=12 
> > > check before setting bigjoiner
> > > to true in intel_dp_mode_valid() and then pass that to 
> > > intel_mode_valid_max_plane_size(..., book bigjoiner)
> > 
> > can_bigjoiner() {
> > return gen >= 12 || (gen==11 && port!=A);
> > }
> 
> Hmm, gen check can be done but can the port check be done in 
> intel_dp_mode_valid() since we dont have
> an encoder yet?

The encoder is there already.

> Else we set the bigjoiner to true here based on gen check but add the port 
> check later in compute_config at
> what point if not supported then encoder config will fail.
> 
> or can this be sufficient check:
> 
> can_bigjoiner() {
>   return gen >= 12 || (gen == 11 && !intel_dp_is_edp())
> }
> 
> Manasi
> 
> > 
> > or something.
> > 
> > > 
> > > Sounds good?
> > > 
> > > > Personally I'd just write the thing as something like:
> > > > intel_mode_valid_max_plane_size(..., bool bigjoiner)
> > > > {
> > > > ...
> > > > plane_width_max = 5120 << bigjoiner;
> > > > ...
> > > > }
> > > > 
> > > > > 
> > > > > Manasi
> > > > > > 
> > > > > > >   plane_height_max = 4320;
> > > > > > >   } else {
> > > > > > >   plane_width_max = 5120;
> > > > > > > diff --git 

Re: [Intel-gfx] [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, September 17, 2020 5:01 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; B 
> S,
> Karthik 
> Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode
> 
> On Wed, Sep 16, 2020 at 09:45:28PM +0530, Vandita Kulkarni wrote:
> > In TE Gate mode or TE NO_GATE mode on every flip we need to set the
> > frame update request bit.
> > After this  bit is set transcoder hardware will automatically send the
> > frame data to the panel in case of TE NO_GATE mode, where it sends
> > after it receives the TE event in case of TE_GATE mode.
> > Once the frame data is sent to the panel, we see the frame counter
> > updating.
> >
> > v2: Use intel_de_read/write
> >
> > v3: remove the usage of private_flags
> >
> > v4: Use icl_dsi in func names if non static,
> > fix code formatting issues. (Jani)
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c   | 26 
> >  drivers/gpu/drm/i915/display/intel_display.c | 10 
> >  drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
> >  3 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 2789020e20db..7d2abc7f6ba3 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host
> *host,
> > return 0;
> >  }
> >
> > +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state) {
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +   u32 tmp, flags;
> > +   enum port port;
> > +
> > +   flags = crtc->mode_flags;
> > +
> > +   /*
> > +* case 1 also covers dual link
> > +* In case of dual link, frame update should be set on
> > +* DSI_0
> > +*/
> > +   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > +   port = PORT_A;
> > +   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > +   port = PORT_B;
> > +   else
> > +   return;
> > +
> > +   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > +   tmp |= DSI_FRAME_UPDATE_REQUEST;
> > +   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > +
> >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > *encoder)  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index f862403388f6..11a20bf2255f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15621,6 +15621,16 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> > intel_set_cdclk_post_plane_update(state);
> > }
> >
> > +   /*
> > +* Incase of mipi dsi command mode, we need to set frame update
> > +* for every commit
> > +*/
> > +   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> > +   if (INTEL_GEN(dev_priv) >= 11 &&
> > +   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
> > +   if (new_crtc_state->hw.active)
> > +   icl_dsi_frame_update(new_crtc_state);
> 
> If this is the thing that triggers the update then it should probably be 
> called at
> the start of intel_pipe_update_end().

I could move it to the end of intel_pipe_update_end, as we need TE to be 
enabled.
Because if the frame updates are gated then, the dsi controller will not drive 
the vblank/ frame start to the display engine
until it receives a TE in the presence of the frame update request.
And if we are in non gated mode then the dsi controller will immediately drive 
the vblank/frame strart as soon as it receives the
frame update request.

So is it ok if I move it to the end of pipe_update_end..

Thanks,
Vandita
> 
> > +
> > /* FIXME: We should call drm_atomic_helper_commit_hw_done()
> here
> >  * already, but still need the state for the delayed optimization. To
> >  * fix this:
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h
> > b/drivers/gpu/drm/i915/display/intel_dsi.h
> > index 19f78a4022d3..625f2f1ae061 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> > @@ -167,6 +167,7 @@ static inline u16 intel_dsi_encoder_ports(struct
> > intel_encoder *encoder)
> >
> >  /* icl_dsi.c */
> >  void icl_dsi_init(struct drm_i915_private *dev_priv);
> > +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state);
> >
> >  /* intel_dsi.c */
> >  int intel_dsi_bitrate(const struct intel_dsi *intel_dsi);
> > --
> > 2.21.0.5.gaeb582a
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list

Re: [Intel-gfx] [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode

[Ville Syrjälä]

On Wed, Sep 16, 2020 at 09:45:28PM +0530, Vandita Kulkarni wrote:
> In TE Gate mode or TE NO_GATE mode on every flip
> we need to set the frame update request bit.
> After this  bit is set transcoder hardware will
> automatically send the frame data to the panel
> in case of TE NO_GATE mode, where it sends after
> it receives the TE event in case of TE_GATE mode.
> Once the frame data is sent to the panel, we see
> the frame counter updating.
> 
> v2: Use intel_de_read/write
> 
> v3: remove the usage of private_flags
> 
> v4: Use icl_dsi in func names if non static,
> fix code formatting issues. (Jani)
> 
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c   | 26 
>  drivers/gpu/drm/i915/display/intel_display.c | 10 
>  drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
>  3 files changed, 37 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 2789020e20db..7d2abc7f6ba3 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host 
> *host,
>   return 0;
>  }
>  
> +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + u32 tmp, flags;
> + enum port port;
> +
> + flags = crtc->mode_flags;
> +
> + /*
> +  * case 1 also covers dual link
> +  * In case of dual link, frame update should be set on
> +  * DSI_0
> +  */
> + if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> + port = PORT_A;
> + else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> + port = PORT_B;
> + else
> + return;
> +
> + tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> + tmp |= DSI_FRAME_UPDATE_REQUEST;
> + intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp);
> +}
> +
>  static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f862403388f6..11a20bf2255f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15621,6 +15621,16 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   intel_set_cdclk_post_plane_update(state);
>   }
>  
> + /*
> +  * Incase of mipi dsi command mode, we need to set frame update
> +  * for every commit
> +  */
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> + if (INTEL_GEN(dev_priv) >= 11 &&
> + intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
> + if (new_crtc_state->hw.active)
> + icl_dsi_frame_update(new_crtc_state);

If this is the thing that triggers the update then it should
probably be called at the start of intel_pipe_update_end().

> +
>   /* FIXME: We should call drm_atomic_helper_commit_hw_done() here
>* already, but still need the state for the delayed optimization. To
>* fix this:
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h 
> b/drivers/gpu/drm/i915/display/intel_dsi.h
> index 19f78a4022d3..625f2f1ae061 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> @@ -167,6 +167,7 @@ static inline u16 intel_dsi_encoder_ports(struct 
> intel_encoder *encoder)
>  
>  /* icl_dsi.c */
>  void icl_dsi_init(struct drm_i915_private *dev_priv);
> +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state);
>  
>  /* intel_dsi.c */
>  int intel_dsi_bitrate(const struct intel_dsi *intel_dsi);
> -- 
> 2.21.0.5.gaeb582a

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

Re: [Intel-gfx] [PATCH v2 18/21] drm/vkms: Introduce GEM object functions

[Melissa Wen]

Hi Thomas,

On 09/15, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in vkms.
> 
> Signed-off-by: Thomas Zimmermann 

Thanks! Looks fine.

Reviewed-by: Melissa Wen 

> ---
>  drivers/gpu/drm/vkms/vkms_drv.c |  8 
>  drivers/gpu/drm/vkms/vkms_gem.c | 13 +
>  2 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index cb0b6230c22c..726801ab44d4 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -51,12 +51,6 @@ static const struct file_operations vkms_driver_fops = {
>   .release= drm_release,
>  };
>  
> -static const struct vm_operations_struct vkms_gem_vm_ops = {
> - .fault = vkms_gem_fault,
> - .open = drm_gem_vm_open,
> - .close = drm_gem_vm_close,
> -};
> -
>  static void vkms_release(struct drm_device *dev)
>  {
>   struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
> @@ -98,8 +92,6 @@ static struct drm_driver vkms_driver = {
>   .release= vkms_release,
>   .fops   = _driver_fops,
>   .dumb_create= vkms_dumb_create,
> - .gem_vm_ops = _gem_vm_ops,
> - .gem_free_object_unlocked = vkms_gem_free_object,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>  
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index a017fc59905e..19a0e260a4df 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -7,6 +7,17 @@
>  
>  #include "vkms_drv.h"
>  
> +static const struct vm_operations_struct vkms_gem_vm_ops = {
> + .fault = vkms_gem_fault,
> + .open = drm_gem_vm_open,
> + .close = drm_gem_vm_close,
> +};
> +
> +static const struct drm_gem_object_funcs vkms_gem_object_funcs = {
> + .free = vkms_gem_free_object,
> + .vm_ops = _gem_vm_ops,
> +};
> +
>  static struct vkms_gem_object *__vkms_gem_create(struct drm_device *dev,
>u64 size)
>  {
> @@ -17,6 +28,8 @@ static struct vkms_gem_object *__vkms_gem_create(struct 
> drm_device *dev,
>   if (!obj)
>   return ERR_PTR(-ENOMEM);
>  
> + obj->gem.funcs = _gem_object_funcs;
> +
>   size = roundup(size, PAGE_SIZE);
>   ret = drm_gem_object_init(dev, >gem, size);
>   if (ret) {
> -- 
> 2.28.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce a ww transaction utility

[Patchwork]

== Series Details ==

Series: Introduce a ww transaction utility
URL   : https://patchwork.freedesktop.org/series/81787/
State : failure

== Summary ==

Applying: drm/i915: Break out dma_resv ww locking utilities to separate files
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/gem/i915_gem_object.h).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915: Break out dma_resv ww locking utilities to 
separate files
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

Re: [Intel-gfx] [PATCH v2 14/21] drm/tegra: Introduce GEM object functions

[Thierry Reding]

On Tue, Sep 15, 2020 at 04:59:51PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in tegra.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/tegra/drm.c | 4 
>  drivers/gpu/drm/tegra/gem.c | 8 
>  2 files changed, 8 insertions(+), 4 deletions(-)

Acked-by: Thierry Reding 


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

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix an error code i915_gem_object_copy_blt()

[Maarten Lankhorst]

Op 11-09-2020 om 09:52 schreef Dan Carpenter:
> This code should use "vma[1]" instead of "vma".  The "vma" variable is a
> valid pointer.
>
> Fixes: 6b05030496f7 ("drm/i915: Convert i915_gem_object/client_blt.c to use 
> ww locking as well, v2.")
> Signed-off-by: Dan Carpenter 
> Reviewed-by: Mika Kuoppala 
> ---
> v2: Fix confusing typo in the commit message
>
>  drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> index d93eb36160c9..aee7ad3cc3c6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> @@ -364,7 +364,7 @@ int i915_gem_object_copy_blt(struct drm_i915_gem_object 
> *src,
>  
>   vma[1] = i915_vma_instance(dst, vm, NULL);
>   if (IS_ERR(vma[1]))
> - return PTR_ERR(vma);
> + return PTR_ERR(vma[1]);
>  
>   i915_gem_ww_ctx_init(, true);
>   intel_engine_pm_get(ce->engine);

Thanks, applied to drm-intel-gt-next. :)

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

[Intel-gfx] [RFC PATCH 0/2] Introduce a ww transaction utility

[Intel]

A ww transaction utility intended to help removing the
obj->mm.lock from the driver and introduce ww transactions
in a robust way.

Patch 1/2 breaks the current i915 utilities out to separate files
Patch 2/2 introduces the ww transaction utility

A similar utility could easily be introduced in the core
ww_mutex code, allowing even for cross-driver ww transactions,
and the template argument could then allow for per-ww-class derived
ww_acquire_mutex types. To facilitate a core implementation, (since we
can never guarantee the contended lock stays alive), we'd need a

void ww_mutex_relax(struct ww_acquire_ctx *)

and its interruptible variant that does the equivalent of
locking and unlocking the contended mutex.

With this driver implementation, we can extend the code to take a
reference on the object containing the contended lock to make sure
it stays alive.

Finally, the drawback of the current implementation is the use of the hash
table and corresponding performance cost, but as mentioned in
patch 2, a core variant could probably do this in a much more
efficient way.


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

[Intel-gfx] [RFC PATCH 1/2] drm/i915: Break out dma_resv ww locking utilities to separate files

[Intel]

From: Thomas Hellström 

As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/Makefile   |  1 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h  |  1 +
 drivers/gpu/drm/i915/gt/intel_renderstate.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 64 --
 drivers/gpu/drm/i915/i915_gem.h | 15 -
 drivers/gpu/drm/i915/i915_gem_ww.c  | 72 +
 drivers/gpu/drm/i915/i915_gem_ww.h  | 23 +++
 7 files changed, 98 insertions(+), 79 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.c
 create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 58d129b5a65a..71503bc26d98 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -45,6 +45,7 @@ i915-y += i915_drv.o \
  i915_switcheroo.o \
  i915_sysfs.o \
  i915_utils.o \
+ i915_gem_ww.o \
  intel_device_info.o \
  intel_dram.o \
  intel_memory_region.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index f084a25c5121..cd64b1fdf53c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -15,6 +15,7 @@
 #include "i915_gem_object_types.h"
 #include "i915_gem_gtt.h"
 #include "i915_vma_types.h"
+#include "i915_gem_ww.h"
 
 void i915_gem_init__objects(struct drm_i915_private *i915);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.h 
b/drivers/gpu/drm/i915/gt/intel_renderstate.h
index 713aa1e86c80..d9db833b873b 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.h
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.h
@@ -26,6 +26,7 @@
 
 #include 
 #include "i915_gem.h"
+#include "i915_gem_ww.h"
 
 struct i915_request;
 struct intel_context;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3f83ac729644..fa1b7861b954 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1365,70 +1365,6 @@ int i915_gem_open(struct drm_i915_private *i915, struct 
drm_file *file)
return ret;
 }
 
-void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ww, bool intr)
-{
-   ww_acquire_init(>ctx, _ww_class);
-   INIT_LIST_HEAD(>obj_list);
-   ww->intr = intr;
-   ww->contended = NULL;
-}
-
-static void i915_gem_ww_ctx_unlock_all(struct i915_gem_ww_ctx *ww)
-{
-   struct drm_i915_gem_object *obj;
-
-   while ((obj = list_first_entry_or_null(>obj_list, struct 
drm_i915_gem_object, obj_link))) {
-   if (WARN_ON(!kref_read(>base.refcount))) {
-   unsigned long *entries;
-   unsigned int nr_entries;
-
-   nr_entries = stack_depot_fetch(obj->bt, );
-   stack_trace_print(entries, nr_entries, 4);
-   }
-
-   obj->bt = 0;
-   list_del(>obj_link);
-   i915_gem_object_unlock(obj);
-   }
-}
-
-void i915_gem_ww_unlock_single(struct drm_i915_gem_object *obj)
-{
-   list_del(>obj_link);
-   i915_gem_object_unlock(obj);
-}
-
-void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ww)
-{
-   i915_gem_ww_ctx_unlock_all(ww);
-   WARN_ON(ww->contended);
-   ww_acquire_fini(>ctx);
-}
-
-int __must_check i915_gem_ww_ctx_backoff(struct i915_gem_ww_ctx *ww)
-{
-   int ret = 0;
-
-   if (WARN_ON(!ww->contended))
-   return -EINVAL;
-
-   i915_gem_ww_ctx_unlock_all(ww);
-   if (ww->intr)
-   ret = 
dma_resv_lock_slow_interruptible(ww->contended->base.resv, >ctx);
-   else
-   dma_resv_lock_slow(ww->contended->base.resv, >ctx);
-
-   if (!ret) {
-   list_add_tail(>contended->obj_link, >obj_list);
-   ww->contended->bt = ww->contended_bt;
-   }
-
-   ww->contended = NULL;
-   ww->contended_bt = 0;
-
-   return ret;
-}
-
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_gem_device.c"
 #include "selftests/i915_gem.c"
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 4d50afab43f2..db0b2835095d 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -27,8 +27,6 @@
 
 #include 
 #include 
-#include 
-#include 
 #include 
 
 #include "i915_utils.h"
@@ -117,17 +115,4 @@ static inline bool __tasklet_is_scheduled(struct 
tasklet_struct *t)
return test_bit(TASKLET_STATE_SCHED, >state);
 }
 
-struct i915_gem_ww_ctx {
-   struct ww_acquire_ctx ctx;
-   struct list_head obj_list;
-   bool intr;
-   struct drm_i915_gem_object *contended;
-   depot_stack_handle_t contended_bt;
-};
-
-void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ctx, bool intr);
-void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx 

[Intel-gfx] [RFC PATCH 2/2] drm/i915: Introduce a i915_gem_do_ww(){} utility

[Intel]

From: Thomas Hellström 

With the huge number of sites where multiple-object locking is
needed in the driver, it becomes difficult to avoid recursive
ww_acquire_ctx initialization, and the function prototypes become
bloated passing the ww_acquire_ctx around. Furthermore it's not
always easy to get the -EDEADLK handling correct and to follow it.

Introduce a i915_gem_do_ww utility that tries to remedy all these problems
by enclosing parts of a ww transaction in the following way:

my_function() {
struct i915_gem_ww_ctx *ww, template;
int err;
bool interruptible = true;

i915_do_ww(ww, , err, interruptible) {
err = ww_transaction_part(ww);
}
return err;
}

The utility will automatically look up an active ww_acquire_ctx if one
is initialized previously in the call chain, and if one found will
forward the -EDEADLK instead of handling it, which takes care of the
recursive initalization. Using the utility also discourages nested ww
unlocking / relocking that is both very fragile and hard to follow.

To look up and register an active ww_acquire_ctx, use a
driver-wide hash table for now. But noting that a task could only have
a single active ww_acqurie_ctx per ww_class, the active CTX is really
task state and a generic version of this utility in the ww_mutex code
could thus probably use a quick lookup from a list in the
struct task_struct.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_gem_ww.c | 73 +-
 drivers/gpu/drm/i915/i915_gem_ww.h | 55 +-
 2 files changed, 126 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_ww.c 
b/drivers/gpu/drm/i915/i915_gem_ww.c
index 3490b72cf613..9b51cb535b65 100644
--- a/drivers/gpu/drm/i915/i915_gem_ww.c
+++ b/drivers/gpu/drm/i915/i915_gem_ww.c
@@ -1,10 +1,12 @@
 // SPDX-License-Identifier: MIT
 /*
- * Copyright © 2020 Intel Corporation
+ * Copyright © 2019 Intel Corporation
  */
+#include 
 #include 
 #include 
 #include "i915_gem_ww.h"
+#include "i915_globals.h"
 #include "gem/i915_gem_object.h"
 
 void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ww, bool intr)
@@ -70,3 +72,72 @@ int __must_check i915_gem_ww_ctx_backoff(struct 
i915_gem_ww_ctx *ww)
 
return ret;
 }
+
+static struct rhashtable ww_ht;
+static const struct rhashtable_params ww_params = {
+   .key_len = sizeof(struct task_struct *),
+   .key_offset = offsetof(struct i915_gem_ww_ctx, ctx.task),
+   .head_offset = offsetof(struct i915_gem_ww_ctx, head),
+   .min_size = 128,
+};
+
+static void i915_ww_item_free(void *ptr, void *arg)
+{
+   WARN_ON_ONCE(1);
+}
+
+static void i915_global_ww_exit(void)
+{
+   rhashtable_free_and_destroy(_ht, i915_ww_item_free, NULL);
+}
+
+static void i915_global_ww_shrink(void)
+{
+}
+
+static struct i915_global global = {
+   .shrink = i915_global_ww_shrink,
+   .exit = i915_global_ww_exit,
+};
+
+int __init i915_global_ww_init(void)
+{
+   int ret = rhashtable_init(_ht, _params);
+
+   if (ret)
+   return ret;
+
+   i915_global_register();
+
+   return 0;
+}
+
+void __i915_gem_ww_mark_unused(struct i915_gem_ww_ctx *ww)
+{
+   GEM_WARN_ON(rhashtable_remove_fast(_ht, >head, ww_params));
+}
+
+/**
+ * __i915_gem_ww_locate_or_find - return the task's i915_gem_ww_ctx context to 
use.
+ *
+ * @template: The context to use if there was none initialized previously
+ * in the call chain.
+ *
+ * RETURN: The task's i915_gem_ww_ctx context.
+ */
+struct i915_gem_ww_ctx *
+__i915_gem_ww_locate_or_use(struct i915_gem_ww_ctx *template)
+{
+   struct i915_gem_ww_ctx *tmp;
+
+   /* ctx.task is the hash key, so set it first. */
+   template->ctx.task = current;
+
+   /*
+* Ideally we'd just hook the active context to the
+* struct task_struct. But for now use a hash table.
+*/
+   tmp = rhashtable_lookup_get_insert_fast(_ht, >head,
+   ww_params);
+   return tmp;
+}
diff --git a/drivers/gpu/drm/i915/i915_gem_ww.h 
b/drivers/gpu/drm/i915/i915_gem_ww.h
index 94fdf8c5f89b..1a874e2d9f13 100644
--- a/drivers/gpu/drm/i915/i915_gem_ww.h
+++ b/drivers/gpu/drm/i915/i915_gem_ww.h
@@ -6,18 +6,71 @@
 #define __I915_GEM_WW_H__
 
 #include 
+#include 
 #include 
 
 struct i915_gem_ww_ctx {
struct ww_acquire_ctx ctx;
+   struct rhash_head head;
struct list_head obj_list;
struct drm_i915_gem_object *contended;
depot_stack_handle_t contended_bt;
-   bool intr;
+   u32 call_depth;
+   unsigned short intr;
+   unsigned short loop;
 };
 
 void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ctx, bool intr);
 void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ctx);
 int __must_check i915_gem_ww_ctx_backoff(struct i915_gem_ww_ctx *ctx);
 void i915_gem_ww_unlock_single(struct drm_i915_gem_object *obj);
+
+/* Internal functions used by the inlines! Don't use. */

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

[Jani Nikula]

Hi Dave & Daniel -

Due to the separate feature pull we haven't picked up gem fixes until
now. Here's the first batch; there's potentially a few more to come [1].

I also just received a gvt fixes pull that didn't make it this week, so
there are still more fixes coming.

BR,
Jani.


[1] http://lore.kernel.org/r/87k0wuw1g3@intel.com



drm-intel-fixes-2020-09-17:
drm/i915 fixes for v5.9-rc6:
- Avoid exposing a partially constructed context
- Use RCU instead of mutex for context termination list iteration
- Avoid data race reported by KCSAN
- Filter wake_flags passed to default_wake_function



The following changes since commit 856deb866d16e29bd65952e0289066f6078af773:

  Linux 5.9-rc5 (2020-09-13 16:06:00 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-09-17

for you to fetch changes up to 20612303a0b45de748d31331407e84300c38e497:

  drm/i915: Filter wake_flags passed to default_wake_function (2020-09-16 
11:10:05 +0300)


drm/i915 fixes for v5.9-rc6:
- Avoid exposing a partially constructed context
- Use RCU instead of mutex for context termination list iteration
- Avoid data race reported by KCSAN
- Filter wake_flags passed to default_wake_function


Chris Wilson (4):
  drm/i915/gem: Delay tracking the GEM context until it is registered
  drm/i915/gem: Reduce context termination list iteration guard to RCU
  drm/i915: Be wary of data races when reading the active execlists
  drm/i915: Filter wake_flags passed to default_wake_function

 drivers/gpu/drm/i915/gem/i915_gem_context.c | 48 ++---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ++---
 drivers/gpu/drm/i915/i915_request.c | 25 +--
 drivers/gpu/drm/i915/i915_sw_fence.c| 10 --
 4 files changed, 71 insertions(+), 27 deletions(-)

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

Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional

[Daniel Vetter]

On Thu, Sep 17, 2020 at 12:39 AM Paul E. McKenney  wrote:
>
> On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney  
> > wrote:
> > >
> > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote:
> > > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney  
> > > > wrote:
> > > > >
> > > > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> > > > > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > OTOH, having a working 'preemptible()' or maybe better named
> > > > > > > > 'can_schedule()' check makes tons of sense to make decisions 
> > > > > > > > about
> > > > > > > > allocation modes or other things.
> > > > > > >
> > > > > > > No. I think that those kinds of decisions about actual behavior 
> > > > > > > are
> > > > > > > always simply fundamentally wrong.
> > > > > > >
> > > > > > > Note that this is very different from having warnings about 
> > > > > > > invalid
> > > > > > > use. THAT is correct. It may not warn in all configurations, but 
> > > > > > > that
> > > > > > > doesn't matter: what matters is that it warns in common enough
> > > > > > > configurations that developers will catch it.
> > > > > > >
> > > > > > > So having a warning in "might_sleep()" that doesn't always 
> > > > > > > trigger,
> > > > > > > because you have a limited configuration that can't even detect 
> > > > > > > the
> > > > > > > situation, that's fine and dandy and intentional.
> > > > > > >
> > > > > > > But having code like
> > > > > > >
> > > > > > >if (can_schedule())
> > > > > > >.. do something different ..
> > > > > > >
> > > > > > > is fundamentally complete and utter garbage.
> > > > > > >
> > > > > > > It's one thing if you test for "am I in hardware interrupt 
> > > > > > > context".
> > > > > > > Those tests aren't great either, but at least they make sense.
> > > > > > >
> > > > > > > But a driver - or some library routine - making a difference 
> > > > > > > based on
> > > > > > > some nebulous "can I schedule" is fundamentally and basically 
> > > > > > > WRONG.
> > > > > > >
> > > > > > > If some code changes behavior, it needs to be explicit to the 
> > > > > > > *caller*
> > > > > > > of that code.
> > > > > > >
> > > > > > > So this is why GFP_ATOMIC is fine, but "if (!can_schedule())
> > > > > > > do_something_atomic()" is pure shite.
> > > > > > >
> > > > > > > And I am not IN THE LEAST interested in trying to help people 
> > > > > > > doing
> > > > > > > pure shite. We need to fix them. Like the crypto code is getting
> > > > > > > fixed.
> > > > > >
> > > > > > Just figured I'll throw my +1 in from reading too many (gpu) 
> > > > > > drivers.
> > > > > > Code that tries to cleverly adjust its behaviour depending upon the
> > > > > > context it's running in is harder to understand and blows up in more
> > > > > > interesting ways. We still have drm_can_sleep() and it's mostly just
> > > > > > used for debug code, and I've largely ended up just deleting
> > > > > > everything that used it because when you're driver is blowing up the
> > > > > > last thing you want is to realize your debug code and output can't 
> > > > > > be
> > > > > > relied upon. Or worse, that the only Oops you have is the one in the
> > > > > > debug code, because the real one scrolled away - the original idea
> > > > > > behind drm_can_sleep was to make all the modeset code work
> > > > > > automagically both in normal ioctl/kworker context and in the panic
> > > > > > handlers or kgdb callbacks. Wishful thinking at best.
> > > > > >
> > > > > > Also at least for me that extends to everything, e.g. I much prefer
> > > > > > explicit spin_lock and spin_lock_irq vs magic spin_lock_irqsave for
> > > > > > locks shared with interrupt handlers, since the former two gives me
> > > > > > clear information from which contexts such function can be called.
> > > > > > Other end is the memalloc_no*_save/restore functions, where I 
> > > > > > recently
> > > > > > made a real big fool of myself because I didn't realize how much 
> > > > > > that
> > > > > > impacts everything that's run within - suddenly "GFP_KERNEL for 
> > > > > > small
> > > > > > stuff never fails" is wrong everywhere.
> > > > > >
> > > > > > It's all great for debugging and sanity checks (and we run with all
> > > > > > that stuff enabled in our CI), but really semantic changes depending
> > > > > > upon magic context checks freak my out :-)
> > > > >
> > > > > All fair, but some of us need to write code that must handle being
> > > > > invoked from a wide variety of contexts.  Now perhaps you like the 
> > > > > idea of
> > > > > call_rcu() for schedulable contexts, call_rcu_nosched() when 
> > > > > preemption
> > > > > is disabled, call_rcu_irqs_are_disabled() when interrupts are 
> > > > > disabled,
> > > > 

Re: [Intel-gfx] [PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions

[Thomas Zimmermann]

Hi

Am 15.09.20 um 17:05 schrieb Christian König:
> Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
>> which is non-trivial to convert.
>>
>> v2:
>> * move object-function instance to amdgpu_gem.c (Christian)
>> * set callbacks in amdgpu_gem_object_create() (Christian)
>>
>> Signed-off-by: Thomas Zimmermann 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c    |  6 --
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c    | 23 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h    |  5 -
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  1 +
>>   4 files changed, 19 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 6edde2b9e402..840ca8f9c1e1 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -1505,19 +1505,13 @@ static struct drm_driver kms_driver = {
>>   .lastclose = amdgpu_driver_lastclose_kms,
>>   .irq_handler = amdgpu_irq_handler,
>>   .ioctls = amdgpu_ioctls_kms,
>> -    .gem_free_object_unlocked = amdgpu_gem_object_free,
>> -    .gem_open_object = amdgpu_gem_object_open,
>> -    .gem_close_object = amdgpu_gem_object_close,
>>   .dumb_create = amdgpu_mode_dumb_create,
>>   .dumb_map_offset = amdgpu_mode_dumb_mmap,
>>   .fops = _driver_kms_fops,
>>     .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>> -    .gem_prime_export = amdgpu_gem_prime_export,
>>   .gem_prime_import = amdgpu_gem_prime_import,
>> -    .gem_prime_vmap = amdgpu_gem_prime_vmap,
>> -    .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
>>   .gem_prime_mmap = amdgpu_gem_prime_mmap,
>>     .name = DRIVER_NAME,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> index aa7f230c71bf..aeecd5dc3ce4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> @@ -36,9 +36,12 @@
>>     #include "amdgpu.h"
>>   #include "amdgpu_display.h"
>> +#include "amdgpu_dma_buf.h"
>>   #include "amdgpu_xgmi.h"
>>   -void amdgpu_gem_object_free(struct drm_gem_object *gobj)
>> +static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
>> +
>> +static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
>>   {
>>   struct amdgpu_bo *robj = gem_to_amdgpu_bo(gobj);
>>   @@ -87,6 +90,7 @@ int amdgpu_gem_object_create(struct amdgpu_device
>> *adev, unsigned long size,
>>   return r;
>>   }
>>   *obj = >tbo.base;
>> +    (*obj)->funcs = _gem_object_funcs;
>>     return 0;
>>   }
>> @@ -119,8 +123,8 @@ void amdgpu_gem_force_release(struct amdgpu_device
>> *adev)
>>    * Call from drm_gem_handle_create which appear in both new and open
>> ioctl
>>    * case.
>>    */
>> -int amdgpu_gem_object_open(struct drm_gem_object *obj,
>> -   struct drm_file *file_priv)
>> +static int amdgpu_gem_object_open(struct drm_gem_object *obj,
>> +  struct drm_file *file_priv)
>>   {
>>   struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
>>   struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
>> @@ -152,8 +156,8 @@ int amdgpu_gem_object_open(struct drm_gem_object
>> *obj,
>>   return 0;
>>   }
>>   -void amdgpu_gem_object_close(struct drm_gem_object *obj,
>> - struct drm_file *file_priv)
>> +static void amdgpu_gem_object_close(struct drm_gem_object *obj,
>> +    struct drm_file *file_priv)
>>   {
>>   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
>>   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>> @@ -211,6 +215,15 @@ void amdgpu_gem_object_close(struct
>> drm_gem_object *obj,
>>   ttm_eu_backoff_reservation(, );
>>   }
>>   +static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = {
>> +    .free = amdgpu_gem_object_free,
>> +    .open = amdgpu_gem_object_open,
>> +    .close = amdgpu_gem_object_close,
>> +    .export = amdgpu_gem_prime_export,
>> +    .vmap = amdgpu_gem_prime_vmap,
>> +    .vunmap = amdgpu_gem_prime_vunmap,
>> +};
>> +
>>   /*
>>    * GEM ioctls.
>>    */
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
>> index e0f025dd1b14..637bf51dbf06 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
>> @@ -33,11 +33,6 @@
>>   #define AMDGPU_GEM_DOMAIN_MAX    0x3
>>   #define gem_to_amdgpu_bo(gobj) container_of((gobj), struct
>> amdgpu_bo, tbo.base)
>>   -void amdgpu_gem_object_free(struct drm_gem_object *obj);
>> -int amdgpu_gem_object_open(struct drm_gem_object *obj,
>> -    struct drm_file *file_priv);
>> -void 

Re: [Intel-gfx] [PATCH v2 00/21] Convert all remaining drivers to GEM object functions

[Thomas Zimmermann]

Hi

Am 15.09.20 um 17:25 schrieb Christian König:
> Added my rb to the amdgpu and radeon patches.
> 
> Should we pick those up through the amd branches or do you want to push
> everything to drm-misc-next?
> 
> I think the later since this should result in much merge clash.

Yes, preferable, I'd merge it all through drm-misc.

Best regards
Thomas

> 
> Christian.
> 
> Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
>> The GEM and PRIME related callbacks in struct drm_driver are
>> deprecated in
>> favor of GEM object functions in struct drm_gem_object_funcs. This
>> patchset
>> converts the remaining drivers to object functions and removes most of
>> the
>> obsolete interfaces.
>>
>> Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object
>> functions,
>> one by one. Each patch moves existing callbacks from struct drm_driver
>> to an
>> instance of struct drm_gem_object_funcs, and sets these funcs when the
>> GEM
>> object is initialized. The expection is .gem_prime_mmap. There are
>> different
>> ways of how drivers implement the callback, and moving it to GEM object
>> functions requires a closer review for each.
>>
>> Patch #17 fixes virtgpu to use GEM object functions where possible. The
>> driver recently introduced a function for one of the deprecated
>> callbacks.
>>
>> Patch #20 converts xlnx to CMA helper macros. There's no apparent reason
>> why the driver does the GEM setup on it's own. Using CMA helper macros
>> adds GEM object functions implicitly.
>>
>> With most of the GEM and PRIME moved to GEM object functions, related
>> code
>> in struct drm_driver and in the DRM core/helpers is being removed by
>> patch
>> #21.
>>
>> Further testing is welcome. I tested the drivers for which I have HW
>> available. These are gma500, i915, nouveau, radeon and vc4. The console,
>> Weston and Xorg apparently work with the patches applied.
>>
>> v2:
>> * moved code in amdgpu and radeon
>> * made several functions static in various drivers
>> * updated TODO-list item
>> * fix virtgpu
>>
>> Thomas Zimmermann (21):
>>    drm/amdgpu: Introduce GEM object functions
>>    drm/armada: Introduce GEM object functions
>>    drm/etnaviv: Introduce GEM object functions
>>    drm/exynos: Introduce GEM object functions
>>    drm/gma500: Introduce GEM object functions
>>    drm/i915: Introduce GEM object functions
>>    drm/mediatek: Introduce GEM object functions
>>    drm/msm: Introduce GEM object funcs
>>    drm/nouveau: Introduce GEM object functions
>>    drm/omapdrm: Introduce GEM object functions
>>    drm/pl111: Introduce GEM object functions
>>    drm/radeon: Introduce GEM object functions
>>    drm/rockchip: Convert to drm_gem_object_funcs
>>    drm/tegra: Introduce GEM object functions
>>    drm/vc4: Introduce GEM object functions
>>    drm/vgem: Introduce GEM object functions
>>    drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs
>>    drm/vkms: Introduce GEM object functions
>>    drm/xen: Introduce GEM object functions
>>    drm/xlnx: Initialize DRM driver instance with CMA helper macro
>>    drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver
>>
>>   Documentation/gpu/todo.rst    |  7 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  6 --
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   | 23 +++--
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h   |  5 --
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c    |  1 +
>>   drivers/gpu/drm/armada/armada_drv.c   |  3 -
>>   drivers/gpu/drm/armada/armada_gem.c   | 12 ++-
>>   drivers/gpu/drm/armada/armada_gem.h   |  2 -
>>   drivers/gpu/drm/drm_gem.c | 35 ++--
>>   drivers/gpu/drm/drm_gem_cma_helper.c  |  6 +-
>>   drivers/gpu/drm/drm_prime.c   | 17 ++--
>>   drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 ---
>>   drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 -
>>   drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 -
>>   drivers/gpu/drm/exynos/exynos_drm_drv.c   | 10 ---
>>   drivers/gpu/drm/exynos/exynos_drm_gem.c   | 15 
>>   drivers/gpu/drm/gma500/framebuffer.c  |  2 +
>>   drivers/gpu/drm/gma500/gem.c  | 18 +++-
>>   drivers/gpu/drm/gma500/gem.h  |  3 +
>>   drivers/gpu/drm/gma500/psb_drv.c  |  9 --
>>   drivers/gpu/drm/gma500/psb_drv.h  |  2 -
>>   drivers/gpu/drm/i915/gem/i915_gem_object.c    | 21 -
>>   drivers/gpu/drm/i915/gem/i915_gem_object.h    |  3 -
>>   drivers/gpu/drm/i915/i915_drv.c   |  4 -
>>   .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 -
>>   drivers/gpu/drm/mediatek/mtk_drm_drv.c    |  5 --
>>   drivers/gpu/drm/mediatek/mtk_drm_gem.c    | 11 +++
>>   drivers/gpu/drm/msm/msm_drv.c | 13 ---
>>   drivers/gpu/drm/msm/msm_drv.h |  1 -
>>   drivers/gpu/drm/msm/msm_gem.c | 19 -
>>   drivers/gpu/drm/nouveau/nouveau_drm.c

[Intel-gfx] [PULL] gvt-fixes

[Zhenyu Wang]

Hi,

Here's one left GVT fix against 5.9 is for kernel oops with VFIO edid
on BDW.

Thanks
--
The following changes since commit a291e4fba259a56a6a274c1989997acb6f0bb03a:

  drm/i915/gvt: Use GFP_ATOMIC instead of GFP_KERNEL in atomic context 
(2020-06-17 12:36:19 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-fixes-2020-09-17

for you to fetch changes up to 28284943ac94014767ecc2f7b3c5747c4a5617a0:

  drm/i915/gvt: Fix port number for BDW on EDID region setup (2020-09-14 
16:44:39 +0800)


gvt-fixes-2020-09-17

- Fix kernel oops for VFIO edid on BDW (Zhenyu)


Zhenyu Wang (1):
  drm/i915/gvt: Fix port number for BDW on EDID region setup

 drivers/gpu/drm/i915/gvt/vgpu.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)


-- 

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Update to GuC v49

[Petri Latvala]

On Wed, Sep 16, 2020 at 06:22:45PM -0700, John Harrison wrote:
> Hello,
> 
> The failures below all appear to be because the new GuC firmware was not
> found on the test system.
> 
> My understanding is that all we need to do to get the CI system to update
> with new firmwares is to push the firmware to a branch on the FDO
> drm-firmware repo and then send a pull request to this mailing list. That
> was done yesterday.

That pull request used an ssh:// url though. Can you send it again
with a git:// url? I suppose that's a plausible reason why I don't see
the binaries in CI's deploy dir.


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Update to GuC v49

[Saarinen, Jani]

+ Tomi

> -Original Message-
> From: John Harrison 
> Sent: torstai 17. syyskuuta 2020 4.23
> To: intel-gfx@lists.freedesktop.org; Latvala, Petri ;
> Saarinen, Jani ; Szwichtenberg, Radoslaw
> 
> Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915/guc: Update to GuC v49
> 
> Hello,
> 
> The failures below all appear to be because the new GuC firmware was not 
> found on
> the test system.
> 
> My understanding is that all we need to do to get the CI system to update 
> with new
> firmwares is to push the firmware to a branch on the FDO drm-firmware repo and
> then send a pull request to this mailing list. That was done yesterday.
> 
> Is there some other step we need to do? Or do I just need to wait longer 
> between
> the PR and sending the patches?
> 
> John.
> 
> 
> On 9/16/2020 11:35, Patchwork wrote:
> 
> 
>   Patch Details
> Series:drm/i915/guc: Update to GuC v49
> URL:   https://patchwork.freedesktop.org/series/81761/
> State: failure
> Details:   
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18516/index.html
> 
>   CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18516
> 
> 
>   Summary
> 
> 
>   FAILURE
> 
>   Serious unknown changes coming with Patchwork_18516 absolutely need to
> be
>   verified manually.
> 
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_18516, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in 
> CI.
> 
>   External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_18516/index.html
> 
> 
>   Possible new issues
> 
> 
>   Here are the unknown changes that may have been introduced in
> Patchwork_18516:
> 
> 
>   IGT changes
> 
> 
>   Possible regressions
> 
> 
>   *   igt@gem_huc_copy@huc-copy:
> 
>   *   fi-cfl-guc: PASS  tip/CI_DRM_9019/fi-cfl-guc/igt@gem_huc_c...@huc-copy.html>  -> FAIL
>  guc/igt@gem_huc_c...@huc-copy.html>
> 
>   *   fi-kbl-guc: PASS  tip/CI_DRM_9019/fi-kbl-guc/igt@gem_huc_c...@huc-copy.html>  -> FAIL
>  guc/igt@gem_huc_c...@huc-copy.html>
> 
>   *   fi-skl-guc: PASS  tip/CI_DRM_9019/fi-skl-guc/igt@gem_huc_c...@huc-copy.html>  -> FAIL
>  guc/igt@gem_huc_c...@huc-copy.html>
> 
> 
>   Warnings
> 
> 
>   *   igt@gem_huc_copy@huc-copy:
> 
>   *   fi-cml-u2: SKIP  tip/CI_DRM_9019/fi-cml-u2/igt@gem_huc_c...@huc-copy.html>  (i915#2190
>  ) -> SKIP 
>  ci.01.org/tree/drm-tip/Patchwork_18516/fi-cml-u2/igt@gem_huc_copy@huc-
> copy.html>
> 
>   *   fi-cml-s: SKIP  tip/CI_DRM_9019/fi-cml-s/igt@gem_huc_c...@huc-copy.html>  (i915#2190
>  ) -> SKIP 
>  ci.01.org/tree/drm-tip/Patchwork_18516/fi-cml-s/igt@gem_huc_copy@huc-
> copy.html>
> 
>   *   fi-icl-y: SKIP  tip/CI_DRM_9019/fi-icl-y/igt@gem_huc_c...@huc-copy.html>  (i915#2190
>  ) -> FAIL 
>  ci.01.org/tree/drm-tip/Patchwork_18516/fi-icl-y/igt@gem_huc_copy@huc-
> copy.html>
> 
>   *   fi-icl-u2: SKIP  tip/CI_DRM_9019/fi-icl-u2/igt@gem_huc_c...@huc-copy.html>  (i915#2190
>  ) -> FAIL 
>  ci.01.org/tree/drm-tip/Patchwork_18516/fi-icl-u2/igt@gem_huc_copy@huc-
> copy.html>
> 
> 
>   Suppressed
> 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   *   igt@gem_huc_copy@huc-copy:
> 
>   *   {fi-ehl-1}: SKIP  tip/CI_DRM_9019/fi-ehl-1/igt@gem_huc_c...@huc-copy.html>  (i915#2190
>  ) -> FAIL 
>  ci.01.org/tree/drm-tip/Patchwork_18516/fi-ehl-1/igt@gem_huc_copy@huc-
> copy.html>
> 
>   *   {fi-tgl-dsi}: SKIP 
>  tip/CI_DRM_9019/fi-tgl-dsi/igt@gem_huc_c...@huc-copy.html>  (i915#2190
>  ) -> FAIL 
>  ci.01.org/tree/drm-tip/Patchwork_18516/fi-tgl-dsi/igt@gem_huc_copy@huc-
> copy.html>
> 
> 
>   Known issues
> 
> 
>   Here are the changes found in Patchwork_18516