RE: [PATCH] drm/i915: use NULL for zero wakeref_t instead of plain integer 0

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-xe  On Behalf Of Jani
> Nikula
> Sent: Wednesday, October 2, 2024 11:47 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: [PATCH] drm/i915: use NULL for zero wakeref_t instead of plain
> integer 0
> 
> As of commit 2edc6a75f26c ("drm/i915: switch intel_wakeref_t underlying
> type to struct ref_tracker *") we gained quite a few sparse warnings about
> "Using plain integer as NULL pointer" for using 0 to initialize wakeref_t. 
> Switch
> to NULL everywhere.
> 
> Signed-off-by: Jani Nikula 

LGTM
Reviewed-by: Chaitanya Kumar Borah 




> ---
>  drivers/gpu/drm/i915/display/intel_display.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_display_power.c |  6 +++---
> drivers/gpu/drm/i915/display/intel_display_power.h |  4 ++--
>  drivers/gpu/drm/i915/display/intel_pps.c   |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c   |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c|  4 ++--
>  drivers/gpu/drm/i915/gt/intel_breadcrumbs.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm.h  |  6 +++---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c  |  2 +-
>  drivers/gpu/drm/i915/i915_vma.c|  4 ++--
>  drivers/gpu/drm/i915/intel_runtime_pm.c|  2 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.h|  6 +++---
>  drivers/gpu/drm/i915/intel_wakeref.c   | 14 +++---
>  drivers/gpu/drm/i915/pxp/intel_pxp.c   |  2 +-
>  .../drm/xe/compat-i915-headers/intel_runtime_pm.h  |  6 +++---
>  15 files changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 74311bb9d290..2864a894d399 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7589,7 +7589,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>   struct intel_crtc_state *new_crtc_state, *old_crtc_state;
>   struct intel_crtc *crtc;
>   struct intel_power_domain_mask put_domains[I915_MAX_PIPES] =
> {};
> - intel_wakeref_t wakeref = 0;
> + intel_wakeref_t wakeref = NULL;
>   int i;
> 
>   intel_atomic_commit_fence_wait(state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 7b16ba1a8226..c2bc80f5bf6b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -545,7 +545,7 @@ intel_display_power_get_if_enabled(struct
> drm_i915_private *dev_priv,
> 
>   wakeref = intel_runtime_pm_get_if_in_use(&dev_priv->runtime_pm);
>   if (!wakeref)
> - return 0;
> + return NULL;
> 
>   mutex_lock(&power_domains->lock);
> 
> @@ -560,7 +560,7 @@ intel_display_power_get_if_enabled(struct
> drm_i915_private *dev_priv,
> 
>   if (!is_enabled) {
>   intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
> - wakeref = 0;
> + wakeref = NULL;
>   }
> 
>   return wakeref;
> @@ -648,7 +648,7 @@ intel_display_power_put_async_work(struct
> work_struct *work)
>   struct i915_power_domains *power_domains = &dev_priv-
> >display.power.domains;
>   struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
>   intel_wakeref_t new_work_wakeref =
> intel_runtime_pm_get_raw(rpm);
> - intel_wakeref_t old_work_wakeref = 0;
> + intel_wakeref_t old_work_wakeref = NULL;
> 
>   mutex_lock(&power_domains->lock);
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> b/drivers/gpu/drm/i915/display/intel_display_power.h
> index 3b7c1a0bb1de..3f8f84df4733 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -297,10 +297,10 @@ void gen9_dbuf_slices_update(struct
> drm_i915_private *dev_priv,
> 
>  #define with_intel_display_power(i915, domain, wf) \
>   for ((wf) = intel_display_power_get((i915), (domain)); (wf); \
> -  intel_display_power_put_async((i915), (domain), (wf)), (wf) = 0)
> +  intel_display_power_put_async((i915), (domain), (wf)), (wf) =
> +NULL)
> 
>  #define with_intel_display_power_if_enabled(i915, domain, wf) \
>   for ((wf) = intel_display_power_get_if_enabled((i915), (domain));
> (wf); \
> -  intel_display_power_put_async((i915), (domain), (wf)), (wf) = 0)
> +  intel_display_power_put_async((i915), (domain), (wf)), (wf) =
> +NULL)
> 
>  #endif /* __INTEL_DISPLAY_POWER_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 88abc4c7cda1..ffeee9daa568 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -87,7 +87,7 @@ intel_wakeref_t intel_pps_unlock(struct intel_dp
> *inte

RE: [PATCH] drm/i915/vdsc: Add bpc check in intel_dsc_compute_params

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Thursday, September 26, 2024 11:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Golani, Mitulkumar Ajitkumar ;
> Borah, Chaitanya Kumar ; Kandpal, Suraj
> 
> Subject: [PATCH] drm/i915/vdsc: Add bpc check in
> intel_dsc_compute_params
> 
> DSC does not support bpc under 8 according to DSC 1.2a Section 2
> Requirements. Return an error if that happens to be the case.
> 
> --v2
> -should be bits_per_component [Mitul/Chaitanya/Srikanth] -Add reference to
> this restriction [Chaitanya]
> 
> Signed-off-by: Suraj Kandpal 

LGTM


Reviewed-by: Chaitanya Kumar Borah 


> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 8158e3702ed5..7a30fdea16da 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -306,6 +306,11 @@ int intel_dsc_compute_params(struct
> intel_crtc_state *pipe_config)
> 
>   vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
> 
> + if (vdsc_cfg->bits_per_component < 8) {
> + drm_dbg_kms(&dev_priv->drm, "DSC bpc requirements not
> met\n");
> + return -EINVAL;
> + }
> +
>   drm_dsc_set_rc_buf_thresh(vdsc_cfg);
> 
>   /*
> --
> 2.43.2

RE: [PATCH] drm/i915/vdsc: Add bpc check in intel_dsc_compute_params

[Borah, Chaitanya Kumar]

Hello Suraj

> -Original Message-
> From: Intel-gfx  On Behalf Of Suraj
> Kandpal
> Sent: Thursday, September 26, 2024 10:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Kandpal, Suraj
> 
> Subject: [PATCH] drm/i915/vdsc: Add bpc check in
> intel_dsc_compute_params
> 
> DSC does not support bpc under 8. Return an error if that happens to be the
> case.
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 8158e3702ed5..39bf8bee106c 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -297,6 +297,11 @@ int intel_dsc_compute_params(struct
> intel_crtc_state *pipe_config)
> 
>   vdsc_cfg->bits_per_pixel = pipe_config->dsc.compressed_bpp_x16;
> 
> + if (vdsc_cfg->bites_per_pixel < 8) {

Typo: bits_per_pixel

Any Bspec link for this limitation?

Regards

Chaitanya

> + drm_dbg_kms(&dev_priv->drm, "DSC bpc requirements not
> met\n");
> + return -EINVAL;
> + }
> +
>   /*
>* According to DSC 1.2 specs in Section 4.1 if native_420 is set
>* we need to double the current bpp.
> --
> 2.43.2

RE: [PATCH] drm/i915/dp: Add FEC Enable Retry mechanism

[Borah, Chaitanya Kumar]

Hello Jani,

Thank you for the review.

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, September 23, 2024 12:40 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org; intel...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/dp: Add FEC Enable Retry mechanism
> 
> On Mon, 23 Sep 2024, Chaitanya Kumar Borah
>  wrote:
> > From PTL, FEC_DECODE_EN sequence can be sent to a DPRX independent of
> > TRANS_CONF enable. This allows us to re-issue an FEC_DECODE_EN
> > sequence without re-doing the whole mode set sequence. This separate
> > control over FEC_ECODE_EN/DIS sequence enables us to have a retry
> > mechanism in case the DPRX does not respond with an FEC_ENABLE within
> > the stipulated 5ms.
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c | 61
> > +++-
> >  1 file changed, 59 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 85e519a21542..589acea9906a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -78,6 +78,8 @@
> >  #include "skl_scaler.h"
> >  #include "skl_universal_plane.h"
> >
> > +#define FEC_RETRY_COUNT 3
> 
> If there's only one user, I wouldn't bother with a macro.
> 

Ack.

> > +
> >  static const u8 index_to_dp_signal_levels[] = {
> > [0] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 |
> DP_TRAIN_PRE_EMPH_LEVEL_0,
> > [1] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 |
> DP_TRAIN_PRE_EMPH_LEVEL_1, @@
> > -2255,6 +2257,57 @@ static int read_fec_detected_status(struct
> drm_dp_aux *aux)
> > return status;
> >  }
> >
> > +static void retry_fec_enable(struct intel_encoder *encoder,
> > +const struct intel_crtc_state *crtc_state,
> > +struct drm_dp_aux *aux)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(aux->drm_dev);
> > +   int ret = 0;
> > +
> > +   /* Clear FEC enable */
> > +   intel_de_rmw(i915, dp_tp_ctl_reg(encoder, crtc_state),
> > +DP_TP_CTL_FEC_ENABLE, 0);
> > +
> > +   /* Set FEC enable */
> > +   intel_de_rmw(i915, dp_tp_ctl_reg(encoder, crtc_state),
> > +0, DP_TP_CTL_FEC_ENABLE);
> > +
> > +   ret = intel_de_wait_for_set(i915, dp_tp_status_reg(encoder,
> crtc_state),
> > +   DP_TP_STATUS_FEC_ENABLE_LIVE, 1);
> > +   if (!ret)
> > +   drm_dbg_kms(&i915->drm,
> > +   "Timeout waiting for FEC live state to get 
> > enabled");
> }
> > +
> > +static void wait_for_fec_detected_with_retry(struct intel_encoder
> *encoder,
> > +const struct intel_crtc_state
> *crtc_state,
> > +struct drm_dp_aux *aux)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(aux->drm_dev);
> > +   int status;
> > +   int err;
> > +   int retrycount = 0;
> > +
> > +   do {
> > +   err = readx_poll_timeout(read_fec_detected_status, aux,
> status,
> > +status &
> DP_FEC_DECODE_EN_DETECTED || status < 0,
> > +500, 5000);
> > +
> > +   if (!err && status >= 0)
> > +   return;
> > +
> > +   if (err == -ETIMEDOUT) {
> > +   drm_dbg_kms(&i915->drm,
> > +   "Timeout waiting for FEC ENABLE to get
> detected, retrying\n");
> > +   retry_fec_enable(encoder, crtc_state, aux);
> > +   } else {
> > +   drm_dbg_kms(&i915->drm, "FEC detected status
> read error: %d\n", status);
> > +   }
> > +   } while (retrycount++ < FEC_RETRY_COUNT);
> 
> Please use a regular for loop with for (i = 0; i < N; i++) so even I can look 
> at it
> and know in an instant how many times it's going to loop.
> 
> > +
> > +   drm_err(&i915->drm, "FEC enable Failed after Retry\n"); }
> > +
> 
> There's just way, way too much duplication between the above two functions
> and the existing intel_ddi_wait_for_fec_status() and wait_for_fec_detected().
> We'll want *one* code path with the retry baked in, with no retries for older
> platforms.

Agreed. Let me try t

RE: [PATCH] drm/i915/dp: Add FEC Enable Retry mechanism

[Borah, Chaitanya Kumar]

Hello Srikanth,

Thank you for the review.

> -Original Message-
> From: Srikanth V, NagaVenkata 
> Sent: Monday, September 23, 2024 4:16 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org; intel...@lists.freedesktop.org
> Subject: RE: [PATCH] drm/i915/dp: Add FEC Enable Retry mechanism
> 
> 
> 
> > -Original Message-
> > From: Intel-xe  On Behalf Of
> > Chaitanya Kumar Borah
> > Sent: Monday, September 23, 2024 10:22 AM
> > To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> > Subject: [PATCH] drm/i915/dp: Add FEC Enable Retry mechanism
> >
> > From PTL, FEC_DECODE_EN sequence can be sent to a DPRX independent of
> > TRANS_CONF enable. This allows us to re-issue an FEC_DECODE_EN
> > sequence without re-doing the whole mode set sequence. This separate
> > control over FEC_ECODE_EN/DIS sequence enables us to have a retry
> > mechanism in case the DPRX does not respond with an FEC_ENABLE within
> the stipulated 5ms.
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c | 61
> > +++-
> >  1 file changed, 59 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 85e519a21542..589acea9906a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -78,6 +78,8 @@
> >  #include "skl_scaler.h"
> >  #include "skl_universal_plane.h"
> >
> > +#define FEC_RETRY_COUNT 3
> > +
> >  static const u8 index_to_dp_signal_levels[] = {
> > [0] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 |
> DP_TRAIN_PRE_EMPH_LEVEL_0,
> > [1] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 |
> DP_TRAIN_PRE_EMPH_LEVEL_1, @@
> > -2255,6 +2257,57 @@ static int read_fec_detected_status(struct
> > drm_dp_aux *aux)
> > return status;
> >  }
> >
> > +static void retry_fec_enable(struct intel_encoder *encoder,
> > +const struct intel_crtc_state *crtc_state,
> > +struct drm_dp_aux *aux)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(aux->drm_dev);
> > +   int ret = 0;
> > +
> 
> You should also be clearing FEC_ENABLE_LIVE_STATUS in DP_TP_STATUS
> register by writing 1.
> 

This seems to be a RO bit according to spec.

> > +   /* Clear FEC enable */
> > +   intel_de_rmw(i915, dp_tp_ctl_reg(encoder, crtc_state),
> > +DP_TP_CTL_FEC_ENABLE, 0);
> > +
> 
> > +   /* Set FEC enable */
> > +   intel_de_rmw(i915, dp_tp_ctl_reg(encoder, crtc_state),
> > +0, DP_TP_CTL_FEC_ENABLE);
> > +
> > +   ret = intel_de_wait_for_set(i915, dp_tp_status_reg(encoder,
> > crtc_state),
> > +   DP_TP_STATUS_FEC_ENABLE_LIVE, 1);
> > +   if (!ret)
> > +   drm_dbg_kms(&i915->drm,
> > +   "Timeout waiting for FEC live state to get 
> > enabled");
> }
> > +
> > +static void wait_for_fec_detected_with_retry(struct intel_encoder
> *encoder,
> > +const struct intel_crtc_state
> > *crtc_state,
> > +struct drm_dp_aux *aux)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(aux->drm_dev);
> > +   int status;
> > +   int err;
> > +   int retrycount = 0;
> > +
> > +   do {
> > +   err = readx_poll_timeout(read_fec_detected_status, aux,
> > status,
> > +status &
> > DP_FEC_DECODE_EN_DETECTED || status < 0,
> > +500, 5000);
> > +
> > +   if (!err && status >= 0)
> > +   return;
> > +
> > +   if (err == -ETIMEDOUT) {
> > +   drm_dbg_kms(&i915->drm,
> > +   "Timeout waiting for FEC ENABLE to get
> > detected, retrying\n");
> > +   retry_fec_enable(encoder, crtc_state, aux);
> > +   } else {
> > +   drm_dbg_kms(&i915->drm, "FEC detected status
> read
> > error: %d\n", status);
> > +   }
> > +   } while (retrycount++ < FEC_RETRY_COUNT);
> > +
> > +   drm_err(&i915->drm, "FEC enable Failed after Retry\n"); }
> > +
> >  static void wait_for_fec_detected(struct drm_dp_aux *au

Regression on i915

[Borah, Chaitanya Kumar]

Hello Alexander,

We have two gitlab issues[1] where a phantom display is detected by the system 
(with i915 driver).
The following patch[2] has been identified as the first bad commit after bisect.

"b49420d6a1 video/aperture: optionally match the device in sysfb_disable()"

Could you please check why the patch causes this regression and provide a fix 
if necessary?

Regards

Chaitanya


[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160
  https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12244
[2] 
https://gitlab.freedesktop.org/drm/i915/kernel/-/commit/b49420d6a1aeb399e5b107fc6eb8584d0860fbd7

Regression on linux-next (next-20240829)

[Borah, Chaitanya Kumar]

Hello Thomas,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

Since the version next-20240829 [2], we are seeing the following regression

`
<4> [28.903830] [ cut here ]
<4> [28.903835] WARNING: CPU: 10 PID: 855 at 
drivers/video/fbdev/core/fbmem.c:467 unregister_framebuffer+0x1f/0xd0
<4> [28.903840] Modules linked in: i915(+) prime_numbers i2c_algo_bit ttm 
drm_display_helper drm_buddy cdc_ncm cdc_ether usbnet btusb btrtl btintel btbcm 
bluetooth x86_pkg_temp_thermal mei_hdcp coretemp mei_pxp wmi_bmof kvm_intel 
r8152 mii r8169 kvm video crct10dif_pclmul i2c_i801 crc32_pclmul 
ghash_clmulni_intel realtek i2c_mux mei_me i2c_smbus mei intel_lpss_pci wmi
<4> [28.903870] CPU: 10 UID: 0 PID: 855 Comm: i915_module_loa Not tainted 
6.11.0-rc5-next-20240829-next-20240829-gb18bbfc14a38+ #1
<4> [28.903872] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 
0812 02/24/2023
<4> [28.903873] RIP: 0010:unregister_framebuffer+0x1f/0xd0
<4> [28.903875] Code: 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 31 f6 48 
89 fd 48 c7 c7 60 2d 7c 82 e8 da aa 5d 00 48 63 45 04 83 f8 1f 76 69 <0f> 0b 48 
8b bd b0 02 00 00 48 85 ff 74 09 f6 85 cc 02 00 00 01 75
<4> [28.903876] RSP: 0018:c9000250f840 EFLAGS: 00010286
<4> [28.903878] RAX:  RBX: 8881066c4740 RCX: 

<4> [28.903880] RDX: 0001 RSI: 82440d5a RDI: 

<4> [28.903881] RBP: 8881066a8800 R08:  R09: 

<4> [28.903881] R10: c9000250f840 R11: 888114940040 R12: 
c9000250f878
<4> [28.903883] R13: 8881066a6810 R14: 8881066a6c20 R15: 
8881066a6be0
<4> [28.903884] FS:  7f8a936adc40() GS:5f28() 
knlGS:
<4> [28.903885] CS:  0010 DS:  ES:  CR0: 80050033
<4> [28.903886] CR2: 7f8a95eb3f70 CR3: 000117808000 CR4: 
00f50ef0
<4> [28.903887] PKRU: 5554
<4> [28.903888] Call Trace:
<4> [28.903889]  
<4> [28.903890]  ? __warn+0x91/0x1a0
<4> [28.903894]  ? unregister_framebuffer+0x1f/0xd0
<4> [28.903896]  ? report_bug+0x1f8/0x200
<4> [28.903899]  ? handle_bug+0x53/0x90
<4> [28.903902]  ? exc_invalid_op+0x18/0x70
<4> [28.903903]  ? asm_exc_invalid_op+0x1a/0x20
<4> [28.903907]  ? unregister_framebuffer+0x1f/0xd0
<4> [28.903909]  release_nodes+0x2e/0xf0
<4> [28.903912]  devres_release_all+0x8a/0xc0
<4> [28.903915]  device_unbind_cleanup+0x9/0x70
<4> [28.903917]  device_release_driver_internal+0xce/0x140
<4> [28.903920]  bus_remove_device+0xcf/0x140
<4> [28.903922]  device_del+0x179/0x3e0
<4> [28.903925]  ? pci_conf1_read+0xa3/0x100
<4> [28.903928]  platform_device_del.part.0+0xe/0x70
<4> [28.903930]  platform_device_unregister+0x1b/0x30
<4> [28.903932]  sysfb_disable+0x4c/0x90
<4> [28.903934]  aperture_remove_conflicting_pci_devices+0x25/0x80
<4> [28.903937]  i915_driver_probe+0x6f3/0xdc0 [i915]
<4> [28.904017]  ? lockdep_hardirqs_on+0x7b/0x100
<4> [28.904019]  ? _raw_spin_unlock_irqrestore+0x41/0x70
<4> [28.904022]  ? device_id_in_list+0xaf/0x120 [i915]
<4> [28.904098]  i915_pci_probe+0xd5/0x200 [i915]
<4> [28.904171]  pci_device_probe+0x95/0x120
<4> [28.904174]  really_probe+0xd9/0x370
<4> [28.904177]  ? __pfx___driver_attach+0x10/0x10
<4> [28.904179]  __driver_probe_device+0x73/0x150
<4> [28.904181]  driver_probe_device+0x19/0xa0
<4> [28.904184]  __driver_attach+0xb6/0x180
<4> [28.904186]  ? __pfx___driver_attach+0x10/0x10
<4> [28.904188]  bus_for_each_dev+0x77/0xd0
<4> [28.904191]  bus_add_driver+0x110/0x240
<4> [28.904193]  driver_register+0x5b/0x110
<4> [28.904195]  i915_init+0x23/0xc0 [i915]
<4> [28.904268]  ? __pfx_i915_init+0x10/0x10 [i915]
<4> [28.904338]  do_one_initcall+0x5c/0x2b0
<4> [28.904341]  ? __kmalloc_cache_noprof+0x21e/0x270
<4> [28.904344]  ? do_init_module+0x1e/0x210
<4> [28.904348]  do_init_module+0x5f/0x210
<4> [28.904350]  load_module+0x1d4e/0x1fd0
<4> [28.904356]  ? init_module_from_file+0x86/0xd0
<4> [28.904358]  init_module_from_file+0x86/0xd0
<4> [28.904362]  idempotent_init_module+0x181/0x280
<4> [28.904366]  __x64_sys_finit_module+0x56/0xb0
<4> [28.904369]  do_syscall_64+0x66/0x140
<4> [28.904371]  entry_SYSCALL_64_after_hwframe+0x76/0x7e 
`
Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the first "bad"
commit

`
commit c2fe0480cd77526411707da46d72a44d9671c9ad
Author: Thomas Weißschuh mailto:li...@weissschuh.net
Date:   Tue Aug 27 17:25:15 2024 +0200

    fbdev/efifb: Use devm_register_framebuffer()

    This simplifies the error handling.
    Also the drvdata slot is now unused and can be used

RE: [PATCH] drm/i915: Preserve value of fec_enable calculated before DSC compute config

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Jani Nikula 
> Sent: Wednesday, August 14, 2024 2:15 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Deak, Imre 
> Subject: RE: [PATCH] drm/i915: Preserve value of fec_enable calculated before
> DSC compute config
> 
> On Mon, 12 Aug 2024, "Borah, Chaitanya Kumar"
>  wrote:
> >> -Original Message-
> >> From: Jani Nikula 
> >> Sent: Monday, August 12, 2024 5:24 PM
> >> To: Borah, Chaitanya Kumar ; intel-
> >> g...@lists.freedesktop.org; intel...@lists.freedesktop.org
> >> Cc: Deak, Imre ; Borah, Chaitanya Kumar
> >> 
> >> Subject: Re: [PATCH] drm/i915: Preserve value of fec_enable
> >> calculated before DSC compute config
> >>
> >> On Mon, 12 Aug 2024, Chaitanya Kumar Borah
> >>  wrote:
> >> > Before DSC compute config, fec_enable value is set in other
> >> > functions (e.g. intel_dp_mst_find_vcpi_slots_for_bpp). We are
> >> > ignoring the value by OR'ing its value in DSC compute config. One
> >> > unintended effect of this is setting fec_enable in UHBR use-cases
> >> > which is not needed for Intel hardware. Therefore, change operator to
> AND.
> >> >
> >> > While at it, add a comment explaining why we don't enable FEC in eDP
> v1.5.
> >> >
> >> > Signed-off-by: Chaitanya Kumar Borah
> >> > 
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
> >> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > index 49a37b996530..3fbf9f33c3e4 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > @@ -2298,7 +2298,12 @@ int intel_dp_dsc_compute_config(struct
> >> intel_dp *intel_dp,
> >> >  &pipe_config->hw.adjusted_mode;
> >> >  int ret;
> >> >
> >> > -pipe_config->fec_enable = pipe_config->fec_enable ||
> >> > +/*
> >> > + * Though eDP v1.5 supports FEC with DSC, unlike DP, it is 
> >> > optional.
> >> > + * Since, FEC is a bandwidth overhead, continue to not enable 
> >> > it for
> >> > + * eDP. Until, there is a good reason to do so.
> >> > + */
> >> > +pipe_config->fec_enable = pipe_config->fec_enable &&
> >> >  (!intel_dp_is_edp(intel_dp) &&
> >> >   intel_dp_supports_fec(intel_dp, connector, 
> >> > pipe_config));
> >>
> >> With this change, FEC will only be enabled for non-UHBR MST DP and
> >> nothing else. This is the place where SST DP DSC gets FEC enabled.
> >
> > Thank you Jani for pointing it out.
> >
> > Something like this should work?
> >
> > pipe_config->fec_enable = pipe_config->fec_enable ||
> > (!intel_dp_is_edp(intel_dp) &&
> >  intel_dp_supports_fec(intel_dp, connector, pipe_config) &&
> > !intel_dp_is_uhbr(pipe_config));
> 
> Technically yes, although I dislike the fact that we now have fec_enable and 
> its
> rules split to multiple locations.
> 

I agree. if I understand correctly this should be covered by the larger 
separation of DP-MST and MTP planned for UHBR.
Until that time, hopefully [1] is acceptable.

[1] https://patchwork.freedesktop.org/series/137611/

Regards

Chaitanya

> BR,
> Jani.
> 
> 
> >
> > Regards
> >
> > Chaitanya
> >
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> --
> >> Jani Nikula, Intel
> 
> --
> Jani Nikula, Intel

RE: [PATCH] drm/i915: Preserve value of fec_enable calculated before DSC compute config

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, August 12, 2024 5:24 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Deak, Imre ; Borah, Chaitanya Kumar
> 
> Subject: Re: [PATCH] drm/i915: Preserve value of fec_enable calculated before
> DSC compute config
> 
> On Mon, 12 Aug 2024, Chaitanya Kumar Borah
>  wrote:
> > Before DSC compute config, fec_enable value is set in other functions
> > (e.g. intel_dp_mst_find_vcpi_slots_for_bpp). We are ignoring the value
> > by OR'ing its value in DSC compute config. One unintended effect of
> > this is setting fec_enable in UHBR use-cases which is not needed for
> > Intel hardware. Therefore, change operator to AND.
> >
> > While at it, add a comment explaining why we don't enable FEC in eDP v1.5.
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 49a37b996530..3fbf9f33c3e4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -2298,7 +2298,12 @@ int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> > &pipe_config->hw.adjusted_mode;
> > int ret;
> >
> > -   pipe_config->fec_enable = pipe_config->fec_enable ||
> > +   /*
> > +* Though eDP v1.5 supports FEC with DSC, unlike DP, it is optional.
> > +* Since, FEC is a bandwidth overhead, continue to not enable it for
> > +* eDP. Until, there is a good reason to do so.
> > +*/
> > +   pipe_config->fec_enable = pipe_config->fec_enable &&
> > (!intel_dp_is_edp(intel_dp) &&
> >  intel_dp_supports_fec(intel_dp, connector, pipe_config));
> 
> With this change, FEC will only be enabled for non-UHBR MST DP and nothing
> else. This is the place where SST DP DSC gets FEC enabled.

Thank you Jani for pointing it out.

Something like this should work?

pipe_config->fec_enable = pipe_config->fec_enable ||
(!intel_dp_is_edp(intel_dp) &&
 intel_dp_supports_fec(intel_dp, connector, pipe_config) && 
!intel_dp_is_uhbr(pipe_config));

Regards

Chaitanya

> 
> BR,
> Jani.
> 
> 
> --
> Jani Nikula, Intel

Regression on linux-next (next-20240722)

[Borah, Chaitanya Kumar]

Hello Anna-Maria,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

Since the version next-20240722 [2], we are seeing the following regression

`
<6>[0.787321] Timer migration: 2 hierarchy levels; 8 children per group; 2 
crossnode level
<4>[0.787330] [ cut here ]
<4>[0.787335] WARNING: CPU: 0 PID: 1 at kernel/time/timer_migration.c:1714 
tmigr_cpu_prepare+0x5f2/0x680
<4>[0.787340] Modules linked in:
<4>[0.787341] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 
6.10.0-next-20240722-next-20240722-gdee7f101b642+ #1
<4>[0.787342] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, 
BIOS 0812 02/24/2023
<4>[0.787343] RIP: 0010:tmigr_cpu_prepare+0x5f2/0x680
<4>[0.787344] Code: fc ff ff 80 3d dc d5 6c 01 00 0f 85 56 fc ff ff 48 c7 
c7 f8 ba 48 82 c6 05 c8 d5 6c 01 01 e8 95 1b f0 ff 0f 0b e9 3c fc ff ff <0f> 0b 
e9 41 fa ff ff 4c 89 e7 48 89 2c 24 e8 7b cd 11 00 48 c7 c7
<4>[0.787345] RSP: :c9067d18 EFLAGS: 00010246
<4>[0.787346] RAX:  RBX: 5f0214e0 RCX: 

<4>[0.787347] RDX: 0001 RSI: 8243cfef RDI: 

<4>[0.787347] RBP: 0002e74c R08:  R09: 

<4>[0.787347] R10: c9067e08 R11: 888100ce8040 R12: 

<4>[0.787348] R13: 0040 R14: 81198620 R15: 
8264b880
<4>[0.787348] FS:  () GS:5f00() 
knlGS:
<4>[0.787349] CS:  0010 DS:  ES:  CR0: 80050033
<4>[0.787350] CR2: 7f7ff000 CR3: 0663a000 CR4: 
00f50ef0
<4>[0.787350] PKRU: 5554
<4>[0.787351] Call Trace:
<4>[0.787351]  
<4>[0.787352]  ? __warn+0x91/0x1a0
<4>[0.787354]  ? tmigr_cpu_prepare+0x5f2/0x680
<4>[0.787355]  ? report_bug+0x1f8/0x200
<4>[0.787359]  ? handle_bug+0x3c/0x70
<4>[0.787361]  ? exc_invalid_op+0x18/0x70
<4>[0.787362]  ? asm_exc_invalid_op+0x1a/0x20
<4>[0.787364]  ? __pfx_tmigr_cpu_prepare+0x10/0x10
<4>[0.787367]  ? tmigr_cpu_prepare+0x5f2/0x680
<4>[0.787369]  ? __pfx_tmigr_cpu_prepare+0x10/0x10
<4>[0.787370]  cpuhp_invoke_callback+0x17b/0x6b0
<4>[0.787372]  cpuhp_issue_call+0x9a/0x1d0
<4>[0.787374]  __cpuhp_setup_state_cpuslocked+0x1cc/0x2c0
<4>[0.787376]  ? __pfx_tmigr_cpu_prepare+0x10/0x10
<4>[0.787377]  __cpuhp_setup_state+0xb8/0x220
<4>[0.787379]  ? __pfx_tmigr_init+0x10/0x10
<4>[0.787381]  tmigr_init+0xd8/0x140
<4>[0.787383]  do_one_initcall+0x5c/0x2b0
<4>[0.787385]  ? call_rcu_tasks_generic.constprop.0+0x182/0x3c0
<4>[0.787388]  kernel_init_freeable+0xae/0x340
<4>[0.787390]  ? __pfx_kernel_init+0x10/0x10
<4>[0.787392]  kernel_init+0x15/0x130
<4>[0.787393]  ret_from_fork+0x2c/0x50
<4>[0.787395]  ? __pfx_kernel_init+0x10/0x10
<4>[0.787396]  ret_from_fork_asm+0x1a/0x30
<4>[0.787399]  
`
Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the first "bad" 
commit

`
commit 7a5ee4aa61afa9f1570c80ffba92987bc73ce3ab
Author: Anna-Maria Behnsen mailto:anna-ma...@linutronix.de
Date:   Wed Jul 17 11:49:40 2024 +0200

    timers/migration: Move hierarchy setup into cpuhotplug prepare callback
`

We could not revert the patch because of a merge conflicts but resetting to the 
parent of the commit seems to fix the issue

Could you please check why the patch causes this regression and provide a fix 
if necessary?

Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240722
[3] 
http://gfx-ci.igk.intel.com/tree/linux-next/next-20240722/bat-rpls-4/boot0.txt
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240722&id=7a5ee4aa61afa9f1570c80ffba92987bc73ce3ab

RE: Regression on linux-next (next-20240712)

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Andrew Morton 
> Sent: Thursday, July 18, 2024 1:31 AM
> To: David Hildenbrand 
> Cc: Borah, Chaitanya Kumar ;
> peili@gmail.com; Nikula, Jani ; Saarinen, Jani
> ; Kurmi, Suresh Kumar
> ; intel-gfx@lists.freedesktop.org; linux-
> m...@kvack.org; linux-ker...@vger.kernel.org
> Subject: Re: Regression on linux-next (next-20240712)
> 
> On Wed, 17 Jul 2024 13:00:58 +0200 David Hildenbrand 
> wrote:
> 
> > > Could you please check why the patch causes this regression and provide
> a fix if necessary?
> >
> > This is know.
> >
> > There is a discussion along the original patch [1] on how to do it
> > differently. But likely we'll tackle it differently [2]. So this patch
> > should be dropped for -- which I think already happened because I
> > cannot spot that patch in mm-unstable anymore.
> 
> Yes, I dropped it on July 15.

Thank you. Our CI runs seems to have recovered from the regression.

Regards

Chaitanya

RE: Regression on linux-next (next-20240709)

[Borah, Chaitanya Kumar]

Hello Lai,

> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Tuesday, July 16, 2024 11:10 AM
> To: Lai Jiangshan 
> Cc: jiangshan@antgroup.com; linux-ker...@vger.kernel.org; Nikula, Jani
> ; Saarinen, Jani ; Kurmi,
> Suresh Kumar ; intel-
> g...@lists.freedesktop.org
> Subject: RE: Regression on linux-next (next-20240709)
> 
> 
> 
> > -Original Message-
> > From: Lai Jiangshan 
> > Sent: Friday, July 12, 2024 2:23 PM
> > To: Borah, Chaitanya Kumar 
> > Cc: jiangshan@antgroup.com; linux-ker...@vger.kernel.org; Nikula,
> > Jani ; Saarinen, Jani
> > ; Kurmi, Suresh Kumar
> > 
> > Subject: Re: Regression on linux-next (next-20240709)
> >
> > Hello
> >
> > On Fri, Jul 12, 2024 at 1:42 PM Borah, Chaitanya Kumar
> > > commit 1726a17135905e2d2773f18d47bd4e17dd26e1ed
> > > Author: Lai Jiangshan mailto:jiangshan@antgroup.com
> > > Date:   Thu Jul 4 11:49:13 2024 +0800
> > >
> > > workqueue: Put PWQ allocation and WQ enlistment in the same lock
> C.S.
> > > 
> > > `
> > >
> > > We could not revert the patch because of merge conflict but
> > > resetting to the
> > parent of the commit seems to fix the issue
> > >
> > > Could you please check why the patch causes this regression and
> > > provide a
> > fix if necessary?
> >
> >
> > It has been fixed and it is in wq/for-6.11.
> >
> > https://lore.kernel.org/lkml/zpasnbn0hptvc...@slm.duckdns.org/
> >

With this patch we are running into another regression.

```
<4>[4.171372] WARNING: CPU: 11 PID: 283 at kernel/cpu.c:527 
lockdep_assert_cpus_held.part.0+0x24/0x30
<4>[4.171377] Modules linked in: kvm_intel(+) mei_hdcp mei_pxp r8152(+) mii 
wmi_bmof kvm r8169 video crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
realtek i2c_i801 mei_me i2c_mux mei intel_lpss_pci(+) i2c_smbus wmi btusb btrtl 
btintel btbcm bluetooth
<4>[4.171385] CPU: 11 UID: 0 PID: 283 Comm: systemd-udevd Tainted: G
W  6.10.0-next-20240715-next-20240715-g91e3b24eb7d2+ #1
<4>[4.171387] Tainted: [W]=WARN
<4>[4.171387] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, 
BIOS 0812 02/24/2023
<4>[4.171388] RIP: 0010:lockdep_assert_cpus_held.part.0+0x24/0x30
```

Please find the full logs here.

https://gfx-ci.igk.intel.com/tree/linux-next/next-20240715/bat-rpls-4/boot0.txt

The issue was bisected to the commit you have mentioned above.

Reverting the patch resolves the issue.

Are you already looking into it?

Regards

Chaitanya
> 
> Thank you Lai for your response.
> 
> Regards
> 
> Chaitanya
> 
> > Thanks
> > Lai

RE: Regression on linux-next (next-20240709)

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Lai Jiangshan 
> Sent: Friday, July 12, 2024 2:23 PM
> To: Borah, Chaitanya Kumar 
> Cc: jiangshan@antgroup.com; linux-ker...@vger.kernel.org; Nikula, Jani
> ; Saarinen, Jani ; Kurmi,
> Suresh Kumar 
> Subject: Re: Regression on linux-next (next-20240709)
> 
> Hello
> 
> On Fri, Jul 12, 2024 at 1:42 PM Borah, Chaitanya Kumar
> > commit 1726a17135905e2d2773f18d47bd4e17dd26e1ed
> > Author: Lai Jiangshan mailto:jiangshan@antgroup.com
> > Date:   Thu Jul 4 11:49:13 2024 +0800
> >
> > workqueue: Put PWQ allocation and WQ enlistment in the same lock C.S.
> > `
> >
> > We could not revert the patch because of merge conflict but resetting to the
> parent of the commit seems to fix the issue
> >
> > Could you please check why the patch causes this regression and provide a
> fix if necessary?
> 
> 
> It has been fixed and it is in wq/for-6.11.
> 
> https://lore.kernel.org/lkml/zpasnbn0hptvc...@slm.duckdns.org/
> 

Thank you Lai for your response.

Regards

Chaitanya

> Thanks
> Lai

Regression on linux-next (next-20240712)

[Borah, Chaitanya Kumar]

Hello Pei,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

In version next-20240712[2], we saw the following regression (currently being 
masked by another regression)

`
<4>[   14.530533] 
<4>[   14.530533] WARNING: possible recursive locking detected
<4>[   14.530534] 6.10.0-rc7-next-20240712-next-20240712-g3fe121b62282+ #1 Not 
tainted
<4>[   14.530535] 
<4>[   14.530535] (direxec)/171 is trying to acquire lock:
<4>[   14.530536] 8881010725d8 (&mm->mmap_lock){}-{3:3}, at: 
unmap_single_vma+0xea/0x170
<4>[   14.530541] 
  but task is already holding lock:
<4>[   14.530542] 8881010725d8 (&mm->mmap_lock){}-{3:3}, at: 
exit_mmap+0x6a/0x450
<4>[   14.530545] 
  other info that might help us debug this:
<4>[   14.530545]  Possible unsafe locking scenario:
`
Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the first "bad"
commit

`
commit a13252049629a8225f38a9be7d8d4fc4ff5350e8
Author: Pei Li mailto:peili@gmail.com
Date:   Wed Jul 10 22:13:17 2024 -0700

    mm: fix mmap_assert_locked() in follow_pte()

`

We also verified that if we revert the patch the issue is not seen.

Could you please check why the patch causes this regression and provide a fix 
if necessary?

Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240712
 
[3] 
https://gfx-ci.igk.intel.com/tree/linux-next/next-20240712/bat-arlh-2/boot0.txt
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240712&id=a13252049629a8225f38a9be7d8d4fc4ff5350e8

RE: Regression on linux-next (next-20240709)

[Borah, Chaitanya Kumar]

[+intel-gfx]

Hello Jiangshan,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

Since the version next-20240709 [2], we are seeing the following regression 
during boot up.

`
<4>[0.813758] 
<4>[0.813758] WARNING: possible recursive locking detected
<4>[0.813758] 6.10.0-rc7-next-20240709-next-20240709-g82d01fe6ee52+ #1 Not 
tainted
<4>[0.813758] 
<4>[0.813758] swapper/0/1 is trying to acquire lock:
<4>[0.813758] 8264adb0 (cpu_hotplug_lock){}-{0:0}, at: 
alloc_workqueue+0x31a/0x820
<4>[0.813758] 
  but task is already holding lock:
<4>[0.813758] 8264adb0 (cpu_hotplug_lock){}-{0:0}, at: 
padata_alloc+0x56/0x140
<4>[0.813758] 
  other info that might help us debug this:
<4>[0.813758]  Possible unsafe locking scenario:

<4>[0.813758]CPU0
<4>[0.813758]
<4>[0.813758]   lock(cpu_hotplug_lock);
<4>[0.813758]   lock(cpu_hotplug_lock);
<4>[0.813758] 
   *** DEADLOCK ***

<4>[0.813758]  May be due to missing lock nesting notation

<4>[0.813758] 1 lock held by swapper/0/1:
<4>[0.813758]  #0: 8264adb0 (cpu_hotplug_lock){}-{0:0}, at: 
padata_alloc+0x56/0x140
<4>[0.813758] 
  stack backtrace:
<4>[0.813758] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 
6.10.0-rc7-next-20240709-next-20240709-g82d01fe6ee52+ #1
<4>[0.813758] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, 
BIOS 0812 02/24/2023
<4>[0.813758] Call Trace:
<4>[0.813758]  
<4>[0.813758]  dump_stack_lvl+0x82/0xd0
<4>[0.813758]  print_deadlock_bug+0x259/0x390
<4>[0.813758]  __lock_acquire+0x733/0x1f60
<4>[0.813758]  lock_acquire+0xd1/0x2f0
<4>[0.813758]  ? alloc_workqueue+0x31a/0x820
<4>[0.813758]  cpus_read_lock+0x3b/0xe0
<4>[0.813758]  ? alloc_workqueue+0x31a/0x820
<4>[0.813758]  alloc_workqueue+0x31a/0x820
<4>[0.813758]  ? __pfx_pcrypt_init+0x10/0x10
<4>[0.813758]  padata_alloc+0x6f/0x140
<4>[0.813758]  pcrypt_init_padata+0x12/0x80
<4>[0.813758]  ? __pfx_pcrypt_init+0x10/0x10
<4>[0.813758]  pcrypt_init+0x3a/0xa0
<4>[0.813758]  do_one_initcall+0x5c/0x2b0
<4>[0.813758]  kernel_init_freeable+0x18e/0x340
<4>[0.813758]  ? __pfx_kernel_init+0x10/0x10
<4>[0.813758]  kernel_init+0x15/0x130
<4>[0.813758]  ret_from_fork+0x2c/0x50
<4>[0.813758]  ? __pfx_kernel_init+0x10/0x10
<4>[0.813758]  ret_from_fork_asm+0x1a/0x30
<4>[0.813758]  
`
Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the first "bad"
commit

`
commit 1726a17135905e2d2773f18d47bd4e17dd26e1ed
Author: Lai Jiangshan mailto:jiangshan@antgroup.com
Date:   Thu Jul 4 11:49:13 2024 +0800

workqueue: Put PWQ allocation and WQ enlistment in the same lock C.S.
`

We could not revert the patch because of merge conflict but resetting to the 
parent of the commit seems to fix the issue

Could you please check why the patch causes this regression and provide a fix 
if necessary?

Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240709
 
[3] 
https://gfx-ci.igk.intel.com/tree/linux-next/next-20240709/bat-rpls-4/boot0.txt
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240709&id=1726a17135905e2d2773f18d47bd4e17dd26e1ed

RE: Regression on linux-next (next-20240625)

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Sidhartha Kumar 
> Sent: Friday, June 28, 2024 8:24 PM
> To: Borah, Chaitanya Kumar 
> Cc: liam.howl...@oracle.com; a...@linux-foundation.org; linux-
> m...@kvack.org; maple-t...@lists.infradead.org; Nikula, Jani
> ; Saarinen, Jani ; Kurmi,
> Suresh Kumar ; intel-
> g...@lists.freedesktop.org
> Subject: Re: Regression on linux-next (next-20240625)
> 
> On 6/27/24 9:45 PM, Borah, Chaitanya Kumar wrote:
> > [converted to plain text]
> > +intel-gfx
> >
> > Gentle Reminder.
> >
> 
> Hello,
> 
> This patch will be dropped from mm-unstable and will not be in linux-next
> after that. I am working on a fix to include for the next version of this 
> series.

Thank you Siddartha, We don't see the regression anymore.

Regards

Chaitanya

> 
> Thanks,
> Sid
> 
> > From: Borah, Chaitanya Kumar
> > Sent: Wednesday, June 26, 2024 8:52 PM
> > To: sidhartha.ku...@oracle.com
> > Cc: liam.howl...@oracle.com; a...@linux-foundation.org;
> > linux...@kvack.org; maple-t...@lists.infradead.org; Nikula, Jani
> > ; Saarinen, Jani ;
> > Kurmi, Suresh Kumar 
> > Subject: Regression on linux-next (next-20240625)
> >
> > Hello Sidhartha,
> >
> > Hope you are doing well. I am Chaitanya from the linux graphics team in
> Intel.
> >
> > This mail is regarding a regression we are seeing in our CI runs[1] on 
> > linux-
> next repository.
> >
> > Since the version next-20240625 [2], we are seeing the following
> > regression
> >
> > ``
> > ``` <3>[    2.336948] BUG: sleeping function called from
> > invalid context at include/linux/sched/mm.h:337 <3>[    2.336974]
> > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 95, name:
> > kdevtmpfs <3>[    2.336989] preempt_count: 1, expected: 0 <3>[
> > 2.336998] RCU nest depth: 0, expected: 0 <4>[    2.337006] 3 locks
> > held by kdevtmpfs/95:
> > <4>[    2.337015]  #0: 888100d2c3f0 (sb_writers){.+.+}-{0:0}, at:
> > filename_create+0x5d/0x160 <4>[    2.337041]  #1: 888100800840
> > (&type->i_mutex_dir_key/1){+.+.}-{3:3}, at: filename_create+0x9d/0x160
> > <4>[    2.337065]  #2: 888100800658 (&simple_offset_lock_class){+.+.}-
> {2:2}, at: mtree_alloc_cyclic+0x71/0xf0 <3>[    2.337089] Preemption disabled
> at:
> > <3>[    2.337091] [<>] 0x0 <4>[    2.337105] CPU: 13
> > UID: 0 PID: 95 Comm: kdevtmpfs Not tainted
> > 6.10.0-rc5-next-20240625-next-20240625-g0fc4bfab2cd4+ #1 <4>[
> > 2.337126] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI,
> BIOS 0812 02/24/2023 <4>[    2.337141] Call Trace:
> > <4>[    2.337147]  
> > <4>[    2.337152]  dump_stack_lvl+0xb0/0xd0 <4>[    2.337163]
> > __might_resched+0x194/0x2b0 <4>[    2.337175]
> > kmem_cache_alloc_noprof+0x20c/0x280
> > <4>[    2.337186]  ? mas_alloc_nodes+0x173/0x230 <4>[    2.337197]
> > mas_alloc_nodes+0x173/0x230 <4>[    2.337207]
> > mas_alloc_cyclic+0x27b/0x550 <4>[    2.337220]
> > mtree_alloc_cyclic+0x92/0xf0
> > ``
> > ```
> > Details log can be found in [3].
> >
> > After bisecting the tree, the following patch [4] seems to be the first 
> > "bad"
> > commit
> >
> > ``
> > ```
> >      maple_tree: remove mas_destroy() from mas_nomem()
> >
> >      Separate call to mas_destroy() from mas_nomem() so we can check
> > for no
> >      memory errors without destroying the current maple state in
> >      mas_store_gfp().  We then add calls to mas_destroy() to callers
> > of
> >      mas_nomem().
> >
> >      Link:
> > https://lkml.kernel.org/r/20240618204750.79512-6-sidhartha.kumar@oracl
> > e.com
> >      Signed-off-by: Sidhartha Kumar mailto:sidhartha.ku...@oracle.com
> >
> > ``
> > ```
> >
> > We could not revert the patch because of merge conflicts but resetting to
> the parent of the commit seems to fix the issue.
> >
> > Could you please check why the patch causes this regression and provide a
> fix if necessary?
> >
> > Thank you.
> >
> > Regards
> >
> > Chaitanya
> >
> > [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/co
> > mmit/?h=next-20240625 [3]
> > https://intel-gfx-ci.01.org/tree/linux-next/next-20240625/bat-rpls-4/b
> > oot0.txt [4]
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/co
> > mmit/?id=187827d2dc3749d66546696b78584ee4c54687b0

RE: Regression on linux-next (next-20240625)

[Borah, Chaitanya Kumar]

[converted to plain text]
+intel-gfx

Gentle Reminder.

From: Borah, Chaitanya Kumar 
Sent: Wednesday, June 26, 2024 8:52 PM
To: sidhartha.ku...@oracle.com
Cc: liam.howl...@oracle.com; a...@linux-foundation.org; linux...@kvack.org; 
maple-t...@lists.infradead.org; Nikula, Jani ; Saarinen, 
Jani ; Kurmi, Suresh Kumar 

Subject: Regression on linux-next (next-20240625)

Hello Sidhartha,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

Since the version next-20240625 [2], we are seeing the following regression

`
<3>[    2.336948] BUG: sleeping function called from invalid context at 
include/linux/sched/mm.h:337
<3>[    2.336974] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 95, 
name: kdevtmpfs
<3>[    2.336989] preempt_count: 1, expected: 0
<3>[    2.336998] RCU nest depth: 0, expected: 0
<4>[    2.337006] 3 locks held by kdevtmpfs/95:
<4>[    2.337015]  #0: 888100d2c3f0 (sb_writers){.+.+}-{0:0}, at: 
filename_create+0x5d/0x160
<4>[    2.337041]  #1: 888100800840 (&type->i_mutex_dir_key/1){+.+.}-{3:3}, 
at: filename_create+0x9d/0x160
<4>[    2.337065]  #2: 888100800658 
(&simple_offset_lock_class){+.+.}-{2:2}, at: mtree_alloc_cyclic+0x71/0xf0
<3>[    2.337089] Preemption disabled at:
<3>[    2.337091] [<>] 0x0
<4>[    2.337105] CPU: 13 UID: 0 PID: 95 Comm: kdevtmpfs Not tainted 
6.10.0-rc5-next-20240625-next-20240625-g0fc4bfab2cd4+ #1
<4>[    2.337126] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, 
BIOS 0812 02/24/2023
<4>[    2.337141] Call Trace:
<4>[    2.337147]  
<4>[    2.337152]  dump_stack_lvl+0xb0/0xd0
<4>[    2.337163]  __might_resched+0x194/0x2b0
<4>[    2.337175]  kmem_cache_alloc_noprof+0x20c/0x280
<4>[    2.337186]  ? mas_alloc_nodes+0x173/0x230
<4>[    2.337197]  mas_alloc_nodes+0x173/0x230
<4>[    2.337207]  mas_alloc_cyclic+0x27b/0x550
<4>[    2.337220]  mtree_alloc_cyclic+0x92/0xf0
`
Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the first "bad"
commit

`
    maple_tree: remove mas_destroy() from mas_nomem()

    Separate call to mas_destroy() from mas_nomem() so we can check for no
    memory errors without destroying the current maple state in
    mas_store_gfp().  We then add calls to mas_destroy() to callers of
    mas_nomem().

    Link: 
https://lkml.kernel.org/r/20240618204750.79512-6-sidhartha.ku...@oracle.com
    Signed-off-by: Sidhartha Kumar mailto:sidhartha.ku...@oracle.com

`

We could not revert the patch because of merge conflicts but resetting to the 
parent of the commit seems to fix the issue.

Could you please check why the patch causes this regression and provide a fix 
if necessary?

Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240625
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20240625/bat-rpls-4/boot0.txt 
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=187827d2dc3749d66546696b78584ee4c54687b0

RE: [core-for-CI PATCH] Revert "e1000e: move force SMBUS near the end of enable_ulp function"

[Borah, Chaitanya Kumar]

Hi Jani,

> -Original Message-
> From: Saarinen, Jani 
> Sent: Monday, June 10, 2024 2:28 PM
> To: Saarinen, Jani ; Borah, Chaitanya Kumar
> ; intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar 
> Subject: RE: [core-for-CI PATCH] Revert "e1000e: move force SMBUS near the
> end of enable_ulp function"
> 
> Hi,
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Saarinen, Jani
> > Sent: Monday, 10 June 2024 11.23
> > To: Borah, Chaitanya Kumar ; intel-
> > g...@lists.freedesktop.org
> > Cc: Borah, Chaitanya Kumar 
> > Subject: RE: [core-for-CI PATCH] Revert "e1000e: move force SMBUS near
> > the end of enable_ulp function"
> >
> > Hi,
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Chaitanya Kumar Borah
> > > Sent: Monday, 10 June 2024 10.46
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Borah, Chaitanya Kumar 
> > > Subject: [core-for-CI PATCH] Revert "e1000e: move force SMBUS near
> > > the end of enable_ulp function"
> > >
> > > This reverts commit bfd546a552e140b0a4c8a21527c39d6d21addb28.
> > >
> > > The commit seems to cause problems in suspend-resume tests
> > >
> > > [212.204897] e1000e :00:1f.6: PM: pci_pm_suspend():
> > > e1000e_pm_suspend [e1000e] returns -2 [212.204928] e1000e
> > :00:1f.6:
> > > PM: dpm_run_callback(): pci_pm_suspend returns -2 [212.204943]
> > > e1000e
> > > :00:1f.6: PM: failed to suspend async: error -2 [212.205092] PM:
> > > suspend of devices aborted after 302.254 msecs
> > >
> > > References:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14904/shard-
> > > dg2-4/igt@gem_ccs@suspend-resume@linear-compressed-compfmt0-
> > > lmem0-lmem0.html
> > > References:
> > > https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11305
> > > Signed-off-by: Chaitanya Kumar Borah
> > > 
> >
> > Acked-By: Jani Saarinen 
> >
> > We have already trybot results from revert
> > https://patchwork.freedesktop.org/series/134603/#rev2 /
> > https://intel-gfx-
> > ci.01.org/tree/drm-tip/Trybot_134603v2/index.html?testfilter=suspend
> > So helps on these. Let's get this merged asap.
> When merging please reference
> https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11308
> 

As discussed, we already have 
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11305 tracking the 
revert :)
We can close this one.

Regards

Chaitanya

> Br,
> Jani
> 
> >
> > Br,
> > Jani
> >
> > > ---
> > >  drivers/net/ethernet/intel/e1000e/ich8lan.c | 22
> > > - drivers/net/ethernet/intel/e1000e/netdev.c  |
> > > 18
> > > +
> > >  2 files changed, 18 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> > > b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> > > index 2e98a2a0bead..f9e94be36e97 100644
> > > --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> > > +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> > > @@ -1225,28 +1225,6 @@ s32 e1000_enable_ulp_lpt_lp(struct e1000_hw
> > > *hw, bool to_sx)
> > >   }
> > >
> > >  release:
> > > - /* Switching PHY interface always returns MDI error
> > > -  * so disable retry mechanism to avoid wasting time
> > > -  */
> > > - e1000e_disable_phy_retry(hw);
> > > -
> > > - /* Force SMBus mode in PHY */
> > > - ret_val = e1000_read_phy_reg_hv_locked(hw, CV_SMB_CTRL,
> > > &phy_reg);
> > > - if (ret_val) {
> > > - e1000e_enable_phy_retry(hw);
> > > - hw->phy.ops.release(hw);
> > > - goto out;
> > > - }
> > > - phy_reg |= CV_SMB_CTRL_FORCE_SMBUS;
> > > - e1000_write_phy_reg_hv_locked(hw, CV_SMB_CTRL, phy_reg);
> > > -
> > > - e1000e_enable_phy_retry(hw);
> > > -
> > > - /* Force SMBus mode in MAC */
> > > - mac_reg = er32(CTRL_EXT);
> > > - mac_reg |= E1000_CTRL_EXT_FORCE_SMBUS;
> > > - ew32(CTRL_EXT, mac_reg);
> > > -
> > >   hw->phy.ops.release(hw);
> > >  out:
> > >   if (ret_val)
> > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > index da5c59daf8ba..220d62fca55d 100644
> > > --- a/drivers/net/ethernet/intel/

RE: [core-for-CI PATCH] Revert "igc: fix a log entry using uninitialized netdev"

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Tuesday, May 28, 2024 1:16 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: [core-for-CI PATCH] Revert "igc: fix a log entry using uninitialized
> netdev"
> 
> This reverts commit 86167183a17e03ec77198897975e9fdfbd53cb0b.
> 
> The commit moved igc_ptp_init() which initializes spinlocks after
> igt_reset() which ends up using the adapter->ptp_tx_lock. Lockdep isn't
> happy:
> 
> <3>[   10.648947] INFO: trying to register non-static key.
> <3>[   10.648950] The code is fine but needs lockdep annotation, or maybe
> <3>[   10.648951] you didn't initialize this object before use?
> <3>[   10.648952] turning off the locking correctness validator.
> <4>[   10.648954] CPU: 2 PID: 313 Comm: systemd-udevd Not tainted 6.9.0-
> next-20240513-next-20240513-g6ba6c795dc73+ #1
> <4>[   10.648958] Hardware name: Intel Corporation Arrow Lake Client
> Platform/MTL-S UDIMM 2DPC EVCRB, BIOS
> MTLSFWI1.R00.3473.D80.2311222130 11/22/2023
> <4>[   10.648960] Call Trace:
> <4>[   10.648962]  
> <4>[   10.648964]  dump_stack_lvl+0x82/0xd0
> <4>[   10.648971]  register_lock_class+0x795/0x7e0
> <4>[   10.648978]  ? __free_object+0xa1/0x340
> <4>[   10.648983]  ? lockdep_hardirqs_on+0xc1/0x140
> <4>[   10.648990]  __lock_acquire+0x75/0x2260
> <4>[   10.648993]  ? __switch_to+0x123/0x600
> <4>[   10.648997]  ? _raw_spin_unlock_irqrestore+0x58/0x70
> <4>[   10.649002]  lock_acquire+0xd9/0x2f0
> <4>[   10.649006]  ? igc_ptp_clear_tx_tstamp+0x28/0x60 [igc]
> <4>[   10.649027]  _raw_spin_lock_irqsave+0x3d/0x60
> <4>[   10.649030]  ? igc_ptp_clear_tx_tstamp+0x28/0x60 [igc]
> <4>[   10.649038]  igc_ptp_clear_tx_tstamp+0x28/0x60 [igc]
> <4>[   10.649048]  igc_ptp_set_timestamp_mode.isra.0+0x20b/0x230 [igc]
> <4>[   10.649056]  igc_ptp_reset+0x31/0x180 [igc]
> <4>[   10.649066]  igc_reset+0xb4/0x100 [igc]
> <4>[   10.649079]  igc_probe+0x797/0x8e0 [igc]
> <4>[   10.649091]  pci_device_probe+0x95/0x120
> <4>[   10.649095]  really_probe+0xd9/0x370
> <4>[   10.649099]  ? __pfx___driver_attach+0x10/0x10
> <4>[   10.649101]  __driver_probe_device+0x73/0x150
> <4>[   10.649103]  driver_probe_device+0x19/0xa0
> <4>[   10.649105]  __driver_attach+0xb6/0x180
> <4>[   10.649107]  ? __pfx___driver_attach+0x10/0x10
> <4>[   10.649109]  bus_for_each_dev+0x77/0xd0
> <4>[   10.649114]  bus_add_driver+0x110/0x240
> <4>[   10.649117]  driver_register+0x5b/0x110
> <4>[   10.649120]  ? __pfx_igc_init_module+0x10/0x10 [igc]
> <4>[   10.649130]  do_one_initcall+0x5c/0x2b0
> <4>[   10.649134]  ? kmalloc_trace_noprof+0x22f/0x290
> <4>[   10.649141]  ? do_init_module+0x1e/0x210
> <4>[   10.669989]  do_init_module+0x5f/0x210
> <4>[   10.669993]  load_module+0x1d44/0x1fc0
> <4>[   10.670001]  ? init_module_from_file+0x86/0xd0
> <4>[   10.670004]  init_module_from_file+0x86/0xd0
> <4>[   10.670009]  idempotent_init_module+0x17c/0x230
> <4>[   10.670015]  __x64_sys_finit_module+0x56/0xb0
> <4>[   10.670019]  do_syscall_64+0x69/0x140
> <4>[   10.670023]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> <4>[   10.670027] RIP: 0033:0x7f6d2704595d
> <4>[   10.670030] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 
> 89
> f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 
> 01
> f0 ff ff 73 01 c3 48
> 8b 0d 03 35 0d 00 f7 d8 64 89 01 48
> <4>[   10.670032] RSP: 002b:7ffc72aad018 EFLAGS: 0246 ORIG_RAX:
> 0139
> <4>[   10.670036] RAX: ffda RBX: 55d3f0e69690 RCX:
> 7f6d2704595d
> <4>[   10.670038] RDX:  RSI: 7f6d26f25ded RDI:
> 0010
> <4>[   10.670039] RBP: 0002 R08:  R09:
> 
> <4>[   10.670041] R10: 0010 R11: 0246 R12:
> 7f6d26f25ded
> <4>[   10.670042] R13:  R14: 55d3f0c64d20 R15:
> 55d3f0e69690
> <4>[   10.670046]  
> <6>[   10.672046] pps pps0: new PPS source ptp0
> 
> References: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11198
> References: https://lore.kernel.org/r/87o78rmkhu@intel.com
> Signed-off-by: Jani Nikula 


Acked-by: Chaitanya Kumar Borah 




> ---
>  drivers/net/ethernet/intel/igc/igc_main.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c
> b/drivers/net/ethernet/intel/igc/igc_main.c
> index 12f004f46082..ace2fbfd87d6 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -7028,6 +7028,8 @@ static int igc_probe(struct pci_dev *pdev,
>   device_set_wakeup_enable(&adapter->pdev->dev,
>adapter->flags &
> IGC_FLAG_WOL_SUPPORTED);
> 
> + igc_ptp_init(adapter);
> +
>   igc_tsn_clear_schedule(adapter);
> 
>   /* reset the hardware with the new settings */ @@ -7049,9 +7051,6
> @@ static int igc_probe(struct pci_dev *pdev,
>   /* Check if Media Autosense is enabled */

RE: [PATCH 0/6] drm/i915/pps: pass dev_priv explicitly to PPS regs

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Monday, May 27, 2024 4:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; ville.syrj...@linux.intel.com
> Subject: [PATCH 0/6] drm/i915/pps: pass dev_priv explicitly to PPS regs
> 
> Continue avoiding the implicit dev_priv local variable.
> 

LGTM
Reviewed-by: Chaitanya Kumar Borah 



> Jani Nikula (6):
>   drm/i915: pass dev_priv explicitly to _MMIO_PPS
>   drm/i915: pass dev_priv explicitly to PP_STATUS
>   drm/i915: pass dev_priv explicitly to PP_CONTROL
>   drm/i915: pass dev_priv explicitly to PP_ON_DELAYS
>   drm/i915: pass dev_priv explicitly to PP_OFF_DELAYS
>   drm/i915: pass dev_priv explicitly to PP_DIVISOR
> 
>  .../drm/i915/display/intel_display_power.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c  |  4 +--
>  drivers/gpu/drm/i915/display/intel_lvds.c | 29 +-
>  drivers/gpu/drm/i915/display/intel_pps.c  | 30 +--
>  drivers/gpu/drm/i915/display/intel_pps_regs.h | 16 +-
>  5 files changed, 41 insertions(+), 40 deletions(-)
> 
> --
> 2.39.2

RE: [PATCH 00/11] drm/i915: pass dev_priv explicitly to DIP regs

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Monday, May 27, 2024 4:41 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: [PATCH 00/11] drm/i915: pass dev_priv explicitly to DIP regs
> 
> Continue removing implicit dev_priv references.
> 

LGTM
Reviewed-by: Chaitanya Kumar Borah 



> Jani Nikula (11):
>   drm/i915: pass dev_priv explicitly to HSW_TVIDEO_DIP_CTL
>   drm/i915: pass dev_priv explicitly to HSW_TVIDEO_DIP_GCP
>   drm/i915: pass dev_priv explicitly to HSW_TVIDEO_DIP_AVI_DATA
>   drm/i915: pass dev_priv explicitly to HSW_TVIDEO_DIP_VS_DATA
>   drm/i915: pass dev_priv explicitly to HSW_TVIDEO_DIP_SPD_DATA
>   drm/i915: pass dev_priv explicitly to HSW_TVIDEO_DIP_GMP_DATA
>   drm/i915: pass dev_priv explicitly to HSW_TVIDEO_DIP_VSC_DATA
>   drm/i915: pass dev_priv explicitly to GLK_TVIDEO_DIP_DRM_DATA
>   drm/i915: pass dev_priv explicitly to ICL_VIDEO_DIP_PPS_DATA
>   drm/i915: pass dev_priv explicitly to ICL_VIDEO_DIP_PPS_ECC
>   drm/i915: pass dev_priv explicitly to ADL_TVIDEO_DIP_AS_SDP_DATA
> 
>  drivers/gpu/drm/i915/display/intel_dp.c |  3 ++-
>  drivers/gpu/drm/i915/display/intel_hdmi.c   | 27 +++--
>  drivers/gpu/drm/i915/display/intel_lspcon.c |  2 +-
>  drivers/gpu/drm/i915/i915_reg.h | 22 -
>  drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 12 -
>  5 files changed, 34 insertions(+), 32 deletions(-)
> 
> --
> 2.39.2

Regression on drm-tip (CI_DRM_14817)

[Borah, Chaitanya Kumar]

Hello Vinschen,



Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.



This mail is regarding a regression we are seeing in our CI runs[1] on 
drm-tip[2] repository.



Since the version CI_DRM_14817[3], we are seeing the following regression



`

4>[   10.361988] Hardware name: Intel Corporation Arrow Lake Client 
Platform/MTL-S UDIMM 2DPC EVCRB, BIOS MTLSFWI1.R00.3473.D80.2311222130 
11/22/2023

<4>[   10.362613] Call Trace:

<4>[   10.363227]  

<4>[   10.363835]  dump_stack_lvl+0x82/0xd0

<4>[   10.364446]  register_lock_class+0x795/0x7e0

<4>[   10.365054]  ? __free_object+0xa1/0x340

<4>[   10.365659]  ? lockdep_hardirqs_on+0xc1/0x140

<4>[   10.366261]  __lock_acquire+0x73/0x2230

<4>[   10.366857]  ? _raw_spin_unlock_irqrestore+0x58/0x70

<4>[   10.367451]  lock_acquire+0xd9/0x2f0

<4>[   10.368038]  ? igc_ptp_clear_tx_tstamp+0x28/0x60 [igc]

<4>[   10.368638]  _raw_spin_lock_irqsave+0x3d/0x60

<4>[   10.369212]  ? igc_ptp_clear_tx_tstamp+0x28/0x60 [igc]

<4>[   10.369794]  igc_ptp_clear_tx_tstamp+0x28/0x60 [igc]

<4>[   10.370369]  igc_ptp_set_timestamp_mode.isra.0+0x20b/0x230 [igc]

<4>[   10.370944]  igc_ptp_reset+0x31/0x180 [igc]

<4>[   10.371513]  igc_reset+0xb4/0x100 [igc]

<4>[   10.372083]  igc_probe+0x797/0x8e0 [igc]

<4>[   10.372647]  pci_device_probe+0x95/0x120

<4>[   10.373199]  really_probe+0xd9/0x370

<4>[   10.373748]  ? __pfx___driver_attach+0x10/0x10

<4>[   10.374291]  __driver_probe_device+0x73/0x150

<4>[   10.374835]  driver_probe_device+0x19/0xa0

<4>[   10.375375]  __driver_attach+0xb6/0x180

<4>[   10.375908]  ? __pfx___driver_attach+0x10/0x10

<4>[   10.376438]  bus_for_each_dev+0x77/0xd0

<4>[   10.376968]  bus_add_driver+0x110/0x240

<4>[   10.377492]  driver_register+0x5b/0x110

<4>[   10.378015]  ? __pfx_igc_init_module+0x10/0x10 [igc]

<4>[   10.378551]  do_one_initcall+0x5c/0x2b0

<4>[   10.379079]  ? kmalloc_trace_noprof+0x22f/0x290

<4>[   10.379602]  ? do_init_module+0x1e/0x210

<4>[   10.380131]  do_init_module+0x5f/0x210

<4>[   10.380651]  load_module+0x1d44/0x1fc0

<4>[   10.381173]  ? init_module_from_file+0x86/0xd0

<4>[   10.381691]  init_module_from_file+0x86/0xd0

<4>[   10.382206]  idempotent_init_module+0x17c/0x230

<4>[   10.382723]  __x64_sys_finit_module+0x56/0xb0

<4>[   10.383237]  do_syscall_64+0x66/0x140

<4>[   10.383751]  entry_SYSCALL_64_after_hwframe+0x76/0x7e

<4>[   10.384264] RIP: 0033:0x7f668aeff95d

`

Details log can be found in [4].



We have identified the following patch [5] to be the first "bad" commit



`

commit 86167183a17e03ec77198897975e9fdfbd53cb0b

Author: Corinna Vinschen vinsc...@redhat.com

Date:   Tue Apr 23 12:24:54 2024 +0200



igc: fix a log entry using uninitialized netdev



During successful probe, igc logs this:



[5.133667] igc :01:00.0 (unnamed net_device) (uninitialized): PHC 
added



The reason is that igc_ptp_init() is called very early, even before

register_netdev() has been called. So the netdev_info() call works

on a partially uninitialized netdev.



Fix this by calling igc_ptp_init() after register_netdev(), right

after the media autosense check, just as in igb.  Add a comment,

just as in igb.



`



Could you please check why the patch causes this regression and provide a fix 
if necessary?



Thank you.



Regards



Chaitanya



[1] https://intel-gfx-ci.01.org/tree/drm-tip/index.html?
[2] https://cgit.freedesktop.org/drm-tip/
[3] https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14817/git-log-oneline.txt

[4] https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14817/bat-arls-1/boot0.txt
[5] 
https://cgit.freedesktop.org/drm-tip/commit/?id=86167183a17e03ec77198897975e9fdfbd53cb0b

RE: [RESEND 6/6] drm/connector: update edid_blob_ptr documentation

[Borah, Chaitanya Kumar]

> -Original Message-
> From: dri-devel  On Behalf Of Jani
> Nikula
> Sent: Friday, May 10, 2024 8:38 PM
> To: dri-de...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org; nouv...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; Nikula, Jani 
> Subject: [RESEND 6/6] drm/connector: update edid_blob_ptr documentation
> 
> Accessing the EDID via edid_blob_ptr causes chicken-and-egg problems. Keep
> edid_blob_ptr as the userspace interface that should be accessed via dedicated
> functions.
> 
> Signed-off-by: Jani Nikula 

LGTM
Reviewed-by: Chaitanya Kumar Borah 


> ---
>  include/drm/drm_connector.h | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index fe88d7fc6b8f..58ee9adf9091 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1636,8 +1636,12 @@ struct drm_connector {
> 
>   /**
>* @edid_blob_ptr: DRM property containing EDID if present.
> Protected by
> -  * &drm_mode_config.mutex. This should be updated only by calling
> +  * &drm_mode_config.mutex.
> +  *
> +  * This must be updated only by calling drm_edid_connector_update()
> or
>* drm_connector_update_edid_property().
> +  *
> +  * This must not be used by drivers directly.
>*/
>   struct drm_property_blob *edid_blob_ptr;
> 
> --
> 2.39.2

RE: [RESEND 5/6] drm/edid: add a helper for EDID sysfs property show

[Borah, Chaitanya Kumar]

> -Original Message-
> From: dri-devel  On Behalf Of Jani
> Nikula
> Sent: Friday, May 10, 2024 8:38 PM
> To: dri-de...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org; nouv...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; Nikula, Jani 
> Subject: [RESEND 5/6] drm/edid: add a helper for EDID sysfs property show
> 
> Add a helper to get the EDID property for sysfs property show. This hides all
> the edid_blob_ptr usage within drm_edid.c.
> 
> Signed-off-by: Jani Nikula 

LGTM,
Reviewed-by: Chaitanya Kumar Borah 



> ---
>  drivers/gpu/drm/drm_crtc_internal.h |  2 ++
>  drivers/gpu/drm/drm_edid.c  | 33 +
>  drivers/gpu/drm/drm_sysfs.c | 24 ++---
>  3 files changed, 37 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 25aaae937ceb..20e9d7b206a2 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -303,6 +303,8 @@ const u8 *drm_edid_find_extension(const struct
> drm_edid *drm_edid,
> int ext_id, int *ext_index);
>  void drm_edid_cta_sad_get(const struct cea_sad *cta_sad, u8 *sad);  void
> drm_edid_cta_sad_set(struct cea_sad *cta_sad, const u8 *sad);
> +ssize_t drm_edid_connector_property_show(struct drm_connector
> *connector,
> +  char *buf, loff_t off, size_t count);
> 
>  /* drm_edid_load.c */
>  #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 4f54c91b31b2..97362dd2330b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6969,6 +6969,39 @@ static int
> _drm_edid_connector_property_update(struct drm_connector *connector,
>   return ret;
>  }
> 
> +/* For sysfs edid show implementation */ ssize_t
> +drm_edid_connector_property_show(struct drm_connector *connector,
> +  char *buf, loff_t off, size_t count) {
> + const void *edid;
> + size_t size;
> + ssize_t ret = 0;
> +
> + mutex_lock(&connector->dev->mode_config.mutex);
> +
> + if (!connector->edid_blob_ptr)
> + goto unlock;
> +
> + edid = connector->edid_blob_ptr->data;
> + size = connector->edid_blob_ptr->length;
> + if (!edid)
> + goto unlock;
> +
> + if (off >= size)
> + goto unlock;
> +
> + if (off + count > size)
> + count = size - off;
> +
> + memcpy(buf, edid + off, count);
> +
> + ret = count;
> +unlock:
> + mutex_unlock(&connector->dev->mode_config.mutex);
> +
> + return ret;
> +}
> +
>  /**
>   * drm_edid_connector_update - Update connector information from EDID
>   * @connector: Connector
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index bd9b8ab4f82b..fb3bbb6adcd1 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -266,29 +266,9 @@ static ssize_t edid_show(struct file *filp, struct
> kobject *kobj,  {
>   struct device *connector_dev = kobj_to_dev(kobj);
>   struct drm_connector *connector =
> to_drm_connector(connector_dev);
> - unsigned char *edid;
> - size_t size;
> - ssize_t ret = 0;
> + ssize_t ret;
> 
> - mutex_lock(&connector->dev->mode_config.mutex);
> - if (!connector->edid_blob_ptr)
> - goto unlock;
> -
> - edid = connector->edid_blob_ptr->data;
> - size = connector->edid_blob_ptr->length;
> - if (!edid)
> - goto unlock;
> -
> - if (off >= size)
> - goto unlock;
> -
> - if (off + count > size)
> - count = size - off;
> - memcpy(buf, edid + off, count);
> -
> - ret = count;
> -unlock:
> - mutex_unlock(&connector->dev->mode_config.mutex);
> + ret = drm_edid_connector_property_show(connector, buf, off, count);
> 
>   return ret;
>  }
> --
> 2.39.2

RE: Regression on linux-next (next-20240506)

[Borah, Chaitanya Kumar]

Hi Thomas,

> -Original Message-
> From: Thomas Zimmermann 
> Sent: Wednesday, May 15, 2024 6:06 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani ;
> Nikula, Jani 
> Subject: Re: Regression on linux-next (next-20240506)
> 
> Hi
> 
> Am 15.05.24 um 13:38 schrieb Borah, Chaitanya Kumar:
> [...]
> >> Sorry, I didn't notice the report before. The commit is not related to 
> >> ACPI.
> >> There's now asm/video.h and acpi/video.h. Maybe there's a conflict
> >> among included files.
> >>
> >> Do you have a kernel config to build with?
> >>
> > ~Sorry my email client messed up my previous reply. So sending again~
> >
> > I could not find a public link for the linux-next config we use but this 
> > should
> be close enough.
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14764/kconfig.txt
> 
> Builds without problems.
> 
> But I think there's a name collision between the video module in drivers/acpi
> and the new video module in arch/*/video. The attached patch renames the
> ACPI module. Could you please try it and report back the results?
> 

The patch is fixing the regression for us 😊 Will you be floating it?

Regards

Chaitanya

> Best regards
> Thomas
> 
> 
> >
> > Regards
> > Chaitanya
> >
> >
> >> Best regards
> >> Thomas
> >>
> >>>> Thank you.
> >>>>
> >>>> Regards
> >>>>
> >>>> Chaitanya
> >>>>
> >>>> [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
> >>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> >>>> next.git/commit/?h=next-20240506
> >>>> [3]
> >>>> https://intel-gfx-ci.01.org/tree/linux-next/next-20240506/bat-mtlp-
> >>>> 9/igt@i915_selftest@live@gt_contexts.html
> >>>> [4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> >>>> next.git/commit/?h=next-
> >>>> 20240506&id=2fd001cd36005846caa6456fff1008c6f5bae9d4
> >> --
> >> --
> >> Thomas Zimmermann
> >> Graphics Driver Developer
> >> SUSE Software Solutions Germany GmbH
> >> Frankenstrasse 146, 90461 Nuernberg, Germany
> >> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB
> >> 36809 (AG Nuernberg)
> 
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB
> 36809 (AG Nuernberg)

RE: Regression on linux-next (next-20240506)

[Borah, Chaitanya Kumar]

Hello

> -Original Message-
> From: Thomas Zimmermann 
> Sent: Wednesday, May 15, 2024 2:25 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani ;
> Nikula, Jani 
> Subject: Re: Regression on linux-next (next-20240506)
> 
> Hi
> 
> Am 15.05.24 um 10:16 schrieb Borah, Chaitanya Kumar:
> >
> >> -----Original Message-
> >> From: Borah, Chaitanya Kumar
> >> Sent: Wednesday, May 8, 2024 3:05 PM
> >> To: tzimmerm...@suse.de
> >> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> >> ; Saarinen, Jani
> >> 
> >> Subject: Regression on linux-next (next-20240506)
> >>
> >> Hello Thomas,
> >>
> >> Hope you are doing well.
> >>
> >> This mail is regarding a regression we are seeing in our CI runs[1]
> >> on linux- next repository.
> >>
> >> Since the version next-20240506 [2], we are seeing the following
> >> regression
> >>
> >> `
> >>  Starting dynamic subtest: gt_contexts
> >> (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
> >> acpi_video_unregister (err -2)
> >> (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
> >> acpi_video_register_backlight (err -2)
> >> (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
> >> __acpi_video_get_backlight_type (err -2)
> >> (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
> >> acpi_video_register (err -2)
> >> (i915_selftest:1107) igt_kmod-CRITICAL: Test assertion failure
> >> function igt_kselftest_execute, file ../../../usr/src/igt-gpu-
> tools/lib/igt_kmod.c:1594:
> >> (i915_selftest:1107) igt_kmod-CRITICAL: Failed assertion: err == 0
> >> (i915_selftest:1107) igt_kmod-CRITICAL: kselftest "i915
> >> igt__23__live_gt_contexts=1 live_selftests=-1 disable_display=1 st_filter="
> >> failed: No such file or directory [2] Dynamic subtest gt_contexts failed.
> >> `
> >> 
> >> Details log can be found in [3].
> >>
> >> After bisecting the tree, the following patch [4] seems to be the first 
> >> "bad"
> >> commit
> >>
> >> `
> >> 
> >> 2fd001cd36005846caa6456fff1008c6f5bae9d4 is the first bad commit
> >> commit
> >> 2fd001cd36005846caa6456fff1008c6f5bae9d4
> >> Author: Thomas Zimmermann tzimmerm...@suse.de
> >> Date:   Fri Mar 29 21:32:12 2024 +0100
> >>
> >>      arch: Rename fbdev header and source files
> >> `
> >> 
> >>
> >> We also verified that if we revert the patch the issue is not seen.
> >>
> >> Could you please check why the patch causes this regression and
> >> provide a fix if necessary?
> >>
> > +Jani N
> >
> > Gentle Reminder 😊
> 
> Sorry, I didn't notice the report before. The commit is not related to ACPI.
> There's now asm/video.h and acpi/video.h. Maybe there's a conflict among
> included files.
> 
> Do you have a kernel config to build with?
> 
~Sorry my email client messed up my previous reply. So sending again~

I could not find a public link for the linux-next config we use but this should 
be close enough.
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14764/kconfig.txt

Regards
Chaitanya


> Best regards
> Thomas
> 
> >
> >> Thank you.
> >>
> >> Regards
> >>
> >> Chaitanya
> >>
> >> [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> >> next.git/commit/?h=next-20240506
> >> [3]
> >> https://intel-gfx-ci.01.org/tree/linux-next/next-20240506/bat-mtlp-
> >> 9/igt@i915_selftest@live@gt_contexts.html
> >> [4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> >> next.git/commit/?h=next-
> >> 20240506&id=2fd001cd36005846caa6456fff1008c6f5bae9d4
> 
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB
> 36809 (AG Nuernberg)

Re: Regression on linux-next (next-20240506)

[Borah, Chaitanya Kumar]

Hi,

On 5/15/2024 2:24 PM, Thomas Zimmermann wrote:

Hi

Am 15.05.24 um 10:16 schrieb Borah, Chaitanya Kumar:



-Original Message-
From: Borah, Chaitanya Kumar
Sent: Wednesday, May 8, 2024 3:05 PM
To: tzimmerm...@suse.de
Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
; Saarinen, Jani 


Subject: Regression on linux-next (next-20240506)

Hello Thomas,

Hope you are doing well.

This mail is regarding a regression we are seeing in our CI runs[1] 
on linux-

next repository.

Since the version next-20240506 [2], we are seeing the following 
regression


` 


Starting dynamic subtest: gt_contexts
(i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
acpi_video_unregister (err -2)
(i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
acpi_video_register_backlight (err -2)
(i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
__acpi_video_get_backlight_type (err -2)
(i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
acpi_video_register (err -2)
(i915_selftest:1107) igt_kmod-CRITICAL: Test assertion failure function
igt_kselftest_execute, file 
../../../usr/src/igt-gpu-tools/lib/igt_kmod.c:1594:

(i915_selftest:1107) igt_kmod-CRITICAL: Failed assertion: err == 0
(i915_selftest:1107) igt_kmod-CRITICAL: kselftest "i915
igt__23__live_gt_contexts=1 live_selftests=-1 disable_display=1 
st_filter="
failed: No such file or directory [2] Dynamic subtest gt_contexts 
failed.
` 


Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the 
first "bad"

commit

` 


2fd001cd36005846caa6456fff1008c6f5bae9d4 is the first bad commit commit
2fd001cd36005846caa6456fff1008c6f5bae9d4
Author: Thomas Zimmermann tzimmerm...@suse.de
Date:   Fri Mar 29 21:32:12 2024 +0100

 arch: Rename fbdev header and source files
` 



We also verified that if we revert the patch the issue is not seen.

Could you please check why the patch causes this regression and 
provide a fix

if necessary?


+Jani N

Gentle Reminder 😊


Sorry, I didn't notice the report before. The commit is not related to 
ACPI. There's now asm/video.h and acpi/video.h. Maybe there's a 
conflict among included files.


Do you have a kernel config to build with?


I could not find a public link for the linux-next config we use but this 
should be close enough.


https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14764/kconfig.txt


Regards

Chaitanya



Best regards
Thomas




Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
next.git/commit/?h=next-20240506
[3] https://intel-gfx-ci.01.org/tree/linux-next/next-20240506/bat-mtlp-
9/igt@i915_selftest@live@gt_contexts.html
[4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
next.git/commit/?h=next-
20240506&id=2fd001cd36005846caa6456fff1008c6f5bae9d4

RE: Regression on linux-next (next-20240506)

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Wednesday, May 8, 2024 3:05 PM
> To: tzimmerm...@suse.de
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: Regression on linux-next (next-20240506)
> 
> Hello Thomas,
> 
> Hope you are doing well.
> 
> This mail is regarding a regression we are seeing in our CI runs[1] on linux-
> next repository.
> 
> Since the version next-20240506 [2], we are seeing the following regression
> 
> `
> Starting dynamic subtest: gt_contexts
> (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
> acpi_video_unregister (err -2)
> (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
> acpi_video_register_backlight (err -2)
> (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
> __acpi_video_get_backlight_type (err -2)
> (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol
> acpi_video_register (err -2)
> (i915_selftest:1107) igt_kmod-CRITICAL: Test assertion failure function
> igt_kselftest_execute, file 
> ../../../usr/src/igt-gpu-tools/lib/igt_kmod.c:1594:
> (i915_selftest:1107) igt_kmod-CRITICAL: Failed assertion: err == 0
> (i915_selftest:1107) igt_kmod-CRITICAL: kselftest "i915
> igt__23__live_gt_contexts=1 live_selftests=-1 disable_display=1 st_filter="
> failed: No such file or directory [2] Dynamic subtest gt_contexts failed.
> `
> Details log can be found in [3].
> 
> After bisecting the tree, the following patch [4] seems to be the first "bad"
> commit
> 
> `
> 2fd001cd36005846caa6456fff1008c6f5bae9d4 is the first bad commit commit
> 2fd001cd36005846caa6456fff1008c6f5bae9d4
> Author: Thomas Zimmermann tzimmerm...@suse.de
> Date:   Fri Mar 29 21:32:12 2024 +0100
> 
>     arch: Rename fbdev header and source files
> `
> 
> We also verified that if we revert the patch the issue is not seen.
> 
> Could you please check why the patch causes this regression and provide a fix
> if necessary?
> 
+Jani N

Gentle Reminder 😊

> Thank you.
> 
> Regards
> 
> Chaitanya
> 
> [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/commit/?h=next-20240506
> [3] https://intel-gfx-ci.01.org/tree/linux-next/next-20240506/bat-mtlp-
> 9/igt@i915_selftest@live@gt_contexts.html
> [4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/commit/?h=next-
> 20240506&id=2fd001cd36005846caa6456fff1008c6f5bae9d4

Regression on linux-next (next-20240506)

[Borah, Chaitanya Kumar]

Hello Thomas,
 
Hope you are doing well.
 
This mail is regarding a regression we are seeing in our CI runs[1] on
linux-next repository.
 
Since the version next-20240506 [2], we are seeing the following regression
 
`
Starting dynamic subtest: gt_contexts
(i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol 
acpi_video_unregister (err -2)
(i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol 
acpi_video_register_backlight (err -2)
(i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol 
__acpi_video_get_backlight_type (err -2)
(i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol acpi_video_register 
(err -2)
(i915_selftest:1107) igt_kmod-CRITICAL: Test assertion failure function 
igt_kselftest_execute, file ../../../usr/src/igt-gpu-tools/lib/igt_kmod.c:1594:
(i915_selftest:1107) igt_kmod-CRITICAL: Failed assertion: err == 0
(i915_selftest:1107) igt_kmod-CRITICAL: kselftest "i915 
igt__23__live_gt_contexts=1 live_selftests=-1 disable_display=1 st_filter=" 
failed: No such file or directory [2]
Dynamic subtest gt_contexts failed.
`
Details log can be found in [3].
 
After bisecting the tree, the following patch [4] seems to be the first "bad" 
commit
 
`
2fd001cd36005846caa6456fff1008c6f5bae9d4 is the first bad commit
commit 2fd001cd36005846caa6456fff1008c6f5bae9d4
Author: Thomas Zimmermann tzimmerm...@suse.de
Date:   Fri Mar 29 21:32:12 2024 +0100
 
    arch: Rename fbdev header and source files
`
 
We also verified that if we revert the patch the issue is not seen.
 
Could you please check why the patch causes this regression and provide a fix 
if necessary?
 
Thank you.
 
Regards
 
Chaitanya
 
[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240506
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20240506/bat-mtlp-9/igt@i915_selftest@live@gt_contexts.html
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240506&id=2fd001cd36005846caa6456fff1008c6f5bae9d4
 

RE: [v3] drm/i915: Implement Audio WA_14020863754

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Shankar, Uma 
> Sent: Monday, May 6, 2024 3:48 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ;
> jani.nik...@linux.intel.com; Roper, Matthew D
> ; Shankar, Uma 
> Subject: [v3] drm/i915: Implement Audio WA_14020863754
> 
> WA_14020863754: Corner case with Min Hblank Fix can cause audio hang
> 
> Issue: Previously a fix was made to avoid issues with extremely small hblanks,
> called the "Min Hblank Fix". However, this can potentially cause an audio
> hang.
> 
> Workaround :
> During "Audio Programming Sequence" Audio Enabling - When DP mode is
> enabled Set mmio offset 0x65F1C bit 18 = 1b, before step #1 "Enable audio
> Presence Detect"
> 
> During "Audio Programming Sequence" Audio Disabling - When DP mode is
> enabled Clear mmio offset 0x65F1C bit 18 = 0b, after step #6 "Disable Audio
> PD (Presence Detect)"
> If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave = 1b)
> 
> v2: Update the platform checks (Jani Nikula)
> 
> v3: Limited the WA to LNL and BMG, added a helper (Matt Roper)
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 18 ++
>  .../gpu/drm/i915/display/intel_audio_regs.h|  3 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index ed81e1466c4b..cb055c16dd98 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -183,6 +183,18 @@ static const struct hdmi_aud_ncts
> hdmi_aud_ncts_36bpp[] = {
>   { 192000, TMDS_445_5M, 20480, 371250 },  };
> 
> +/*
> + * WA_14020863754: Implement Audio Workaround
> + * Corner case with Min Hblank Fix can cause audio hang  */ static bool
> +needs_wa_14020863754(struct drm_i915_private *i915) {
> + if (DISPLAY_VER(i915) == 20 || IS_BATTLEMAGE(i915))
> + return true;
> +
> + return false;
> +}
> +
>  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */  static u32
> audio_config_hdmi_pixel_clock(const struct intel_crtc_state *crtc_state)  {
> @@ -415,6 +427,9 @@ static void hsw_audio_codec_disable(struct
> intel_encoder *encoder,
>   intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
>AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0);
> 
> + if (needs_wa_14020863754(i915))
> + intel_de_rmw(i915, AUD_CHICKENBIT_REG3,
> CHICKEN3_SPARE18, 0);
> +
>   mutex_unlock(&i915->display.audio.mutex);
>  }
> 
> @@ -540,6 +555,9 @@ static void hsw_audio_codec_enable(struct
> intel_encoder *encoder,
>   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP))
>   enable_audio_dsc_wa(encoder, crtc_state);
> 
> + if (needs_wa_14020863754(i915))
> + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0,
> CHICKEN3_SPARE18);
> +
>   /* Enable audio presence detect */
>   intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
>0, AUDIO_OUTPUT_ENABLE(cpu_transcoder));
> diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> index 88ea2740365d..7de82cd3380e 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> @@ -164,4 +164,7 @@
> 
> _VLV_AUD_PORT_EN_D_DBG)
>  #define VLV_AMP_MUTE (1 << 1)
> 
> +#define AUD_CHICKENBIT_REG3  _MMIO(0x65F1C)
> +#define  CHICKEN3_SPARE18REG_BIT(18)

Nit. This bit seems to have a name now (Bspec-69036). Otherwise, LGTM.

Reviewed-by: Chaitanya Kumar Borah 



> +
>  #endif /* __INTEL_AUDIO_REGS_H__ */
> --
> 2.42.0

RE: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-gfx  On Behalf Of Suraj
> Kandpal
> Sent: Tuesday, May 7, 2024 11:53 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Kandpal, Suraj
> 
> Subject: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on
> HDMI
> 
> Disable HDCP Line Rekeying when HDCP ver > 1.4 and when we are on HDMI
> TMDS operation for DISPLAY_VER >= 14.
> 
> --v2
> -Wa to be mentioned in comments not in commit message [Jani] -Remove
> blankline [Jani]
> 
> --v3
> -No need to write what is being done in comments when code is self
> explanatory [Jani]
> 
> --v4
> -Add comment regarding need of this WA when in TMDS mode [Chaitanya] -
> Write in chicken register for MTL [CHaitanya]
> 
> --v5
> -Fix comment [Chaitanya]
> -Use correct set and clear value in intel_de_rmw [Chaitanya]
> 
> --v6
> -No need to define C, D chicken bits it gets calculated [Animesh]
> 
> Bspec: 49273
> Bspec: 69964

LGTM,
Reviewed-by: Chaitanya Kumar Borah 

> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 23 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  2 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index d5ed4c7dfbc0..02cbbbfd8e25 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -30,6 +30,27 @@
>  #define KEY_LOAD_TRIES   5
>  #define HDCP2_LC_RETRY_CNT   3
> 
> +/* WA: 16022217614 */
> +static void
> +intel_hdcp_disable_hdcp_line_rekeying(struct intel_encoder *encoder,
> +   struct intel_hdcp *hdcp)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + /* Here we assume HDMI is in TMDS mode of operation */
> + if (encoder->type != INTEL_OUTPUT_HDMI)
> + return;
> +
> + if (DISPLAY_VER(dev_priv) >= 14) {
> + if (IS_METEORLAKE(dev_priv))
> + intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(hdcp-
> >cpu_transcoder),
> +  0, HDCP_LINE_REKEY_DISABLE);
> + else
> + intel_de_rmw(dev_priv, TRANS_DDI_FUNC_CTL(hdcp-
> >cpu_transcoder),
> +  0,
> TRANS_DDI_HDCP_LINE_REKEY_DISABLE);
> + }
> +}
> +
>  static int intel_conn_to_vcpi(struct intel_atomic_state *state,
> struct intel_connector *connector)  { @@ -2005,6
> +2026,8 @@ static int _intel_hdcp2_enable(struct intel_atomic_state *state,
>   connector->base.base.id, connector->base.name,
>   hdcp->content_type);
> 
> + intel_hdcp_disable_hdcp_line_rekeying(connector->encoder, hdcp);
> +
>   ret = hdcp2_authenticate_and_encrypt(state, connector);
>   if (ret) {
>   drm_dbg_kms(&i915->drm, "HDCP2 Type%d  Enabling Failed.
> (%d)\n", diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index ae692f461982..9f2171f0adf8
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3520,6 +3520,7 @@
>  #define   DP_FEC_BS_JITTER_WAREG_BIT(15)
>  #define   PSR2_VSC_ENABLE_PROG_HEADERREG_BIT(12)
>  #define   DP_DSC_INSERT_SF_AT_EOL_WA REG_BIT(4)
> +#define   HDCP_LINE_REKEY_DISABLEREG_BIT(0)
> 
>  #define DISP_ARB_CTL _MMIO(0x45000)
>  #define   DISP_FBC_MEMORY_WAKE   REG_BIT(31)
> @@ -4521,6 +4522,7 @@ enum skl_power_gate {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5 << 12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6 << 12)
>  #define  TRANS_DDI_EDP_INPUT_D_ONOFF (7 << 12)
> +#define  TRANS_DDI_HDCP_LINE_REKEY_DISABLE   REG_BIT(12)
>  #define  TRANS_DDI_MST_TRANSPORT_SELECT_MASK REG_GENMASK(11,
> 10)
>  #define  TRANS_DDI_MST_TRANSPORT_SELECT(trans)   \
>   REG_FIELD_PREP(TRANS_DDI_MST_TRANSPORT_SELECT_MASK,
> trans)
> --
> 2.43.2

RE: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Thursday, May 2, 2024 10:11 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Shankar,
> Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj 
> Subject: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on
> HDMI
> 
> Disable HDCP Line Rekeying when HDCP ver > 1.4 and when we are on HDMI
> TMDS operation for DISPLAY_VER >= 14.
> 
> --v2
> -Wa to be mentioned in comments not in commit message [Jani] -Remove
> blankline [Jani]
> 
> --v3
> -No need to write what is being done in comments when code is self
> explanatory [Jani]
> 
> --v4
> -Add comment regarding need of this WA when in TMDS mode [Chaitanya] -
> Write in chicken register for MTL [CHaitanya]
> 
> --v5
> -Fix comment [Chaitanya]
> -Use correct set and clear value in intel_de_rmw [Chaitanya]
> 
> Bspec: 49273
> Bspec: 69964

LGTM

Reviewed-by: Chaitanya Kumar Borah 


> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 23 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  4 
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index d5ed4c7dfbc0..02cbbbfd8e25 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -30,6 +30,27 @@
>  #define KEY_LOAD_TRIES   5
>  #define HDCP2_LC_RETRY_CNT   3
> 
> +/* WA: 16022217614 */
> +static void
> +intel_hdcp_disable_hdcp_line_rekeying(struct intel_encoder *encoder,
> +   struct intel_hdcp *hdcp)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + /* Here we assume HDMI is in TMDS mode of operation */
> + if (encoder->type != INTEL_OUTPUT_HDMI)
> + return;
> +
> + if (DISPLAY_VER(dev_priv) >= 14) {
> + if (IS_METEORLAKE(dev_priv))
> + intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(hdcp-
> >cpu_transcoder),
> +  0, HDCP_LINE_REKEY_DISABLE);
> + else
> + intel_de_rmw(dev_priv, TRANS_DDI_FUNC_CTL(hdcp-
> >cpu_transcoder),
> +  0,
> TRANS_DDI_HDCP_LINE_REKEY_DISABLE);
> + }
> +}
> +
>  static int intel_conn_to_vcpi(struct intel_atomic_state *state,
> struct intel_connector *connector)  { @@ -2005,6
> +2026,8 @@ static int _intel_hdcp2_enable(struct intel_atomic_state *state,
>   connector->base.base.id, connector->base.name,
>   hdcp->content_type);
> 
> + intel_hdcp_disable_hdcp_line_rekeying(connector->encoder, hdcp);
> +
>   ret = hdcp2_authenticate_and_encrypt(state, connector);
>   if (ret) {
>   drm_dbg_kms(&i915->drm, "HDCP2 Type%d  Enabling Failed.
> (%d)\n", diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index e22a82a5ddd7..31338d825e34
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3501,6 +3501,8 @@
>   [TRANSCODER_D] =
> _CHICKEN_TRANS_D))
>  #define _MTL_CHICKEN_TRANS_A 0x604e0
>  #define _MTL_CHICKEN_TRANS_B 0x614e0
> +#define _MTL_CHICKEN_TRANS_C 0x624e0
> +#define _MTL_CHICKEN_TRANS_D 0x634e0
>  #define MTL_CHICKEN_TRANS(trans) _MMIO_TRANS((trans), \
>   _MTL_CHICKEN_TRANS_A,
> \
>   _MTL_CHICKEN_TRANS_B)
> @@ -3519,6 +3521,7 @@
>  #define   DP_FEC_BS_JITTER_WAREG_BIT(15)
>  #define   PSR2_VSC_ENABLE_PROG_HEADERREG_BIT(12)
>  #define   DP_DSC_INSERT_SF_AT_EOL_WA REG_BIT(4)
> +#define   HDCP_LINE_REKEY_DISABLEREG_BIT(0)
> 
>  #define DISP_ARB_CTL _MMIO(0x45000)
>  #define   DISP_FBC_MEMORY_WAKE   REG_BIT(31)
> @@ -4520,6 +4523,7 @@ enum skl_power_gate {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5 << 12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6 << 12)
>  #define  TRANS_DDI_EDP_INPUT_D_ONOFF (7 << 12)
> +#define  TRANS_DDI_HDCP_LINE_REKEY_DISABLE   REG_BIT(12)
>  #define  TRANS_DDI_MST_TRANSPORT_SELECT_MASK REG_GENMASK(11,
> 10)
>  #define  TRANS_DDI_MST_TRANSPORT_SELECT(trans)   \
>   REG_FIELD_PREP(TRANS_DDI_MST_TRANSPORT_SELECT_MASK,
> trans)
> --
> 2.43.2

RE: [PATCH] drm/i915/audio: Fix audio time stamp programming for DP

[Borah, Chaitanya Kumar]

Hello all,

Please ignore this version. I accidentally sent a version I was experimenting 
with. I will correct it in the next revision.
Sorry for the spam.


> -Original Message-
> From: Intel-gfx  On Behalf Of
> Chaitanya Kumar Borah
> Sent: Tuesday, April 30, 2024 2:04 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vehmanen, Kai ; Saarinen, Jani
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com; Yang, Libin ; Shankar, Uma
> 
> Subject: [PATCH] drm/i915/audio: Fix audio time stamp programming for DP
> 
> Intel hardware is capable of programming the Maud/Naud SDPs on its own
> based on real-time clocks. While doing so, it takes care of any deviations 
> from
> the theoretical values. Programming the registers explicitly with static 
> values
> can interfere with this logic. Therefore, let the HW decide the Maud and Naud
> SDPs on it's own.
> 
> Cc: sta...@vger.kernel.org # v5.17
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097
> Co-developed-by: Kai Vehmanen 
> Signed-off-by: Kai Vehmanen 
> Signed-off-by: Chaitanya Kumar Borah 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 111 ++---
>  1 file changed, 6 insertions(+), 105 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 07e0c73204f3..12e2ba462077 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -76,19 +76,6 @@ struct intel_audio_funcs {
>  struct intel_crtc_state *crtc_state);  };
> 
> -/* DP N/M table */
> -#define LC_810M  81
> -#define LC_540M  54
> -#define LC_270M  27
> -#define LC_162M  162000
> -
> -struct dp_aud_n_m {
> - int sample_rate;
> - int clock;
> - u16 m;
> - u16 n;
> -};
> -
>  struct hdmi_aud_ncts {
>   int sample_rate;
>   int clock;
> @@ -96,60 +83,6 @@ struct hdmi_aud_ncts {
>   int cts;
>  };
> 
> -/* Values according to DP 1.4 Table 2-104 */ -static const struct dp_aud_n_m
> dp_aud_n_m[] = {
> - { 32000, LC_162M, 1024, 10125 },
> - { 44100, LC_162M, 784, 5625 },
> - { 48000, LC_162M, 512, 3375 },
> - { 64000, LC_162M, 2048, 10125 },
> - { 88200, LC_162M, 1568, 5625 },
> - { 96000, LC_162M, 1024, 3375 },
> - { 128000, LC_162M, 4096, 10125 },
> - { 176400, LC_162M, 3136, 5625 },
> - { 192000, LC_162M, 2048, 3375 },
> - { 32000, LC_270M, 1024, 16875 },
> - { 44100, LC_270M, 784, 9375 },
> - { 48000, LC_270M, 512, 5625 },
> - { 64000, LC_270M, 2048, 16875 },
> - { 88200, LC_270M, 1568, 9375 },
> - { 96000, LC_270M, 1024, 5625 },
> - { 128000, LC_270M, 4096, 16875 },
> - { 176400, LC_270M, 3136, 9375 },
> - { 192000, LC_270M, 2048, 5625 },
> - { 32000, LC_540M, 1024, 33750 },
> - { 44100, LC_540M, 784, 18750 },
> - { 48000, LC_540M, 512, 11250 },
> - { 64000, LC_540M, 2048, 33750 },
> - { 88200, LC_540M, 1568, 18750 },
> - { 96000, LC_540M, 1024, 11250 },
> - { 128000, LC_540M, 4096, 33750 },
> - { 176400, LC_540M, 3136, 18750 },
> - { 192000, LC_540M, 2048, 11250 },
> - { 32000, LC_810M, 1024, 50625 },
> - { 44100, LC_810M, 784, 28125 },
> - { 48000, LC_810M, 512, 16875 },
> - { 64000, LC_810M, 2048, 50625 },
> - { 88200, LC_810M, 1568, 28125 },
> - { 96000, LC_810M, 1024, 16875 },
> - { 128000, LC_810M, 4096, 50625 },
> - { 176400, LC_810M, 3136, 28125 },
> - { 192000, LC_810M, 2048, 16875 },
> -};
> -
> -static const struct dp_aud_n_m *
> -audio_config_dp_get_n_m(const struct intel_crtc_state *crtc_state, int rate) 
> -
> {
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(dp_aud_n_m); i++) {
> - if (rate == dp_aud_n_m[i].sample_rate &&
> - crtc_state->port_clock == dp_aud_n_m[i].clock)
> - return &dp_aud_n_m[i];
> - }
> -
> - return NULL;
> -}
> -
>  static const struct {
>   int clock;
>   u32 config;
> @@ -387,47 +320,15 @@ hsw_dp_audio_config_update(struct
> intel_encoder *encoder,
>  const struct intel_crtc_state *crtc_state)  {
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> - struct i915_audio_component *acomp = i915-
> >display.audio.component;
>   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - enum port port = encoder->port;
> - const struct dp_aud_n_m *nm;
> - int rate;
> - u32 tmp;
> 
> - rate = acomp ? acomp->aud_sample_rate[port] : 0;
> - nm = audio_config_dp_get_n_m(crtc_state, rate);
> - if (nm)
> - drm_dbg_kms(&i915->drm, "using Maud %u, Naud %u\n",
> nm->m,
> - nm->n);
> - else
> - drm_dbg_kms(&i915->drm, "using automatic Maud,
> Naud\n");
> -
> - tmp = intel_de_read(i915, HSW_AUD_CFG(cpu_transcoder));
> - tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> - tmp &= ~A

RE: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI

[Borah, Chaitanya Kumar]

Hi Suraj,

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, April 24, 2024 10:42 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj 
> Subject: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on
> HDMI
> 
> Disable HDCP Line Rekeying when HDCP ver > 1.4 and when we are on HDMI
> TMDS operation for DISPLAY_VER >= 14.
> 
> --v2
> -Wa to be mentioned in comments not in commit message [Jani] -Remove
> blankline [Jani]
> 
> --v3
> -No need to write what is being done in comments when code is self
> explanatory [Jani]
> 
> --v4
> -Add comment regarding need of this WA when in TMDS mode [Chaitanya] -
> Write in chicken register for MTL [CHaitanya]
> 
> Bspec: 49273
> Bspec: 69964
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  4 
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index d5ed4c7dfbc0..0d8ae6962d34 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -30,6 +30,30 @@
>  #define KEY_LOAD_TRIES   5
>  #define HDCP2_LC_RETRY_CNT   3
> 
> +/*
> + * WA: 16022217614
> + * Disable HDCP line rekeying if we are using HDMI and in
> + * TMDS mode.
> + */

Thank you for the change. My idea was more to document the fact that here we 
assume that HDMI is in TDMS mode (which is currently true but might change 
later)
and not the WA itself. More on that below.

> +static void
> +intel_hdcp_disable_hdcp_line_rekeying(struct intel_encoder *encoder,
> +   struct intel_hdcp *hdcp)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +

Something on the lines of

/* Here we assume that HDMI is in TMDS mode */

But you are welcome to come up with something better.

Also, s/dev_priv/i915/

> + if (encoder->type != INTEL_OUTPUT_HDMI)
> + return;
> +
> + if (DISPLAY_VER(dev_priv) >= 14) {
> + if (IS_METEORLAKE(dev_priv))
> + intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(hdcp-
> >cpu_transcoder),
> +  HDCP_LINE_REKEY_DISABLE, 1);

Since we are only setting the HDCP_LINE_REKEY_DISABLE bit (and clearing 
nothing) the correct use of the function would be

intel_de_rmw(dev_priv, 
MTL_CHICKEN_TRANS(hdcp->cpu_transcoder), 0, HDCP_LINE_REKEY_DISABLE);

> + else
> + intel_de_rmw(dev_priv, TRANS_DDI_FUNC_CTL(hdcp-
> >cpu_transcoder),
> +  TRANS_DDI_HDCP_LINE_REKEY_DISABLE,
> 1);

Same here.

> + }
> +}
> +
>  static int intel_conn_to_vcpi(struct intel_atomic_state *state,
> struct intel_connector *connector)  { @@ -2005,6
> +2029,8 @@ static int _intel_hdcp2_enable(struct intel_atomic_state *state,
>   connector->base.base.id, connector->base.name,
>   hdcp->content_type);
> 
> + intel_hdcp_disable_hdcp_line_rekeying(connector->encoder, hdcp);
> +
>   ret = hdcp2_authenticate_and_encrypt(state, connector);
>   if (ret) {
>   drm_dbg_kms(&i915->drm, "HDCP2 Type%d  Enabling Failed.
> (%d)\n", diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 3f34efcd7d6c..39b1a2d516fe
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4613,6 +4613,8 @@
>   [TRANSCODER_D] =
> _CHICKEN_TRANS_D))
>  #define _MTL_CHICKEN_TRANS_A 0x604e0
>  #define _MTL_CHICKEN_TRANS_B 0x614e0
> +#define _MTL_CHICKEN_TRANS_C 0x624e0
> +#define _MTL_CHICKEN_TRANS_D 0x634e0

These look good.

Regards

Chaitanya

>  #define MTL_CHICKEN_TRANS(trans) _MMIO_TRANS((trans), \
>   _MTL_CHICKEN_TRANS_A,
> \
>   _MTL_CHICKEN_TRANS_B)
> @@ -4631,6 +4633,7 @@
>  #define   DP_FEC_BS_JITTER_WAREG_BIT(15)
>  #define   PSR2_VSC_ENABLE_PROG_HEADERREG_BIT(12)
>  #define   DP_DSC_INSERT_SF_AT_EOL_WA REG_BIT(4)
> +#define   HDCP_LINE_REKEY_DISABLEREG_BIT(0)
> 
>  #define DISP_ARB_CTL _MMIO(0x45000)
>  #define   DISP_FBC_MEMORY_WAKE   REG_BIT(31)
> @@ -5630,6 +5633,7 @@ enum skl_power_gate {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5 << 12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6 << 12)
>  #define  TRANS_DDI_EDP_INPUT_D_ONOFF (7 << 12)
> +#define  TRANS_DDI_HDCP_LINE_REKEY_DISABLE   REG_BIT(12)
>  #define  TRANS_DDI_MST_TRANSPORT_SELECT_MASK REG_GENMASK(11,
> 10)
>  #define  TRANS_DDI_MST_TRANSPORT_SELECT(trans)   \
>   REG_FIELD_PREP(TRANS_DDI_MST_TRANSPORT_SELECT_MASK,
> trans)
> --
> 2.43.2

RE: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI

[Borah, Chaitanya Kumar]

Hello Suraj,

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, April 17, 2024 3:26 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Shankar,
> Uma ; Nautiyal, Ankit K
> ; Nikula, Jani ; Kandpal,
> Suraj 
> Subject: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on
> HDMI
> 
> Disable HDCP Line Rekeying when HDCP ver > 1.4 and when we are on HDMI
> TMDS operation for DISPLAY_VER >= 14.
> 
> --v2
> -Wa to be mentioned in comments not in commit message [Jani] -Remove
> blankline [Jani]
> 
> --v3
> -No need to write what is being done in comments when code is self
> explanatory [Jani]
> 
> Bspec: 49273
> Bspec: 69964
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 17 +
>  drivers/gpu/drm/i915/i915_reg.h   |  1 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index d5ed4c7dfbc0..78b20f23a2e1 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -30,6 +30,21 @@
>  #define KEY_LOAD_TRIES   5
>  #define HDCP2_LC_RETRY_CNT   3
> 
> +/* WA: 16022217614 */
> +static void
> +intel_hdcp_disable_hdcp_line_rekeying(struct intel_encoder *encoder,
> +   struct intel_hdcp *hdcp)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + if (encoder->type != INTEL_OUTPUT_HDMI)
> + return;

(Nit) Though we can't do much here for non-TMDS HDMI, we can keep a comment so 
that if such support is added in future, there is a hint to make the change.

> +
> + if (DISPLAY_VER(dev_priv) >= 14)
> + intel_de_rmw(dev_priv, TRANS_DDI_FUNC_CTL(hdcp-
> >cpu_transcoder),

This register seems to differ for MTL and BMG. Kindly re-check.

Regards

Chaitanya

> +  TRANS_DDI_HDCP_LINE_REKEY_DISABLE, 1); }
> +
>  static int intel_conn_to_vcpi(struct intel_atomic_state *state,
> struct intel_connector *connector)  { @@ -2005,6
> +2020,8 @@ static int _intel_hdcp2_enable(struct intel_atomic_state *state,
>   connector->base.base.id, connector->base.name,
>   hdcp->content_type);
> 
> + intel_hdcp_disable_hdcp_line_rekeying(connector->encoder, hdcp);
> +

>   ret = hdcp2_authenticate_and_encrypt(state, connector);
>   if (ret) {
>   drm_dbg_kms(&i915->drm, "HDCP2 Type%d  Enabling Failed.
> (%d)\n", diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 3f34efcd7d6c..fbf4623cd536 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5630,6 +5630,7 @@ enum skl_power_gate {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5 << 12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6 << 12)
>  #define  TRANS_DDI_EDP_INPUT_D_ONOFF (7 << 12)
> +#define  TRANS_DDI_HDCP_LINE_REKEY_DISABLE   REG_BIT(12)
>  #define  TRANS_DDI_MST_TRANSPORT_SELECT_MASK REG_GENMASK(11,
> 10)
>  #define  TRANS_DDI_MST_TRANSPORT_SELECT(trans)   \
>   REG_FIELD_PREP(TRANS_DDI_MST_TRANSPORT_SELECT_MASK,
> trans)
> --
> 2.43.2

RE: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability function

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Monday, April 1, 2024 11:27 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj 
> Subject: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability function
> 
> HDCP 1.x capability needs to be checked even if setup is not HDCP 2.x capable.
> 
> --v2
> -Assign hdcp_capable and hdcp2_capable to false [Chaitanya]
> 
> --v3
> -Fix variable assignment [Chaitanya]
> 
> Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check shim
> function")
> Signed-off-by: Suraj Kandpal 

LGTM

Reviewed-by: Chaitanya Kumar Borah 


> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 179e754e5c30..92b03073acdd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -691,12 +691,15 @@ int intel_dp_hdcp_get_remote_capability(struct
> intel_connector *connector,
>   u8 bcaps;
>   int ret;
> 
> + *hdcp_capable = false;
> + *hdcp2_capable = false;
>   if (!intel_encoder_is_mst(connector->encoder))
>   return -EINVAL;
> 
>   ret =  _intel_dp_hdcp2_get_capability(aux, hdcp2_capable);
>   if (ret)
> - return ret;
> + drm_dbg_kms(&i915->drm,
> + "HDCP2 DPCD capability read failed err: %d\n", ret);
> 
>   ret = intel_dp_hdcp_read_bcaps(aux, i915, &bcaps);
>   if (ret)
> --
> 2.43.2

RE: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability function

[Borah, Chaitanya Kumar]

Hello Suraj,

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Monday, April 1, 2024 8:31 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj 
> Subject: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability function
> 
> HDCP 1.x capability needs to be checked even if setup is not HDCP 2.x capable.
> 
> --v2
> -Assign hdcp_capable and hdcp2_capable to false [Chaitanya]
> 
> Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check shim
> function")
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 179e754e5c30..bd2cd7417136 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -694,9 +694,12 @@ int intel_dp_hdcp_get_remote_capability(struct
> intel_connector *connector,
>   if (!intel_encoder_is_mst(connector->encoder))
>   return -EINVAL;
> 
> + hdcp_capable = false;
> + hdcp2_capable = false;

Here pointers are being overwritten.
Anywhere we try to write to them will lead to crash.

You can also move them above the EINVAL check for the sake of readability. 
Anyway the caller of this function should not rely on the values if there is 
error code returned.
(even though no one is doing that right now)

Regards

Chaitanya


>   ret =  _intel_dp_hdcp2_get_capability(aux, hdcp2_capable);
>   if (ret)
> - return ret;
> + drm_dbg_kms(&i915->drm,
> + "HDCP2 DPCD capability read failed err: %d\n", ret);
> 
>   ret = intel_dp_hdcp_read_bcaps(aux, i915, &bcaps);
>   if (ret)
> --
> 2.43.2

RE: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability function

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Thursday, March 28, 2024 3:56 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability
> function
> 
> Hello,
> 
> > -Original Message-
> > From: Kandpal, Suraj 
> > Sent: Wednesday, March 27, 2024 10:14 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Borah, Chaitanya Kumar ; Kandpal,
> > Suraj 
> > Subject: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability
> > function
> >
> > HDCP 1.x capability needs to be checked even if setup is not HDCP 2.x
> capable.
> >
> > Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check
> > shim
> > function")
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 9 -
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index b98a87883fef..7f52043b0f9f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -688,7 +688,7 @@ int intel_dp_hdcp_get_remote_capability(struct
> > intel_connector *connector,  {
> > struct drm_i915_private *i915 = to_i915(connector->base.dev);
> > struct drm_dp_aux *aux = &connector->port->aux;
> > -   u8 bcaps;
> > +   u8 bcaps = 0;
> > int ret;
> >
> > if (!intel_encoder_is_mst(connector->encoder))
> > @@ -696,15 +696,14 @@ int intel_dp_hdcp_get_remote_capability(struct
> > intel_connector *connector,
> >
> > ret =  _intel_dp_hdcp2_get_capability(aux, hdcp2_capable);
> > if (ret)
> > -   return ret;
> > +   drm_dbg_kms(&i915->drm,
> > +   "HDCP2 DPCD capability read failed err: %d\n", ret);
> >
> > ret = intel_dp_hdcp_read_bcaps(aux, i915, &bcaps);
> > -   if (ret)
> > -   return ret;
> >
> > *hdcp_capable = bcaps & DP_BCAPS_HDCP_CAPABLE;
> >
> 
> Let's keep the behavior same for both hdcp_capable and hdcp2_capable in
> case of failure.
> 
> Either assign both of them as false, or not assign anything.
> 

IMO, assigning them false could be a better approach if you don't see any harm 
in it. It is not great to be dependent on the semantics of them being 
initialized first.

> Regards
> 
> Chaitanya
> 
> 
> 
> > -   return 0;
> > +   return ret;
> >  }
> >
> >  static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
> > --
> > 2.43.2

RE: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability function

[Borah, Chaitanya Kumar]

Hello,

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, March 27, 2024 10:14 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj 
> Subject: [PATCH 2/2] drm/i915/hdcp: Fix get remote hdcp capability function
> 
> HDCP 1.x capability needs to be checked even if setup is not HDCP 2.x capable.
> 
> Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check shim
> function")
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index b98a87883fef..7f52043b0f9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -688,7 +688,7 @@ int intel_dp_hdcp_get_remote_capability(struct
> intel_connector *connector,  {
>   struct drm_i915_private *i915 = to_i915(connector->base.dev);
>   struct drm_dp_aux *aux = &connector->port->aux;
> - u8 bcaps;
> + u8 bcaps = 0;
>   int ret;
> 
>   if (!intel_encoder_is_mst(connector->encoder))
> @@ -696,15 +696,14 @@ int intel_dp_hdcp_get_remote_capability(struct
> intel_connector *connector,
> 
>   ret =  _intel_dp_hdcp2_get_capability(aux, hdcp2_capable);
>   if (ret)
> - return ret;
> + drm_dbg_kms(&i915->drm,
> + "HDCP2 DPCD capability read failed err: %d\n", ret);
> 
>   ret = intel_dp_hdcp_read_bcaps(aux, i915, &bcaps);
> - if (ret)
> - return ret;
> 
>   *hdcp_capable = bcaps & DP_BCAPS_HDCP_CAPABLE;
> 

Let's keep the behavior same for both hdcp_capable and hdcp2_capable in case of 
failure.

Either assign both of them as false, or not assign anything.

Regards

Chaitanya



> - return 0;
> + return ret;
>  }
> 
>  static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
> --
> 2.43.2

RE: [PATCH 1/2] drm/i915/display: Initialize capability variables

[Borah, Chaitanya Kumar]

Hello

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, March 27, 2024 10:14 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj 
> Subject: [PATCH 1/2] drm/i915/display: Initialize capability variables
> 
> Initialize HDCP capability variables to false to avoid UBSAN warning in
> boolean value.
> 

Nit: I would add the fact that we need this change because the functions 
filling up these Booleans may return without actually assigning values to them.

Otherwise, LGTM.

Reviewed-by: Chaitanya Kumar Borah 


> --v2
> -Fix Typo [Chaitanya]
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index b99c024b0934..95d14dab089e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -191,7 +191,7 @@ static void intel_hdcp_info(struct seq_file *m,
>   struct intel_connector *intel_connector,
>   bool remote_req)
>  {
> - bool hdcp_cap, hdcp2_cap;
> + bool hdcp_cap = false, hdcp2_cap = false;
> 
>   if (!intel_connector->hdcp.shim) {
>   seq_puts(m, "No Connector Support");
> --
> 2.43.2

RE: [PATCH] drm/i915/display: Initalizalize capability variables

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, March 27, 2024 9:06 AM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH] drm/i915/display: Initalizalize capability variables
> 
> > Hello Suraj,
> >
> > > -Original Message-
> > > From: Kandpal, Suraj 
> > > Sent: Tuesday, March 26, 2024 10:45 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Borah, Chaitanya Kumar ;
> > > Kandpal, Suraj 
> > > Subject: [PATCH] drm/i915/display: Initalizalize capability
> > > variables
> >
> > Typo: Initialize
> >
> 
> Sure will fix
> 
> > > Initialize HDCP capability variables to false to avoid UBSAN warning
> > > in boolean value.
> > >
> >
> > I can see a case where hdcp_cap remains unassigned in case
> > intel_dp_hdcp_get_remote_capability() returns without assigning it a value.
> >
> > Is that intended/expected?
> >
> 
> That is not intentional but this patch makes sure hdcp_capable will be false
> when this function gets called.
> 

This patch makes sense for sure but what I am getting at is if UBSAN is 
revealing a bug in our code.

intel_dp_hdcp_get_remote_capability() returns if 
_intel_dp_hdcp2_get_capability() fails. In that case we never check for hdcp 
1.4 capability.
If a remote sink can be hdcp 1.4 capable but not hdcp 2 capable, this logic is 
problematic.

Regards

Chaitanya

> Regards,
> Suraj Kandpal
> 
> > Regards
> >
> > Chaitanya
> >
> > > Signed-off-by: Suraj Kandpal 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index b99c024b0934..95d14dab089e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -191,7 +191,7 @@ static void intel_hdcp_info(struct seq_file *m,
> > >   struct intel_connector *intel_connector,
> > >   bool remote_req)
> > >  {
> > > - bool hdcp_cap, hdcp2_cap;
> > > + bool hdcp_cap = false, hdcp2_cap = false;
> > >
> > >   if (!intel_connector->hdcp.shim) {
> > >   seq_puts(m, "No Connector Support");
> > > --
> > > 2.43.2

RE: [PATCH] drm/i915/display: Initalizalize capability variables

[Borah, Chaitanya Kumar]

Hello Suraj,

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Tuesday, March 26, 2024 10:45 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj 
> Subject: [PATCH] drm/i915/display: Initalizalize capability variables

Typo: Initialize 

> Initialize HDCP capability variables to false to avoid UBSAN warning in
> boolean value.
> 

I can see a case where hdcp_cap remains unassigned in case 
intel_dp_hdcp_get_remote_capability() returns without assigning it a value.

Is that intended/expected?

Regards

Chaitanya

> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index b99c024b0934..95d14dab089e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -191,7 +191,7 @@ static void intel_hdcp_info(struct seq_file *m,
>   struct intel_connector *intel_connector,
>   bool remote_req)
>  {
> - bool hdcp_cap, hdcp2_cap;
> + bool hdcp_cap = false, hdcp2_cap = false;
> 
>   if (!intel_connector->hdcp.shim) {
>   seq_puts(m, "No Connector Support");
> --
> 2.43.2

RE: [PATCH] drm/i915: Pre-populate the cursor physical dma address

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Monday, March 25, 2024 11:28 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Borislav Petkov 
> Subject: [PATCH] drm/i915: Pre-populate the cursor physical dma address
> 
> From: Ville Syrjälä 
> 
> Calling i915_gem_object_get_dma_address() from the vblank evade critical
> section triggers might_sleep().
> 
> While we know that we've already pinned the framebuffer and thus
> i915_gem_object_get_dma_address() will in fact not sleep in this case, it
> seems reasonable to keep the unconditional might_sleep() for maximum
> coverage.
> 
> So let's instead pre-populate the dma address during fb pinning, which all
> happens before we enter the vblank evade critical section.
> 
> We can use u32 for the dma address as this class of hardware doesn't
> support >32bit addresses.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 0225a90981c8 ("drm/i915: Make cursor plane registers unlocked")
> Link: https://lore.kernel.org/intel-
> gfx/20240227100342.GAZd2zfmYcPS_SndtO@fat_crate.local/

Nit. This could be changed to Closes and moved after Reported-by to keep 
checkpatch happy but otherwise, LGTM.

Reviewed-by: Chaitanya Kumar Borah 

> Reported-by: Borislav Petkov 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c|  4 +---
>  drivers/gpu/drm/i915/display/intel_display_types.h |  1 +
>  drivers/gpu/drm/i915/display/intel_fb_pin.c| 10 ++
>  3 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index f8b33999d43f..0d3da55e1c24 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -36,12 +36,10 @@ static u32 intel_cursor_base(const struct
> intel_plane_state *plane_state)  {
>   struct drm_i915_private *dev_priv =
>   to_i915(plane_state->uapi.plane->dev);
> - const struct drm_framebuffer *fb = plane_state->hw.fb;
> - struct drm_i915_gem_object *obj = intel_fb_obj(fb);
>   u32 base;
> 
>   if (DISPLAY_INFO(dev_priv)->cursor_needs_physical)
> - base = i915_gem_object_get_dma_address(obj, 0);
> + base = plane_state->phys_dma_addr;
>   else
>   base = intel_plane_ggtt_offset(plane_state);
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 8a35fb6b2ade..68f26a33870b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -728,6 +728,7 @@ struct intel_plane_state {  #define PLANE_HAS_FENCE
> BIT(0)
> 
>   struct intel_fb_view view;
> + u32 phys_dma_addr; /* for cursor_needs_physical */
> 
>   /* Plane pxp decryption state */
>   bool decrypt;
> diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> index 7b42aef37d2f..b6df9baf481b 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> @@ -255,6 +255,16 @@ int intel_plane_pin_fb(struct intel_plane_state
> *plane_state)
>   return PTR_ERR(vma);
> 
>   plane_state->ggtt_vma = vma;
> +
> + /*
> +  * Pre-populate the dma address before we enter the vblank
> +  * evade critical section as
> i915_gem_object_get_dma_address()
> +  * will trigger might_sleep() even if it won't actually sleep,
> +  * which is the case when the fb has already been pinned.
> +  */
> + if (phys_cursor)
> + plane_state->phys_dma_addr =
> +
>   i915_gem_object_get_dma_address(intel_fb_obj(fb), 0);
>   } else {
>   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> 
> --
> 2.43.2

RE: [PATCH] drm/i915/dp: Enable AUX based backlight for HDR

[Borah, Chaitanya Kumar]

Hello Suraj,

> -Original Message-
> From: Intel-gfx  On Behalf Of Suraj
> Kandpal
> Sent: Thursday, March 7, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj 
> Subject: [PATCH] drm/i915/dp: Enable AUX based backlight for HDR
> 
> As of now whenerver HDR is switched on we use the PWM to change the
> backlight as opposed to AUX based backlight changes in terms of nits.
> This patch writes to the appropriate DPCD registers to enable aux based
> backlight using values in nits.
> 
> --v2
> -Fix max_cll and max_fall assignment [Jani] -Fix the size sent in
> drm_dpcd_write [Jani]
> 
> --v3
> -Content Luminance needs to be sent only for pre-ICL after that it is directly
> picked up from hdr metadata [Ville]
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  .../drm/i915/display/intel_dp_aux_backlight.c | 33 ++-
>  1 file changed, 25 insertions(+), 8 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 4f58efdc688a..cba7b8f5dad4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -40,11 +40,6 @@
>  #include "intel_dp.h"
>  #include "intel_dp_aux_backlight.h"
> 
> -/* TODO:
> - * Implement HDR, right now we just implement the bare minimum to bring
> us back into SDR mode so we
> - * can make people's backlights work in the mean time
> - */
> -
>  /*
>   * DP AUX registers for Intel's proprietary HDR backlight interface. We 
> define
>   * them here since we'll likely be the only driver to ever use these.
> @@ -221,7 +216,7 @@ intel_dp_aux_hdr_set_backlight(const struct
> drm_connector_state *conn_state, u32
>   struct intel_connector *connector = to_intel_connector(conn_state-
> >connector);
>   struct intel_panel *panel = &connector->panel;
> 
> - if (panel->backlight.edp.intel.sdr_uses_aux) {
> + if (panel->backlight.edp.intel.sdr_uses_aux ||
> +conn_state->hdr_output_metadata) {
>   intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
>   } else {
>   const u32 pwm_level =
> intel_backlight_level_to_pwm(connector, level); @@ -251,8 +246,15 @@
> intel_dp_aux_hdr_enable_backlight(const struct intel_crtc_state *crtc_state,
>   }
> 
>   ctrl = old_ctrl;
> - if (panel->backlight.edp.intel.sdr_uses_aux) {
> + if (panel->backlight.edp.intel.sdr_uses_aux ||
> +conn_state->hdr_output_metadata) {
>   ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE;
> +
> + if (conn_state->hdr_output_metadata) {
> + ctrl |=
> INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_ENABLE;
> + ctrl |=
> INTEL_EDP_HDR_TCON_2084_DECODE_ENABLE;
> + ctrl |=
> INTEL_EDP_HDR_TCON_2020_GAMUT_ENABLE;
> + }
> +
>   intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
>   } else {
>   u32 pwm_level = intel_backlight_level_to_pwm(connector,
> level); @@ -292,9 +294,11 @@ intel_dp_aux_hdr_setup_backlight(struct
> intel_connector *connector, enum pipe pi  {
>   struct drm_i915_private *i915 = to_i915(connector->base.dev);
>   struct intel_panel *panel = &connector->panel;
> + struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
>   struct drm_luminance_range_info *luminance_range =
>   &connector->base.display_info.luminance_range;
>   int ret;
> + u8 buf[4];
> 
>   drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s] SDR backlight is
> controlled through %s\n",
>   connector->base.base.id, connector->base.name, @@ -
> 318,11 +322,24 @@ intel_dp_aux_hdr_setup_backlight(struct intel_connector
> *connector, enum pipe pi
>   panel->backlight.min = 0;
>   }
> 
> + if (DISPLAY_VER(i915) < 11) {
> + buf[0] = connector-
> >base.hdr_sink_metadata.hdmi_type1.max_cll & 0xFF;
> + buf[1] = (connector-
> >base.hdr_sink_metadata.hdmi_type1.max_cll & 0xFF00) >> 8;
> + buf[2] = connector-
> >base.hdr_sink_metadata.hdmi_type1.max_fall & 0xFF;
> + buf[3] = (connector-
> >base.hdr_sink_metadata.hdmi_type1.max_fall &
> +0xFF00) >> 8;
> +
> + ret = drm_dp_dpcd_write(&intel_dp->aux,
> INTEL_EDP_HDR_CONTENT_LUMINANCE, buf,
> + sizeof(buf));
> + if (ret < 0)
> + drm_dbg_kms(&i915->drm,
> + "Content Luminance DPCD reg write failed,
> err:-%d\n",

Any reason for printing this in negative?

Regards
Chaitanya

> + ret);
> + }
> +
>   drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s] Using AUX HDR
> interface for backlight control (range %d..%d)\n",
>   connector->base.base.id, connector->base.name,
>   panel->backlight.min, panel->backlight.max);
> 
> -
> 

RE: Regression on linux-next (next-20240228)

[Borah, Chaitanya Kumar]

Hello Mathew,

> -Original Message-
> From: Matthew Wilcox 
> Sent: Tuesday, March 5, 2024 11:19 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: Re: Regression on linux-next (next-20240228)
> 
> On Tue, Mar 05, 2024 at 06:49:16AM +0000, Borah, Chaitanya Kumar wrote:
> > Issue is still seen with the following changes
> >
> > void put_pages_list(struct list_head *pages)
> >
> > folio_batch_init(&fbatch);
> > list_for_each_entry(folio, pages, lru) {
> > -   if (!folio_put_testzero(folio))
> > +   if (!folio_put_testzero(folio)) {
> > +   list_del(&folio->lru);
> > continue;
> > +   }
> > if (folio_test_large(folio)) {
> > __folio_put_large(folio);
> > +   list_del(&folio->lru);
> > continue;
> > }
> 
> Thanks for testing.  Sorry about this.  I think I figured out what the problem
> actually is.  I switched from list_for_each_entry_safe() to 
> list_for_each_entry()
> since I was no longer deleting the entries from the list.  Unfortunately, I 
> was
> still freeing the entries as I walked the list!  So it would dereference 
> folio-
> >lru.next after giving folio back to the page allocator (which probably put 
> >it on
> the PCP list, where it would point to another free folio?)
> 
> Anyway, this should do the job, without the change I asked you to test above.
> If this doesn't do the job by itself, you could try combining the two changes,
> but I don't think that will be necessary.
> 
> diff --git a/mm/swap.c b/mm/swap.c
> index a910af21ba68..1d4b7713605d 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -139,10 +139,10 @@ EXPORT_SYMBOL(__folio_put);  void
> put_pages_list(struct list_head *pages)  {
>   struct folio_batch fbatch;
> - struct folio *folio;
> + struct folio *folio, *next;
> 
>   folio_batch_init(&fbatch);
> - list_for_each_entry(folio, pages, lru) {
> + list_for_each_entry_safe(folio, next, pages, lru) {
>   if (!folio_put_testzero(folio))
>   continue;
>   if (folio_test_hugetlb(folio)) {

The following change works for us.

void put_pages_list(struct list_head *pages)
{
struct folio_batch fbatch;
-   struct folio *folio;
+   struct folio *folio, *next;
 
folio_batch_init(&fbatch);
-   list_for_each_entry(folio, pages, lru) {
+   list_for_each_entry_safe(folio, next, pages, lru) {
if (!folio_put_testzero(folio))
continue;
if (folio_test_large(folio)) {

Thank you for the resolution. When can we expect a patch?

Regards

Chaitanya

RE: Regression on linux-next (next-20240228)

[Borah, Chaitanya Kumar]

Hello Mathew,

> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Monday, March 4, 2024 8:18 PM
> To: Matthew Wilcox 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: RE: Regression on linux-next (next-20240228)
> 
> Hello Mathew,
> 
> > -Original Message-
> > From: Matthew Wilcox 
> > Sent: Monday, March 4, 2024 6:52 PM
> > To: Borah, Chaitanya Kumar 
> > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > ; Saarinen, Jani
> > 
> > Subject: Re: Regression on linux-next (next-20240228)
> >
> > On Mon, Mar 04, 2024 at 10:03:13AM +, Borah, Chaitanya Kumar
> > wrote:
> > > > Could you try putting the two:
> > > >
> > > > -   list_del(&folio->lru);
> > > >
> > > > statements back in and see if that fixes it?
> > >
> > > That seems to fix it.
> > >
> > > if (!folio_put_testzero(folio))
> > > +   list_del(&folio->lru);
> > > continue;
> >
> > Ummm ... did you put { and } around this?  Otherwise the indentation
> > is misleading and what you're actually done is:
> >
> > if (!folio_put_testzero(folio))
> > list_del(&folio->lru);
> > continue;
> >
> > which will simply leak memory.
> >
> 
> Oops look like a miss on our side. Let us re-do this and get back to you.
> 

Issue is still seen with the following changes

void put_pages_list(struct list_head *pages)
 
folio_batch_init(&fbatch);
list_for_each_entry(folio, pages, lru) {
-   if (!folio_put_testzero(folio))
+   if (!folio_put_testzero(folio)) {
+   list_del(&folio->lru);
continue;
+   }
if (folio_test_large(folio)) {
__folio_put_large(folio);
+   list_del(&folio->lru);
continue;
}

Regards

Chaitanya

> Regards
> 
> Chaitanya
> 
> > > if (folio_test_large(folio)) {
> > > __folio_put_large(folio);
> > > +   list_del(&folio->lru);
> > > continue;
> > > }
> > > Regards
> > >
> > > Chaitanya

RE: Regression on linux-next (next-20240228)

[Borah, Chaitanya Kumar]

Hello Mathew,

> -Original Message-
> From: Matthew Wilcox 
> Sent: Monday, March 4, 2024 6:52 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: Re: Regression on linux-next (next-20240228)
> 
> On Mon, Mar 04, 2024 at 10:03:13AM +0000, Borah, Chaitanya Kumar
> wrote:
> > > Could you try putting the two:
> > >
> > > -   list_del(&folio->lru);
> > >
> > > statements back in and see if that fixes it?
> >
> > That seems to fix it.
> >
> > if (!folio_put_testzero(folio))
> > +   list_del(&folio->lru);
> > continue;
> 
> Ummm ... did you put { and } around this?  Otherwise the indentation is
> misleading and what you're actually done is:
> 
>   if (!folio_put_testzero(folio))
>   list_del(&folio->lru);
>   continue;
> 
> which will simply leak memory.
> 

Oops look like a miss on our side. Let us re-do this and get back to you.

Regards

Chaitanya

> > if (folio_test_large(folio)) {
> > __folio_put_large(folio);
> > +   list_del(&folio->lru);
> > continue;
> > }
> > Regards
> >
> > Chaitanya

RE: Regression on linux-next (next-20240228)

[Borah, Chaitanya Kumar]

Hello Mathew,

> -Original Message-
> From: Matthew Wilcox 
> Sent: Monday, March 4, 2024 11:27 AM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: Re: Regression on linux-next (next-20240228)
> 
> On Mon, Mar 04, 2024 at 04:49:47AM +0000, Borah, Chaitanya Kumar
> wrote:
> > After bisecting the tree, the following patch [4] seems to be the first 
> > "bad"
> > commit
> >
> > ``
> > ```
> > commit ac7130117e8860081be88149061b5abb654d5759
> > Author: Matthew Wilcox (Oracle) mailto:wi...@infradead.org
> > Date:   Tue Feb 27 17:42:41 2024 +
> >
> >     mm: use free_unref_folios() in put_pages_list()
> >
> >     Break up the list of folios into batches here so that the folios
> > are more
> >     likely to be cache hot when doing the rest of the processing.
> >
> >     Link:
> > https://lkml.kernel.org/r/20240227174254.710559-8-wi...@infradead.org
> >     Signed-off-by: Matthew Wilcox (Oracle) mailto:wi...@infradead.org
> > ``
> > ```
> >
> > We could not revert the patch because of a build errors but resetting
> > to the parent of the commit seems to fix the issue
> >
> > Could you please check why the patch causes this regression and provide a
> fix if necessary?
> 
> Could you try putting the two:
> 
> -   list_del(&folio->lru);
> 
> statements back in and see if that fixes it?

That seems to fix it.

if (!folio_put_testzero(folio))
+   list_del(&folio->lru);
continue;
if (folio_test_large(folio)) {
__folio_put_large(folio);
+   list_del(&folio->lru);
continue;
}
Regards

Chaitanya

Regression on linux-next (next-20240228)

[Borah, Chaitanya Kumar]

Hello Matthew,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

Since the version next-20240228 [2], we are seeing the following regression

`
<6> [388.274691] i915: Running intel_migrate_live_selftests/live_migrate_copy
<7> [388.274790] i915 :00:02.0: [drm:gsc_work [i915]] GT1: GSC Proxy 
initialized
<4> [388.540070] page:ea0004666880 refcount:0 mapcount:0 
mapping: index:0x0 pfn:0x1199a2
<4> [388.540111] flags: 0x8000(zone=2)
<4> [388.540117] page_type: 0x()
<4> [388.540123] raw: 8000 ea0004524008 ea0005f68e08 

<4> [388.540127] raw:    

<4> [388.540130] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
<4> [388.540140] [ cut here ]
<2> [388.540143] kernel BUG at include/linux/mm.h:1134!
<4> [388.544999] invalid opcode:  [#1] PREEMPT SMP NOPTI
<4> [388.550187] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U 
6.8.0-rc6-next-20240228-next-20240228-g20af1ca418d2+ #1
<4> [388.561471] Hardware name: Intel Corporation Meteor Lake Client 
Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 
01/31/2024
<4> [388.574636] RIP: 0010:put_pages_list+0x92/0xe0
`
Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the first "bad"
commit

`
commit ac7130117e8860081be88149061b5abb654d5759
Author: Matthew Wilcox (Oracle) mailto:wi...@infradead.org
Date:   Tue Feb 27 17:42:41 2024 +

    mm: use free_unref_folios() in put_pages_list()

    Break up the list of folios into batches here so that the folios are more
    likely to be cache hot when doing the rest of the processing.

    Link: https://lkml.kernel.org/r/20240227174254.710559-8-wi...@infradead.org
    Signed-off-by: Matthew Wilcox (Oracle) mailto:wi...@infradead.org
`

We could not revert the patch because of a build errors but resetting to the 
parent of the commit seems to fix the issue

Could you please check why the patch causes this regression and provide a fix 
if necessary?

Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240228
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20240228/bat-mtlp-8/igt@i915_selftest@l...@migrate.html
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240228&id=ac7130117e8860081be88149061b5abb654d5759

RE: [PATCH 0/6] Cursor Fault Fixes

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, February 5, 2024 6:52 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma ; Borah, Chaitanya Kumar
> ; maarten.lankho...@linux.intel.com;
> ville.syrj...@linux.intel.com
> Subject: Re: [PATCH 0/6] Cursor Fault Fixes
> 
> On Mon, 05 Feb 2024, Chaitanya Kumar Borah
>  wrote:
> > This series is based on top of [1] floated by Maarten.
> > To fix regressions seen in CI, following changes were made on top of
> > the original series.
> 
> You've sent at least three versions of this in the past 24 hours, with no
> indication of the version. Please use the -vN parameter in git format-patch or
> git send-email to indicate the series version number in patch subjects, so 
> it's
> easier for people to track.

Noted. For now, the reviewers can refer to the version history in the body of 
the cover letter. I will take care to add it into the subject as and when there 
is a next version.

Thank you.

Regards

Chaitanya

> 
> Thanks,
> Jani.
> 
> 
> 
> >
> > 1. add a check in the plane state destroy hook to not move forward if the
> vblank worker is scheduled.
> > 2. add checks before accessing frame buffer object (we are not sure
> > yet how much this helps but we have found that this operation causes
> dump stacks) 3. do not defer the intel atomic cleanup into a work queue,
> instead execute it at the end of atomic commit tail.
> >
> > While this series is in noway a complete or proper solution it is meant to
> trigger a discussion to arrive at one.
> >
> > [1] https://patchwork.freedesktop.org/series/126934/
> >
> > v2: Add missing patch
> > v3: Remove misleading error log
> > Change condition to access fb object
> >
> > Chaitanya Kumar Borah (3):
> >   drm/i915: do not destroy plane state if cursor unpin worker is
> > scheduled
> >   drm/i915: Add sanity check before accessing fb buffer object
> >   drm/i915: do not defer cleanup work
> >
> > Maarten Lankhorst (2):
> >   drm: Add drm_vblank_work_flush_all().
> >   drm/i915: Use the same vblank worker for atomic unpin
> >
> > Ville Syrjälä (1):
> >   drm/i915: Use vblank worker to unpin old legacy cursor fb safely
> >
> >  drivers/gpu/drm/drm_vblank_work.c | 22 
> >  .../gpu/drm/i915/display/intel_atomic_plane.c | 53
> > ++-  .../gpu/drm/i915/display/intel_atomic_plane.h |  4
> ++
> >  drivers/gpu/drm/i915/display/intel_crtc.c | 27 ++
> >  drivers/gpu/drm/i915/display/intel_cursor.c   | 26 -
> >  drivers/gpu/drm/i915/display/intel_cursor.h   |  3 ++
> >  drivers/gpu/drm/i915/display/intel_display.c  | 11 ++--
> >  .../drm/i915/display/intel_display_types.h|  3 ++
> >  include/drm/drm_vblank_work.h |  2 +
> >  9 files changed, 142 insertions(+), 9 deletions(-)
> 
> --
> Jani Nikula, Intel

RE: [PATCH 2/2] drm/i915/lnl: Program PKGC_LATENCY register

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Thursday, February 1, 2024 2:22 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj 
> Subject: [PATCH 2/2] drm/i915/lnl: Program PKGC_LATENCY register
> 
> Program the PKGC_LATENCY register with the highest latency from level 1 and
> above LP registers else program with all 1's.
> This is used to improve package C residency by sending the highest latency
> tolerance requirement (LTR) when the planes are done with the frame until
> the next frame programming window (set context latency, window 2) starts.
> Bspec: 68986
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/skl_watermark.c | 31 
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 051a02ac01a4..c07376f37baa 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3394,6 +3394,34 @@ static void skl_read_wm_latency(struct
> drm_i915_private *i915, u16 wm[])
>   adjust_wm_latency(i915, wm, num_levels, read_latency);  }
> 
> +/*
> + * Program PKG_C_LATENCY Pkg C with highest valid latency from
> + * watermark level1 and up and above. If watermark level 1 is
> + * invalid program it with all 1's.
> + * Program PKG_C_LATENCY Added Wake Time = 0.
> + */
> +static void intel_program_pkgc_latency(struct drm_i915_private *i915,
> +u16 wm_latency[])
> +{
> + u16 max_value = 0;
> + u32 clear = 0, val = 0;
> + int max_level = i915->display.wm.num_levels, i;
> +
> + for (i = 1; i <= max_level; i++) {
> + if (wm_latency[i] == 0)
> + break;
> + else if (wm_latency[i] > max_value)

Fix the indentation here.

With the understanding that this is a bare bones implementation and pending 
work will be floated in a different series.

LGTM

Reviewed-by: Chaitanya Kumar Borah 

> + max_value = wm_latency[i];
> + }
> +
> + if (max_value == 0)
> + max_value = ~0 & LNL_PKG_C_LATENCY_MASK;
> +
> + clear |= LNL_ADDED_WAKE_TIME_MASK |
> LNL_PKG_C_LATENCY_MASK;
> + val |= max_value;
> + intel_uncore_rmw(&i915->uncore, LNL_PKG_C_LATENCY, clear, val); }
> +
>  static void skl_setup_wm_latency(struct drm_i915_private *i915)  {
>   if (HAS_HW_SAGV_WM(i915))
> @@ -3407,6 +3435,9 @@ static void skl_setup_wm_latency(struct
> drm_i915_private *i915)
>   skl_read_wm_latency(i915, i915->display.wm.skl_latency);
> 
>   intel_print_wm_latency(i915, "Gen9 Plane", i915-
> >display.wm.skl_latency);
> +
> + if (DISPLAY_VER(i915) >= 20)
> + intel_program_pkgc_latency(i915, i915-
> >display.wm.skl_latency);
>  }
> 
>  static const struct intel_wm_funcs skl_wm_funcs = {
> --
> 2.25.1

RE: [CI 2/3] drm/i915: Use vblank worker to unpin old legacy cursor fb safely

[Borah, Chaitanya Kumar]

Hello Maarten,

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Maarten Lankhorst
> Sent: Wednesday, January 31, 2024 5:40 PM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: [CI 2/3] drm/i915: Use vblank worker to unpin old legacy cursor fb
> safely
> 
> From: Ville Syrjälä 
> 
> The cursor hardware only does sync updates, and thus the hardware will be
> scanning out from the old fb until the next start of vblank.
> So in order to make the legacy cursor fastpath actually safe we should not
> unpin the old fb until we're sure the hardware has ceased accessing it. The
> simplest approach is to just use a vblank work here to do the delayed unpin.
> 
> Not 100% sure it's a good idea to put this onto the same high priority vblank
> worker as eg. our timing critical gamma updates.
> But let's keep it simple for now, and it we later discover that this is 
> causing
> problems we can think about adding a lower priority worker for such things.
> 
> This patch is slightly reworked by Maarten
> 

We have been looking into the CI regression which were seen with this patch 
series.

As far as we understand, there are multiple code paths which manipulate the 
plane state. They can be called "asynchronously" at any time which is leading 
to the
random dump stacks and NULL pointer references. [1] and [2] are some of the 
examples. We have identified the following code paths.

1. vblank fb unpin worker
2. intel_atomic_cleanup_work
3. legacy cursor ioctl
4. atomic commit ioctls

Another interesting finding was that, in at least the ADL-P, the vblank unpin 
worker was never scheduled from the legacy cursor update call. In other words, 
the following condition was never true within intel_cursor_unpin_work

if (old_plane_state->ggtt_vma != new_plane_state->ggtt_vma)

The vblank worker was exclusively scheduled from intel_pipe_update_end.

We tried a few things to work around these issues.

1. add a check in the plane state destroy hook to not move forward if the 
vblank worker is scheduled.
2. add checks before accessing frame buffer object (we are not sure yet how 
much this helps but we have found that this operation causes dump stacks)
3. do not defer the intel atomic cleanup into a work queue, instead execute it 
at the end of atomic commit tail.

With these changes we were able to get good results in trybot.[3] There were 
some "Potential atomic update failure" issues but in a discussion with Ville we 
concluded that these can be ignored.

I will float an RFC series with these changes to trigger a discussion.

Regards

Chaitanya

[1]
<4> [436.749743] Call Trace:
<4> [436.749746]  
<4> [436.749748]  ? __die_body+0x1a/0x60
<4> [436.749756]  ? die_addr+0x38/0x60
<4> [436.749759]  ? exc_general_protection+0x1a2/0x400
<4> [436.749767]  ? asm_exc_general_protection+0x26/0x30
<4> [436.749773]  ? process_scheduled_works+0x264/0x530
<4> [436.749778]  ? __pfx_intel_cleanup_plane_fb+0x10/0x10 [i915]
<4> [436.750085]  ? intel_cleanup_plane_fb+0x10/0x90 [i915]
<4> [436.750391]  drm_atomic_helper_cleanup_planes+0x42/0x60
<4> [436.750398]  intel_atomic_cleanup_work+0x66/0xb0 [i915]
<4> [436.750704]  ? process_scheduled_works+0x264/0x530
<4> [436.750709]  process_scheduled_works+0x2db/0x530
<4> [436.750715]  ? __pfx_worker_thread+0x10/0x10
<4> [436.750718]  worker_thread+0x18c/0x350
<4> [436.750722]  ? __pfx_worker_thread+0x10/0x10
<4> [436.750725]  kthread+0xfe/0x130
<4> [436.750730]  ? __pfx_kthread+0x10/0x10
<4> [436.750735]  ret_from_fork+0x2c/0x50
<4> [436.750739]  ? __pfx_kthread+0x10/0x10
<4> [436.750743]  ret_from_fork_asm+0x1b/0x30
<4> [436.750750]  

[2]

  613.496510] Call Trace:
[  613.496514]  
[  613.496516]  ? __die_body+0x1a/0x60
[  613.496525]  ? page_fault_oops+0x156/0x450
[  613.496530]  ? do_user_addr_fault+0x65/0x9e0
[  613.496536]  ? exc_page_fault+0x68/0x1a0
[  613.496543]  ? asm_exc_page_fault+0x26/0x30
[  613.496551]  ? intel_display_rps_mark_interactive+0x4/0x40 [i915]
[  613.496860]  intel_cleanup_plane_fb+0x5d/0xc0 [i915]
[  613.497173]  drm_atomic_helper_cleanup_planes+0x42/0x60
[  613.497181]  intel_atomic_cleanup_work+0x70/0xc0 [i915]
[  613.497493]  ? process_scheduled_works+0x264/0x530
[  613.497498]  process_scheduled_works+0x2db/0x530
[  613.497504]  ? __pfx_worker_thread+0x10/0x10
[  613.497507]  worker_thread+0x18c/0x350
[  613.497511]  ? __pfx_worker_thread+0x10/0x10
[  613.497514]  kthread+0xfe/0x130
[  613.497520]  ? __pfx_kthread+0x10/0x10
[  613.497524]  ret_from_fork+0x2c/0x50
[  613.497528]  ? __pfx_kthread+0x10/0x10
[  613.497532]  ret_from_fork_asm+0x1b/0x30
[  613.497540]  

[3] https://patchwork.freedesktop.org/series/128430/#rev7

> Cc: Maarten Lankhorst 
> Signed-off-by: Ville Syrjälä 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c   | 26 +--
>  drivers/gpu/drm/i915/display/intel_display.c  |  3 +++
>  .../drm/i915/display/intel_display_types.h|  3 +++
>  3 files changed, 30 inser

RE: [PATCH 1/2] drm/i915/lnl: Add pkgc related register

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Thursday, February 1, 2024 2:22 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj 
> Subject: [PATCH 1/2] drm/i915/lnl: Add pkgc related register
> 
> Add the register that needs to read and written onto for deep pkgc
> programming.
> 
> Signed-off-by: Suraj Kandpal 

Reviewed-by: Chaitanya Kumar Borah 

> ---
>  drivers/gpu/drm/i915/display/skl_watermark_regs.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark_regs.h
> b/drivers/gpu/drm/i915/display/skl_watermark_regs.h
> index 628c5920ad49..20b30c9a6613 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark_regs.h
> +++ b/drivers/gpu/drm/i915/display/skl_watermark_regs.h
> @@ -157,4 +157,8 @@
>  #define MTL_LATENCY_SAGV _MMIO(0x4578c)
>  #define   MTL_LATENCY_QCLK_SAGV  REG_GENMASK(12, 0)
> 
> +#define LNL_PKG_C_LATENCY_MMIO(0x46460)
> +#define   LNL_ADDED_WAKE_TIME_MASK   REG_GENMASK(28, 16)
> +#define   LNL_PKG_C_LATENCY_MASK REG_GENMASK(12, 0)
> +
>  #endif /* __SKL_WATERMARK_REGS_H__ */
> --
> 2.25.1

RE: Regression on drm-tip

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Richard Fitzgerald 
> Sent: Wednesday, January 31, 2024 4:05 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani ;
> David Gow ; kunit-...@googlegroups.com; linux-
> kselft...@vger.kernel.org
> Subject: Re: Regression on drm-tip
> 
> On 31/1/24 05:34, Borah, Chaitanya Kumar wrote:
> > Hello Richard,
> >
> > Hope you are doing well. I am Chaitanya from the Linux graphics team in
> Intel.
> >
> > This mail is regarding a regression we are seeing in our CI runs[1] on drm-
> tip[2] repository.
> > These are captured by gitlab issues[3].
> >
> > We bisected the issue and have found the following commit to be the first
> bad commit.
> > ``
> > ```
> > commit a0b84213f947176ddcd0e96e0751a109f28cde21
> > Author: Richard Fitzgerald r...@opensource.cirrus.com
> > Date:   Mon Dec 18 15:17:29 2023 +
> >
> >  kunit: Fix NULL-dereference in kunit_init_suite() if suite->log
> > is NULL
> >
> >  suite->log must be checked for NULL before passing it to
> >  string_stream_clear(). This was done in kunit_init_test() but was 
> > missing
> >  from kunit_init_suite().
> >
> >  Signed-off-by: Richard Fitzgerald r...@opensource.cirrus.com
> >  Fixes: 6d696c4695c5 ("kunit: add ability to run tests after boot using
> debugfs")
> >  Reviewed-by: Rae Moar rm...@google.com
> >  Acked-by: David Gow david...@google.com
> >  Reviewed-by: Muhammad Usama Anjum usama.an...@collabora.com
> >  Signed-off-by: Shuah Khan sk...@linuxfoundation.org
> >
> > lib/kunit/test.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> > ``
> > ```
> > We tried reverting the patch and the original issue is not seen but it 
> > results
> in NULL pointer deference[4] which I am guessing is expected.
> >
> > Could you please check why the patch causes this regression and provide a
> fix if necessary?
> >
> > [1] https://intel-gfx-ci.01.org/tree/drm-tip/index.html?testfilter=drm
> > [2] https://cgit.freedesktop.org/drm-tip/
> > [3] https://gitlab.freedesktop.org/drm/intel/-/issues/10140
> >https://gitlab.freedesktop.org/drm/intel/-/issues/10143
> > [4]
> > [  179.849411] [IGT] drm_buddy: executing
> > [  179.856385] [IGT] drm_buddy: starting subtest drm_buddy
> > [  179.862594] KTAP version 1
> > [  179.862600] 1..1
> > [  179.863375] BUG: kernel NULL pointer dereference, address:
> 0030
> > [  179.863381] #PF: supervisor read access in kernel mode
> > [  179.863384] #PF: error_code(0x) - not-present page
> > [  179.863387] PGD 0 P4D 0
> > [  179.863391] Oops:  [#1] PREEMPT SMP NOPTI
> > [  179.863395] CPU: 1 PID: 1319 Comm: drm_buddy Not tainted 6.8.0-
> rc1-bisecttrail015 #16
> > [  179.863398] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS
> MTLPFWI1.R00.3471.D81.2311291340 11/29/2023
> > [  179.863400] RIP: 0010:__lock_acquire+0x71f/0x2300
> > [  179.863408] Code: 84 03 06 00 00 44 8b 15 27 f6 72 01 45 85 d2 0f
> 84 9c 00 00 00 f6 45 22 10 0f 84 63 03 00 00 41 bf 01 00 00 00 e9 8a 00 00 00
> <48> 81 3f 40 d7 fa 82 41 b9 00 00 00 00 45 0f45 c8 83 fe 01 0f 87
> > ...
> > [  179.863445] PKRU: 5554
> > [  179.863448] Call Trace:
> > [  179.863450]  
> > [  179.863453]  ? __die_body+0x1a/0x60
> > [  179.863459]  ? page_fault_oops+0x156/0x450
> > [  179.863465]  ? do_user_addr_fault+0x65/0x9e0
> > [  179.863472]  ? exc_page_fault+0x68/0x1a0
> > [  179.863479]  ? asm_exc_page_fault+0x26/0x30
> > [  179.863487]  ? __lock_acquire+0x71f/0x2300
> > [  179.863493]  ? __pfx_do_sync_core+0x10/0x10
> > [  179.863500]  lock_acquire+0xd8/0x2d0
> > [  179.863505]  ? string_stream_clear+0x29/0xb0 [kunit]
> > [  179.863523]  _raw_spin_lock+0x2e/0x40
> > [  179.863528]  ? string_stream_clear+0x29/0xb0 [kunit]
> > [  179.863540]  string_stream_clear+0x29/0xb0 [kunit]
> > [  179.863554]  __kunit_test_suites_init+0x7e/0xe0 [kunit]
> > [  179.863568]  kunit_module_notify+0x20f/0x220 [kunit]
> > [  179.863583]  notifier_call_chain+0x46/0x130
> > [  179.863591]  notifier_call_chain_r

Regression on drm-tip

[Borah, Chaitanya Kumar]

Hello Richard,

Hope you are doing well. I am Chaitanya from the Linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
drm-tip[2] repository.
These are captured by gitlab issues[3].

We bisected the issue and have found the following commit to be the first bad 
commit.
`
commit a0b84213f947176ddcd0e96e0751a109f28cde21
Author: Richard Fitzgerald r...@opensource.cirrus.com
Date:   Mon Dec 18 15:17:29 2023 +

kunit: Fix NULL-dereference in kunit_init_suite() if suite->log is NULL

suite->log must be checked for NULL before passing it to
string_stream_clear(). This was done in kunit_init_test() but was missing
from kunit_init_suite().

Signed-off-by: Richard Fitzgerald r...@opensource.cirrus.com
Fixes: 6d696c4695c5 ("kunit: add ability to run tests after boot using 
debugfs")
Reviewed-by: Rae Moar rm...@google.com
Acked-by: David Gow david...@google.com
Reviewed-by: Muhammad Usama Anjum usama.an...@collabora.com
Signed-off-by: Shuah Khan sk...@linuxfoundation.org

lib/kunit/test.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
`
We tried reverting the patch and the original issue is not seen but it results 
in NULL pointer deference[4] which I am guessing is expected.

Could you please check why the patch causes this regression and provide a fix 
if necessary?
 
[1] https://intel-gfx-ci.01.org/tree/drm-tip/index.html?testfilter=drm
[2] https://cgit.freedesktop.org/drm-tip/
[3] https://gitlab.freedesktop.org/drm/intel/-/issues/10140
  https://gitlab.freedesktop.org/drm/intel/-/issues/10143
[4]
[  179.849411] [IGT] drm_buddy: executing
[  179.856385] [IGT] drm_buddy: starting subtest drm_buddy
[  179.862594] KTAP version 1
[  179.862600] 1..1
[  179.863375] BUG: kernel NULL pointer dereference, address: 
0030
[  179.863381] #PF: supervisor read access in kernel mode
[  179.863384] #PF: error_code(0x) - not-present page
[  179.863387] PGD 0 P4D 0
[  179.863391] Oops:  [#1] PREEMPT SMP NOPTI
[  179.863395] CPU: 1 PID: 1319 Comm: drm_buddy Not tainted 
6.8.0-rc1-bisecttrail015 #16
[  179.863398] Hardware name: Intel Corporation Meteor Lake Client 
Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3471.D81.2311291340 
11/29/2023
[  179.863400] RIP: 0010:__lock_acquire+0x71f/0x2300
[  179.863408] Code: 84 03 06 00 00 44 8b 15 27 f6 72 01 45 85 d2 0f 84 
9c 00 00 00 f6 45 22 10 0f 84 63 03 00 00 41 bf 01 00 00 00 e9 8a 00 00 00 <48> 
81 3f 40 d7 fa 82 41 b9 00 00 00 00 45 0f   45 c8 83 fe 01 0f 87
...
[  179.863445] PKRU: 5554
[  179.863448] Call Trace:
[  179.863450]  
[  179.863453]  ? __die_body+0x1a/0x60
[  179.863459]  ? page_fault_oops+0x156/0x450
[  179.863465]  ? do_user_addr_fault+0x65/0x9e0
[  179.863472]  ? exc_page_fault+0x68/0x1a0
[  179.863479]  ? asm_exc_page_fault+0x26/0x30
[  179.863487]  ? __lock_acquire+0x71f/0x2300
[  179.863493]  ? __pfx_do_sync_core+0x10/0x10
[  179.863500]  lock_acquire+0xd8/0x2d0
[  179.863505]  ? string_stream_clear+0x29/0xb0 [kunit]
[  179.863523]  _raw_spin_lock+0x2e/0x40
[  179.863528]  ? string_stream_clear+0x29/0xb0 [kunit]
[  179.863540]  string_stream_clear+0x29/0xb0 [kunit]
[  179.863554]  __kunit_test_suites_init+0x7e/0xe0 [kunit]
[  179.863568]  kunit_module_notify+0x20f/0x220 [kunit]
[  179.863583]  notifier_call_chain+0x46/0x130
[  179.863591]  notifier_call_chain_robust+0x3e/0x90
[  179.863598]  blocking_notifier_call_chain_robust+0x42/0x60
[  179.863605]  load_module+0x1bcd/0x1f80
[  179.863617]  ? init_module_from_file+0x86/0xd0
[  179.863621]  init_module_from_file+0x86/0xd0
[  179.863629]  idempotent_init_module+0x17c/0x230
[  179.863637]  __x64_sys_finit_module+0x56/0xb0
[  179.863642]  do_syscall_64+0x6f/0x140
[  179.863649]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[  179.863654] RIP: 0033:0x7f0e6676195d

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

[Borah, Chaitanya Kumar]

Hello Johannes,

> -Original Message-
> From: Berg, Johannes 
> Sent: Monday, December 4, 2023 11:41 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: RE: Regression on linux-next (next-20231130)
> 
> Hi,
> 
> > [snip lockdep report]
> 
> > commit f4acfcd4deb158b96595250cc332901b282d15b0
> > Author: Johannes Berg johannes.b...@intel.com
> > Date:   Fri Nov 24 17:25:25 2023 +0100
> >
> > debugfs: annotate debugfs handlers vs. removal with lockdep
> 
> Yes, obviously, since before that there was no lockdep class
> "debugfs:i915_pipe" 😊
> 
> > We also verified that if we revert the patch the issue is not seen.
> >
> > Could you please check why the patch causes this regression and
> > provide a fix if necessary?
> 
> First off, I already sent a revert, which should be included in the next -rc.
> Anyway this patch shouldn't have been included in the -rc cycle, I just
> erroneously included it with some bugfixes (that patch-wise had a
> dependency).
> 
> Secondly, we did find a false positive in another case, and yours seems to be
> the same or similar, due to seq_file not differentiating between the file
> instances.
> 
> That's a bit unfortunate, because we _did_ have actual deadlocks in wireless
> with debugfs_remove() being called on a file while holding a lock that the 
> file
> also acquires, which can lead to a deadlock. Unless we differentiate seq_file
> instances though, there doesn't seem to be a good way to annotate that in
> debugfs, as this report and others show.

Thank you for the confirmation. We will wait for the revert to be included in 
linux-next.
Sounds like a useful addition. Hopefully, we can find a way for both of them to 
co-exist.

Regards

Chaitanya

> 
> johannes
> --

[Intel-gfx] Regression on linux-next (next-20231130)

[Borah, Chaitanya Kumar]

Hello Johannes,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

Since the version next-20231130 [2], we are seeing the following regression

 
`
<4> [198.663557] ==
<4> [198.663559] WARNING: possible circular locking dependency detected
<4> [198.663562] 6.7.0-rc4-next-20231204-next-20231204-g629a3b49f3f9+ #1 Not 
tainted
<4> [198.663566] --
<4> [198.663568] core_hotunplug/5433 is trying to acquire lock:
<4> [198.663571] 8881481b5068 (debugfs:i915_lpsp_capability#7){}-{0:0}, 
at: remove_one+0x56/0x160
<4> [198.663580] 
but task is already holding lock:
<4> [198.663583] 88810ef2e9d0 (&sb->s_type->i_mutex_key#2){}-{3:3}, at: 
simple_recursive_removal+0x1a1/0x2e0
<4> [198.663591] 
which lock already depends on the new lock.
<4> [198.663594] 
the existing dependency chain (in reverse order) is:
 
`
Details log can be found in [3].

Locally we have seen a slightly different version of the issue

[  663.199573] core_hotunplug/1735 is trying to acquire lock:
[  663.199574] 888133406e68 (debugfs:i915_pipe){}-{0:0}, at: 
remove_one+0x56/0x160
 
After bisecting the tree, the following patch [4] seems to be the first "bad"
commit

`
commit f4acfcd4deb158b96595250cc332901b282d15b0
Author: Johannes Berg johannes.b...@intel.com
Date:   Fri Nov 24 17:25:25 2023 +0100

debugfs: annotate debugfs handlers vs. removal with lockdep

When you take a lock in a debugfs handler but also try
to remove the debugfs file under that lock, things can
deadlock since the removal has to wait for all users
to finish.

Add lockdep annotations in debugfs_file_get()/_put()
to catch such issues.

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Johannes Berg johannes.b...@intel.com

fs/debugfs/file.c | 10 ++
fs/debugfs/inode.c| 12 
fs/debugfs/internal.h |  6 ++
3 files changed, 28 insertions(+)
`

We also verified that if we revert the patch the issue is not seen.

Could you please check why the patch causes this regression and provide a fix
if necessary?

Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231130
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231204/bat-dg2-9/igt@core_hotunp...@unbind-rebind.html
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231130&id=f4acfcd4deb158b96595250cc332901b282d15b0

Re: [Intel-gfx] [PATCH] drm/i915/irq: Improve error logging for unexpected DE Misc interrupts

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-gfx  On Behalf Of Rahul
> Rameshbabu
> Sent: Thursday, November 23, 2023 11:27 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; dri-de...@lists.freedesktop.org;
> Rahul Rameshbabu 
> Subject: [Intel-gfx] [PATCH] drm/i915/irq: Improve error logging for
> unexpected DE Misc interrupts
> 
> Dump the iir value in hex when the interrupt is unexpected.
> 
> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9652#note_2178501
> Cc: Jani Nikula 
> Signed-off-by: Rahul Rameshbabu 
> ---
>  drivers/gpu/drm/i915/display/intel_display_irq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index bff4a76310c0..1a5a9e0fc01e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -896,7 +896,7 @@ gen8_de_misc_irq_handler(struct drm_i915_private
> *dev_priv, u32 iir)
>   }
> 
>   if (!found)
> - drm_err(&dev_priv->drm, "Unexpected DE Misc
> interrupt\n");
> + drm_err(&dev_priv->drm, "Unexpected DE Misc interrupt:
> %#x\n", iir);

Nit: It could use a format specifier like "0x%08x" (like other instances in the 
file) to maintain uniform width.

Other than that. LGTM.

Reviewed-by: Chaitanya Kumar Borah 


>  }
> 
>  static void gen11_dsi_te_interrupt_handler(struct drm_i915_private
> *dev_priv,
> --
> 2.40.1
> 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Adjust LUT rounding rules

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Monday, November 20, 2023 7:57 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH 2/4] drm/i915: Adjust LUT rounding rules
> 
> On Mon, Nov 20, 2023 at 06:08:57AM +, Borah, Chaitanya Kumar wrote:
> > Hello Ville,
> >
> > > -Original Message-
> > > From: dri-devel  On Behalf
> > > Of Ville Syrjala
> > > Sent: Friday, October 13, 2023 6:44 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: dri-de...@lists.freedesktop.org
> > > Subject: [PATCH 2/4] drm/i915: Adjust LUT rounding rules
> > >
> > > From: Ville Syrjälä 
> > >
> > > drm_color_lut_extract() rounding was changed to follow the OpenGL
> > > int<-
> > > >float conversion rules. Adjust intel_color_lut_pack() to match.
> > >
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_color.c | 14 ++
> > >  1 file changed, 6 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > index 2a2a163ea652..b01f463af861 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > @@ -785,14 +785,12 @@ static void chv_assign_csc(struct
> > > intel_crtc_state
> > > *crtc_state)
> > >  /* convert hw value with given bit_precision to lut property val */
> > > static u32
> > > intel_color_lut_pack(u32 val, int bit_precision)  {
> >
> > Is this operation unique to Intel. Should there be a drm helper for this?
> 
> If some other driver gains gamma readout support they could probably use
> something like this. The other option would be to rework the current helper
> to allow conversions both ways.
> 

The function name could be a minor inconvenience but anyway until that time 
arrives.

LGTM.

Reviewed-by: Chaitanya Kumar Borah 

> >
> > Regards
> >
> > Chaitanya
> >
> > > - u32 max = 0x >> (16 - bit_precision);
> > > -
> > > - val = clamp_val(val, 0, max);
> > > -
> > > - if (bit_precision < 16)
> > > - val <<= 16 - bit_precision;
> > > -
> > > - return val;
> > > + if (bit_precision > 16)
> > > + return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(val, (1 << 16)
> > > - 1),
> > > +  (1 << bit_precision) - 1);
> > > + else
> > > + return DIV_ROUND_CLOSEST(val * ((1 << 16) - 1),
> > > +  (1 << bit_precision) - 1);
> > >  }
> > >
> > >  static u32 i9xx_lut_8(const struct drm_color_lut *color)
> > > --
> > > 2.41.0
> >
> 
> --
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Monday, November 20, 2023 6:33 PM
> To: Ville Syrjälä 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Jani
> Nikula 
> Subject: RE: [Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding
> 
> Hello Ville,
> 
> > -Original Message-
> > From: dri-devel  On Behalf Of
> > Ville Syrjälä
> > Sent: Tuesday, October 31, 2023 9:37 PM
> > To: Jani Nikula 
> > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding
> >
> > On Tue, Oct 31, 2023 at 11:15:35AM +0200, Jani Nikula wrote:
> > > On Fri, 13 Oct 2023, Ville Syrjala  wrote:
> > > > entrirely. But perhaps a better idea would be to follow the OpenGL
> > > > int<->float conversion rules, in which case we get the following
> > > > results:
> > >
> > > Do you have a pointer to the rules handy, I couldn't find it. :(
> >
> > Eg. '2.3.5 Fixed-Point Data Conversions' in GL 4.6 spec. The section
> > number probably changes depending on which version of the spec you look
> at.
> >
> 
> This section particularly talks about conversion of normalized fixed point  to
> floating point numbers and vice versa.
> Pardon my limited knowledge on the topic but aren't we just doing a scaling
> factor conversion(Q0.16 -> Q0.8) in these patches?
> 
> I could not draw a direct relation between the formulas in the section[1] and
> what we are doing here.(but it could be just me!)

Scratch that! As I understand, in effect we are doing a Q0.16 Fixed Point -> 
Floating point -> Q0.8 Fixed Point conversion.
Correct me if I am wrong! Otherwise

LGTM.

Reviewed-by: Chaitanya Kumar Borah 


> 
> Regards
> 
> Chaitanya
> 
> [1] https://registry.khronos.org/OpenGL/specs/gl/glspec46.core.pdf '2.3.5
> Fixed-Point Data Conversions'
> 
> > >
> > > Might also add the reference to the commit message and/or comment.
> > >
> > > BR,
> > > Jani.
> > >
> > > --
> > > Jani Nikula, Intel
> >
> > --
> > Ville Syrjälä
> > Intel

Re: [Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding

[Borah, Chaitanya Kumar]

Hello Ville,

> -Original Message-
> From: dri-devel  On Behalf Of Ville
> Syrjälä
> Sent: Tuesday, October 31, 2023 9:37 PM
> To: Jani Nikula 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding
> 
> On Tue, Oct 31, 2023 at 11:15:35AM +0200, Jani Nikula wrote:
> > On Fri, 13 Oct 2023, Ville Syrjala  wrote:
> > > entrirely. But perhaps a better idea would be to follow the OpenGL
> > > int<->float conversion rules, in which case we get the following
> > > results:
> >
> > Do you have a pointer to the rules handy, I couldn't find it. :(
> 
> Eg. '2.3.5 Fixed-Point Data Conversions' in GL 4.6 spec. The section number
> probably changes depending on which version of the spec you look at.
> 

This section particularly talks about conversion of normalized fixed point  to 
floating point numbers and vice versa.
Pardon my limited knowledge on the topic but aren't we just doing a scaling 
factor conversion(Q0.16 -> Q0.8) in these patches?

I could not draw a direct relation between the formulas in the section[1] and 
what we are doing here.(but it could be just me!)

Regards

Chaitanya

[1] https://registry.khronos.org/OpenGL/specs/gl/glspec46.core.pdf '2.3.5 
Fixed-Point Data Conversions'

> >
> > Might also add the reference to the commit message and/or comment.
> >
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel
> 
> --
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Fix glk+ degamma LUT conversions

[Borah, Chaitanya Kumar]

> -Original Message-
> From: dri-devel  On Behalf Of Ville
> Syrjala
> Sent: Friday, October 13, 2023 6:44 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 4/4] drm/i915: Fix glk+ degamma LUT conversions
> 
> From: Ville Syrjälä 
> 
> The current implementation of change_lut_val_precision() is just a convoluted
> way of shifting by 8. Implement the proper rounding by just using
> drm_color_lut_extract() and intel_color_lut_pack() like everyone else does.
> 
> And as the uapi can't handle >=1.0 values but the hardware can we need to
> clamp the results appropriately in the readout path.
> 
> Signed-off-by: Ville Syrjälä 

LGTM.

Reviewed-by: Chaitanya Kumar Borah 


> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 54 +++---
>  1 file changed, 28 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index a4b30614bd63..1cfbb3650304 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1526,14 +1526,27 @@ static int glk_degamma_lut_size(struct
> drm_i915_private *i915)
>   return 35;
>  }
> 
> -/*
> - * change_lut_val_precision: helper function to upscale or downscale lut
> values.
> - * Parameters 'to' and 'from' needs to be less than 32. This should be
> sufficient
> - * as currently there are no lut values exceeding 32 bit.
> - */
> -static u32 change_lut_val_precision(u32 lut_val, int to, int from)
> +static u32 glk_degamma_lut(const struct drm_color_lut *color) {
> + return color->green;
> +}
> +
> +static void glk_degamma_lut_pack(struct drm_color_lut *entry, u32 val)
> +{
> + /* PRE_CSC_GAMC_DATA is 3.16, clamp to 0.16 */
> + entry->red = entry->green = entry->blue = min(val, 0xu); }
> +
> +static u32 mtl_degamma_lut(const struct drm_color_lut *color) {
> + return drm_color_lut_extract(color->green, 24); }
> +
> +static void mtl_degamma_lut_pack(struct drm_color_lut *entry, u32 val)
>  {
> - return mul_u32_u32(lut_val, (1 << to)) / (1 << from);
> + /* PRE_CSC_GAMC_DATA is 3.24, clamp to 0.16 */
> + entry->red = entry->green = entry->blue =
> + intel_color_lut_pack(min(val, 0xffu), 24);
>  }
> 
>  static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state,
> @@ -1570,20 +1583,16 @@ static void glk_load_degamma_lut(const struct
> intel_crtc_state *crtc_state,
>* ToDo: Extend to max 7.0. Enable 32 bit input value
>* as compared to just 16 to achieve this.
>*/
> - u32 lut_val;
> -
> - if (DISPLAY_VER(i915) >= 14)
> - lut_val = change_lut_val_precision(lut[i].green, 24,
> 16);
> - else
> - lut_val = lut[i].green;
> -
>   ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe),
> -   lut_val);
> +   DISPLAY_VER(i915) >= 14 ?
> +   mtl_degamma_lut(&lut[i]) :
> glk_degamma_lut(&lut[i]));
>   }
> 
>   /* Clamp values > 1.0. */
>   while (i++ < glk_degamma_lut_size(i915))
> - ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe), 1 <<
> 16);
> + ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe),
> +   DISPLAY_VER(i915) >= 14 ?
> +   1 << 24 : 1 << 16);
> 
>   ilk_lut_write(crtc_state, PRE_CSC_GAMC_INDEX(pipe), 0);  } @@ -
> 3573,17 +3582,10 @@ static struct drm_property_blob
> *glk_read_degamma_lut(struct intel_crtc *crtc)
>   for (i = 0; i < lut_size; i++) {
>   u32 val = intel_de_read_fw(dev_priv,
> PRE_CSC_GAMC_DATA(pipe));
> 
> - /*
> -  * For MTL and beyond, convert back the 24 bit lut values
> -  * read from HW to 16 bit values to maintain parity with
> -  * userspace values
> -  */
>   if (DISPLAY_VER(dev_priv) >= 14)
> - val = change_lut_val_precision(val, 16, 24);
> -
> - lut[i].red = val;
> - lut[i].green = val;
> - lut[i].blue = val;
> + mtl_degamma_lut_pack(&lut[i], val);
> + else
> + glk_degamma_lut_pack(&lut[i], val);
>   }
> 
>   intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe),
> --
> 2.41.0

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Adjust LUT rounding rules

[Borah, Chaitanya Kumar]

Hello Ville,

> -Original Message-
> From: dri-devel  On Behalf Of Ville
> Syrjala
> Sent: Friday, October 13, 2023 6:44 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 2/4] drm/i915: Adjust LUT rounding rules
> 
> From: Ville Syrjälä 
> 
> drm_color_lut_extract() rounding was changed to follow the OpenGL int<-
> >float conversion rules. Adjust intel_color_lut_pack() to match.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 2a2a163ea652..b01f463af861 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -785,14 +785,12 @@ static void chv_assign_csc(struct intel_crtc_state
> *crtc_state)
>  /* convert hw value with given bit_precision to lut property val */  static 
> u32
> intel_color_lut_pack(u32 val, int bit_precision)  {

Is this operation unique to Intel. Should there be a drm helper for this?

Regards

Chaitanya

> - u32 max = 0x >> (16 - bit_precision);
> -
> - val = clamp_val(val, 0, max);
> -
> - if (bit_precision < 16)
> - val <<= 16 - bit_precision;
> -
> - return val;
> + if (bit_precision > 16)
> + return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(val, (1 << 16)
> - 1),
> +  (1 << bit_precision) - 1);
> + else
> + return DIV_ROUND_CLOSEST(val * ((1 << 16) - 1),
> +  (1 << bit_precision) - 1);
>  }
> 
>  static u32 i9xx_lut_8(const struct drm_color_lut *color)
> --
> 2.41.0

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

[Borah, Chaitanya Kumar]

Hello Krister,

> -Original Message-
> From: Krister Johansen 
> Sent: Tuesday, November 14, 2023 11:11 PM
> To: Borah, Chaitanya Kumar 
> Cc: Krister Johansen ; intel-
> g...@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani ;
> Miklos Szeredi 
> Subject: Re: Regression on linux-next (next-20231107)
> 
> Hi Chaitanya,
> 
> On Mon, Nov 13, 2023 at 06:21:57AM +, Borah, Chaitanya Kumar wrote:
> > Hello Krister,
> >
> > Any luck with this?
> >
> > > -Original Message-
> > > From: Borah, Chaitanya Kumar
> > > Sent: Friday, November 10, 2023 9:09 AM
> > > To: Krister Johansen 
> > > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > > ; Saarinen, Jani
> > > ; Miklos Szeredi 
> > > Subject: RE: Regression on linux-next (next-20231107)
> > >
> > > Hello Krister,
> > >
> > > > -Original Message-
> > > > From: Krister Johansen 
> > > > Sent: Friday, November 10, 2023 2:10 AM
> > > > To: Borah, Chaitanya Kumar 
> > > > Cc: k...@templeofstupid.com; intel-gfx@lists.freedesktop.org;
> > > > Kurmi, Suresh Kumar ; Saarinen, Jani
> > > > ; Miklos Szeredi 
> > > > Subject: Re: Regression on linux-next (next-20231107)
> > > >
> > > > Hi Chaitanya,
> > > >
> > > > On Thu, Nov 09, 2023 at 05:00:09PM +, Borah, Chaitanya Kumar
> wrote:
> > > > > Hello Krister,
> > > > >
> > > > > Hope you are doing well. I am Chaitanya from the linux graphics
> > > > > team in
> > > > Intel.
> > > > >
> > > > > This mail is regarding a regression we are seeing in our CI
> > > > > runs[1] for some
> > > > machines (dg2 and adl-p) on linux-next  repository.
> > > > >
> > > > > Since the version next-20231107 [2], we are seeing the following
> > > > > error 
> > > > > ```
> > > > > <4>[   32.015910] stack segment:  [#1] PREEMPT SMP NOPTI
> > > > > <4>[   32.021048] CPU: 15 PID: 766 Comm: fusermount Not tainted
> 6.6.0-
> > > > next-20231107-next-20231107-g5cd631a52568+ #1
> > > > > <4>[   32.031135] Hardware name: Intel Corporation Raptor Lake Client
> > > > Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS
> > > > RPLSFWI1.R00.4221.A00.2305271351 05/27/2023
> > > > > <4>[   32.044657] RIP: 0010:fuse_evict_inode+0x61/0x150 [fuse]
> > > > > 
> > > > > 
> > > > > ``
> > > > > ```
> > > > >
> > > > > Details log can be found in [3].
> > > > >
> > > > > After bisecting the tree, the following patch [4] seems to be
> > > > > the first "bad" commit
> > > > >
> > > > >
> > > > > 
> > > > > 
> > > > > ``
> > > > > ```
> > > > > 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5 is the first bad commit
> > > > > commit 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5
> > > > > Author: Krister Johansen k...@templeofstupid.com
> > > > > Date:   Fri Nov 3 10:39:47 2023 -0700
> > > > >
> > > > > fuse: share lookup state between submount and its parent
> > > > >
> > > > > Fuse submounts do not perform a lookup for the nodeid that
> > > > > they
> > > inherit
> > > > > from their parent.  Instead, the code decrements the nlookup on 
> > > > > the
> > > > > submount's fuse_inode when it is instantiated, and no forget is
> > > > > performed when a submount root is evicted.
> > > > >
> > > > > Trouble arises when the submount's parent is evicted despite the
> > > > > submount itself being in use.  In this author's case, the submount
> was
> > > > > in a container and deatched from the initial mount namespace via a
> > > > > MNT_DEATCH operation.  When memory pressure triggered the
> > > > > shrinker,
> > > > the
> > > > > inode from the parent was evicted, which tri

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

[Borah, Chaitanya Kumar]

Hello Krister,

Any luck with this?

> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Friday, November 10, 2023 9:09 AM
> To: Krister Johansen 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani ;
> Miklos Szeredi 
> Subject: RE: Regression on linux-next (next-20231107)
> 
> Hello Krister,
> 
> > -Original Message-
> > From: Krister Johansen 
> > Sent: Friday, November 10, 2023 2:10 AM
> > To: Borah, Chaitanya Kumar 
> > Cc: k...@templeofstupid.com; intel-gfx@lists.freedesktop.org; Kurmi,
> > Suresh Kumar ; Saarinen, Jani
> > ; Miklos Szeredi 
> > Subject: Re: Regression on linux-next (next-20231107)
> >
> > Hi Chaitanya,
> >
> > On Thu, Nov 09, 2023 at 05:00:09PM +, Borah, Chaitanya Kumar wrote:
> > > Hello Krister,
> > >
> > > Hope you are doing well. I am Chaitanya from the linux graphics team
> > > in
> > Intel.
> > >
> > > This mail is regarding a regression we are seeing in our CI runs[1]
> > > for some
> > machines (dg2 and adl-p) on linux-next  repository.
> > >
> > > Since the version next-20231107 [2], we are seeing the following
> > > error 
> > > ```
> > > <4>[   32.015910] stack segment:  [#1] PREEMPT SMP NOPTI
> > > <4>[   32.021048] CPU: 15 PID: 766 Comm: fusermount Not tainted 6.6.0-
> > next-20231107-next-20231107-g5cd631a52568+ #1
> > > <4>[   32.031135] Hardware name: Intel Corporation Raptor Lake Client
> > Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS
> > RPLSFWI1.R00.4221.A00.2305271351 05/27/2023
> > > <4>[   32.044657] RIP: 0010:fuse_evict_inode+0x61/0x150 [fuse]
> > > 
> > > ``
> > > ```
> > >
> > > Details log can be found in [3].
> > >
> > > After bisecting the tree, the following patch [4] seems to be the
> > > first "bad" commit
> > >
> > >
> > > 
> > > ``
> > > ```
> > > 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5 is the first bad commit
> > > commit 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5
> > > Author: Krister Johansen k...@templeofstupid.com
> > > Date:   Fri Nov 3 10:39:47 2023 -0700
> > >
> > > fuse: share lookup state between submount and its parent
> > >
> > > Fuse submounts do not perform a lookup for the nodeid that they
> inherit
> > > from their parent.  Instead, the code decrements the nlookup on the
> > > submount's fuse_inode when it is instantiated, and no forget is
> > > performed when a submount root is evicted.
> > >
> > > Trouble arises when the submount's parent is evicted despite the
> > > submount itself being in use.  In this author's case, the submount was
> > > in a container and deatched from the initial mount namespace via a
> > > MNT_DEATCH operation.  When memory pressure triggered the
> > > shrinker,
> > the
> > > inode from the parent was evicted, which triggered enough forgets to
> > > render the submount's nodeid invalid.
> > >
> > > Since submounts should still function, even if their parent goes away,
> > > solve this problem by sharing refcounted state between the parent and
> > > its submount.  When all of the references on this shared state reach
> > > zero, it's safe to forget the final lookup of the fuse nodeid.
> > >
> > >
> > > 
> > > ``
> > > ```
> > >
> > > We also verified that if we revert the patch the issue is not seen.
> > >
> > > Could you please check why the patch causes this regression and
> > > provide a
> > fix if necessary?
> >
> > Apologies for the inconvenience.  I've reproduced the problem, tested
> > a fix, and am in the process of preparing patches to send to Miklos.
> > I'll cc the people on this e-mail in that thread.
> >
> > > [3]
> > > http://gfx-ci.igk.intel.com/tree/linux-next/next-20231109/bat-dg2-14
> > > /b
> > > oot0.txt
> >
> > This link didn't resolve in DNS when I tried to access it.  I needed
> > to use intel- gfx-ci.01.org as the hostname instead.
> >
> 
> My bad. I realized it too late. Hope you found the logs. If not here they are.
> 
> https://intel-gfx-ci.01.org/tree/linux-next/next-20231109/bat-dg2-
> 14/boot0.txt
> 
> Regards
> 
> Chaitanya
> > Thanks,
> >
> > -K

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

[Borah, Chaitanya Kumar]

Hello Krister,

> -Original Message-
> From: Krister Johansen 
> Sent: Friday, November 10, 2023 2:10 AM
> To: Borah, Chaitanya Kumar 
> Cc: k...@templeofstupid.com; intel-gfx@lists.freedesktop.org; Kurmi, Suresh
> Kumar ; Saarinen, Jani
> ; Miklos Szeredi 
> Subject: Re: Regression on linux-next (next-20231107)
> 
> Hi Chaitanya,
> 
> On Thu, Nov 09, 2023 at 05:00:09PM +, Borah, Chaitanya Kumar wrote:
> > Hello Krister,
> >
> > Hope you are doing well. I am Chaitanya from the linux graphics team in
> Intel.
> >
> > This mail is regarding a regression we are seeing in our CI runs[1] for some
> machines (dg2 and adl-p) on linux-next  repository.
> >
> > Since the version next-20231107 [2], we are seeing the following error
> > ```
> > <4>[   32.015910] stack segment:  [#1] PREEMPT SMP NOPTI
> > <4>[   32.021048] CPU: 15 PID: 766 Comm: fusermount Not tainted 6.6.0-
> next-20231107-next-20231107-g5cd631a52568+ #1
> > <4>[   32.031135] Hardware name: Intel Corporation Raptor Lake Client
> Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS
> RPLSFWI1.R00.4221.A00.2305271351 05/27/2023
> > <4>[   32.044657] RIP: 0010:fuse_evict_inode+0x61/0x150 [fuse]
> > ``
> > ```
> >
> > Details log can be found in [3].
> >
> > After bisecting the tree, the following patch [4] seems to be the
> > first "bad" commit
> >
> >
> > ``
> > ```
> > 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5 is the first bad commit
> > commit 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5
> > Author: Krister Johansen k...@templeofstupid.com
> > Date:   Fri Nov 3 10:39:47 2023 -0700
> >
> > fuse: share lookup state between submount and its parent
> >
> > Fuse submounts do not perform a lookup for the nodeid that they inherit
> > from their parent.  Instead, the code decrements the nlookup on the
> > submount's fuse_inode when it is instantiated, and no forget is
> > performed when a submount root is evicted.
> >
> > Trouble arises when the submount's parent is evicted despite the
> > submount itself being in use.  In this author's case, the submount was
> > in a container and deatched from the initial mount namespace via a
> > MNT_DEATCH operation.  When memory pressure triggered the shrinker,
> the
> > inode from the parent was evicted, which triggered enough forgets to
> > render the submount's nodeid invalid.
> >
> > Since submounts should still function, even if their parent goes away,
> > solve this problem by sharing refcounted state between the parent and
> > its submount.  When all of the references on this shared state reach
> > zero, it's safe to forget the final lookup of the fuse nodeid.
> >
> >
> > ``
> > ```
> >
> > We also verified that if we revert the patch the issue is not seen.
> >
> > Could you please check why the patch causes this regression and provide a
> fix if necessary?
> 
> Apologies for the inconvenience.  I've reproduced the problem, tested a fix,
> and am in the process of preparing patches to send to Miklos.  I'll cc the
> people on this e-mail in that thread.
> 
> > [3]
> > http://gfx-ci.igk.intel.com/tree/linux-next/next-20231109/bat-dg2-14/b
> > oot0.txt
> 
> This link didn't resolve in DNS when I tried to access it.  I needed to use 
> intel-
> gfx-ci.01.org as the hostname instead.
> 

My bad. I realized it too late. Hope you found the logs. If not here they are.

https://intel-gfx-ci.01.org/tree/linux-next/next-20231109/bat-dg2-14/boot0.txt

Regards

Chaitanya
> Thanks,
> 
> -K

[Intel-gfx] Regression on linux-next (next-20231107)

[Borah, Chaitanya Kumar]

Hello Krister,
 
Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
 
This mail is regarding a regression we are seeing in our CI runs[1] for some 
machines (dg2 and adl-p) on linux-next  repository.

Since the version next-20231107 [2], we are seeing the following error
```
<4>[   32.015910] stack segment:  [#1] PREEMPT SMP NOPTI
<4>[   32.021048] CPU: 15 PID: 766 Comm: fusermount Not tainted 
6.6.0-next-20231107-next-20231107-g5cd631a52568+ #1
<4>[   32.031135] Hardware name: Intel Corporation Raptor Lake Client 
Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.4221.A00.2305271351 
05/27/2023
<4>[   32.044657] RIP: 0010:fuse_evict_inode+0x61/0x150 [fuse]
`

Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the first "bad" 
commit

 
`
513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5 is the first bad commit
commit 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5
Author: Krister Johansen k...@templeofstupid.com
Date:   Fri Nov 3 10:39:47 2023 -0700

fuse: share lookup state between submount and its parent

Fuse submounts do not perform a lookup for the nodeid that they inherit
from their parent.  Instead, the code decrements the nlookup on the
submount's fuse_inode when it is instantiated, and no forget is
performed when a submount root is evicted.

Trouble arises when the submount's parent is evicted despite the
submount itself being in use.  In this author's case, the submount was
in a container and deatched from the initial mount namespace via a
MNT_DEATCH operation.  When memory pressure triggered the shrinker, the
inode from the parent was evicted, which triggered enough forgets to
render the submount's nodeid invalid.

Since submounts should still function, even if their parent goes away,
solve this problem by sharing refcounted state between the parent and
its submount.  When all of the references on this shared state reach
zero, it's safe to forget the final lookup of the fuse nodeid.

 
`
 
We also verified that if we revert the patch the issue is not seen.

Could you please check why the patch causes this regression and provide a fix 
if necessary?

Thank you.

Regards

Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231107
[3] 
http://gfx-ci.igk.intel.com/tree/linux-next/next-20231109/bat-dg2-14/boot0.txt
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231107&id=513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5

Re: [Intel-gfx] [PATCH 3/4] drm/i915: s/clamp()/min()/ in i965_lut_11p6_max_pack()

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, October 13, 2023 6:44 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/4] drm/i915: s/clamp()/min()/ in
> i965_lut_11p6_max_pack()
> 
> From: Ville Syrjälä 
> 
> Use min() instead of clamp() since the color values involved are unsigned. No
> functional changes.
> 

LGTM.

Reviewed-by: Chaitanya Kumar Borah 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index b01f463af861..a4b30614bd63 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -909,7 +909,7 @@ static void i965_lut_10p6_pack(struct drm_color_lut
> *entry, u32 ldw, u32 udw)  static u16 i965_lut_11p6_max_pack(u32 val)  {
>   /* PIPEGCMAX is 11.6, clamp to 10.6 */
> - return clamp_val(val, 0, 0x);
> + return min(val, 0xu);
>  }
> 
>  static u32 ilk_lut_10(const struct drm_color_lut *color)
> --
> 2.41.0

Re: [Intel-gfx] Build broken in drm-tip

[Borah, Chaitanya Kumar]

Hello Dave,

> -Original Message-
> From: Dave Airlie 
> Sent: Tuesday, October 31, 2023 11:22 AM
> To: Borah, Chaitanya Kumar 
> Cc: mario.limoncie...@amd.com; intel-gfx@lists.freedesktop.org; Saarinen,
> Jani ; Nautiyal, Ankit K
> ; dri-de...@lists.freedesktop.org; Kurmi, Suresh
> Kumar 
> Subject: Re: Build broken in drm-tip
> 
> On Tue, 31 Oct 2023 at 15:23, Dave Airlie  wrote:
> >
> > On Tue, 31 Oct 2023 at 15:09, Borah, Chaitanya Kumar
> >  wrote:
> > >
> > > Hello Mario,
> > >
> > > This is Chaitanya from the Linux graphics team in Intel.
> > >
> > > We are seeing a build issue in drm-tip[1]
> >
> > Sorry that was a mismerge from me, let me go fix it for summon someone
> else.
> 
> Should be fixed now.
> 

Thank you for the quick fix.

Regards

Chaitanya

> sorry for noise,
> Dave.

[Intel-gfx] Build broken in drm-tip

[Borah, Chaitanya Kumar]

Hello Mario,

This is Chaitanya from the Linux graphics team in Intel.

We are seeing a build issue in drm-tip[1]

``
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  INSTALL libsubcmd_headers
  CC [M]  drivers/gpu/drm/amd/amdgpu/vi.o
drivers/gpu/drm/amd/amdgpu/vi.c: In function ‘vi_program_aspm’:
drivers/gpu/drm/amd/amdgpu/vi.c:1127:47: error: implicit declaration of 
function ‘amdgpu_device_pcie_dynamic_switching_supported’ 
[-Werror=implicit-function-declaration]
 1127 |  if (!amdgpu_device_should_use_aspm(adev) || 
!amdgpu_device_pcie_dynamic_switching_supported())
  |   
^~
cc1: some warnings being treated as errors
make[6]: *** [scripts/Makefile.build:243: drivers/gpu/drm/amd/amdgpu/vi.o] 
Error 1
make[5]: *** [scripts/Makefile.build:480: drivers/gpu/drm/amd/amdgpu] Error 2
make[4]: *** [scripts/Makefile.build:480: drivers/gpu/drm] Error 2
make[3]: *** [scripts/Makefile.build:480: drivers/gpu] Error 2
make[2]: *** [scripts/Makefile.build:480: drivers] Error 2
make[1]: *** [/home/kbuild2/kernel/Makefile:1913: .] Error 2
make: *** [Makefile:234: __sub-make] Error 2
``

It seems to be caused by the following commit [2]

“drm/amd: Explicitly disable ASPM when dynamic switching disabled”

Could you please check and provide a fix if necessary?

[1] https://cgit.freedesktop.org/drm-tip/tree/
[2] https://cgit.freedesktop.org/drm-tip/commit/?id=2757a848cb0f1

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, October 30, 2023 5:21 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: Syrjala, Ville ; sta...@vger.kernel.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Support HBR3 rate with C10
> phy and eDP in MTL
> 
> On Wed, 18 Oct 2023, Chaitanya Kumar Borah
>  wrote:
> > eDP specification supports HBR3 link rate since v1.4a. Moreover,
> > C10 phy can support HBR3 link rate for both DP and eDP. Therefore, do
> > not clamp the supported rates for eDP at 6.75Gbps.
> >
> > Cc: 
> >
> > BSpec: 70073 74224
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> 
> For future reference, the trailers (Cc, Bspec, Signed-off-by, etc.)  all go 
> together
> with no blank lines in between.
> 

Sure Jani, will keep in mind.

Thanks

Regards

Chaitanya

> BR,
> Jani.
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 1891c0cc187d..2c1034578984 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -430,7 +430,7 @@ static int mtl_max_source_rate(struct intel_dp
> *intel_dp)
> > enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> >
> > if (intel_is_c10phy(i915, phy))
> > -   return intel_dp_is_edp(intel_dp) ? 675000 : 81;
> > +   return 81;
> >
> > return 200;
> >  }
> 
> --
> Jani Nikula, Intel

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

[Borah, Chaitanya Kumar]

Hello Christian,

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

The solution is working for us.

Also, linux-next turned green.

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

Thank you.

Regards

Chaitanya

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

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

[Borah, Chaitanya Kumar]

Hello Christian,

> -Original Message-
> From: Christian Brauner 
> Sent: Wednesday, October 25, 2023 1:02 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: Re: Regression on linux-next (next-20231013)
> 
> On Wed, Oct 25, 2023 at 06:32:01AM +0000, Borah, Chaitanya Kumar wrote:
> >  Hello Christian,
> >
> >  Hope you are doing well. I am Chaitanya from the linux graphics team in
> Intel.
> >
> >  This mail is regarding a regression we are seeing in our CI runs[1]
> > on linux-next  repository.
> 
> Any chance I can reproduce this locally?

Thank you for your response.

I see that you have already floated a patch [1] to fix the issue. We will test 
it and get back to you ASAP.

In case, you still need it.

If you happen to have a device with intel CPU on it (we are seeing it in 
machines as old as Gen3[2]), you can follow the below steps.

1. Get the latest drm-tip from https://cgit.freedesktop.org/drm-tip/ and 
install it on the machine

2. Get IGT suite from https://gitlab.freedesktop.org/drm/igt-gpu-tools

3. Build the test suite
You can use the instructions in the README.md file for building the suite.

We use ubuntu and I generally do the following

a) Make sure the packages listed in Dockerfile.build-debian-minimal and 
Dockerfile.build-debian are installed.
b) meson build && ninja -C build

4. If everything goes fine, there should be a "build" folder created within the 
base folder of your repository
Then run the test using the following command.

sudo build/tests/i915_selftest --run-subtest live

Regards

Chaitanya


[1] 
https://lore.kernel.org/intel-gfx/20231025-formfrage-watscheln-84526cd3bd7d@brauner/
[2] http://gfx-ci.igk.intel.com/tree/linux-next/igt@i915_selftest@l...@mman.html

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

[Borah, Chaitanya Kumar]

 Hello Christian,
 
 Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
 
 This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next
 repository.
 
 Since the version next-20231013 [2], we are seeing the following RCU splat
 ```
 <3> [511.395679] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
<3> [511.395716] rcu:   Tasks blocked on level-1 rcu_node (CPUs 0-9): P6238
<3> [511.395934] rcu:   (detected by 16, t=65002 jiffies, g=123977, q=439 
ncpus=20)
<6> [511.395944] task:i915_selftest   state:R  running task stack:10568 
pid:6238  tgid:6238  ppid:1001   flags:0x4002
 
`
 
 Details log can be found in [3].
 
 After bisecting the tree, the following patch [4] seems to be the first "bad" 
commit
 
 
`
commit 3a77344f50d847d51abb8629a6f181cb21684157
Author: Christian Brauner 
Date:   Fri Sep 29 08:45:59 2023 +0200

file: convert to SLAB_TYPESAFE_BY_RCU
`
 
 We also verified that if we reset the tree to the parent commit the issue is 
not seen.
 
Could you please check how the commit results in the issue?

Thank you.

Regards

Chaitanya

 [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
 [2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231013
 [3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231013/bat-dg2-11/igt@i915_selftest@l...@mman.html
 [4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231013&id=3a77344f50d847d51abb8629a6f181cb21684157

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

[Borah, Chaitanya Kumar]

Hello Lorenzo,

> -Original Message-
> From: Lorenzo Stoakes 
> Sent: Friday, October 20, 2023 12:08 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: Re: Regression on linux-next (next-20231016)
> 
> On Fri, 20 Oct 2023 at 06:52, Borah, Chaitanya Kumar
>  wrote:
> >
> > Hello Lorenzo,
> >
> > Hope you are doing well. I am Chaitanya from the linux graphics team in
> Intel.
> >
> > This mail is regarding a regression we are seeing in our CI runs[1] on 
> > linux-
> next repository.
> >
> 
> Thanks for reporting :) It is reassuring that this has been picked up from
> multiple sources.
> 
> [snip]
> 
> > We didn't see the issue on next-20231018. Is there a fix already available 
> > for
> this? If not, could you please check why this patch causes the regression and 
> if
> we can find a solution for it soon?
> 
> This is because I submitted a fix on Monday [0] which has now been taken into
> the weds revision of -next which resolves this issue altogether, so this
> regression -> not regression is expected and intentional.
> 
> Apologies for the noise!
> 

No problem! Thank you for the fix and a quick response.

Regards

Chaitanya

> [0]:https://lore.kernel.org/all/c9eb4cc6-7db4-4c2b-838d-
> 43a0b319a4f0@lucifer.local/
> 
> Thanks, Lorenzo

[Intel-gfx] Regression on linux-next (next-20231016)

[Borah, Chaitanya Kumar]

Hello Lorenzo,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.

Since the version next-20231016 [2], we are seeing the following error
```
<6>[4.550196] e1000e :00:1f.6 enp0s31f6: renamed from eth0
<1>[4.581173] BUG: kernel NULL pointer dereference, address: 
01b8
<1>[4.581178] #PF: supervisor read access in kernel mode
<1>[4.581180] #PF: error_code(0x) - not-present page
<6>[4.581182] PGD 0 P4D 0 
<4>[4.581184] Oops:  [#1] PREEMPT SMP NOPTI
<4>[4.581186] CPU: 6 PID: 460 Comm: apache2 Not tainted 
6.6.0-rc6-next-20231016-next-20231016-g4d0515b235de+ #1
<4>[4.581189] Hardware name: Intel Corporation Raptor Lake Client 
Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.3157.A00.2204200131 
04/20/2022
<4>[4.581193] RIP: 0010:mmap_region+0x803/0xa50
`

Details log can be found in [3].

After bisecting the tree, the following patch [4] seems to be causing the 
regression.

`
1db41d29b79ad271674081c752961edd064bbbac is the first bad commit
commit 1db41d29b79ad271674081c752961edd064bbbac
Author: Lorenzo Stoakes lstoa...@gmail.com
Date:   Thu Oct 12 18:04:30 2023 +0100

mm: perform the mapping_map_writable() check after call_mmap()

In order for a F_SEAL_WRITE sealed memfd mapping to have an opportunity to
clear VM_MAYWRITE, we must be able to invoke the appropriate
vm_ops->mmap() handler to do so.  We would otherwise fail the
mapping_map_writable() check before we had the opportunity to avoid it.

This patch moves this check after the call_mmap() invocation.  Only memfd
actively denies write access causing a potential failure here (in
memfd_add_seals()), so there should be no impact on non-memfd cases.

This patch makes the userland-visible change that MAP_SHARED, PROT_READ
mappings of an F_SEAL_WRITE sealed memfd mapping will now succeed.

There is a delicate situation with cleanup paths assuming that a writable
mapping must have occurred in circumstances where it may now not have.  In
order to ensure we do not accidentally mark a writable file unwritable by
mistake, we explicitly track whether we have a writable mapping and unmap
only if we do.
`

We also verified that reverting  the patch fixes the issue.

We didn't see the issue on next-20231018. Is there a fix already available for 
this? If not, could you please check why this patch causes the regression and 
if we can find a solution for it soon?

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231016
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231016/bat-rpls-1/boot0.txt 
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231016&id=1db41d29b79ad271674081c752961edd064bbbac

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

[Borah, Chaitanya Kumar]

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

LGTM.

Reviewed-by: Chaitanya Kumar Borah 

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

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/display: debugfs entry to list display capabilities

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Govindapillai, Vinod 
> Sent: Wednesday, October 18, 2023 3:57 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Govindapillai, Vinod ; Sharma, Swati2
> ; Borah, Chaitanya Kumar
> 
> Subject: [PATCH v4 1/2] drm/i915/display: debugfs entry to list display
> capabilities
> 
> Create a separate debugfs entry to list the display capabilities IGT can rely 
> on
> this debugfs entry for tests that depend on display device and display runtime
> info for both xe and i915 drivers.
> 
> v2: rename the entry to i915_display_capabilities (Chaitanya)
> 
> Signed-off-by: Vinod Govindapillai 

Assuming that it has no other impact in user-space. The change looks LGTM.

Reviewed-by: Chaitanya Kumar Borah 

> ---
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index fbe75d47a165..b0248dfa8dea 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -641,6 +641,17 @@ static int i915_display_info(struct seq_file *m, void
> *unused)
>   return 0;
>  }
> 
> +static int i915_display_capabilities(struct seq_file *m, void *unused)
> +{
> + struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + intel_display_device_info_print(DISPLAY_INFO(i915),
> + DISPLAY_RUNTIME_INFO(i915), &p);
> +
> + return 0;
> +}
> +
>  static int i915_shared_dplls_info(struct seq_file *m, void *unused)  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private); @@
> -1059,6 +1070,7 @@ static const struct drm_info_list
> intel_display_debugfs_list[] = {
>   {"i915_gem_framebuffer", i915_gem_framebuffer_info, 0},
>   {"i915_power_domain_info", i915_power_domain_info, 0},
>   {"i915_display_info", i915_display_info, 0},
> + {"i915_display_capabilities", i915_display_capabilities, 0},
>   {"i915_shared_dplls_info", i915_shared_dplls_info, 0},
>   {"i915_dp_mst_info", i915_dp_mst_info, 0},
>   {"i915_ddb_info", i915_ddb_info, 0},
> --
> 2.34.1

Re: [Intel-gfx] [PATCH v1 1/2] drm/i915/display: display device info debugfs entry

[Borah, Chaitanya Kumar]

Hello Vinod,

> -Original Message-
> From: Intel-gfx  On Behalf Of Vinod
> Govindapillai
> Sent: Tuesday, October 17, 2023 1:25 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v1 1/2] drm/i915/display: display device info
> debugfs entry
> 
> Have a common debugfs entry to get the display device info for both xe and
> i915 drivers.
> 
> Signed-off-by: Vinod Govindapillai 
> ---
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index fbe75d47a165..ed83339f50f0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -641,6 +641,16 @@ static int i915_display_info(struct seq_file *m, void
> *unused)
>   return 0;
>  }
> 
> +static int i915_display_device_info(struct seq_file *m, void *unused) {
> + struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + intel_display_device_info_print(DISPLAY_INFO(i915),
> +DISPLAY_RUNTIME_INFO(i915), &p);
> +
> + return 0;
> +}
> +
>  static int i915_shared_dplls_info(struct seq_file *m, void *unused)  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private); @@
> -1059,6 +1069,7 @@ static const struct drm_info_list
> intel_display_debugfs_list[] = {
>   {"i915_gem_framebuffer", i915_gem_framebuffer_info, 0},
>   {"i915_power_domain_info", i915_power_domain_info, 0},
>   {"i915_display_info", i915_display_info, 0},
> + {"i915_display_device_info", i915_display_device_info, 0},

Nit: Perhaps we can name it " i915_display_capabilities" keeping the essence of 
the original debugfs entry.

Regards

Chaitanya

>   {"i915_shared_dplls_info", i915_shared_dplls_info, 0},
>   {"i915_dp_mst_info", i915_dp_mst_info, 0},
>   {"i915_ddb_info", i915_ddb_info, 0},
> --
> 2.34.1

Re: [Intel-gfx] Regression in linux-next

[Borah, Chaitanya Kumar]

Hello Rafael,

> -Original Message-
> From: Borah, Chaitanya Kumar
> Sent: Wednesday, October 11, 2023 10:19 PM
> To: Wysocki, Rafael J 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: RE: Regression in linux-next
> 
> Hello Rafael,
> 
> > -Original Message-
> > From: Wysocki, Rafael J 
> > Sent: Wednesday, October 11, 2023 9:44 PM
> > To: Borah, Chaitanya Kumar 
> > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > ; Saarinen, Jani
> > 
> > Subject: Re: Regression in linux-next
> >
> > Hi,
> >
> > On 10/11/2023 6:00 AM, Borah, Chaitanya Kumar wrote:
> > > Hello Rafael,
> > >
> > >> -----Original Message-
> > >> From: Wysocki, Rafael J 
> > >> Sent: Tuesday, October 10, 2023 12:54 AM
> > >> To: Borah, Chaitanya Kumar 
> > >> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > >> ; Saarinen, Jani
> > >> 
> > >> Subject: Re: Regression in linux-next
> > >>
> > >> Hi,
> > >>
> > >> On 10/9/2023 7:10 AM, Borah, Chaitanya Kumar wrote:
> > >>> Hello Rafael
> > >>>
> > >>>> Thanks for the report, I think that this is a lockdep assertion 
> > >>>> failing.
> > >>>> If that is correct, it should be straightforward to fix.
> > >>>> I'll take care of this early next week.
> > >>>> Thanks!
> > >>> Thank you for your response.  Please let us know when a fix is 
> > >>> available.
> > >> It should be fixed in linux-next from today, by this commit:
> > >>
> > >> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-
> > >> pm.git/commit/?h=linux-
> > >> next&id=b4027ce7714f309e96b804b7fb088a40d708
> > >>
> > >> Thanks!
> > > Thanks a lot for the fix. This seems to have fixed the issue in most
> > > of the
> > machines but we are still seeing a similar problem in few of the machines.
> >
> > Thanks for reporting this!
> >
> >
> > > This has a different call stack but seems to be from the same
> > > thermal subsystem. Full logs in [1]
> > >
> > > <4>[4.392015] WARNING: CPU: 1 PID: 306 at
> > drivers/thermal/thermal_trip.c:178 thermal_zone_trip_id+0x61/0x70
> > > <4>[4.392022] Modules linked in: x86_pkg_temp_thermal coretemp
> > kvm_intel mei_pxp mei_hdcp wmi_bmof kvm e1000e irqbypass
> > crct10dif_pclmul video ptp crc32_pclmul ghash_clmulni_intel i2c_i801
> > mei_me pps_core mei i2c_smbus wmi
> > > <4>[4.392057] CPU: 1 PID: 306 Comm: thermald Not tainted 6.6.0-rc5-
> > next-20231010-next-20231010-gc0a6edb636cb+ #1
> > > <4>[4.392061] Hardware name: System manufacturer System Product
> > Name/Z170M-PLUS, BIOS 3610 03/29/2018
> > > <4>[4.392063] RIP: 0010:thermal_zone_trip_id+0x61/0x70
> > > <4>[4.392066] Code: 74 0c 83 c0 01 39 c8 75 f0 b8 c3 ff ff ff 5b 5d 
> > > c3 cc
> cc
> > cc cc 48 8d bf f0 05 00 00 be ff ff ff ff e8 63 a4 2d 00 85 c0 75 b5
> > <0f> 0b eb b1
> > 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
> > > <4>[4.392069] RSP: 0018:c9000156bda8 EFLAGS: 00010246
> > > <4>[4.392073] RAX:  RBX: 888103828ae8 RCX:
> > 0001
> > > <4>[4.392075] RDX: 8000 RSI: 823de5ab RDI:
> > 823fdfba
> > > <4>[4.392078] RBP: 888103a88800 R08: 888103828ae8 R09:
> > 0001
> > > <4>[4.392080] R10: 0001 R11: 88811494d3c0 R12:
> > 888103a88818
> > > <4>[4.392082] R13: 8881108bfa00 R14: 888103794408 R15:
> > 0001
> > > <4>[4.392084] FS:  7f1f0d6d28c0()
> GS:88822e68()
> > knlGS:
> > > <4>[4.392087] CS:  0010 DS:  ES:  CR0: 80050033
> > > <4>[4.392089] CR2: 55857c50b750 CR3: 000111efa005
> CR4:
> > 003706f0
> > > <4>[4.392091] DR0:  DR1: 
> DR2:
> > 
> > > <4>[4.392093] DR3:  DR6: fffe0ff0 DR7:
> > 0400
> > > <4>[4.392095] Call Trace:
> > > <4>[4.392097]  
> > > <4>[4.392100]  ? __warn+0x7f/0x17

Re: [Intel-gfx] Regression in linux-next

[Borah, Chaitanya Kumar]

Hello Rafael,

> -Original Message-
> From: Wysocki, Rafael J 
> Sent: Wednesday, October 11, 2023 9:44 PM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: Re: Regression in linux-next
> 
> Hi,
> 
> On 10/11/2023 6:00 AM, Borah, Chaitanya Kumar wrote:
> > Hello Rafael,
> >
> >> -Original Message-
> >> From: Wysocki, Rafael J 
> >> Sent: Tuesday, October 10, 2023 12:54 AM
> >> To: Borah, Chaitanya Kumar 
> >> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> >> ; Saarinen, Jani
> >> 
> >> Subject: Re: Regression in linux-next
> >>
> >> Hi,
> >>
> >> On 10/9/2023 7:10 AM, Borah, Chaitanya Kumar wrote:
> >>> Hello Rafael
> >>>
> >>>> Thanks for the report, I think that this is a lockdep assertion failing.
> >>>> If that is correct, it should be straightforward to fix.
> >>>> I'll take care of this early next week.
> >>>> Thanks!
> >>> Thank you for your response.  Please let us know when a fix is available.
> >> It should be fixed in linux-next from today, by this commit:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-
> >> pm.git/commit/?h=linux-
> >> next&id=b4027ce7714f309e96b804b7fb088a40d708
> >>
> >> Thanks!
> > Thanks a lot for the fix. This seems to have fixed the issue in most of the
> machines but we are still seeing a similar problem in few of the machines.
> 
> Thanks for reporting this!
> 
> 
> > This has a different call stack but seems to be from the same thermal
> > subsystem. Full logs in [1]
> >
> > <4>[4.392015] WARNING: CPU: 1 PID: 306 at
> drivers/thermal/thermal_trip.c:178 thermal_zone_trip_id+0x61/0x70
> > <4>[4.392022] Modules linked in: x86_pkg_temp_thermal coretemp
> kvm_intel mei_pxp mei_hdcp wmi_bmof kvm e1000e irqbypass
> crct10dif_pclmul video ptp crc32_pclmul ghash_clmulni_intel i2c_i801
> mei_me pps_core mei i2c_smbus wmi
> > <4>[4.392057] CPU: 1 PID: 306 Comm: thermald Not tainted 6.6.0-rc5-
> next-20231010-next-20231010-gc0a6edb636cb+ #1
> > <4>[4.392061] Hardware name: System manufacturer System Product
> Name/Z170M-PLUS, BIOS 3610 03/29/2018
> > <4>[4.392063] RIP: 0010:thermal_zone_trip_id+0x61/0x70
> > <4>[4.392066] Code: 74 0c 83 c0 01 39 c8 75 f0 b8 c3 ff ff ff 5b 5d c3 
> > cc cc
> cc cc 48 8d bf f0 05 00 00 be ff ff ff ff e8 63 a4 2d 00 85 c0 75 b5 <0f> 0b 
> eb b1
> 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
> > <4>[4.392069] RSP: 0018:c9000156bda8 EFLAGS: 00010246
> > <4>[4.392073] RAX:  RBX: 888103828ae8 RCX:
> 0001
> > <4>[4.392075] RDX: 8000 RSI: 823de5ab RDI:
> 823fdfba
> > <4>[4.392078] RBP: 888103a88800 R08: 888103828ae8 R09:
> 0001
> > <4>[4.392080] R10: 0001 R11: 88811494d3c0 R12:
> 888103a88818
> > <4>[4.392082] R13: 8881108bfa00 R14: 888103794408 R15:
> 0001
> > <4>[4.392084] FS:  7f1f0d6d28c0() GS:88822e68()
> knlGS:
> > <4>[4.392087] CS:  0010 DS:  ES:  CR0: 80050033
> > <4>[4.392089] CR2: 55857c50b750 CR3: 000111efa005 CR4:
> 003706f0
> > <4>[4.392091] DR0:  DR1:  DR2:
> 
> > <4>[4.392093] DR3:  DR6: fffe0ff0 DR7:
> 0400
> > <4>[4.392095] Call Trace:
> > <4>[4.392097]  
> > <4>[4.392100]  ? __warn+0x7f/0x170
> > <4>[4.392104]  ? thermal_zone_trip_id+0x61/0x70
> > <4>[4.392109]  ? report_bug+0x1f8/0x200
> > <4>[4.392116]  ? handle_bug+0x3c/0x70
> > <4>[4.392119]  ? exc_invalid_op+0x18/0x70
> > <4>[4.392123]  ? asm_exc_invalid_op+0x1a/0x20
> > <4>[4.392133]  ? thermal_zone_trip_id+0x61/0x70
> > <4>[4.392137]  ? thermal_zone_trip_id+0x5d/0x70
> > <4>[4.392141]  trip_point_show+0x18/0x40
> > <4>[4.392145]  dev_attr_show+0x15/0x60
> > <4>[4.392149]  sysfs_kf_seq_show+0xb5/0x100
> > <4>[4.392154]  seq_read_iter+0x111/0x450
> > <4>[4.392158]  ? check_object+0x133/0x320
> > <4>[4.392164]  vfs_read+0x20d/0x300
> >

Re: [Intel-gfx] Regression in linux-next

[Borah, Chaitanya Kumar]

Hello Rafael,

> -Original Message-
> From: Wysocki, Rafael J 
> Sent: Tuesday, October 10, 2023 12:54 AM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani 
> Subject: Re: Regression in linux-next
> 
> Hi,
> 
> On 10/9/2023 7:10 AM, Borah, Chaitanya Kumar wrote:
> > Hello Rafael
> >
> >> Thanks for the report, I think that this is a lockdep assertion failing.
> >> If that is correct, it should be straightforward to fix.
> >> I'll take care of this early next week.
> >> Thanks!
> > Thank you for your response.  Please let us know when a fix is available.
> 
> It should be fixed in linux-next from today, by this commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-
> pm.git/commit/?h=linux-
> next&id=b4027ce7714f309e96b804b7fb088a40d708
> 
> Thanks!

Thanks a lot for the fix. This seems to have fixed the issue in most of the 
machines but we are still seeing a similar problem in few of the machines.

This has a different call stack but seems to be from the same thermal 
subsystem. Full logs in [1]

<4>[4.392015] WARNING: CPU: 1 PID: 306 at 
drivers/thermal/thermal_trip.c:178 thermal_zone_trip_id+0x61/0x70
<4>[4.392022] Modules linked in: x86_pkg_temp_thermal coretemp kvm_intel 
mei_pxp mei_hdcp wmi_bmof kvm e1000e irqbypass crct10dif_pclmul video ptp 
crc32_pclmul ghash_clmulni_intel i2c_i801 mei_me pps_core mei i2c_smbus wmi
<4>[4.392057] CPU: 1 PID: 306 Comm: thermald Not tainted 
6.6.0-rc5-next-20231010-next-20231010-gc0a6edb636cb+ #1
<4>[4.392061] Hardware name: System manufacturer System Product 
Name/Z170M-PLUS, BIOS 3610 03/29/2018
<4>[4.392063] RIP: 0010:thermal_zone_trip_id+0x61/0x70
<4>[4.392066] Code: 74 0c 83 c0 01 39 c8 75 f0 b8 c3 ff ff ff 5b 5d c3 cc 
cc cc cc 48 8d bf f0 05 00 00 be ff ff ff ff e8 63 a4 2d 00 85 c0 75 b5 <0f> 0b 
eb b1 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
<4>[4.392069] RSP: 0018:c9000156bda8 EFLAGS: 00010246
<4>[4.392073] RAX:  RBX: 888103828ae8 RCX: 
0001
<4>[4.392075] RDX: 8000 RSI: 823de5ab RDI: 
823fdfba
<4>[4.392078] RBP: 888103a88800 R08: 888103828ae8 R09: 
0001
<4>[4.392080] R10: 0001 R11: 88811494d3c0 R12: 
888103a88818
<4>[4.392082] R13: 8881108bfa00 R14: 888103794408 R15: 
0001
<4>[4.392084] FS:  7f1f0d6d28c0() GS:88822e68() 
knlGS:
<4>[4.392087] CS:  0010 DS:  ES:  CR0: 80050033
<4>[4.392089] CR2: 55857c50b750 CR3: 000111efa005 CR4: 
003706f0
<4>[4.392091] DR0:  DR1:  DR2: 

<4>[4.392093] DR3:  DR6: fffe0ff0 DR7: 
0400
<4>[4.392095] Call Trace:
<4>[4.392097]  
<4>[4.392100]  ? __warn+0x7f/0x170
<4>[4.392104]  ? thermal_zone_trip_id+0x61/0x70
<4>[4.392109]  ? report_bug+0x1f8/0x200
<4>[4.392116]  ? handle_bug+0x3c/0x70
<4>[4.392119]  ? exc_invalid_op+0x18/0x70
<4>[4.392123]  ? asm_exc_invalid_op+0x1a/0x20
<4>[4.392133]  ? thermal_zone_trip_id+0x61/0x70
<4>[4.392137]  ? thermal_zone_trip_id+0x5d/0x70
<4>[4.392141]  trip_point_show+0x18/0x40
<4>[4.392145]  dev_attr_show+0x15/0x60
<4>[4.392149]  sysfs_kf_seq_show+0xb5/0x100
<4>[4.392154]  seq_read_iter+0x111/0x450
<4>[4.392158]  ? check_object+0x133/0x320
<4>[4.392164]  vfs_read+0x20d/0x300
<4>[4.392175]  ksys_read+0x64/0xe0
<4>[4.392180]  do_syscall_64+0x3c/0x90
<4>[4.392183]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
<4>[4.392187] RIP: 0033:0x7f1f0e193392

Can you please check what could be the reason for this issue?

[1] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231010/fi-kbl-guc/boot0.txt

Regards

Chaitanya




> 
> 
> > From: Wysocki, Rafael J 
> > Sent: Saturday, October 7, 2023 2:01 AM
> > To: Borah, Chaitanya Kumar 
> > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > ; Saarinen, Jani
> > 
> > Subject: Re: Regression in linux-next
> >
> > Hi,
> > On 10/5/2023 5:58 PM, Borah, Chaitanya Kumar wrote:
> > Hello Rafael,
> >
> > Hope you are doing well. I am Chaitanya from the linux graphics team in
> Intel.
> > This mail is regarding a regression we are seeing in our CI runs[1] on 
> > linux-
> next repository.
> >
> > Thanks for the report, I think that this is a lockdep assertion failing.
> > If that is corre

Re: [Intel-gfx] Regression in linux-next

[Borah, Chaitanya Kumar]

Hello Rafael

>Thanks for the report, I think that this is a lockdep assertion failing.
>If that is correct, it should be straightforward to fix.
>I'll take care of this early next week.
>Thanks!

Thank you for your response.  Please let us know when a fix is available.

Regards

Chaitanya

From: Wysocki, Rafael J  
Sent: Saturday, October 7, 2023 2:01 AM
To: Borah, Chaitanya Kumar 
Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar 
; Saarinen, Jani 
Subject: Re: Regression in linux-next

Hi,
On 10/5/2023 5:58 PM, Borah, Chaitanya Kumar wrote:
Hello Rafael,
 
Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.
 
Thanks for the report, I think that this is a lockdep assertion failing.
If that is correct, it should be straightforward to fix.
I'll take care of this early next week.
Thanks!

On next-20231003 [2], we are seeing the following error
 
```
<4>[   14.093075] [ cut here ]
<4>[   14.097664] WARNING: CPU: 0 PID: 1 at drivers/thermal/thermal_trip.c:18 
for_each_thermal_trip+0x83/0x90
<4>[   14.106977] Modules linked in:
<4>[   14.110017] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G    W      
6.6.0-rc4-next-20231003-next-20231003-gc9f2baaa18b5+ #1
<4>[   14.121305] Hardware name: Intel Corporation Meteor Lake Client 
Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3323.D89.2309110529 
09/11/2023
<4>[   14.134478] RIP: 0010:for_each_thermal_trip+0x83/0x90
<4>[   14.139496] Code: 5c 41 5d c3 cc cc cc cc 5b 31 c0 5d 41 5c 41 5d c3 cc 
cc cc cc 48 8d bf f0 05 00 00 be ff ff ff ff e8 21 a2 2d 00 85 c0 75 9a <0f> 0b 
eb 96 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
 
Details log can be found in [3].
 
After bisecting the tree, the following patch [4] seems to be causing the 
regression.
 
commit d5ea889246b112e228433a5f27f57af90ca0c1fb
Author: Rafael J. Wysocki mailto:rafael.j.wyso...@intel.com
Date:   Thu Sep 21 20:02:59 2023 +0200
 
    ACPI: thermal: Do not use trip indices for cooling device binding
 
    Rearrange the ACPI thermal driver's callback functions used for cooling
    device binding and unbinding, acpi_thermal_bind_cooling_device() and
    acpi_thermal_unbind_cooling_device(), respectively, so that they use trip
    pointers instead of trip indices which is more straightforward and allows
    the driver to become independent of the ordering of trips in the thermal
    zone structure.
 
    The general functionality is not expected to be changed.
 
    Signed-off-by: Rafael J. Wysocki mailto:rafael.j.wyso...@intel.com
    Reviewed-by: Daniel Lezcano mailto:daniel.lezc...@linaro.org
 
We also verified by moving the head of the tree to the previous commit.
 
Could you please check why this patch causes the regression and if we can find 
a solution for it soon?
 
[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231003
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231003/bat-mtlp-6/boot0.txt
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231003&id=d5ea889246b112e228433a5f27f57af90ca0c1fb

[Intel-gfx] Regression in linux-next

[Borah, Chaitanya Kumar]

Hello Rafael,


Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.



On next-20231003 [2], we are seeing the following error


```
<4>[   14.093075] [ cut here ]
<4>[   14.097664] WARNING: CPU: 0 PID: 1 at drivers/thermal/thermal_trip.c:18 
for_each_thermal_trip+0x83/0x90
<4>[   14.106977] Modules linked in:
<4>[   14.110017] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW  
6.6.0-rc4-next-20231003-next-20231003-gc9f2baaa18b5+ #1
<4>[   14.121305] Hardware name: Intel Corporation Meteor Lake Client 
Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3323.D89.2309110529 
09/11/2023
<4>[   14.134478] RIP: 0010:for_each_thermal_trip+0x83/0x90
<4>[   14.139496] Code: 5c 41 5d c3 cc cc cc cc 5b 31 c0 5d 41 5c 41 5d c3 cc 
cc cc cc 48 8d bf f0 05 00 00 be ff ff ff ff e8 21 a2 2d 00 85 c0 75 9a <0f> 0b 
eb 96 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90



Details log can be found in [3].



After bisecting the tree, the following patch [4] seems to be causing the 
regression.


commit d5ea889246b112e228433a5f27f57af90ca0c1fb
Author: Rafael J. Wysocki 
rafael.j.wyso...@intel.com
Date:   Thu Sep 21 20:02:59 2023 +0200

ACPI: thermal: Do not use trip indices for cooling device binding

Rearrange the ACPI thermal driver's callback functions used for cooling
device binding and unbinding, acpi_thermal_bind_cooling_device() and
acpi_thermal_unbind_cooling_device(), respectively, so that they use trip
pointers instead of trip indices which is more straightforward and allows
the driver to become independent of the ordering of trips in the thermal
zone structure.

The general functionality is not expected to be changed.

Signed-off-by: Rafael J. Wysocki 
rafael.j.wyso...@intel.com
Reviewed-by: Daniel Lezcano 
daniel.lezc...@linaro.org



We also verified by moving the head of the tree to the previous commit.



Could you please check why this patch causes the regression and if we can find 
a solution for it soon?


[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231003
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231003/bat-mtlp-6/boot0.txt
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231003&id=d5ea889246b112e228433a5f27f57af90ca0c1fb

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Fix pic_width readout

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Tuesday, September 12, 2023 1:08 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Manna, Animesh
> ; Borah, Chaitanya Kumar
> ; Kandpal, Suraj
> 
> Subject: [PATCH] drm/i915/dsc: Fix pic_width readout
> 
> pic_width when written into the PPS register is divided by the no.
> of vdsc instances first but the actual variable that we compare it to does not
> change i.e vdsc_cfg->pic_width hence when reading the register back for
> pic_width it needs to be multiplied by num_vdsc_instances rather than being
> divided.
> 
> Fixes: 8b70b5691704 ("drm/i915/vdsc: Fill the intel_dsc_get_pps_config
> function")
> Signed-off-by: Suraj Kandpal 

LGTM.

Reviewed-by: Chaitanya Kumar Borah 

Regards
Chaitanya

> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 5c00f7ccad7f..6757dbae9ee5 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -879,7 +879,7 @@ static void intel_dsc_get_pps_config(struct
> intel_crtc_state *crtc_state)
>   /* PPS 2 */
>   pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 2);
> 
> - vdsc_cfg->pic_width = REG_FIELD_GET(DSC_PPS2_PIC_WIDTH_MASK,
> pps_temp) / num_vdsc_instances;
> + vdsc_cfg->pic_width = REG_FIELD_GET(DSC_PPS2_PIC_WIDTH_MASK,
> pps_temp)
> +* num_vdsc_instances;
>   vdsc_cfg->pic_height =
> REG_FIELD_GET(DSC_PPS2_PIC_HEIGHT_MASK, pps_temp);
> 
>   /* PPS 3 */
> --
> 2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Fix pic_width readout

[Borah, Chaitanya Kumar]

Hello Suraj,

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Friday, September 8, 2023 10:26 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Manna, Animesh
> ; Borah, Chaitanya Kumar
> ; Kandpal, Suraj
> 
> Subject: [PATCH] drm/i915/dsc: Fix pic_width readout
> 
> pic_width when written into the PPS register is divided by the no.
> of vdsc instances first but the actual variable that we compare it to does not
> change i.e vdsc_cfg->pic_width hence when reading the register back for
> pic_width it needs to be multiplied by num_vdsc_instances rather than being
> divided.
> 
> Fixes: 8b70b5691704 ("drm/i915/vdsc: Fill the intel_dsc_get_pps_config
> function")
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index b24601d0b2c5..2d4279df9521 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -883,7 +883,7 @@ static void intel_dsc_get_pps_config(struct
> intel_crtc_state *crtc_state)
>   /* PPS_2 */
>   intel_dsc_read_and_verify_pps_reg(crtc_state, 2, &pps_temp);
> 
> - vdsc_cfg->pic_width = REG_FIELD_GET(DSC_PIC_WIDTH_MASK,
> pps_temp) / num_vdsc_instances;
> + vdsc_cfg->pic_width = REG_FIELD_GET(DSC_PIC_WIDTH_MASK,
> pps_temp) *
> +num_vdsc_instances;

The patch need a rebase after

https://patchwork.freedesktop.org/patch/555835/

Change look good to me. Will wait for the rebase for the rb tag.

Regards

Chaitanya

>   vdsc_cfg->pic_height = REG_FIELD_GET(DSC_PIC_HEIGHT_MASK,
> pps_temp);
> 
>   /* PPS_3 */
> --
> 2.25.1

Re: [Intel-gfx] [PATCH 2/6] drm/eld: replace uint8_t with u8

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Thursday, September 7, 2023 2:58 PM
> To: dri-de...@lists.freedesktop.org
> Cc: Nikula, Jani ; intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/6] drm/eld: replace uint8_t with u8
>
> Unify on kernel types.
>
> Cc: Mitul Golani 
> Signed-off-by: Jani Nikula 

LGTM

Reviewed-by: Chaitanya Kumar Borah 

> ---
>  include/drm/drm_eld.h | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/drm/drm_eld.h b/include/drm/drm_eld.h index
> 9bde89bd96ea..7b674256b9aa 100644
> --- a/include/drm/drm_eld.h
> +++ b/include/drm/drm_eld.h
> @@ -70,7 +70,7 @@
>   * drm_eld_mnl - Get ELD monitor name length in bytes.
>   * @eld: pointer to an eld memory structure with mnl set
>   */
> -static inline int drm_eld_mnl(const uint8_t *eld)
> +static inline int drm_eld_mnl(const u8 *eld)
>  {
>   return (eld[DRM_ELD_CEA_EDID_VER_MNL] &
> DRM_ELD_MNL_MASK) >> DRM_ELD_MNL_SHIFT;  } @@ -79,7 +79,7 @@
> static inline int drm_eld_mnl(const uint8_t *eld)
>   * drm_eld_sad - Get ELD SAD structures.
>   * @eld: pointer to an eld memory structure with sad_count set
>   */
> -static inline const uint8_t *drm_eld_sad(const uint8_t *eld)
> +static inline const u8 *drm_eld_sad(const u8 *eld)
>  {
>   unsigned int ver, mnl;
>
> @@ -98,7 +98,7 @@ static inline const uint8_t *drm_eld_sad(const uint8_t
> *eld)
>   * drm_eld_sad_count - Get ELD SAD count.
>   * @eld: pointer to an eld memory structure with sad_count set
>   */
> -static inline int drm_eld_sad_count(const uint8_t *eld)
> +static inline int drm_eld_sad_count(const u8 *eld)
>  {
>   return (eld[DRM_ELD_SAD_COUNT_CONN_TYPE] &
> DRM_ELD_SAD_COUNT_MASK) >>
>   DRM_ELD_SAD_COUNT_SHIFT;
> @@ -111,7 +111,7 @@ static inline int drm_eld_sad_count(const uint8_t *eld)
>   * This is a helper for determining the payload size of the baseline block, 
> in
>   * bytes, for e.g. setting the Baseline_ELD_Len field in the ELD header 
> block.
>   */
> -static inline int drm_eld_calc_baseline_block_size(const uint8_t *eld)
> +static inline int drm_eld_calc_baseline_block_size(const u8 *eld)
>  {
>   return DRM_ELD_MONITOR_NAME_STRING -
> DRM_ELD_HEADER_BLOCK_SIZE +
>   drm_eld_mnl(eld) + drm_eld_sad_count(eld) * 3; @@ -127,7
> +127,7 @@ static inline int drm_eld_calc_baseline_block_size(const uint8_t
> *eld)
>   *
>   * The returned value is guaranteed to be a multiple of 4.
>   */
> -static inline int drm_eld_size(const uint8_t *eld)
> +static inline int drm_eld_size(const u8 *eld)
>  {
>   return DRM_ELD_HEADER_BLOCK_SIZE +
> eld[DRM_ELD_BASELINE_ELD_LEN] * 4;  } @@ -139,7 +139,7 @@ static inline
> int drm_eld_size(const uint8_t *eld)
>   * The returned value is the speakers mask. User has to use
> %DRM_ELD_SPEAKER
>   * field definitions to identify speakers.
>   */
> -static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
> +static inline u8 drm_eld_get_spk_alloc(const u8 *eld)
>  {
>   return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK;  } @@ -
> 151,7 +151,7 @@ static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
>   * The caller need to use %DRM_ELD_CONN_TYPE_HDMI or
> %DRM_ELD_CONN_TYPE_DP to
>   * identify the display type connected.
>   */
> -static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
> +static inline u8 drm_eld_get_conn_type(const u8 *eld)
>  {
>   return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] &
> DRM_ELD_CONN_TYPE_MASK;  }
> --
> 2.39.2

Re: [Intel-gfx] [PATCH] drm/i915/rpl: Add new RPL PCI-IDs

[Borah, Chaitanya Kumar]

Just noticed that Dnyaneshwar has already sent patches for this change.

https://patchwork.freedesktop.org/patch/554112/?series=122712&rev=3

We can perhaps ignore this.

Regards

Chaitanya

> -Original Message-
> From: Borah, Chaitanya Kumar 
> Sent: Thursday, August 24, 2023 2:09 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Shankar, Uma
> ; Borah, Chaitanya Kumar
> 
> Subject: [PATCH] drm/i915/rpl: Add new RPL PCI-IDs
> 
> Add newly added PCI-IDs for RPL
> 
> BSpec: 55376
> 
> Signed-off-by: Chaitanya Kumar Borah 
> ---
>  include/drm/i915_pciids.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index
> 1661f9e552d2..1256770d3827 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -689,14 +689,18 @@
>  #define INTEL_RPLU_IDS(info) \
>   INTEL_VGA_DEVICE(0xA721, info), \
>   INTEL_VGA_DEVICE(0xA7A1, info), \
> - INTEL_VGA_DEVICE(0xA7A9, info)
> + INTEL_VGA_DEVICE(0xA7A9, info), \
> + INTEL_VGA_DEVICE(0xA7AC, info), \
> + INTEL_VGA_DEVICE(0xA7AD, info)
> 
>  /* RPL-P */
>  #define INTEL_RPLP_IDS(info) \
>   INTEL_RPLU_IDS(info), \
>   INTEL_VGA_DEVICE(0xA720, info), \
>   INTEL_VGA_DEVICE(0xA7A0, info), \
> - INTEL_VGA_DEVICE(0xA7A8, info)
> + INTEL_VGA_DEVICE(0xA7A8, info), \
> + INTEL_VGA_DEVICE(0xA7AA, info), \
> + INTEL_VGA_DEVICE(0xA7AB, info)
> 
>  /* DG2 */
>  #define INTEL_DG2_G10_IDS(info) \
> --
> 2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in SDP CRC enable

[Borah, Chaitanya Kumar]

Hello Arun,

> -Original Message-
> From: Murthy, Arun R 
> Sent: Monday, July 31, 2023 11:25 AM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in SDP CRC
> enable
> 
> > -Original Message-----
> > From: Borah, Chaitanya Kumar 
> > Sent: Friday, July 28, 2023 2:48 PM
> > To: Murthy, Arun R 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: RE: [Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in
> > SDP CRC enable
> >
> > Hello Arun,
> >
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Arun R Murthy
> > > Sent: Friday, July 14, 2023 11:08 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in SDP
> > > CRC enable
> > >
> > > The debug print for enabling SDP CRC16 is applicable only for DP2.0,
> >
> > DP2.0 and UHBR?
> 
> This is a DP2.0 feature that can be enabled on UHBR rates.
> 
> >
> > >but this
> > > debug print was not within the uhbr check and was always printed.
> > > Fis this by adding proper checks and returning.
> >
> > Typo.
> >
> > >
> > > Signed-off-by: Arun R Murthy 
> > > ---
> > >  .../gpu/drm/i915/display/intel_dp_link_training.c| 12 +++-
> > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > index a263773f4d68..4485ef4f8ec6 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > @@ -1390,11 +1390,13 @@ void intel_dp_128b132b_sdp_crc16(struct
> > > intel_dp *intel_dp,
> > >* Default value of bit 31 is '0' hence discarding the write
> > >* TODO: Corrective actions on SDP corruption yet to be defined
> > >*/
> > > - if (intel_dp_is_uhbr(crtc_state))
> > > - /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
> > > - drm_dp_dpcd_writeb(&intel_dp->aux,
> > > -
> > > DP_SDP_ERROR_DETECTION_CONFIGURATION,
> > > -DP_SDP_CRC16_128B132B_EN);
> > > + if (!intel_dp_is_uhbr(crtc_state))
> > > + return;
> >
> > I see that while calling this function in intel_ddi_pre_enable_dp(),
> > we do have a check for for DP2.0
> >
> > if (HAS_DP20(dev_priv))
> > intel_dp_128b132b_sdp_crc16(enc_to_intel_dp(encoder),
> > crtc_state);
> >
> > Should this check be added within the function too for the sake of
> > completion?
> >
> 
> HAS DP20 just checked for the display version number and not UHBR rates.
> We need to check for UHBR rates and then enable this CRC.
> 

I was alluding more to the fact that there are two conditions for enabling the 
CRC.

if (!HAS_DP20(dev_priv) || !intel_dp_is_uhbr(crtc_state))
return;

But if it is implicit that UHBR will only be supported on DP2.0 or/and this 
function is not
expected to be used anywhere else (and hence without any possibility of this 
function being
called without the HAS_DP20() check), the change looks good to me.

Reviewed-by: Chaitanya Kumar Borah 

Regards

Chaitanya


> Thanks and Regards,
> Arun R Murthy
> ---
> 
> > Regards
> >
> > Chaitanya
> >
> > > +
> > > + /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
> > > + drm_dp_dpcd_writeb(&intel_dp->aux,
> > > +DP_SDP_ERROR_DETECTION_CONFIGURATION,
> > > +DP_SDP_CRC16_128B132B_EN);
> > >
> > >   lt_dbg(intel_dp, DP_PHY_DPRX, "DP2.0 SDP CRC16 for 128b/132b
> > > enabled\n");  }
> > > --
> > > 2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in SDP CRC enable

[Borah, Chaitanya Kumar]

Hello Arun,

> -Original Message-
> From: Intel-gfx  On Behalf Of Arun R
> Murthy
> Sent: Friday, July 14, 2023 11:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in SDP CRC enable
> 
> The debug print for enabling SDP CRC16 is applicable only for DP2.0, 

DP2.0 and UHBR?

>but this
> debug print was not within the uhbr check and was always printed.
> Fis this by adding proper checks and returning.

Typo.

> 
> Signed-off-by: Arun R Murthy 
> ---
>  .../gpu/drm/i915/display/intel_dp_link_training.c| 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index a263773f4d68..4485ef4f8ec6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -1390,11 +1390,13 @@ void intel_dp_128b132b_sdp_crc16(struct
> intel_dp *intel_dp,
>* Default value of bit 31 is '0' hence discarding the write
>* TODO: Corrective actions on SDP corruption yet to be defined
>*/
> - if (intel_dp_is_uhbr(crtc_state))
> - /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
> - drm_dp_dpcd_writeb(&intel_dp->aux,
> -
> DP_SDP_ERROR_DETECTION_CONFIGURATION,
> -DP_SDP_CRC16_128B132B_EN);
> + if (!intel_dp_is_uhbr(crtc_state))
> + return;

I see that while calling this function in intel_ddi_pre_enable_dp(), we do have 
a
check for for DP2.0

if (HAS_DP20(dev_priv))
intel_dp_128b132b_sdp_crc16(enc_to_intel_dp(encoder),
crtc_state);

Should this check be added within the function too for the sake of completion?

Regards

Chaitanya

> +
> + /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
> + drm_dp_dpcd_writeb(&intel_dp->aux,
> +DP_SDP_ERROR_DETECTION_CONFIGURATION,
> +DP_SDP_CRC16_128B132B_EN);
> 
>   lt_dbg(intel_dp, DP_PHY_DPRX, "DP2.0 SDP CRC16 for 128b/132b
> enabled\n");  }
> --
> 2.25.1

Re: [Intel-gfx] Regression in linux-next

[Borah, Chaitanya Kumar]

Hello Tvrtko,

Your analysis is correct. Alistair has sent a new patch set with a fix.

Thank you.

Regards

Chaitanya

> -Original Message-
> From: Tvrtko Ursulin 
> Sent: Tuesday, July 25, 2023 4:24 PM
> To: Borah, Chaitanya Kumar ;
> apop...@nvidia.com
> Cc: Nikula, Jani ; intel-gfx@lists.freedesktop.org; 
> linux-
> ker...@vger.kernel.org; linux...@kvack.org; Kurmi, Suresh Kumar
> ; Yedireswarapu, SaiX Nandan
> 
> Subject: Re: [Intel-gfx] Regression in linux-next
> 
> 
> On 25/07/2023 07:42, Borah, Chaitanya Kumar wrote:
> > Hello Alistair,
> >
> > Hope you are doing well. I am Chaitanya from the linux graphics team in
> Intel.
> >
> > This mail is regarding a regression we are seeing in our CI runs[1] on
> > linux-next repository.
> >
> > On next-20230720 [2], we are seeing the following error
> >
> > <4>[   76.189375] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS
> MTLPFWI1.R00.3271.D81.2307101805 07/10/2023
> > <4>[   76.202534] RIP: 0010:__mmu_notifier_register+0x40/0x210
> > <4>[   76.207804] Code: 1a 71 5a 01 85 c0 0f 85 ec 00 00 00 48 8b 85 30 01 
> > 00
> 00 48 85 c0 0f 84 04 01 00 00 8b 85 cc 00 00 00 85 c0 0f 8e bb 01 00 00 <49> 
> 8b
> 44 24 10 48 83 78 38 00 74 1a 48 83 78 28 00 74 0c 0f 0b b8
> > <4>[   76.226368] RSP: 0018:c900019d7ca8 EFLAGS: 00010202
> > <4>[   76.231549] RAX: 0001 RBX: 1000 RCX:
> 0001
> > <4>[   76.238613] RDX:  RSI: 823ceb7b RDI:
> 823ee12d
> > <4>[   76.245680] RBP: 888102ec9b40 R08:  R09:
> 0001
> > <4>[   76.252747] R10: 0001 R11: 8881157cd2c0 R12:
> 
> > <4>[   76.259811] R13: 888102ec9c70 R14: a07de500 R15:
> 888102ec9ce0
> > <4>[   76.266875] FS:  7fbcabe11c00() GS:88846ec0()
> knlGS:
> > <4>[   76.274884] CS:  0010 DS:  ES:  CR0: 80050033
> > <4>[   76.280578] CR2: 0010 CR3: 00010d4c2005 CR4:
> 00f70ee0
> > <4>[   76.287643] DR0:  DR1:  DR2:
> 
> > <4>[   76.294711] DR3:  DR6: 07f0 DR7:
> 0400
> > <4>[   76.301775] PKRU: 5554
> > <4>[   76.304463] Call Trace:
> > <4>[   76.306893]  
> > <4>[   76.308983]  ? __die_body+0x1a/0x60
> > <4>[   76.312444]  ? page_fault_oops+0x156/0x450
> > <4>[   76.316510]  ? do_user_addr_fault+0x65/0x980
> > <4>[   76.320747]  ? exc_page_fault+0x68/0x1a0
> > <4>[   76.324643]  ? asm_exc_page_fault+0x26/0x30
> > <4>[   76.328796]  ? __mmu_notifier_register+0x40/0x210
> > <4>[   76.333460]  ? __mmu_notifier_register+0x11c/0x210
> > <4>[   76.338206]  ? preempt_count_add+0x4c/0xa0
> > <4>[   76.342273]  mmu_notifier_register+0x30/0xe0
> > <4>[   76.346509]  mmu_interval_notifier_insert+0x74/0xb0
> > <4>[   76.351344]  i915_gem_userptr_ioctl+0x21a/0x320 [i915]
> > <4>[   76.356565]  ? __pfx_i915_gem_userptr_ioctl+0x10/0x10 [i915]
> > <4>[   76.362271]  drm_ioctl_kernel+0xb4/0x150
> > <4>[   76.366159]  drm_ioctl+0x21d/0x420
> > <4>[   76.369537]  ? __pfx_i915_gem_userptr_ioctl+0x10/0x10 [i915]
> > <4>[   76.375242]  ? find_held_lock+0x2b/0x80
> > <4>[   76.379046]  __x64_sys_ioctl+0x79/0xb0
> > <4>[   76.382766]  do_syscall_64+0x3c/0x90
> > <4>[   76.386312]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> > <4>[   76.391317] RIP: 0033:0x7fbcae63f3ab
> >
> > Details log can be found in [3].
> >
> > After bisecting the tree, the following patch seems to be causing the
> > regression.
> >
> > commit 828fe4085cae77acb3abf7dd3d25b3ed6c560edf
> > Author: Alistair Popple apop...@nvidia.com
> > Date:   Wed Jul 19 22:18:46 2023 +1000
> >
> >  mmu_notifiers: rename invalidate_range notifier
> >
> >  There are two main use cases for mmu notifiers.  One is by KVM which
> uses
> >  mmu_notifier_invalidate_range_start()/end() to manage a software TLB.
> >
> >  The other is to manage hardware TLBs which need to use the
> >  invalidate_range() callback because HW can establish new TLB entries at
> >  any time.  Hence using start/end() can lead to memory corruption as
> these
> >  callbacks happen too soon/late during page unmap.
> >
> &

Re: [Intel-gfx] Regression in linux-next

[Borah, Chaitanya Kumar]

Hello Alistair,

Thank you for the quick fix.

Regards

Chaitanya

> -Original Message-
> From: Alistair Popple 
> Sent: Tuesday, July 25, 2023 6:45 PM
> To: Borah, Chaitanya Kumar 
> Cc: Yedireswarapu, SaiX Nandan ;
> Saarinen, Jani ; Kurmi, Suresh Kumar
> ; Nikula, Jani ; intel-
> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; linux-
> m...@kvack.org; dan.carpen...@linaro.org
> Subject: Re: Regression in linux-next
> 
> 
> Thanks Chaitanya for the detailed report. Dan Carpenter also reported a
> Smatch warning for this:
> 
> https://lore.kernel.org/linux-mm/38ed0627-1283-4da2-827a-
> e90484d7bd7d@moroto.mountain/
> 
> The below should fix the problem, will respin the series to include the fix.
> 
> ---
> 
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c index
> 63c8eb740af7..ec3b068cbbe6 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -621,9 +621,10 @@ int __mmu_notifier_register(struct mmu_notifier
> *subscription,
>* Subsystems should only register for invalidate_secondary_tlbs() or
>* invalidate_range_start()/end() callbacks, not both.
>*/
> - if (WARN_ON_ONCE(subscription->ops-
> >arch_invalidate_secondary_tlbs &&
> - (subscription->ops->invalidate_range_start ||
> - subscription->ops->invalidate_range_end)))
> + if (WARN_ON_ONCE(subscription &&
> +  (subscription->ops->arch_invalidate_secondary_tlbs
> &&
> +  (subscription->ops->invalidate_range_start ||
> +   subscription->ops->invalidate_range_end
>   return -EINVAL;
> 
>   if (!mm->notifier_subscriptions) {
> 
> 
> "Borah, Chaitanya Kumar"  writes:
> 
> > Hello Alistair,
> >
> > Hope you are doing well. I am Chaitanya from the linux graphics team in
> Intel.
> >
> > This mail is regarding a regression we are seeing in our CI runs[1] on
> > linux-next repository.
> >
> > On next-20230720 [2], we are seeing the following error
> >
> > <4>[   76.189375] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS
> MTLPFWI1.R00.3271.D81.2307101805 07/10/2023
> > <4>[   76.202534] RIP: 0010:__mmu_notifier_register+0x40/0x210
> > <4>[ 76.207804] Code: 1a 71 5a 01 85 c0 0f 85 ec 00 00 00 48 8b 85 30
> > 01 00 00 48 85 c0 0f 84 04 01 00 00 8b 85 cc 00 00 00 85 c0 0f 8e bb
> > 01 00 00 <49> 8b 44 24 10 48 83 78 38 00 74 1a 48 83 78 28 00 74 0c 0f
> > 0b b8
> > <4>[   76.226368] RSP: 0018:c900019d7ca8 EFLAGS: 00010202
> > <4>[   76.231549] RAX: 0001 RBX: 1000 RCX:
> 0001
> > <4>[   76.238613] RDX:  RSI: 823ceb7b RDI:
> 823ee12d
> > <4>[   76.245680] RBP: 888102ec9b40 R08:  R09:
> 0001
> > <4>[   76.252747] R10: 0001 R11: 8881157cd2c0 R12:
> 
> > <4>[   76.259811] R13: 888102ec9c70 R14: a07de500 R15:
> 888102ec9ce0
> > <4>[   76.266875] FS:  7fbcabe11c00() GS:88846ec0()
> knlGS:
> > <4>[   76.274884] CS:  0010 DS:  ES:  CR0: 80050033
> > <4>[   76.280578] CR2: 0010 CR3: 00010d4c2005 CR4:
> 00f70ee0
> > <4>[   76.287643] DR0:  DR1:  DR2:
> 
> > <4>[   76.294711] DR3:  DR6: 07f0 DR7:
> 0400
> > <4>[   76.301775] PKRU: 5554
> > <4>[   76.304463] Call Trace:
> > <4>[   76.306893]  
> > <4>[   76.308983]  ? __die_body+0x1a/0x60
> > <4>[   76.312444]  ? page_fault_oops+0x156/0x450
> > <4>[   76.316510]  ? do_user_addr_fault+0x65/0x980
> > <4>[   76.320747]  ? exc_page_fault+0x68/0x1a0
> > <4>[   76.324643]  ? asm_exc_page_fault+0x26/0x30
> > <4>[   76.328796]  ? __mmu_notifier_register+0x40/0x210
> > <4>[   76.333460]  ? __mmu_notifier_register+0x11c/0x210
> > <4>[   76.338206]  ? preempt_count_add+0x4c/0xa0
> > <4>[   76.342273]  mmu_notifier_register+0x30/0xe0
> > <4>[   76.346509]  mmu_interval_notifier_insert+0x74/0xb0
> > <4>[   76.351344]  i915_gem_userptr_ioctl+0x21a/0x320 [i915]
> > <4>[   76.356565]  ? __pfx_i915_gem_userptr_ioctl+0x10/0x10 [i915]
> > <4>[   76.362271]  drm_ioctl_kernel+0xb4/0x150
> > <4>[   76

[Intel-gfx] Regression in linux-next

[Borah, Chaitanya Kumar]

Hello Alistair,

Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
 
This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next
repository.
 
On next-20230720 [2], we are seeing the following error

<4>[   76.189375] Hardware name: Intel Corporation Meteor Lake Client 
Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3271.D81.2307101805 
07/10/2023
<4>[   76.202534] RIP: 0010:__mmu_notifier_register+0x40/0x210
<4>[   76.207804] Code: 1a 71 5a 01 85 c0 0f 85 ec 00 00 00 48 8b 85 30 01 00 
00 48 85 c0 0f 84 04 01 00 00 8b 85 cc 00 00 00 85 c0 0f 8e bb 01 00 00 <49> 8b 
44 24 10 48 83 78 38 00 74 1a 48 83 78 28 00 74 0c 0f 0b b8
<4>[   76.226368] RSP: 0018:c900019d7ca8 EFLAGS: 00010202
<4>[   76.231549] RAX: 0001 RBX: 1000 RCX: 
0001
<4>[   76.238613] RDX:  RSI: 823ceb7b RDI: 
823ee12d
<4>[   76.245680] RBP: 888102ec9b40 R08:  R09: 
0001
<4>[   76.252747] R10: 0001 R11: 8881157cd2c0 R12: 

<4>[   76.259811] R13: 888102ec9c70 R14: a07de500 R15: 
888102ec9ce0
<4>[   76.266875] FS:  7fbcabe11c00() GS:88846ec0() 
knlGS:
<4>[   76.274884] CS:  0010 DS:  ES:  CR0: 80050033
<4>[   76.280578] CR2: 0010 CR3: 00010d4c2005 CR4: 
00f70ee0
<4>[   76.287643] DR0:  DR1:  DR2: 

<4>[   76.294711] DR3:  DR6: 07f0 DR7: 
0400
<4>[   76.301775] PKRU: 5554
<4>[   76.304463] Call Trace:
<4>[   76.306893]  
<4>[   76.308983]  ? __die_body+0x1a/0x60
<4>[   76.312444]  ? page_fault_oops+0x156/0x450
<4>[   76.316510]  ? do_user_addr_fault+0x65/0x980
<4>[   76.320747]  ? exc_page_fault+0x68/0x1a0
<4>[   76.324643]  ? asm_exc_page_fault+0x26/0x30
<4>[   76.328796]  ? __mmu_notifier_register+0x40/0x210
<4>[   76.333460]  ? __mmu_notifier_register+0x11c/0x210
<4>[   76.338206]  ? preempt_count_add+0x4c/0xa0
<4>[   76.342273]  mmu_notifier_register+0x30/0xe0
<4>[   76.346509]  mmu_interval_notifier_insert+0x74/0xb0
<4>[   76.351344]  i915_gem_userptr_ioctl+0x21a/0x320 [i915]
<4>[   76.356565]  ? __pfx_i915_gem_userptr_ioctl+0x10/0x10 [i915]
<4>[   76.362271]  drm_ioctl_kernel+0xb4/0x150
<4>[   76.366159]  drm_ioctl+0x21d/0x420
<4>[   76.369537]  ? __pfx_i915_gem_userptr_ioctl+0x10/0x10 [i915]
<4>[   76.375242]  ? find_held_lock+0x2b/0x80
<4>[   76.379046]  __x64_sys_ioctl+0x79/0xb0
<4>[   76.382766]  do_syscall_64+0x3c/0x90
<4>[   76.386312]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
<4>[   76.391317] RIP: 0033:0x7fbcae63f3ab

Details log can be found in [3].

After bisecting the tree, the following patch seems to be causing the
regression.

commit 828fe4085cae77acb3abf7dd3d25b3ed6c560edf
Author: Alistair Popple apop...@nvidia.com
Date:   Wed Jul 19 22:18:46 2023 +1000

mmu_notifiers: rename invalidate_range notifier

There are two main use cases for mmu notifiers.  One is by KVM which uses
mmu_notifier_invalidate_range_start()/end() to manage a software TLB.

The other is to manage hardware TLBs which need to use the
invalidate_range() callback because HW can establish new TLB entries at
any time.  Hence using start/end() can lead to memory corruption as these
callbacks happen too soon/late during page unmap.

mmu notifier users should therefore either use the start()/end() callbacks
or the invalidate_range() callbacks.  To make this usage clearer rename
the invalidate_range() callback to arch_invalidate_secondary_tlbs() and
update documention.

Link: 
https://lkml.kernel.org/r/9a02dde2f8ddaad2db31e54706a80c12d1817aaf.1689768831.git-series.apop...@nvidia.com


We also verified by reverting the patch in the tree.

Could you please check why this patch causes the regression and if we can find
a solution for it soon?

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20230720
 
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20230720/bat-mtlp-6/dmesg0.txt

[Intel-gfx] WW29.4 Linux-next Regression update

[Borah, Chaitanya Kumar]

Regression found:
 
#1
Test case: igt@gem_exec_parallel@engines@.*
Boards impacted: all
Error:
...
<1>[   76.153388] BUG: kernel NULL pointer dereference, address: 
0010
<1>[   76.160308] #PF: supervisor read access in kernel mode
<1>[   76.165405] #PF: error_code(0x) - not-present page
...
Logs: 
https://intel-gfx-ci.01.org/tree/linux-next/next-20230721/bat-mtlp-6/dmesg0.txt
Already existing issue: -NA-
Next Steps: Bisecting in progress
 
Linux-kernel tag: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20230719
CI Run Status : https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?

Issue observed on runs from WW29.5 too.
 
Note: Please reply to this thread for any kind of information on this 
regression.

Re: [Intel-gfx] [PATCH 2/2] drm/i915/color: For MTL convert 24 bit lut values to 16 bit

[Borah, Chaitanya Kumar]

Hello Jani,

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, June 26, 2023 5:53 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/color: For MTL convert 24 bit 
> lut
> values to 16 bit
> 
> On Mon, 26 Jun 2023, Chaitanya Kumar Borah
>  wrote:
> > For MTL and beyond, convert back the 24 bit lut values read from HW to
> > 16 bit values to maintain parity with userspace values. This way we
> > avoid pipe config mismatch for pre-csc lut values.
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 25c73e2e6fa3..856191640e71 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -3477,6 +3477,14 @@ static struct drm_property_blob
> *glk_read_degamma_lut(struct intel_crtc *crtc)
> > for (i = 0; i < lut_size; i++) {
> > u32 val = intel_de_read_fw(dev_priv,
> PRE_CSC_GAMC_DATA(pipe));
> >
> > +   /*
> > +* For MTL and beyond, convert back the 24 bit lut values
> > +* read from HW to 16 bit values to maintain parity with
> > +* userspace values
> > +*/
> > +   if (DISPLAY_VER(dev_priv) >= 14)
> > +   val = mul_u32_u32(val, (1 << 16)) / (1 << 24);
> > +
> 
> Here too please add a small helper for the conversion.
> 

Thank you for the comment.
I have sent a new version with a helper function. Please let me know if you see 
any pitfalls with it.

Regards

Chaitanya.

> BR,
> Jani.
> 
> > lut[i].red = val;
> > lut[i].green = val;
> > lut[i].blue = val;
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/2] drm/i915/color: Add function to load degamma LUT in MTL

[Borah, Chaitanya Kumar]

Hello Jani,

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, June 26, 2023 5:52 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/color: Add function to load
> degamma LUT in MTL
> 
> On Mon, 26 Jun 2023, Chaitanya Kumar Borah
>  wrote:
> > MTL onwards Degamma LUT/PRE-CSC LUT precision has been increased
> from
> > 16 bits to 24 bits. Currently, drm framework only supports LUTs up to
> > 16 bit precision. Until a new uapi comes along to support higher
> > bitdepth, upscale the values sent from userland to 24 bit before
> > writing into the HW to continue supporting degamma on MTL.
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 42
> > --
> >  1 file changed, 40 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 8966e6560516..25c73e2e6fa3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -1498,6 +1498,38 @@ static void glk_load_degamma_lut(const struct
> intel_crtc_state *crtc_state,
> > ilk_lut_write(crtc_state, PRE_CSC_GAMC_INDEX(pipe), 0);  }
> >
> > +static void mtl_load_degamma_lut(const struct intel_crtc_state *crtc_state,
> > +const struct drm_property_blob *blob) {
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > +   struct drm_color_lut *degamma_lut = blob->data;
> > +   enum pipe pipe = crtc->pipe;
> > +   int i, lut_size = drm_color_lut_size(blob);
> > +
> > +   /*
> > +* 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_fw(i915, PRE_CSC_GAMC_INDEX(pipe), 0);
> > +   intel_de_write_fw(i915, PRE_CSC_GAMC_INDEX(pipe),
> > + PRE_CSC_GAMC_AUTO_INCREMENT);
> > +
> > +   for (i = 0; i < lut_size; i++) {
> > +   u64 word = mul_u32_u32(degamma_lut[i].green, (1 << 24)) /
> (1 << 16);
> > +   u32 lut_val = (word & 0xff);
> > +
> > +   intel_de_write_fw(i915, PRE_CSC_GAMC_DATA(pipe),
> > + lut_val);
> > +   }
> > +   /* Clamp values > 1.0. */
> > +   while (i++ < glk_degamma_lut_size(i915))
> > +   intel_de_write_fw(i915, PRE_CSC_GAMC_DATA(pipe), 1 <<
> 24);
> > +
> > +   intel_de_write_fw(i915, PRE_CSC_GAMC_INDEX(pipe), 0); }
> 
> Please adjust glk_load_degamma_lut() instead of copy-pasting the entire thing
> with small modifications. One of which is breaking dsb use.
> 
> You'll probably also want to add small conversion helpers between 16 and
> 24 bits instead of doing them inline.
> 

Thank you for the review. I have sent a new version of the patch set with the 
comments addressed.
I look forward to your comments.

Regards

Chaitanya

> BR,
> Jani.
> 
> 
> > +
> >  static void glk_load_luts(const struct intel_crtc_state *crtc_state)
> > {
> > const struct drm_property_blob *pre_csc_lut =
> > crtc_state->pre_csc_lut; @@ -1635,11 +1667,17 @@
> > icl_program_gamma_multi_segment(const struct intel_crtc_state
> > *crtc_state)
> >
> >  static void icl_load_luts(const struct intel_crtc_state *crtc_state)
> > {
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > const struct drm_property_blob *pre_csc_lut = crtc_state-
> >pre_csc_lut;
> > const struct drm_property_blob *post_csc_lut =
> > crtc_state->post_csc_lut;
> >
> > -   if (pre_csc_lut)
> > -   glk_load_degamma_lut(crtc_state, pre_csc_lut);
> > +   if (pre_csc_lut) {
> > +   if (DISPLAY_VER(i915) >= 14)
> > +   mtl_load_degamma_lut(crtc_state, pre_csc_lut);
> > +   else
> > +   glk_load_degamma_lut(crtc_state, pre_csc_lut);
> > +   }
> >
> > switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
> > case GAMMA_MODE_MODE_8BIT:
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915/display: Add forward declaration for struct seq_file

[Borah, Chaitanya Kumar]

> -Original Message-
> From: Jani Nikula 
> Sent: Tuesday, June 27, 2023 3:17 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma ; Murthy, Arun R
> 
> Subject: RE: [PATCH] drm/i915/display: Add forward declaration for struct
> seq_file
> 
> On Tue, 27 Jun 2023, "Borah, Chaitanya Kumar"
>  wrote:
> > Hello Jani,
> >
> >> -Original Message-
> >> From: Jani Nikula 
> >> Sent: Monday, June 26, 2023 8:05 PM
> >> To: Borah, Chaitanya Kumar ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Shankar, Uma ; Murthy, Arun R
> >> 
> >> Subject: RE: [PATCH] drm/i915/display: Add forward declaration for
> >> struct seq_file
> >>
> >> On Mon, 26 Jun 2023, "Borah, Chaitanya Kumar"
> >>  wrote:
> >> > Hello Jani,
> >> >
> >> >> -Original Message-
> >> >> From: Jani Nikula 
> >> >> Sent: Monday, June 26, 2023 5:37 PM
> >> >> To: Borah, Chaitanya Kumar ;
> >> >> intel- g...@lists.freedesktop.org
> >> >> Cc: Shankar, Uma ; Murthy, Arun R
> >> >> ; Borah, Chaitanya Kumar
> >> >> 
> >> >> Subject: Re: [PATCH] drm/i915/display: Add forward declaration for
> >> >> struct seq_file
> >> >>
> >> >> On Mon, 26 Jun 2023, Chaitanya Kumar Borah
> >> >>  wrote:
> >> >> > With change [1], visibility of struct seq_file is lost in
> >> >> > intel_display_power.h leading to build errors. Add forward
> >> >> > declaration.
> >> >> >
> >> >> > [1] ef104443bffa ("procfs: consolidate arch_report_meminfo
> >> >> > declaration")
> >> >> >
> >> >> > v2: Use forward declaration instead of headerfile inclusion
> >> >> > [Jani]
> >> >> >
> >> >> > Signed-off-by: Chaitanya Kumar Borah
> >> >> > 
> >> >>
> >> >> Hey, thanks for the patch, this would've been fine, but looks like
> >> >> Imre just pushed commit f4fab137dd2b ("drm/i915: Add missing
> >> >> forward declarations/includes to display power headers") which
> >> >> adds the forward declaration among other things.
> >> >>
> >> >> Sorry for the trouble.
> >> >>
> >> >
> >> > No problem, Thank you for the info.
> >> >
> >> > Sorry for my ignorance but will this patch eventually find its way
> >> > to linux-next or do we need to do something special here?
> >>
> >> It'll show up in linux-next once -rc1 is out. But I'm not sure that's
> >> the
> >> *question* you want the answer to, really.
> >>
> >
> > If I understand correctly, the patch will get merged with linux-next
> > along with the release of 6.4-rc1.
> >
> > The pertinent question is when will linux-next builds be fixed?
> > We are missing out on regression tracking because of the build failures.
> 
> I've asked Tvrtko to pick this up to drm-intel-next-fixes, which should show 
> up
> in linux-next when it's next generated (it's daily).
> 

Thanks a lot, Jani!

Best Regards

Chaitanya

> BR,
> Jani.
> 
> >
> > Regards
> >
> > Chaitanya
> >
> >> BR,
> >> Jani.
> >>
> >>
> >> >
> >> > Regards
> >> >
> >> > Chaitanya
> >> >
> >> >> BR,
> >> >> Jani.
> >> >>
> >> >> > ---
> >> >> >  drivers/gpu/drm/i915/display/intel_display_power.h | 1 +
> >> >> >  1 file changed, 1 insertion(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> >> >> > b/drivers/gpu/drm/i915/display/intel_display_power.h
> >> >> > index be1a87bde0c9..0ba268e566b0 100644
> >> >> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> >> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> >> >> > @@ -16,6 +16,7 @@ enum port;
> >> >> >  struct drm_i915_private;
> >> >> >  struct i915_power_well;
> >> >> >  struct intel_encoder;
> >> >> > +struct seq_file;
> >> >> >
> >> >> >  /*
> >> >> >   * Keep the pipe, transcoder, port (DDI_LANES,DDI_IO,AUX)
> >> >> > domain instances
> >> >>
> >> >> --
> >> >> Jani Nikula, Intel Open Source Graphics Center
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915/display: Add forward declaration for struct seq_file

[Borah, Chaitanya Kumar]

Hello Jani,

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, June 26, 2023 8:05 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma ; Murthy, Arun R
> 
> Subject: RE: [PATCH] drm/i915/display: Add forward declaration for struct
> seq_file
> 
> On Mon, 26 Jun 2023, "Borah, Chaitanya Kumar"
>  wrote:
> > Hello Jani,
> >
> >> -Original Message-
> >> From: Jani Nikula 
> >> Sent: Monday, June 26, 2023 5:37 PM
> >> To: Borah, Chaitanya Kumar ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Shankar, Uma ; Murthy, Arun R
> >> ; Borah, Chaitanya Kumar
> >> 
> >> Subject: Re: [PATCH] drm/i915/display: Add forward declaration for
> >> struct seq_file
> >>
> >> On Mon, 26 Jun 2023, Chaitanya Kumar Borah
> >>  wrote:
> >> > With change [1], visibility of struct seq_file is lost in
> >> > intel_display_power.h leading to build errors. Add forward
> >> > declaration.
> >> >
> >> > [1] ef104443bffa ("procfs: consolidate arch_report_meminfo
> >> > declaration")
> >> >
> >> > v2: Use forward declaration instead of headerfile inclusion [Jani]
> >> >
> >> > Signed-off-by: Chaitanya Kumar Borah
> >> > 
> >>
> >> Hey, thanks for the patch, this would've been fine, but looks like
> >> Imre just pushed commit f4fab137dd2b ("drm/i915: Add missing forward
> >> declarations/includes to display power headers") which adds the
> >> forward declaration among other things.
> >>
> >> Sorry for the trouble.
> >>
> >
> > No problem, Thank you for the info.
> >
> > Sorry for my ignorance but will this patch eventually find its way to
> > linux-next or do we need to do something special here?
> 
> It'll show up in linux-next once -rc1 is out. But I'm not sure that's the
> *question* you want the answer to, really.
> 

If I understand correctly, the patch will get merged with linux-next
along with the release of 6.4-rc1.

The pertinent question is when will linux-next builds be fixed?
We are missing out on regression tracking because of the build failures.

Regards

Chaitanya

> BR,
> Jani.
> 
> 
> >
> > Regards
> >
> > Chaitanya
> >
> >> BR,
> >> Jani.
> >>
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_display_power.h | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> >> > b/drivers/gpu/drm/i915/display/intel_display_power.h
> >> > index be1a87bde0c9..0ba268e566b0 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> >> > @@ -16,6 +16,7 @@ enum port;
> >> >  struct drm_i915_private;
> >> >  struct i915_power_well;
> >> >  struct intel_encoder;
> >> > +struct seq_file;
> >> >
> >> >  /*
> >> >   * Keep the pipe, transcoder, port (DDI_LANES,DDI_IO,AUX) domain
> >> > instances
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915/display: Add forward declaration for struct seq_file

[Borah, Chaitanya Kumar]

Hello Jani,

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, June 26, 2023 5:37 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma ; Murthy, Arun R
> ; Borah, Chaitanya Kumar
> 
> Subject: Re: [PATCH] drm/i915/display: Add forward declaration for struct
> seq_file
> 
> On Mon, 26 Jun 2023, Chaitanya Kumar Borah
>  wrote:
> > With change [1], visibility of struct seq_file is lost in
> > intel_display_power.h leading to build errors. Add forward
> > declaration.
> >
> > [1] ef104443bffa ("procfs: consolidate arch_report_meminfo
> > declaration")
> >
> > v2: Use forward declaration instead of headerfile inclusion [Jani]
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> 
> Hey, thanks for the patch, this would've been fine, but looks like Imre just
> pushed commit f4fab137dd2b ("drm/i915: Add missing forward
> declarations/includes to display power headers") which adds the forward
> declaration among other things.
> 
> Sorry for the trouble.
> 

No problem, Thank you for the info.

Sorry for my ignorance but will this patch eventually find its way to 
linux-next or do we need to do something special here?

Regards

Chaitanya

> BR,
> Jani.
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_power.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> > b/drivers/gpu/drm/i915/display/intel_display_power.h
> > index be1a87bde0c9..0ba268e566b0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> > @@ -16,6 +16,7 @@ enum port;
> >  struct drm_i915_private;
> >  struct i915_power_well;
> >  struct intel_encoder;
> > +struct seq_file;
> >
> >  /*
> >   * Keep the pipe, transcoder, port (DDI_LANES,DDI_IO,AUX) domain
> > instances
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915/display: Add header file for struct seq_file

[Borah, Chaitanya Kumar]

Hello Jani,

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, June 26, 2023 12:25 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma ; Murthy, Arun R
> ; Borah, Chaitanya Kumar
> 
> Subject: Re: [PATCH] drm/i915/display: Add header file for struct seq_file
> 
> On Mon, 26 Jun 2023, Chaitanya Kumar Borah
>  wrote:
> > With change [1], visibility of struct seq_file is lost in
> > intel_display_power.h leading to build errors. Add header file
> > explicitly to restore visibility.
> >
> > [1] ef104443bffa ("procfs: consolidate arch_report_meminfo
> > declaration")
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_power.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> > b/drivers/gpu/drm/i915/display/intel_display_power.h
> > index be1a87bde0c9..888993079a7b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> > @@ -6,6 +6,8 @@
> >  #ifndef __INTEL_DISPLAY_POWER_H__
> >  #define __INTEL_DISPLAY_POWER_H__
> >
> > +#include 
> > +
> 
> Always prefer a forward declaration over an include when it's sufficient.
> 

Thank you for your comment, I have sent out the v2 of the patch with forward 
declaration.

Is there a path for this patch to get merged into linux-next?

Regards

Chaitanya

> BR,
> Jani.
> 
> 
> >  #include "intel_wakeref.h"
> >
> >  enum aux_ch;
> 
> --
> Jani Nikula, Intel Open Source Graphics Center