RE: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line count maximums are 63

[Shankar, Uma]

> -Original Message-
> From: Hogander, Jouni 
> Sent: Friday, May 17, 2024 1:02 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line
> count maximums are 63
> 
> On Fri, 2024-05-17 at 06:28 +, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Jouni Högander
> > > Sent: Friday, May 3, 2024 11:36 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Hogander, Jouni 
> > > Subject: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time
> > > line count maximums are 63
> > >
> > > On LunarLake maximum for IO and Fast Wake times are 63. Take this
> > > into account in calculation and when writing the IO Wake lines.
> > >
> > > Bspec: 69885, 70294
> > >
> > > Signed-off-by: Jouni Högander 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_psr.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index f5b5a9ae..678987bbe168 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1364,8 +1364,9 @@ static bool _compute_alpm_params(struct
> > > intel_dp *intel_dp,
> > > fast_wake_time = precharge + preamble + phy_wake +
> > > tfw_exit_latency;
> > >
> > > -   if (DISPLAY_VER(i915) >= 12)
> > > -   /* TODO: Check how we can use ALPM_CTL fast wake
> > > extended field */
> > > +   if (DISPLAY_VER(i915) >= 20)
> > > +   max_wake_lines = 63;
> >
> > As per spec, hardware will add 5 extra lines to the programmed value.
> > For prior platforms it was set to 12 as 7 (3bits) + 5. I guess we
> > should make this consistent.
> 
> Thank you Uma for pointing this out. I have fixed this and the typo you 
> mentioned
> on patch 3. Please recheck.

Hi Jouni, 
Looks good, RB'ed now. You can go ahead for merge (seems some unrelated CI 
failures are there).

Regards,
Uma Shankar

> BR,
> 
> Jouni Högander
> >
> > Regards,
> > Uma Shankar
> >
> > > +   else if (DISPLAY_VER(i915) >= 12)
> > > max_wake_lines = 12;
> > > else
> > > max_wake_lines = 8;
> > > --
> > > 2.34.1
> >

RE: [PATCH v2 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line count maximums are 68

[Shankar, Uma]

> -Original Message-
> From: Hogander, Jouni 
> Sent: Friday, May 17, 2024 1:00 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Hogander, Jouni
> 
> Subject: [PATCH v2 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line
> count maximums are 68
> 
> On LunarLake maximum for IO and Fast Wake time line counts are 68: 6 bits +
> 5 lines added by the HW. Take this into account in calculation and when 
> writing
> the IO Wake lines.
> 
> v2: maximum line count is 68 (6 bits + 5 lines added by HW)

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index df0d14a5023f..f5d3eb776833 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1421,8 +1421,9 @@ static bool _compute_alpm_params(struct intel_dp
> *intel_dp,
>   fast_wake_time = precharge + preamble + phy_wake +
>   tfw_exit_latency;
> 
> - if (DISPLAY_VER(i915) >= 12)
> - /* TODO: Check how we can use ALPM_CTL fast wake extended
> field */
> + if (DISPLAY_VER(i915) >= 20)
> + max_wake_lines = 68;
> + else if (DISPLAY_VER(i915) >= 12)
>   max_wake_lines = 12;
>   else
>   max_wake_lines = 8;
> --
> 2.34.1

RE: [PATCH 3/3] drm/i915/psr: PSR2_CTL[Block Count Number] no needed for LunarLake

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jouni
> Högander
> Sent: Friday, May 3, 2024 11:36 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hogander, Jouni 
> Subject: [PATCH 3/3] drm/i915/psr: PSR2_CTL[Block Count Number] no needed
> for LunarLake

Nit: s/no/not

Looks Good to me.
Reviewed-by: Uma Shankar 

> 
> PSR2_CTL[Block Count Number] is not used by LunarLake do not configure it.
> 
> Bspec: 69885
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 4d67a384e149..5ebfe4244d51 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -869,7 +869,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> 
>   val |= intel_psr2_get_tp_time(intel_dp);
> 
> - if (DISPLAY_VER(dev_priv) >= 12) {
> + if (DISPLAY_VER(dev_priv) >= 12 && DISPLAY_VER(dev_priv) < 20) {
>   if (psr2_block_count(intel_dp) > 2)
>   val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_3;
>   else
> --
> 2.34.1

RE: [PATCH 2/3] drm/i915/psr: LunarLake PSR2_CTL[IO Wake Lines] is 6 bits wide

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jouni
> Högander
> Sent: Friday, May 3, 2024 11:36 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hogander, Jouni 
> Subject: [PATCH 2/3] drm/i915/psr: LunarLake PSR2_CTL[IO Wake Lines] is 6 bits
> wide
> 
> On LunarLake  PSR2_CTL[IO Wake Lines] contains now bit 13:18. Take this into
> account when enabling PSR2_CTL.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Bspec: 69885
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c  | 2 ++
>  drivers/gpu/drm/i915/display/intel_psr_regs.h | 4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 678987bbe168..4d67a384e149 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -900,6 +900,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> 
>   tmp = map[psr->alpm_parameters.fast_wake_lines -
> TGL_EDP_PSR2_FAST_WAKE_MIN_LINES];
>   val |= TGL_EDP_PSR2_FAST_WAKE(tmp +
> TGL_EDP_PSR2_FAST_WAKE_MIN_LINES);
> + } else if (DISPLAY_VER(dev_priv) >= 20) {
> + val |=
> +LNL_EDP_PSR2_IO_BUFFER_WAKE(psr->alpm_parameters.io_wake_lines);
>   } else if (DISPLAY_VER(dev_priv) >= 12) {
>   val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(psr-
> >alpm_parameters.io_wake_lines);
>   val |= TGL_EDP_PSR2_FAST_WAKE(psr-
> >alpm_parameters.fast_wake_lines);
> diff --git a/drivers/gpu/drm/i915/display/intel_psr_regs.h
> b/drivers/gpu/drm/i915/display/intel_psr_regs.h
> index ebc22999572c..68381bbf462e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_psr_regs.h
> @@ -172,6 +172,10 @@
>  #define   TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES  5
>  #define   TGL_EDP_PSR2_IO_BUFFER_WAKE(lines)
>   REG_FIELD_PREP(TGL_EDP_PSR2_IO_BUFFER_WAKE_MASK, \
>  (lines) -
> TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES)
> +#define   LNL_EDP_PSR2_IO_BUFFER_WAKE_MASK   REG_GENMASK(18, 13)
> +#define   LNL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES  5
> +#define   LNL_EDP_PSR2_IO_BUFFER_WAKE(lines)
>   REG_FIELD_PREP(LNL_EDP_PSR2_IO_BUFFER_WAKE_MASK, \
> +(lines) -
> LNL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES)
>  #define   EDP_PSR2_FAST_WAKE_MASKREG_GENMASK(12, 11)
>  #define   EDP_PSR2_FAST_WAKE_MAX_LINES   8
>  #define   EDP_PSR2_FAST_WAKE(lines)
>   REG_FIELD_PREP(EDP_PSR2_FAST_WAKE_MASK, \
> --
> 2.34.1

RE: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line count maximums are 63

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jouni
> Högander
> Sent: Friday, May 3, 2024 11:36 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Hogander, Jouni 
> Subject: [PATCH 1/3] drm/i915/psr: LunarLake IO and Fast Wake time line count
> maximums are 63
> 
> On LunarLake maximum for IO and Fast Wake times are 63. Take this into
> account in calculation and when writing the IO Wake lines.
> 
> Bspec: 69885, 70294
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index f5b5a9ae..678987bbe168 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1364,8 +1364,9 @@ static bool _compute_alpm_params(struct intel_dp
> *intel_dp,
>   fast_wake_time = precharge + preamble + phy_wake +
>   tfw_exit_latency;
> 
> - if (DISPLAY_VER(i915) >= 12)
> - /* TODO: Check how we can use ALPM_CTL fast wake extended
> field */
> + if (DISPLAY_VER(i915) >= 20)
> + max_wake_lines = 63;

As per spec, hardware will add 5 extra lines to the programmed value.
For prior platforms it was set to 12 as 7 (3bits) + 5. I guess we should make 
this
consistent.

Regards,
Uma Shankar

> + else if (DISPLAY_VER(i915) >= 12)
>   max_wake_lines = 12;
>   else
>   max_wake_lines = 8;
> --
> 2.34.1

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

[Shankar, Uma]

> -Original Message-
> From: Shankar, Uma 
> Sent: Thursday, May 9, 2024 11:05 AM
> 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: [v4] 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)
> 
> v4: Updated the bit naming, fixed redundant if statement

Pushed to drm-intel-next. Thanks for the reviews.

Regards,
Uma Shankar

> Signed-off-by: Uma Shankar 
> Reviewed-by: Chaitanya Kumar Borah 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c  | 15 +++
>  drivers/gpu/drm/i915/display/intel_audio_regs.h |  3 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index ed81e1466c4b..adde87900557 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -183,6 +183,15 @@ 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) {
> + return (DISPLAY_VER(i915) == 20 || IS_BATTLEMAGE(i915)); }
> +
>  /* 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 +424,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,
> DACBE_DISABLE_MIN_HBLANK_FIX,
> +0);
> +
>   mutex_unlock(>display.audio.mutex);
>  }
> 
> @@ -540,6 +552,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,
> +DACBE_DISABLE_MIN_HBLANK_FIX);
> +
>   /* 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..4c31844d21df 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  DACBE_DISABLE_MIN_HBLANK_FIXREG_BIT(18)
> +
>  #endif /* __INTEL_AUDIO_REGS_H__ */
> --
> 2.42.0

RE: [PATCH 0/7] Enable Aux Based EDP HDR

[Shankar, Uma]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Tuesday, May 7, 2024 9:34 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Shankar, Uma
> ; Nautiyal, Ankit K ;
> Murthy, Arun R ; Kandpal, Suraj
> 
> Subject: [PATCH 0/7] Enable Aux Based EDP HDR
> 
> This series enables Aux based EDP HDR and backlight controls.
> The DPCD written to are intel proprietary and are filled based on the specs 
> that
> were provided to TCON vendors.

Merged to drm-intel-next.  Thanks for the patches and reviews.

Regards,
Uma Shankar

> Signed-off-by: Suraj Kandpal 
> 
> Suraj Kandpal (7):
>   drm/i915/dp: Make has_gamut_metadata_dip() non static
>   drm/i915/dp: Rename intel struct inside intel_panel
>   drm/i915/dp: Add TCON HDR capability checks
>   drm/i915/dp: Fix Register bit naming
>   drm/i915/dp: Drop comments on EDP HDR DPCD registers
>   drm/i915/dp: Enable AUX based backlight for HDR
>   drm/i915/dp: Write panel override luminance values
> 
>  .../drm/i915/display/intel_display_types.h|   7 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   |   6 +-
>  drivers/gpu/drm/i915/display/intel_dp.h   |   1 +
>  .../drm/i915/display/intel_dp_aux_backlight.c | 149 +++---
>  4 files changed, 140 insertions(+), 23 deletions(-)
> 
> --
> 2.43.2

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

[Shankar, Uma]

> -Original Message-
> From: Jani Nikula 
> Sent: Tuesday, May 7, 2024 4:12 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> intel...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Roper,
> Matthew D ; Shankar, Uma
> 
> Subject: Re: [v3] drm/i915: Implement Audio WA_14020863754
> 
> On Mon, 06 May 2024, Uma Shankar  wrote:
> > 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))
> 
> Why do we need to check for both display version and the platform?
> Especially weird that it's || and not &&.

Hi Jani,
WA is applicable for display version 20 and any derivative, but it was also
needed on BMG (which is based out of MTL i.e ver14).
Hence added this condition along with a ||.

> > +   return true;
> > +
> > +   return false;
> 
> The whole function is just "return ver == 20 || is_bmg", there's no need to 
> have
> the if and two different return locations.

Yeah right, will drop the redundant if.

Regards,
Uma Shankar

> 
> BR,
> Jani.
> 
> 
> > +}
> > +
> >  /* 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(>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_SPARE18  REG_BIT(18)
> > +
> >  #endif /* __INTEL_AUDIO_REGS_H__ */
> 
> --
> Jani Nikula, Intel

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

[Shankar, Uma]

> -Original Message-
> From: Borah, Chaitanya Kumar 
> Sent: Tuesday, May 7, 2024 1:48 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> intel...@lists.freedesktop.org
> Cc: jani.nik...@linux.intel.com; Roper, Matthew D 
> Subject: RE: [v3] drm/i915: Implement Audio WA_14020863754
> 
> 
> 
> > -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(>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_SPARE18  REG_BIT(18)
> 
> Nit. This bit seems to have a name now (Bspec-69036). Otherwise, LGTM.

Yeah this got renamed now, will update the name.
Thanks for the review.

Regards,
Uma Shankar
 
> Reviewed-by: Chaitanya Kumar Borah 

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

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

[Shankar, Uma]

> -Original Message-
> From: Borah, Chaitanya Kumar 
> Sent: Tuesday, April 30, 2024 2:48 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.

Based on internal discussions with hardware team and validation on various 
platforms,
Maud/Naud programming can be dropped. Looks ok to me.

Reviewed-by: Uma Shankar 

> 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 | 113 ++---
>  1 file changed, 8 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..ed81e1466c4b 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 _aud_n_m[i];
> - }
> -
> - return NULL;
> -}
> -
>  static const struct {
>   int clock;
>   u32 config;
> @@ -387,47 +320,17 @@ 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_c

RE: [PATCH v5 1/4] drm/i915/display: add support for DMC wakelocks

[Shankar, Uma]

> -Original Message-
> From: Luca Coelho 
> Sent: Friday, April 12, 2024 5:57 PM
> To: Shankar, Uma ; Coelho, Luciano
> ; intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula, 
> Jani
> 
> Subject: Re: [PATCH v5 1/4] drm/i915/display: add support for DMC wakelocks
> 
> On Fri, 2024-04-12 at 10:30 +, Shankar, Uma wrote:
> >
> > > -Original Message-
> > > From: Coelho, Luciano 
> > > Sent: Friday, April 12, 2024 3:12 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: intel...@lists.freedesktop.org; Shankar, Uma
> > > ; ville.syrj...@linux.intel.com; Nikula, Jani
> > > 
> > > Subject: [PATCH v5 1/4] drm/i915/display: add support for DMC
> > > wakelocks
> > >
> > > In order to reduce the DC5->DC2 restore time, wakelocks have been
> > > introduced in DMC so the driver can tell it when registers and other
> > > memory areas are going to be accessed and keep their respective blocks
> awake.
> > >
> > > Implement this in the driver by adding the concept of DMC wakelocks.
> > > When the driver needs to access memory which lies inside pre-defined
> > > ranges, it will tell DMC to set the wakelock, access the memory,
> > > then wait for a while and clear the wakelock.
> > >
> > > The wakelock state is protected in the driver with spinlocks to
> > > prevent concurrency issues.
> >
> > Hi Luca,
> > Seems you missed to add the version history.
> 
> I've been sending the version history in the cover letter, because I don't 
> think it
> adds any information after it gets to the mainline kernel.  The history is 
> lost
> anyway, so the mailing list is a better place to store it (it's unique and 
> meaningful
> there).

Its matter of preference, but being part of the patch's commit message it stays 
with it
and can be checked with a git show. Cover letter details gets lost though as it 
doesn't
end up in the tree.

> Bur as I said to someone else before, I can add it to the commit message if 
> you
> think that it's needed.

Not needed Luca, it was a simple nitpick . You can skip that.

> >
> > Anyways, changes look good to me.
> > Reviewed-by: Uma Shankar 
> 
> Thanks a lot!
> 
> Though you didn't review patch 3/4, the one about the module parameter.
> Was that intentional or did you just miss it?

I think I have reviewed and RB'ed it. The entire series is RB'ed now.

Regards,
Uma Shankar

> --
> Cheers,
> Luca.

RE: [PATCH v5 1/4] drm/i915/display: add support for DMC wakelocks

[Shankar, Uma]

> -Original Message-
> From: Coelho, Luciano 
> Sent: Friday, April 12, 2024 3:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani 
> Subject: [PATCH v5 1/4] drm/i915/display: add support for DMC wakelocks
> 
> In order to reduce the DC5->DC2 restore time, wakelocks have been introduced
> in DMC so the driver can tell it when registers and other memory areas are 
> going
> to be accessed and keep their respective blocks awake.
> 
> Implement this in the driver by adding the concept of DMC wakelocks.
> When the driver needs to access memory which lies inside pre-defined ranges, 
> it
> will tell DMC to set the wakelock, access the memory, then wait for a while 
> and
> clear the wakelock.
> 
> The wakelock state is protected in the driver with spinlocks to prevent
> concurrency issues.

Hi Luca,
Seems you missed to add the version history.

Anyways, changes look good to me.
Reviewed-by: Uma Shankar 

Regards,
Uma Shankar

> BSpec: 71583
> Signed-off-by: Luca Coelho 
> ---
>  Documentation/gpu/i915.rst|   9 +
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_de.h   |  97 +++-
>  .../gpu/drm/i915/display/intel_display_core.h |   2 +
>  drivers/gpu/drm/i915/display/intel_dmc_regs.h |   6 +
>  drivers/gpu/drm/i915/display/intel_dmc_wl.c   | 234 ++
>  drivers/gpu/drm/i915/display/intel_dmc_wl.h   |  31 +++
>  drivers/gpu/drm/xe/Makefile   |   1 +
>  8 files changed, 373 insertions(+), 8 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_dmc_wl.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dmc_wl.h
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index
> 0ca1550fd9dc..17261ba18313 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -204,6 +204,15 @@ DMC Firmware Support  .. kernel-doc::
> drivers/gpu/drm/i915/display/intel_dmc.c
> :internal:
> 
> +DMC wakelock support
> +
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c
> +   :doc: DMC wakelock support
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c
> +   :internal:
> +
>  Video BIOS Table (VBT)
>  --
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index af9e871daf1d..7cad944b825c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -266,6 +266,7 @@ i915-y += \
>   display/intel_display_rps.o \
>   display/intel_display_wa.o \
>   display/intel_dmc.o \
> + display/intel_dmc_wl.o \
>   display/intel_dpio_phy.o \
>   display/intel_dpll.o \
>   display/intel_dpll_mgr.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_de.h
> b/drivers/gpu/drm/i915/display/intel_de.h
> index ba7a1c6ebc2a..0a0fba81e7af 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.h
> +++ b/drivers/gpu/drm/i915/display/intel_de.h
> @@ -13,52 +13,125 @@
>  static inline u32
>  intel_de_read(struct drm_i915_private *i915, i915_reg_t reg)  {
> - return intel_uncore_read(>uncore, reg);
> + u32 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read(>uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
>  }
> 
>  static inline u8
>  intel_de_read8(struct drm_i915_private *i915, i915_reg_t reg)  {
> - return intel_uncore_read8(>uncore, reg);
> + u8 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read8(>uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
>  }
> 
>  static inline u64
>  intel_de_read64_2x32(struct drm_i915_private *i915,
>i915_reg_t lower_reg, i915_reg_t upper_reg)  {
> - return intel_uncore_read64_2x32(>uncore, lower_reg,
> upper_reg);
> + u64 val;
> +
> + intel_dmc_wl_get(i915, lower_reg);
> + intel_dmc_wl_get(i915, upper_reg);
> +
> + val = intel_uncore_read64_2x32(>uncore, lower_reg, upper_reg);
> +
> + intel_dmc_wl_put(i915, upper_reg);
> + intel_dmc_wl_put(i915, lower_reg);
> +
> + return val;
>  }
> 
>  static inline void
>  intel_de_posting_read(struct drm_i915_private *i915, i915_reg_t reg)  {
> + intel_dmc_wl_get(i915, reg);
> +
>   intel_uncore_posting_read(>uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
>  }
> 
>  static inline void
>  intel_de_write(struct drm_i915_private *i915, i915_reg_t reg, u32 val

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

[Shankar, Uma]

> -Original Message-
> From: Roper, Matthew D 
> Sent: Friday, April 12, 2024 4:07 AM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org; Borah,
> Chaitanya Kumar ;
> jani.nik...@linux.intel.com
> Subject: Re: [v2] drm/i915: Implement Audio WA_14020863754
> 
> On Wed, Apr 10, 2024 at 07:20:46PM +0530, Uma Shankar wrote:
> > 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)
> >
> > Signed-off-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_audio.c  | 14 ++
> >  drivers/gpu/drm/i915/display/intel_audio_regs.h |  3 +++
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > b/drivers/gpu/drm/i915/display/intel_audio.c
> > index 07e0c73204f3..61df5115c970 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > @@ -512,6 +512,13 @@ 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);
> >
> > +   /*
> > +* WA_14020863754: Implement Audio Workaround
> > +* Corner case with Min Hblank Fix can cause audio hang
> > +*/
> > +   if (DISPLAY_VER(i915) >= 20)
> 
> The workaround is currently listed as applying to both Xe2_LPD (20.00) and
> Xe2_HPD (14.01).  So we should match on those precise IP versions for now.
> Future platforms and/or refreshes may or may not need this workaround and we
> don't want to just assume the workaround will carry forward forever, so the
> condition may get updated further as new platforms/IP versions are added to 
> the
> driver.

Hi Matt,
Yes, agree to limit till platforms where we have visibility.

Should I just keep it for LNL and add BMG later once the PE changes get merged 
and the
macros become available?
Also, will add the helper as you suggested.

Regards,
Uma Shankar

> 
> Matt
> 
> > +   intel_de_rmw(i915, AUD_CHICKENBIT_REG3,
> CHICKEN3_SPARE18, 0);
> > +
> > mutex_unlock(>display.audio.mutex);
> >  }
> >
> > @@ -637,6 +644,13 @@ 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);
> >
> > +   /*
> > +* WA_14020863754: Implement Audio Workaround
> > +* Corner case with Min Hblank Fix can cause audio hang
> > +*/
> > +   if (DISPLAY_VER(i915) >= 20)
> > +   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 616e7b1275c4..6f8d33299ecd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > @@ -148,4 +148,7 @@
> >  #define HBLANK_START_COUNT_96  4
> >  #define HBLANK_START_COUNT_128 5
> >
> > +#define AUD_CHICKENBIT_REG3_MMIO(0x65F1C)
> > +#define  CHICKEN3_SPARE18  REG_BIT(18)
> > +
> >  #endif /* __INTEL_AUDIO_REGS_H__ */
> > --
> > 2.42.0
> >
> 
> --
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation

RE: [PATCH v4 4/4] drm/i915/display: tie DMC wakelock to DC5/6 state transitions

[Shankar, Uma]

> -Original Message-
> From: Coelho, Luciano 
> Sent: Thursday, April 4, 2024 5:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani 
> Subject: [PATCH v4 4/4] drm/i915/display: tie DMC wakelock to DC5/6 state
> transitions
> 
> We only need DMC wakelocks when we allow DC5 and DC6 states.  Add the calls
> to enable and disable DMC wakelock accordingly.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Luca Coelho 
> ---
>  drivers/gpu/drm/i915/display/intel_display_power_well.c | 7 +++
>  drivers/gpu/drm/i915/display/intel_dmc.c| 4 
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> index e4de40228997..7f4b7602cf02 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> @@ -17,6 +17,7 @@
>  #include "intel_dkl_phy.h"
>  #include "intel_dkl_phy_regs.h"
>  #include "intel_dmc.h"
> +#include "intel_dmc_wl.h"
>  #include "intel_dp_aux_regs.h"
>  #include "intel_dpio_phy.h"
>  #include "intel_dpll.h"
> @@ -821,6 +822,8 @@ void gen9_enable_dc5(struct drm_i915_private
> *dev_priv)
>   intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
>0, SKL_SELECT_ALTERNATE_DC_EXIT);
> 
> + intel_dmc_wl_enable(dev_priv);
> +
>   gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC5);  }
> 
> @@ -850,6 +853,8 @@ void skl_enable_dc6(struct drm_i915_private *dev_priv)
>   intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
>0, SKL_SELECT_ALTERNATE_DC_EXIT);
> 
> + intel_dmc_wl_enable(dev_priv);
> +
>   gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);  }
> 
> @@ -970,6 +975,8 @@ void gen9_disable_dc_states(struct drm_i915_private
> *dev_priv)
>   if (!HAS_DISPLAY(dev_priv))
>   return;
> 
> + intel_dmc_wl_disable(dev_priv);
> +
>   intel_cdclk_get_cdclk(dev_priv, _config);
>   /* Can't read out voltage_level so can't use intel_cdclk_changed() */
>   drm_WARN_ON(_priv->drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 3fa851b5c7a6..b20cc018b9a8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -550,6 +550,8 @@ void intel_dmc_disable_program(struct
> drm_i915_private *i915)
>   pipedmc_clock_gating_wa(i915, true);
>   disable_all_event_handlers(i915);
>   pipedmc_clock_gating_wa(i915, false);
> +
> + intel_dmc_wl_disable(i915);
>  }
> 
>  void assert_dmc_loaded(struct drm_i915_private *i915) @@ -1079,6 +1081,8
> @@ void intel_dmc_suspend(struct drm_i915_private *i915)
>   if (dmc)
>   flush_work(>work);
> 
> + intel_dmc_wl_disable(i915);
> +
>   /* Drop the reference held in case DMC isn't loaded. */
>   if (!intel_dmc_has_payload(i915))
>   intel_dmc_runtime_pm_put(i915);
> --
> 2.39.2

RE: [PATCH v4 2/4] drm/i915/display: don't allow DMC wakelock on older hardware

[Shankar, Uma]

> -Original Message-
> From: Coelho, Luciano 
> Sent: Thursday, April 4, 2024 5:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani 
> Subject: [PATCH v4 2/4] drm/i915/display: don't allow DMC wakelock on older
> hardware
> 
> Only allow running DMC wakelock code if the display version is 20 or greater. 
>  Also
> check if DMC is loaded before enabling.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Luca Coelho 
> ---
>  .../drm/i915/display/intel_display_driver.c   |  1 +
>  drivers/gpu/drm/i915/display/intel_dmc_wl.c   | 26 +++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index 87dd07e0d138..e4015557af6a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -198,6 +198,7 @@ void intel_display_driver_early_probe(struct
> drm_i915_private *i915)
>   intel_dpll_init_clock_hook(i915);
>   intel_init_display_hooks(i915);
>   intel_fdi_init_hook(i915);
> + intel_dmc_wl_init(i915);
>  }
> 
>  /* part #1: call before irq install */
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> index 3d7cf47321c2..065652fc475c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> @@ -6,6 +6,7 @@
>  #include 
> 
>  #include "intel_de.h"
> +#include "intel_dmc.h"
>  #include "intel_dmc_regs.h"
>  #include "intel_dmc_wl.h"
> 
> @@ -110,10 +111,23 @@ static bool intel_dmc_wl_check_range(u32 address)
>   return wl_needed;
>  }
> 
> +static bool __intel_dmc_wl_supported(struct drm_i915_private *i915) {
> + if (DISPLAY_VER(i915) < 20 ||
> + !intel_dmc_has_payload(i915))
> + return false;
> +
> + return true;
> +}
> +
>  void intel_dmc_wl_init(struct drm_i915_private *i915)  {
>   struct intel_dmc_wl *wl = >display.wl;
> 
> + /* don't call __intel_dmc_wl_supported(), DMC is not loaded yet */
> + if (DISPLAY_VER(i915) < 20)
> + return;
> +
>   INIT_DELAYED_WORK(>work, intel_dmc_wl_work);
>   spin_lock_init(>lock);
>   refcount_set(>refcount, 0);
> @@ -124,6 +138,9 @@ void intel_dmc_wl_enable(struct drm_i915_private
> *i915)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> + if (!__intel_dmc_wl_supported(i915))
> + return;
> +
>   spin_lock_irqsave(>lock, flags);
> 
>   if (wl->enabled)
> @@ -148,6 +165,9 @@ void intel_dmc_wl_disable(struct drm_i915_private
> *i915)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> + if (!__intel_dmc_wl_supported(i915))
> + return;
> +
>   flush_delayed_work(>work);
> 
>   spin_lock_irqsave(>lock, flags);
> @@ -171,6 +191,9 @@ void intel_dmc_wl_get(struct drm_i915_private *i915,
> i915_reg_t reg)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> + if (!__intel_dmc_wl_supported(i915))
> + return;
> +
>   if (!intel_dmc_wl_check_range(reg.reg))
>   return;
> 
> @@ -215,6 +238,9 @@ void intel_dmc_wl_put(struct drm_i915_private *i915,
> i915_reg_t reg)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> + if (!__intel_dmc_wl_supported(i915))
> + return;
> +
>   if (!intel_dmc_wl_check_range(reg.reg))
>   return;
> 
> --
> 2.39.2

RE: [PATCH v4 1/4] drm/i915/display: add support for DMC wakelocks

[Shankar, Uma]

> -Original Message-
> From: Coelho, Luciano 
> Sent: Thursday, April 4, 2024 5:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani 
> Subject: [PATCH v4 1/4] drm/i915/display: add support for DMC wakelocks
> 
> In order to reduce the DC5->DC2 restore time, wakelocks have been introduced
> in DMC so the driver can tell it when registers and other memory areas are 
> going
> to be accessed and keep their respective blocks awake.
> 
> Implement this in the driver by adding the concept of DMC wakelocks.
> When the driver needs to access memory which lies inside pre-defined ranges, 
> it
> will tell DMC to set the wakelock, access the memory, then wait for a while 
> and
> clear the wakelock.
> 
> The wakelock state is protected in the driver with spinlocks to prevent
> concurrency issues.
> 
> BSpec: 71583
> Signed-off-by: Luca Coelho 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_de.h   |  97 ++-
>  .../gpu/drm/i915/display/intel_display_core.h |   2 +
>  drivers/gpu/drm/i915/display/intel_dmc_regs.h |   6 +
>  drivers/gpu/drm/i915/display/intel_dmc_wl.c   | 238 ++
>  drivers/gpu/drm/i915/display/intel_dmc_wl.h   |  31 +++
>  drivers/gpu/drm/xe/Makefile   |   1 +
>  7 files changed, 368 insertions(+), 8 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_dmc_wl.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dmc_wl.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index af9e871daf1d..7cad944b825c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -266,6 +266,7 @@ i915-y += \
>   display/intel_display_rps.o \
>   display/intel_display_wa.o \
>   display/intel_dmc.o \
> + display/intel_dmc_wl.o \
>   display/intel_dpio_phy.o \
>   display/intel_dpll.o \
>   display/intel_dpll_mgr.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_de.h
> b/drivers/gpu/drm/i915/display/intel_de.h
> index ba7a1c6ebc2a..0a0fba81e7af 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.h
> +++ b/drivers/gpu/drm/i915/display/intel_de.h
> @@ -13,52 +13,125 @@
>  static inline u32
>  intel_de_read(struct drm_i915_private *i915, i915_reg_t reg)  {
> - return intel_uncore_read(>uncore, reg);
> + u32 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read(>uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
>  }
> 
>  static inline u8
>  intel_de_read8(struct drm_i915_private *i915, i915_reg_t reg)  {
> - return intel_uncore_read8(>uncore, reg);
> + u8 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read8(>uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
>  }
> 
>  static inline u64
>  intel_de_read64_2x32(struct drm_i915_private *i915,
>i915_reg_t lower_reg, i915_reg_t upper_reg)  {
> - return intel_uncore_read64_2x32(>uncore, lower_reg,
> upper_reg);
> + u64 val;
> +
> + intel_dmc_wl_get(i915, lower_reg);
> + intel_dmc_wl_get(i915, upper_reg);
> +
> + val = intel_uncore_read64_2x32(>uncore, lower_reg, upper_reg);
> +
> + intel_dmc_wl_put(i915, upper_reg);
> + intel_dmc_wl_put(i915, lower_reg);
> +
> + return val;
>  }
> 
>  static inline void
>  intel_de_posting_read(struct drm_i915_private *i915, i915_reg_t reg)  {
> + intel_dmc_wl_get(i915, reg);
> +
>   intel_uncore_posting_read(>uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
>  }
> 
>  static inline void
>  intel_de_write(struct drm_i915_private *i915, i915_reg_t reg, u32 val)  {
> + intel_dmc_wl_get(i915, reg);
> +
>   intel_uncore_write(>uncore, reg, val);
> +
> + intel_dmc_wl_put(i915, reg);
>  }
> 
>  static inline u32
> -intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg, u32 clear, u32 
> set)
> +__intel_de_rmw_nowl(struct drm_i915_private *i915, i915_reg_t reg,
> + u32 clear, u32 set)
>  {
>   return intel_uncore_rmw(>uncore, reg, clear, set);  }
> 
> +static inline u32
> +intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg, u32 clear,
> +u32 set) {
> + u32 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = __intel_de_rmw_nowl(i915, reg, clear, set);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
> +}
> +
> +st

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

[Shankar, Uma]

> -Original Message-
> From: Jani Nikula 
> Sent: Wednesday, April 10, 2024 3:47 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> intel...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Shankar, Uma
> 
> Subject: Re: [PATCH] drm/i915: Implement Audio WA_14020863754
> 
> On Wed, 10 Apr 2024, Uma Shankar  wrote:
> > 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)
> 
> hsw_audio_codec_disable/enable get called on hsw and display ver >= 8, but a 
> lot
> of those platforms have the bit reserved MBZ. I didn't go through all the 
> platforms
> in bspec, but enough to notice this needs some platform check.

Yes Jani, realized it after sending. Will update and re-float.
Thanks for spotting it.

Regards,
Uma Shankar

> BR,
> Jani.
> 
> >
> > Signed-off-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_audio.c  | 12 
> >  drivers/gpu/drm/i915/display/intel_audio_regs.h |  3 +++
> >  2 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > b/drivers/gpu/drm/i915/display/intel_audio.c
> > index 07e0c73204f3..a8e3e515aaa0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > @@ -512,6 +512,12 @@ 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);
> >
> > +   /*
> > +* WA_14020863754: Implement Audio Workaround
> > +* Corner case with Min Hblank Fix can cause audio hang
> > +*/
> > +   intel_de_rmw(i915, AUD_CHICKENBIT_REG3, CHICKEN3_SPARE18, 0);
> > +
> > mutex_unlock(>display.audio.mutex);
> >  }
> >
> > @@ -637,6 +643,12 @@ 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);
> >
> > +   /*
> > +* WA_14020863754: Implement Audio Workaround
> > +* Corner case with Min Hblank Fix can cause audio hang
> > +*/
> > +   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 616e7b1275c4..6f8d33299ecd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h
> > @@ -148,4 +148,7 @@
> >  #define HBLANK_START_COUNT_96  4
> >  #define HBLANK_START_COUNT_128 5
> >
> > +#define AUD_CHICKENBIT_REG3_MMIO(0x65F1C)
> > +#define  CHICKEN3_SPARE18  REG_BIT(18)
> > +
> >  #endif /* __INTEL_AUDIO_REGS_H__ */
> 
> --
> Jani Nikula, Intel

RE: [PATCH 14/22] drm/i915/mst: Reject FEC+MST on ICL

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 14/22] drm/i915/mst: Reject FEC+MST on ICL
> 
> From: Ville Syrjälä 
> 
> ICL supposedly doesn't support FEC on MST. Reject it.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index cbabd1924474..8b8059b6bb21 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1415,7 +1415,8 @@ static bool intel_dp_source_supports_fec(struct
> intel_dp *intel_dp,
>   if (DISPLAY_VER(dev_priv) >= 12)
>   return true;
> 
> - if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A)
> + if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A &&
> + !intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST))
>   return true;
> 
>   return false;
> --
> 2.43.2

RE: [PATCH 13/22] drm/i915/mst: Limit MST+DSC to TGL+

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 13/22] drm/i915/mst: Limit MST+DSC to TGL+
> 
> From: Ville Syrjälä 
> 
> The MST code currently assumes that glk+ alerady supports MST+DSC, which is

Nit: Typo in already 

> incorrect. We need to check for TGL+ actually. ICL does support SST+DSC, but
> supposedly it can't do MST+FEC which will also rule MST+DSC.
> 
> Note that a straight TGL+ check doesn't work here because DSC support can get
> fused out, so we do need to also check 'has_dsc'.

Yeah right.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display_device.h | 1 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index fe4268813786..9b1bce2624b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -47,6 +47,7 @@ struct drm_printer;
>  #define HAS_DPT(i915)(DISPLAY_VER(i915) >= 13)
>  #define HAS_DSB(i915)(DISPLAY_INFO(i915)->has_dsb)
>  #define HAS_DSC(__i915)
>   (DISPLAY_RUNTIME_INFO(__i915)->has_dsc)
> +#define HAS_DSC_MST(__i915)  (DISPLAY_VER(__i915) >= 12 &&
> HAS_DSC(__i915))
>  #define HAS_FBC(i915)(DISPLAY_RUNTIME_INFO(i915)-
> >fbc_mask != 0)
>  #define HAS_FPGA_DBG_UNCLAIMED(i915) (DISPLAY_INFO(i915)-
> >has_fpga_dbg)
>  #define HAS_FW_BLC(i915) (DISPLAY_VER(i915) >= 3)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index a3b0026adb2d..de364ed77c08 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1352,7 +1352,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
>   return 0;
>   }
> 
> - if (DISPLAY_VER(dev_priv) >= 10 &&
> + if (HAS_DSC_MST(dev_priv) &&
>   drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
>   /*
>* TBD pass the connector BPC,
> --
> 2.43.2

RE: [PATCH 12/22] drm/i915: Pass connector to intel_dp_need_bigjoiner()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 12/22] drm/i915: Pass connector to intel_dp_need_bigjoiner()
> 
> From: Ville Syrjälä 
> 
> Pass the connector explicitly to intel_dp_need_bigjoiner() so that it'll 
> actually
> check the correct place for the bigjoiner force flag.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
>  drivers/gpu/drm/i915/display/intel_dp.h |  1 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +++--
>  3 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6fa8fc56a39c..cbabd1924474 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1194,10 +1194,10 @@ intel_dp_mode_valid_downstream(struct
> intel_connector *connector,  }
> 
>  bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> +  struct intel_connector *connector,
>int hdisplay, int clock)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_connector *connector = intel_dp->attached_connector;
> 
>   if (!intel_dp_has_bigjoiner(intel_dp))
>   return false;
> @@ -1241,7 +1241,8 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
>   target_clock = fixed_mode->clock;
>   }
> 
> - if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock)) {
> + if (intel_dp_need_bigjoiner(intel_dp, connector,
> + mode->hdisplay, target_clock)) {
>   bigjoiner = true;
>   max_dotclk *= 2;
>   }
> @@ -2409,7 +2410,7 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,  {
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>   struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> - const struct intel_connector *connector =
> + struct intel_connector *connector =
>   to_intel_connector(conn_state->connector);
>   const struct drm_display_mode *adjusted_mode =
>   _config->hw.adjusted_mode;
> @@ -2422,7 +2423,8 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
>   !intel_dp_supports_fec(intel_dp, connector, pipe_config))
>   return -EINVAL;
> 
> - if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
> + if (intel_dp_need_bigjoiner(intel_dp, connector,
> + adjusted_mode->crtc_hdisplay,
>   adjusted_mode->crtc_clock))
>   pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1, crtc-
> >pipe);
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index d5697b99ac21..cd6969d05fe3 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -150,6 +150,7 @@ u8 intel_dp_dsc_get_slice_count(const struct
> intel_connector *connector,
>   int mode_clock, int mode_hdisplay,
>   bool bigjoiner);
>  bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> +  struct intel_connector *connector,
>int hdisplay, int clock);
> 
>  static inline unsigned int intel_dp_unused_lane_mask(int lane_count) diff 
> --git
> a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 1cf6241a7d53..a3b0026adb2d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -527,7 +527,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>   struct intel_atomic_state *state = to_intel_atomic_state(conn_state-
> >state);
>   struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
>   struct intel_dp *intel_dp = _mst->primary->dp;
> - const struct intel_connector *connector =
> + struct intel_connector *connector =
>   to_intel_connector(conn_state->connector);
>   const struct drm_display_mode *adjusted_mode =
>   _config->hw.adjusted_mode;
> @@ -1342,7 +1342,8 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
>   *status = MODE_CLOCK_HIGH;
>   return 0;
>   }
> - if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock)) {
> + if (intel_dp_need_bigjoiner(intel_dp, intel_connector,
> + mode->hdisplay, target_clock)) {
>   bigjoiner = true;
>   max_dotclk *= 2;
> 
> --
> 2.43.2

RE: [PATCH 11/22] drm/i915/mst: Check intel_dp_joiner_needs_dsc()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 11/22] drm/i915/mst: Check intel_dp_joiner_needs_dsc()
> 
> From: Ville Syrjälä 
> 
> intel_dp_mst_compute_config() is missing the "does the joiner need DSC?" check
> despite claiming to have a lot of other joiner/dsc stuff in there (albeit 
> disabled).
> Replicate the logic from the SST side.
> 
> TODO: refactor all this duplicated code!

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 6da031f9724d..1cf6241a7d53 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -532,7 +532,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>   const struct drm_display_mode *adjusted_mode =
>   _config->hw.adjusted_mode;
>   struct link_config_limits limits;
> - bool dsc_needed;
> + bool dsc_needed, joiner_needs_dsc;
>   int ret = 0;
> 
>   if (pipe_config->fec_enable &&
> @@ -546,7 +546,9 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
>   pipe_config->has_pch_encoder = false;
> 
> - dsc_needed = intel_dp->force_dsc_en ||
> + joiner_needs_dsc = intel_dp_joiner_needs_dsc(dev_priv,
> +pipe_config->bigjoiner_pipes);
> +
> + dsc_needed = joiner_needs_dsc || intel_dp->force_dsc_en ||
>!intel_dp_mst_compute_config_limits(intel_dp,
>connector,
>pipe_config,
> @@ -566,8 +568,8 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> 
>   /* enable compression if the mode doesn't fit available BW */
>   if (dsc_needed) {
> - drm_dbg_kms(_priv->drm, "Try DSC (fallback=%s,
> force=%s)\n",
> - str_yes_no(ret),
> + drm_dbg_kms(_priv->drm, "Try DSC (fallback=%s,
> joiner=%s, force=%s)\n",
> + str_yes_no(ret), str_yes_no(joiner_needs_dsc),
>   str_yes_no(intel_dp->force_dsc_en));
> 
>   if (!intel_dp_mst_dsc_source_support(pipe_config))
> --
> 2.43.2

RE: [PATCH 10/22] drm/i915: Extract intel_dp_joiner_needs_dsc()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 10/22] drm/i915: Extract intel_dp_joiner_needs_dsc()
> 
> From: Ville Syrjälä 
> 
> Pull the "does joiner need DSC?" check into a helper. MST will want to use 
> this too
> at some point.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 26 ++---
>  drivers/gpu/drm/i915/display/intel_dp.h |  1 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  6 +
>  3 files changed, 15 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 402b3b8f6382..6fa8fc56a39c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1302,11 +1302,7 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
>   dsc = dsc_max_compressed_bpp && dsc_slice_count;
>   }
> 
> - /*
> -  * Big joiner configuration needs DSC for TGL which is not true for
> -  * XE_LPD where uncompressed joiner is supported.
> -  */
> - if (DISPLAY_VER(dev_priv) < 13 && bigjoiner && !dsc)
> + if (intel_dp_joiner_needs_dsc(dev_priv, bigjoiner) && !dsc)
>   return MODE_CLOCK_HIGH;
> 
>   if (mode_rate > max_rate && !dsc)
> @@ -2395,6 +2391,16 @@ int intel_dp_config_required_rate(const struct
> intel_crtc_state *crtc_state)
>   return intel_dp_link_required(adjusted_mode->crtc_clock, bpp);  }
> 
> +bool intel_dp_joiner_needs_dsc(struct drm_i915_private *i915, bool
> +use_joiner) {
> + /*
> +  * Pipe joiner needs compression up to display 12 due to bandwidth
> +  * limitation. DG2 onwards pipe joiner can be enabled without
> +  * compression.
> +  */
> + return DISPLAY_VER(i915) < 13 && use_joiner; }
> +
>  static int
>  intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config, @@ -2409,8
> +2415,7 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>   _config->hw.adjusted_mode;
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>   struct link_config_limits limits;
> - bool joiner_needs_dsc = false;
> - bool dsc_needed;
> + bool dsc_needed, joiner_needs_dsc;
>   int ret = 0;
> 
>   if (pipe_config->fec_enable &&
> @@ -2421,12 +2426,7 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
>   adjusted_mode->crtc_clock))
>   pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1, crtc-
> >pipe);
> 
> - /*
> -  * Pipe joiner needs compression up to display 12 due to bandwidth
> -  * limitation. DG2 onwards pipe joiner can be enabled without
> -  * compression.
> -  */
> - joiner_needs_dsc = DISPLAY_VER(i915) < 13 && pipe_config-
> >bigjoiner_pipes;
> + joiner_needs_dsc = intel_dp_joiner_needs_dsc(i915,
> +pipe_config->bigjoiner_pipes);
> 
>   dsc_needed = joiner_needs_dsc || intel_dp->force_dsc_en ||
>!intel_dp_compute_config_limits(intel_dp, pipe_config, 
> diff --
> git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 4a4b39f2748b..d5697b99ac21 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -119,6 +119,7 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
>int bw_overhead);
>  int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
>   int max_dprx_rate, int max_dprx_lanes);
> +bool intel_dp_joiner_needs_dsc(struct drm_i915_private *i915, bool
> +use_joiner);
>  bool intel_dp_has_bigjoiner(struct intel_dp *intel_dp);  bool
> intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
>   const struct drm_connector_state *conn_state); diff 
> --
> git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 1405ab5e3acc..6da031f9724d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1377,11 +1377,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector
> *connector,
>   dsc = dsc_max_compressed_bpp && dsc_slice_count;
>   }
> 
> - /*
> -  * Big joiner configuration needs DSC for TGL which is not true for
> -  * XE_LPD where uncompressed joiner is supported.
> -  */
> - if (DISPLAY_VER(dev_priv) < 13 && bigjoiner && !dsc) {
> + if (intel_dp_joiner_needs_dsc(dev_priv, bigjoiner) && !dsc) {
>   *status = MODE_CLOCK_HIGH;
>   return 0;
>   }
> --
> 2.43.2

RE: [PATCH 00/13] drm/i915: Implemnt vblank sycnhronized mbus joining changes

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 00/13] drm/i915: Implemnt vblank sycnhronized mbus joining
> changes

Nit: Typo in implement and synchronized

> From: Ville Syrjälä 
> 
> Get rid of the full modeset requirement for changing mbus joining. Things got
> quite a bit more complicated than originally envisioned due to the dynamic
> cdclk/mdclk ratio.
> Sadly we have to do a fairly careful dance between the dbuf and cdclk code to
> make sure everything is programmed in the correct sequence.
> 
> Stan did the grunt work, but the sequence vs. cdclk updates was still not 
> right so I
> finished that part.
> I also reorganized the code quite a bit to make the resulting patches more 
> legible.
> And I tossed in more debugs and whatnot so we can actually observe what it's
> doing.
> 
> Quickly smoke tested on tgl and adl, and things seem pretty decent.
> Unfortunately I don't have a LNL on me right now so I haven't fully tested the
> mdclk/cdclk ratio changes on real hw, but I did hack my adl to pretend that 
> the
> ratio changes with cdclk and double checked that the logs look sensible for 
> all the
> combinations of cdclk increase/decrease and mbus join enable/disable.
> So should work (tm) on real hw too.

Reviewed the series and it looks good to me.

This is ready for merge.
Reviewed-by: Uma Shankar 

Regards,
Uma Shankar

> Stanislav Lisovskiy (3):
>   drm/i915: Loop over all active pipes in intel_mbus_dbox_update
>   drm/i915: Use old mbus_join value when increasing CDCLK
>   drm/i915: Implement vblank synchronized MBUS join changes
> 
> Ville Syrjälä (10):
>   drm/i915/cdclk: Fix CDCLK programming order when pipes are active
>   drm/i915/cdclk: Fix voltage_level programming edge case
>   drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacks
>   drm/i915/cdclk: Indicate whether CDCLK change happens during pre or
> post plane update
>   drm/i915: Relocate intel_mbus_dbox_update()
>   drm/i915: Extract intel_dbuf_mbus_join_update()
>   drm/i915: Extract intel_dbuf_mdclk_min_tracker_update()
>   drm/i915: Add debugs for mbus joining and dbuf ratio programming
>   drm/i915: Use a plain old int for the cdclk/mdclk ratio
>   drm/i915: Optimize out redundant dbuf slice updates
> 
>  drivers/gpu/drm/i915/display/intel_cdclk.c   |  85 +++--
>  drivers/gpu/drm/i915/display/intel_cdclk.h   |   8 +-
>  drivers/gpu/drm/i915/display/intel_display.c |   5 +-
>  drivers/gpu/drm/i915/display/skl_watermark.c | 344 ---
>  drivers/gpu/drm/i915/display/skl_watermark.h |   9 +-
>  5 files changed, 271 insertions(+), 180 deletions(-)
> 
> --
> 2.43.2

RE: [PATCH 13/13] drm/i915: Optimize out redundant dbuf slice updates

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 13/13] drm/i915: Optimize out redundant dbuf slice updates
> 
> From: Ville Syrjälä 
> 
> if the new dbuf slices are a superset of the old dbuf slices then we don't 
> have to
> do anything in intel_dbuf_post_plane_update(). Restructure the code to skip 
> such
> redundant dbuf slice updates. The main benefit is slightly less confusing 
> logs.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/skl_watermark.c | 27 +---
>  1 file changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 1b48009efe2b..50ec51065118 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3788,16 +3788,20 @@ void intel_dbuf_pre_plane_update(struct
> intel_atomic_state *state)
>   intel_atomic_get_new_dbuf_state(state);
>   const struct intel_dbuf_state *old_dbuf_state =
>   intel_atomic_get_old_dbuf_state(state);
> + u8 old_slices, new_slices;
> 
> - if (!new_dbuf_state ||
> - new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
> + if (!new_dbuf_state)
> + return;
> +
> + old_slices = old_dbuf_state->enabled_slices;
> + new_slices = old_dbuf_state->enabled_slices |
> +new_dbuf_state->enabled_slices;
> +
> + if (old_slices == new_slices)
>   return;
> 
>   WARN_ON(!new_dbuf_state->base.changed);
> 
> - gen9_dbuf_slices_update(i915,
> - old_dbuf_state->enabled_slices |
> - new_dbuf_state->enabled_slices);
> + gen9_dbuf_slices_update(i915, new_slices);
>  }
> 
>  void intel_dbuf_post_plane_update(struct intel_atomic_state *state) @@ -
> 3807,15 +3811,20 @@ void intel_dbuf_post_plane_update(struct
> intel_atomic_state *state)
>   intel_atomic_get_new_dbuf_state(state);
>   const struct intel_dbuf_state *old_dbuf_state =
>   intel_atomic_get_old_dbuf_state(state);
> + u8 old_slices, new_slices;
> 
> - if (!new_dbuf_state ||
> - new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
> + if (!new_dbuf_state)
> + return;
> +
> + old_slices = old_dbuf_state->enabled_slices | new_dbuf_state-
> >enabled_slices;
> + new_slices = new_dbuf_state->enabled_slices;
> +
> + if (old_slices == new_slices)
>   return;
> 
>   WARN_ON(!new_dbuf_state->base.changed);
> 
> - gen9_dbuf_slices_update(i915,
> - new_dbuf_state->enabled_slices);
> + gen9_dbuf_slices_update(i915, new_slices);
>  }
> 
>  static int skl_watermark_ipc_status_show(struct seq_file *m, void *data)
> --
> 2.43.2

RE: [PATCH 12/13] drm/i915: Use a plain old int for the cdclk/mdclk ratio

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 12/13] drm/i915: Use a plain old int for the cdclk/mdclk ratio
> 
> From: Ville Syrjälä 
> 
> No point in throwing around u8 when we're dealing with just an integer. Use a
> plain old boring 'int'.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c   | 6 +++---
>  drivers/gpu/drm/i915/display/intel_cdclk.h   | 4 ++--
>  drivers/gpu/drm/i915/display/skl_watermark.c | 6 --
> drivers/gpu/drm/i915/display/skl_watermark.h | 6 --
>  4 files changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 66c161d7b485..5cba0d08189b 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1893,8 +1893,8 @@ static u32 xe2lpd_mdclk_source_sel(struct
> drm_i915_private *i915)
>   return MDCLK_SOURCE_SEL_CD2XCLK;
>  }
> 
> -u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> -const struct intel_cdclk_config *cdclk_config)
> +int intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> + const struct intel_cdclk_config *cdclk_config)
>  {
>   if (mdclk_source_is_cdclk_pll(i915))
>   return DIV_ROUND_UP(cdclk_config->vco, cdclk_config->cdclk);
> @@ -3321,7 +3321,7 @@ int intel_modeset_calc_cdclk(struct
> intel_atomic_state *state)
> 
>   if (intel_mdclk_cdclk_ratio(dev_priv, _cdclk_state->actual) !=
>   intel_mdclk_cdclk_ratio(dev_priv, _cdclk_state->actual)) {
> - u8 ratio = intel_mdclk_cdclk_ratio(dev_priv, _cdclk_state-
> >actual);
> + int ratio = intel_mdclk_cdclk_ratio(dev_priv,
> +_cdclk_state->actual);
> 
>   ret = intel_dbuf_state_set_mdclk_cdclk_ratio(state, ratio);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index 5d4faf401774..cfdcdec07a4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -67,8 +67,8 @@ void intel_update_cdclk(struct drm_i915_private
> *dev_priv);
>  u32 intel_read_rawclk(struct drm_i915_private *dev_priv);  bool
> intel_cdclk_clock_changed(const struct intel_cdclk_config *a,
>  const struct intel_cdclk_config *b);
> -u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> -const struct intel_cdclk_config *cdclk_config);
> +int intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> + const struct intel_cdclk_config *cdclk_config);
>  bool intel_cdclk_is_decreasing_later(struct intel_atomic_state *state);  void
> intel_set_cdclk_pre_plane_update(struct intel_atomic_state *state);  void
> intel_set_cdclk_post_plane_update(struct intel_atomic_state *state); diff 
> --git
> a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index ca0f1f89e6d9..1b48009efe2b 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3616,7 +3616,8 @@ static void intel_mbus_dbox_update(struct
> intel_atomic_state *state)
>   }
>  }
> 
> -int intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state, 
> u8
> ratio)
> +int intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state,
> +int ratio)
>  {
>   struct intel_dbuf_state *dbuf_state;
> 
> @@ -3629,7 +3630,8 @@ int intel_dbuf_state_set_mdclk_cdclk_ratio(struct
> intel_atomic_state *state, u8
>   return intel_atomic_lock_global_state(_state->base);
>  }
> 
> -void intel_dbuf_mdclk_cdclk_ratio_update(struct drm_i915_private *i915, u8
> ratio, bool joined_mbus)
> +void intel_dbuf_mdclk_cdclk_ratio_update(struct drm_i915_private *i915,
> +  int ratio, bool joined_mbus)
>  {
>   enum dbuf_slice slice;
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.h
> b/drivers/gpu/drm/i915/display/skl_watermark.h
> index 3323a1d973f9..ef1a008466be 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.h
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.h
> @@ -74,11 +74,13 @@ intel_atomic_get_dbuf_state(struct intel_atomic_state
> *state);
>   to_intel_dbuf_state(intel_atomic_get_new_global_obj_state(state,
> _i915(state->base.dev)->display.dbuf.obj))
> 
>  int intel_dbuf_init(struct drm_i915_private *i915); -int
> intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state, u8
> ratio);
> +int intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state,
> +int ratio);
> 
>  void intel_dbuf_pre_plane_update(struct 

RE: [PATCH 11/13] drm/i915: Implement vblank synchronized MBUS join changes

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Subject: [PATCH 11/13] drm/i915: Implement vblank synchronized MBUS join
> changes
> 
> From: Stanislav Lisovskiy 
> 
> Currently we can't change MBUS join status without doing a modeset, because
> we are lacking mechanism to synchronize those with vblank.
> However then this means that we can't do a fastset, if there is a need to 
> change
> MBUS join state. Fix that by implementing such change.
> We already call correspondent check and update at pre_plane dbuf update, so 
> the
> only thing left is to have a non-modeset version of that.
> If active pipes stay the same then fastset is possible and only MBUS join
> state/ddb allocation updates would be committed.
> 
> The full mbus/cdclk sequence will look as follows:
> 1. disable pipes
> 2. increase cdclk if necessary
>  2.1 reprogram cdclk
>  2.2 update dbuf tracker value
> 3. enable mbus joining if necessary
>  3.1 update mbus_ctl
>  3.2 update dbuf tracker value
> 4. reallocate dbuf for planes on active pipes 5. disable mbus joining if 
> necessary
>  5.1 update dbuf tracker value
>  5.2 update mbus_ctl
> 6. enable pipes
> 7. decrease cdclk if necessary
>   7.1 update dbuf tracker value
>   7.2 reprogram cdclk
> 
> And in order to keep things in sync we need:
> Step 2:
> - mbus_join == old
> - mdclk/cdclk ratio == new
> Step 3:
> - mbus_join == new
> - mdclk/cdclk ratio == old when cdclk is changing in step 7
> - mdclk/cdclk ratio == new when cdclk is changing in step 2 Step 5:
> - mbus_join == new
> - mdclk/cdclk ratio == old when cdclk is changing in step 7
> - mdclk/cdclk ratio == new when cdclk is changing in step 2 Step 7:
> - mbus_join == new
> - mdclk/cdclk ratio == new
> 
> v2: - Removed redundant parentheses(Ville Syrjälä)
> - Constified new_crtc_state in intel_mbus_joined_pipe(Ville Syrjälä)
> - Removed pipe_select variable(Ville Syrjälä)
> [v3: vsyrjala: Correctly sequence vs. cdclk updates,
>properly describe the full sequence,
>  shuffle code around to make the diff more legible,
>  streamline a few things]

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Stanislav Lisovskiy 
> Co-developed-by: Ville Syrjälä 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c   |  11 ++
>  drivers/gpu/drm/i915/display/intel_cdclk.h   |   1 +
>  drivers/gpu/drm/i915/display/intel_display.c |   5 +-
>  drivers/gpu/drm/i915/display/skl_watermark.c | 141 ---
>  drivers/gpu/drm/i915/display/skl_watermark.h |   3 +-
>  5 files changed, 112 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 4024118a7ffb..66c161d7b485 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2576,6 +2576,17 @@ static void intel_cdclk_pcode_post_notify(struct
> intel_atomic_state *state)
>  update_cdclk, update_pipe_count);  }
> 
> +bool intel_cdclk_is_decreasing_later(struct intel_atomic_state *state)
> +{
> + const struct intel_cdclk_state *old_cdclk_state =
> + intel_atomic_get_old_cdclk_state(state);
> + const struct intel_cdclk_state *new_cdclk_state =
> + intel_atomic_get_new_cdclk_state(state);
> +
> + return new_cdclk_state && !new_cdclk_state->disable_pipes &&
> + new_cdclk_state->actual.cdclk < old_cdclk_state->actual.cdclk;
> }
> +
>  /**
>   * intel_set_cdclk_pre_plane_update - Push the CDCLK state to the hardware
>   * @state: intel atomic state
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index 2843fc091086..5d4faf401774 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -69,6 +69,7 @@ bool intel_cdclk_clock_changed(const struct
> intel_cdclk_config *a,
>  const struct intel_cdclk_config *b);
>  u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
>  const struct intel_cdclk_config *cdclk_config);
> +bool intel_cdclk_is_decreasing_later(struct intel_atomic_state *state);
>  void intel_set_cdclk_pre_plane_update(struct intel_atomic_state *state);  
> void
> intel_set_cdclk_post_plane_update(struct intel_atomic_state *state);  void
> intel_cdclk_dump_config(struct drm_i915_private *i915, diff --git
> a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4d6668a5f1ab..023cf4a77e6f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6915,6 +6915,8 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
>   intel_pre_update_crtc(state, 

RE: [PATCH 10/13] drm/i915: Use old mbus_join value when increasing CDCLK

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 10/13] drm/i915: Use old mbus_join value when increasing
> CDCLK
> 
> From: Stanislav Lisovskiy 
> 
> In order to make sure we are not breaking the proper sequence lets to updates

Nit: %s/lets to/lets do

> step by step and don't change MBUS join value during MDCLK/CDCLK
> programming stage.
> MBUS join programming would be taken care by pre/post ddb hooks.
> 
> v2: - Reworded comment about using old mbus_join value in
>   intel_set_cdclk(Ville Syrjälä)

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Stanislav Lisovskiy 
> [v3: vsyrjala: rebase on top of cdclk changes, reword a bit more]
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 98546f384023..4024118a7ffb 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2612,6 +2612,12 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
>old_cdclk_state-
> >actual.voltage_level);
>   }
> 
> + /*
> +  * mbus joining will be changed later by
> +  * intel_dbuf_mbus_{pre,post}_ddb_update()
> +  */
> + cdclk_config.joined_mbus = old_cdclk_state->actual.joined_mbus;
> +
>   drm_WARN_ON(>drm, !new_cdclk_state->base.changed);
> 
>   intel_set_cdclk(i915, _config, new_cdclk_state->pipe,
> --
> 2.43.2

RE: [PATCH 09/13] drm/i915: Add debugs for mbus joining and dbuf ratio programming

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 09/13] drm/i915: Add debugs for mbus joining and dbuf ratio
> programming

Looks Good to me.
Reviewed-by: Uma Shankar 

> From: Ville Syrjälä 
> 
> Add some debugs so that we can actually observe what is actually happening
> during the mbus/dbuf programming steps.
> We can just shove them into fairly low level functions as none of them are 
> called
> during any critical sections/etc.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/skl_watermark.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 7767c5eada36..a118ecf9e532 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3647,6 +3647,9 @@ void intel_dbuf_mdclk_cdclk_ratio_update(struct
> drm_i915_private *i915, u8 ratio
>   if (joined_mbus)
>   ratio *= 2;
> 
> + drm_dbg_kms(>drm, "Updating dbuf ratio to %d (mbus joined:
> %s)\n",
> + ratio, str_yes_no(joined_mbus));
> +
>   for_each_dbuf_slice(i915, slice)
>   intel_de_rmw(i915, DBUF_CTL_S(slice),
>DBUF_MIN_TRACKER_STATE_SERVICE_MASK,
> @@ -3680,10 +3683,16 @@ static void
> intel_dbuf_mdclk_min_tracker_update(struct intel_atomic_state *state  static
> void intel_dbuf_mbus_join_update(struct intel_atomic_state *state)  {
>   struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
>   const struct intel_dbuf_state *new_dbuf_state =
>   intel_atomic_get_new_dbuf_state(state);
>   u32 mbus_ctl;
> 
> + drm_dbg_kms(>drm, "Changing mbus joined: %s -> %s\n",
> + str_yes_no(old_dbuf_state->joined_mbus),
> + str_yes_no(new_dbuf_state->joined_mbus));
> +
>   /*
>* TODO: Implement vblank synchronized MBUS joining changes.
>* Must be properly coordinated with dbuf reprogramming.
> --
> 2.43.2

RE: [PATCH 08/13] drm/i915: Extract intel_dbuf_mdclk_min_tracker_update()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 08/13] drm/i915: Extract
> intel_dbuf_mdclk_min_tracker_update()
> 
> From: Ville Syrjälä 
> 
> Extact the stuff that writes the dbuf/mbus ration stuff into its own 
> function. Will

Nit: Typo in extract and ratio

Looks Good to me.
Reviewed-by: Uma Shankar 

> help with correctly sequencing the operations done during mbus programming.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/skl_watermark.c | 43 
>  1 file changed, 25 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index f7e03078bd43..7767c5eada36 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3653,6 +3653,30 @@ void intel_dbuf_mdclk_cdclk_ratio_update(struct
> drm_i915_private *i915, u8 ratio
>DBUF_MIN_TRACKER_STATE_SERVICE(ratio - 1));  }
> 
> +static void intel_dbuf_mdclk_min_tracker_update(struct
> +intel_atomic_state *state) {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> +
> + if (DISPLAY_VER(i915) >= 20 &&
> + old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state-
> >mdclk_cdclk_ratio) {
> + /*
> +  * For Xe2LPD and beyond, when there is a change in the ratio
> +  * between MDCLK and CDCLK, updates to related registers need
> to
> +  * happen at a specific point in the CDCLK change sequence. In
> +  * that case, we defer to the call to
> +  * intel_dbuf_mdclk_cdclk_ratio_update() to the CDCLK logic.
> +  */
> + return;
> + }
> +
> + intel_dbuf_mdclk_cdclk_ratio_update(i915, new_dbuf_state-
> >mdclk_cdclk_ratio,
> + new_dbuf_state->joined_mbus);
> +}
> +
>  static void intel_dbuf_mbus_join_update(struct intel_atomic_state *state)  {
>   struct drm_i915_private *i915 = to_i915(state->base.dev); @@ -3683,10
> +3707,6 @@ static void intel_dbuf_mbus_join_update(struct intel_atomic_state
> *state)  static void update_mbus_pre_enable(struct intel_atomic_state *state) 
>  {
>   struct drm_i915_private *i915 = to_i915(state->base.dev);
> - const struct intel_dbuf_state *old_dbuf_state =
> - intel_atomic_get_old_dbuf_state(state);
> - const struct intel_dbuf_state *new_dbuf_state =
> - intel_atomic_get_new_dbuf_state(state);
> 
>   if (!HAS_MBUS_JOINING(i915))
>   return;
> @@ -3697,20 +3717,7 @@ static void update_mbus_pre_enable(struct
> intel_atomic_state *state)
>*/
>   intel_dbuf_mbus_join_update(state);
> 
> - if (DISPLAY_VER(i915) >= 20 &&
> - old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state-
> >mdclk_cdclk_ratio) {
> - /*
> -  * For Xe2LPD and beyond, when there is a change in the ratio
> -  * between MDCLK and CDCLK, updates to related registers need
> to
> -  * happen at a specific point in the CDCLK change sequence. In
> -  * that case, we defer to the call to
> -  * intel_dbuf_mdclk_cdclk_ratio_update() to the CDCLK logic.
> -  */
> - return;
> - }
> -
> - intel_dbuf_mdclk_cdclk_ratio_update(i915, new_dbuf_state-
> >mdclk_cdclk_ratio,
> - new_dbuf_state->joined_mbus);
> + intel_dbuf_mdclk_min_tracker_update(state);
>  }
> 
>  void intel_dbuf_pre_plane_update(struct intel_atomic_state *state)
> --
> 2.43.2

RE: [PATCH 07/13] drm/i915: Extract intel_dbuf_mbus_join_update()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 07/13] drm/i915: Extract intel_dbuf_mbus_join_update()
> 
> From: Ville Syrjälä 
> 
> Extact the stuff that writes the joining bits in MBUS_CTL into its own 
> function.
> Will help with correctly sequencing the operations done during mbus
> programming.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/skl_watermark.c | 37 +---
>  1 file changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 6bd3fec0aa56..f7e03078bd43 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3653,21 +3653,12 @@ void intel_dbuf_mdclk_cdclk_ratio_update(struct
> drm_i915_private *i915, u8 ratio
>DBUF_MIN_TRACKER_STATE_SERVICE(ratio - 1));  }
> 
> -/*
> - * Configure MBUS_CTL and all DBUF_CTL_S of each slice to join_mbus state
> before
> - * update the request state of all DBUS slices.
> - */
> -static void update_mbus_pre_enable(struct intel_atomic_state *state)
> +static void intel_dbuf_mbus_join_update(struct intel_atomic_state
> +*state)
>  {
>   struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
>   u32 mbus_ctl;
> - const struct intel_dbuf_state *old_dbuf_state =
> - intel_atomic_get_old_dbuf_state(state);
> - const struct intel_dbuf_state *new_dbuf_state =
> - intel_atomic_get_new_dbuf_state(state);
> -
> - if (!HAS_MBUS_JOINING(i915))
> - return;
> 
>   /*
>* TODO: Implement vblank synchronized MBUS joining changes.
> @@ -3683,6 +3674,28 @@ static void update_mbus_pre_enable(struct
> intel_atomic_state *state)
>   intel_de_rmw(i915, MBUS_CTL,
>MBUS_HASHING_MODE_MASK | MBUS_JOIN |
>MBUS_JOIN_PIPE_SELECT_MASK, mbus_ctl);
> +}
> +
> +/*
> + * Configure MBUS_CTL and all DBUF_CTL_S of each slice to join_mbus
> +state before
> + * update the request state of all DBUS slices.
> + */
> +static void update_mbus_pre_enable(struct intel_atomic_state *state) {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> +
> + if (!HAS_MBUS_JOINING(i915))
> + return;
> +
> + /*
> +  * TODO: Implement vblank synchronized MBUS joining changes.
> +  * Must be properly coordinated with dbuf reprogramming.
> +  */
> + intel_dbuf_mbus_join_update(state);
> 
>   if (DISPLAY_VER(i915) >= 20 &&
>   old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state-
> >mdclk_cdclk_ratio) {
> --
> 2.43.2

RE: [PATCH 06/13] drm/i915: Relocate intel_mbus_dbox_update()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 06/13] drm/i915: Relocate intel_mbus_dbox_update()
> 
> From: Ville Syrjälä 
> 
> intel_mbus_dbox_update() will become static soon. Relocate it into a place 
> that
> avoids having to add a forward declaration for it.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/skl_watermark.c | 166 +--
>  1 file changed, 83 insertions(+), 83 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index f582992592c1..6bd3fec0aa56 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3540,6 +3540,89 @@ int intel_dbuf_init(struct drm_i915_private *i915)
>   return 0;
>  }
> 
> +static bool xelpdp_is_only_pipe_per_dbuf_bank(enum pipe pipe, u8
> +active_pipes) {
> + switch (pipe) {
> + case PIPE_A:
> + return !(active_pipes & BIT(PIPE_D));
> + case PIPE_D:
> + return !(active_pipes & BIT(PIPE_A));
> + case PIPE_B:
> + return !(active_pipes & BIT(PIPE_C));
> + case PIPE_C:
> + return !(active_pipes & BIT(PIPE_B));
> + default: /* to suppress compiler warning */
> + MISSING_CASE(pipe);
> + break;
> + }
> +
> + return false;
> +}
> +
> +void intel_mbus_dbox_update(struct intel_atomic_state *state) {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_dbuf_state *new_dbuf_state, *old_dbuf_state;
> + const struct intel_crtc *crtc;
> + u32 val = 0;
> +
> + if (DISPLAY_VER(i915) < 11)
> + return;
> +
> + new_dbuf_state = intel_atomic_get_new_dbuf_state(state);
> + old_dbuf_state = intel_atomic_get_old_dbuf_state(state);
> + if (!new_dbuf_state ||
> + (new_dbuf_state->joined_mbus == old_dbuf_state->joined_mbus &&
> +  new_dbuf_state->active_pipes == old_dbuf_state->active_pipes))
> + return;
> +
> + if (DISPLAY_VER(i915) >= 14)
> + val |= MBUS_DBOX_I_CREDIT(2);
> +
> + if (DISPLAY_VER(i915) >= 12) {
> + val |= MBUS_DBOX_B2B_TRANSACTIONS_MAX(16);
> + val |= MBUS_DBOX_B2B_TRANSACTIONS_DELAY(1);
> + val |= MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN;
> + }
> +
> + if (DISPLAY_VER(i915) >= 14)
> + val |= new_dbuf_state->joined_mbus ?
> MBUS_DBOX_A_CREDIT(12) :
> +  MBUS_DBOX_A_CREDIT(8);
> + else if (IS_ALDERLAKE_P(i915))
> + /* Wa_22010947358:adl-p */
> + val |= new_dbuf_state->joined_mbus ?
> MBUS_DBOX_A_CREDIT(6) :
> +  MBUS_DBOX_A_CREDIT(4);
> + else
> + val |= MBUS_DBOX_A_CREDIT(2);
> +
> + if (DISPLAY_VER(i915) >= 14) {
> + val |= MBUS_DBOX_B_CREDIT(0xA);
> + } else if (IS_ALDERLAKE_P(i915)) {
> + val |= MBUS_DBOX_BW_CREDIT(2);
> + val |= MBUS_DBOX_B_CREDIT(8);
> + } else if (DISPLAY_VER(i915) >= 12) {
> + val |= MBUS_DBOX_BW_CREDIT(2);
> + val |= MBUS_DBOX_B_CREDIT(12);
> + } else {
> + val |= MBUS_DBOX_BW_CREDIT(1);
> + val |= MBUS_DBOX_B_CREDIT(8);
> + }
> +
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc, new_dbuf_state-
> >active_pipes) {
> + u32 pipe_val = val;
> +
> + if (DISPLAY_VER(i915) >= 14) {
> + if (xelpdp_is_only_pipe_per_dbuf_bank(crtc->pipe,
> +   new_dbuf_state-
> >active_pipes))
> + pipe_val |= MBUS_DBOX_BW_8CREDITS_MTL;
> + else
> + pipe_val |= MBUS_DBOX_BW_4CREDITS_MTL;
> + }
> +
> + intel_de_write(i915, PIPE_MBUS_DBOX_CTL(crtc->pipe),
> pipe_val);
> + }
> +}
> +
>  int intel_dbuf_state_set_mdclk_cdclk_ratio(struct intel_atomic_state *state, 
> u8
> ratio)  {
>   struct intel_dbuf_state *dbuf_state;
> @@ -3657,89 +3740,6 @@ void intel_dbuf_post_plane_update(struct
> intel_atomic_state *state)
>   new_dbuf_state->enabled_slices);
>  }
> 
> -static bool xelpdp_is_only_pipe_per_dbuf_bank(enum pipe pipe, u8
> active_pipes) -{
> - switch (pipe) {
> - case PIPE_A:
> - return !(active_pipes & BIT(PIPE_D));
> - case PIPE_D:
> - return !(active_pipes & BIT(PIPE_A));
> - case PIPE_B:
> - return !(active_pipes & BIT(PIPE_C));
> - case PIPE_C:
> - return !(active_pipes & BIT(PIPE_B));
> - default: /* to suppress compiler warning */
> - MISSING_CASE(pipe);
> - break;
> - }
> -
> 

RE: [PATCH 05/13] drm/i915: Loop over all active pipes in intel_mbus_dbox_update

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 05/13] drm/i915: Loop over all active pipes in
> intel_mbus_dbox_update
> 
> From: Stanislav Lisovskiy 
> 
> We need to loop through all active pipes, not just the ones, that are in 
> current
> state, because disabling and enabling even a particular pipe affects credits 
> in
> another one.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Stanislav Lisovskiy 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/skl_watermark.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index bc341abcab2f..f582992592c1 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3680,10 +3680,8 @@ void intel_mbus_dbox_update(struct
> intel_atomic_state *state)  {
>   struct drm_i915_private *i915 = to_i915(state->base.dev);
>   const struct intel_dbuf_state *new_dbuf_state, *old_dbuf_state;
> - const struct intel_crtc_state *new_crtc_state;
>   const struct intel_crtc *crtc;
>   u32 val = 0;
> - int i;
> 
>   if (DISPLAY_VER(i915) < 11)
>   return;
> @@ -3727,12 +3725,9 @@ void intel_mbus_dbox_update(struct
> intel_atomic_state *state)
>   val |= MBUS_DBOX_B_CREDIT(8);
>   }
> 
> - for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc,
> +new_dbuf_state->active_pipes) {
>   u32 pipe_val = val;
> 
> - if (!new_crtc_state->hw.active)
> - continue;
> -
>   if (DISPLAY_VER(i915) >= 14) {
>   if (xelpdp_is_only_pipe_per_dbuf_bank(crtc->pipe,
> new_dbuf_state-
> >active_pipes))
> --
> 2.43.2

RE: [PATCH 04/13] drm/i915/cdclk: Indicate whether CDCLK change happens during pre or post plane update

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 04/13] drm/i915/cdclk: Indicate whether CDCLK change happens
> during pre or post plane update
> 
> From: Ville Syrjälä 
> 
> Currently we just get a plain "Changing CDCLK to ..." in the logs. It would 
> actually
> be interesting to see whether we're doing the programming during the pre or 
> post
> plane phase of the commit. Include that information in the debug message.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 19 ++-
>  1 file changed, 6 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 99d2657f29a7..98546f384023 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2434,18 +2434,9 @@ static void intel_pcode_notify(struct
> drm_i915_private *i915,
>   ret);
>  }
> 
> -/**
> - * intel_set_cdclk - Push the CDCLK configuration to the hardware
> - * @dev_priv: i915 device
> - * @cdclk_config: new CDCLK configuration
> - * @pipe: pipe with which to synchronize the update
> - *
> - * Program the hardware based on the passed in CDCLK state,
> - * if necessary.
> - */
>  static void intel_set_cdclk(struct drm_i915_private *dev_priv,
>   const struct intel_cdclk_config *cdclk_config,
> - enum pipe pipe)
> + enum pipe pipe, const char *context)
>  {
>   struct intel_encoder *encoder;
> 
> @@ -2455,7 +2446,7 @@ static void intel_set_cdclk(struct drm_i915_private
> *dev_priv,
>   if (drm_WARN_ON_ONCE(_priv->drm, !dev_priv-
> >display.funcs.cdclk->set_cdclk))
>   return;
> 
> - intel_cdclk_dump_config(dev_priv, cdclk_config, "Changing CDCLK to");
> + intel_cdclk_dump_config(dev_priv, cdclk_config, context);
> 
>   for_each_intel_encoder_with_psr(_priv->drm, encoder) {
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder); @@ -
> 2623,7 +2614,8 @@ intel_set_cdclk_pre_plane_update(struct intel_atomic_state
> *state)
> 
>   drm_WARN_ON(>drm, !new_cdclk_state->base.changed);
> 
> - intel_set_cdclk(i915, _config, new_cdclk_state->pipe);
> + intel_set_cdclk(i915, _config, new_cdclk_state->pipe,
> + "Pre changing CDCLK to");
>  }
> 
>  /**
> @@ -2651,7 +2643,8 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
> 
>   drm_WARN_ON(>drm, !new_cdclk_state->base.changed);
> 
> - intel_set_cdclk(i915, _cdclk_state->actual, new_cdclk_state-
> >pipe);
> + intel_set_cdclk(i915, _cdclk_state->actual, new_cdclk_state->pipe,
> + "Post changing CDCLK to");
>  }
> 
>  static int intel_pixel_rate_to_cdclk(const struct intel_crtc_state 
> *crtc_state)
> --
> 2.43.2

RE: [PATCH 03/13] drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacks

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 03/13] drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacks
> 
> From: Ville Syrjälä 
> 
> No ever figured out why bumping the cdclk helped with whatever issue we were
> having at the time.
> Remove the hacks and start from scratch so that we can actually see if any
> problems still remain.

Yeah, there can be cases where bumping the clock can help avoid the latency
and suppress an issue. However, this is not recommended by hardware and we
should be able to drive the display as per the calculated clock based on pixel 
rate.
Having said that, we should brace ourselves for the issues which it was fixing.

Ok to drop the hack,
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 19 ---
>  1 file changed, 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 504c5cbbcfff..99d2657f29a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2802,25 +2802,6 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
>   if (crtc_state->dsc.compression_enable)
>   min_cdclk = max(min_cdclk, intel_vdsc_min_cdclk(crtc_state));
> 
> - /*
> -  * HACK. Currently for TGL/DG2 platforms we calculate
> -  * min_cdclk initially based on pixel_rate divided
> -  * by 2, accounting for also plane requirements,
> -  * however in some cases the lowest possible CDCLK
> -  * doesn't work and causing the underruns.
> -  * Explicitly stating here that this seems to be currently
> -  * rather a Hack, than final solution.
> -  */
> - if (IS_TIGERLAKE(dev_priv) || IS_DG2(dev_priv)) {
> - /*
> -  * Clamp to max_cdclk_freq in case pixel rate is higher,
> -  * in order not to break an 8K, but still leave W/A at place.
> -  */
> - min_cdclk = max_t(int, min_cdclk,
> -   min_t(int, crtc_state->pixel_rate,
> - dev_priv-
> >display.cdclk.max_cdclk_freq));
> - }
> -
>   return min_cdclk;
>  }
> 
> --
> 2.43.2

RE: [PATCH 02/13] drm/i915/cdclk: Fix voltage_level programming edge case

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 02/13] drm/i915/cdclk: Fix voltage_level programming edge case
> 
> From: Ville Syrjälä 
> 
> Currently we only consider the relationship of the old and new CDCLK 
> frequencies
> when determining whether to do the repgramming from
> intel_set_cdclk_pre_plane_update()
> or intel_set_cdclk_post_plane_update().
> 
> It is technically possible to have a situation where the CDCLK frequency is
> decreasing, but the voltage_level is increasing due a DDI port. In this case 
> we
> should bump the voltage level already in intel_set_cdclk_pre_plane_update()
> (so that the voltage_level will have been increased by the time the port gets
> enabled), while leaving the CDCLK frequency unchanged (as active planes/etc.
> may still depend on it).
> We can then reduce the CDCLK frequency to its final value from
> intel_set_cdclk_post_plane_update().
> 
> In order to handle that correctly we shall construct a suitable amalgam of 
> the old
> and new cdclk states in intel_set_cdclk_pre_plane_update().
> 
> And we can simply call intel_set_cdclk() unconditionally in both places as it 
> will
> not do anything if nothing actually changes vs. the current hw state.
> 
> v2: Handle cdclk_state->disable_pipes

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 27 +-
>  1 file changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 619529dba095..504c5cbbcfff 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2600,6 +2600,7 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
>   intel_atomic_get_old_cdclk_state(state);
>   const struct intel_cdclk_state *new_cdclk_state =
>   intel_atomic_get_new_cdclk_state(state);
> + struct intel_cdclk_config cdclk_config;
> 
>   if (!intel_cdclk_changed(_cdclk_state->actual,
>_cdclk_state->actual))
> @@ -2608,13 +2609,21 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
>   if (IS_DG2(i915))
>   intel_cdclk_pcode_pre_notify(state);
> 
> - if (new_cdclk_state->disable_pipes ||
> - old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
> - drm_WARN_ON(>drm, !new_cdclk_state-
> >base.changed);
> + if (new_cdclk_state->disable_pipes) {
> + cdclk_config = new_cdclk_state->actual;
> + } else {
> + if (new_cdclk_state->actual.cdclk >= old_cdclk_state-
> >actual.cdclk)
> + cdclk_config = new_cdclk_state->actual;
> + else
> + cdclk_config = old_cdclk_state->actual;
> 
> - intel_set_cdclk(i915, _cdclk_state->actual,
> - new_cdclk_state->pipe);
> + cdclk_config.voltage_level = max(new_cdclk_state-
> >actual.voltage_level,
> +  old_cdclk_state-
> >actual.voltage_level);
>   }
> +
> + drm_WARN_ON(>drm, !new_cdclk_state->base.changed);
> +
> + intel_set_cdclk(i915, _config, new_cdclk_state->pipe);
>  }
> 
>  /**
> @@ -2640,13 +2649,9 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
>   if (IS_DG2(i915))
>   intel_cdclk_pcode_post_notify(state);
> 
> - if (!new_cdclk_state->disable_pipes &&
> - old_cdclk_state->actual.cdclk > new_cdclk_state->actual.cdclk) {
> - drm_WARN_ON(>drm, !new_cdclk_state-
> >base.changed);
> + drm_WARN_ON(>drm, !new_cdclk_state->base.changed);
> 
> - intel_set_cdclk(i915, _cdclk_state->actual,
> - new_cdclk_state->pipe);
> - }
> + intel_set_cdclk(i915, _cdclk_state->actual,
> +new_cdclk_state->pipe);
>  }
> 
>  static int intel_pixel_rate_to_cdclk(const struct intel_crtc_state 
> *crtc_state)
> --
> 2.43.2

RE: [PATCH 01/13] drm/i915/cdclk: Fix CDCLK programming order when pipes are active

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 11:16 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 01/13] drm/i915/cdclk: Fix CDCLK programming order when
> pipes are active
> 
> From: Ville Syrjälä 
> 
> Currently we always reprogram CDCLK from the
> intel_set_cdclk_pre_plane_update() when using squahs/crawl.

Nitpick: Typo in squash

Change Looks Good to me.
Reviewed-by: Uma Shankar 

> The code only works correctly for the cd2x update or full modeset cases, and 
> it
> was simply never updated to deal with squash/crawl.
> 
> If the CDCLK frequency is increasing we must reprogram it before we do 
> anything
> else that might depend on the new higher frequency, and conversely we must not
> decrease the frequency until everything that might still depend on the old 
> higher
> frequency has been dealt with.
> 
> Since cdclk_state->pipe is only relevant when doing a cd2x update we can't 
> use it
> to determine the correct sequence during squash/crawl. To that end introduce
> cdclk_state->disable_pipes which simply indicates that we must perform the
> update while the pipes are disable (ie. during
> intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new
> CDCLK frequency comparsiong as for cd2x updates.
> 
> The only remaining problem case is when the voltage_level needs to increase 
> due
> to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are 
> being
> disabled). The current approach will not bump the voltage level up until 
> after the
> port has already been enabled, which is too late.
> But we'll take care of that case separately.
> 
> v2: Don't break the "must disable pipes case"
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 15 +--
> drivers/gpu/drm/i915/display/intel_cdclk.h |  3 +++
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 31aaa9780dfc..619529dba095 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2600,7 +2600,6 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
>   intel_atomic_get_old_cdclk_state(state);
>   const struct intel_cdclk_state *new_cdclk_state =
>   intel_atomic_get_new_cdclk_state(state);
> - enum pipe pipe = new_cdclk_state->pipe;
> 
>   if (!intel_cdclk_changed(_cdclk_state->actual,
>_cdclk_state->actual))
> @@ -2609,11 +2608,12 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
>   if (IS_DG2(i915))
>   intel_cdclk_pcode_pre_notify(state);
> 
> - if (pipe == INVALID_PIPE ||
> + if (new_cdclk_state->disable_pipes ||
>   old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
>   drm_WARN_ON(>drm, !new_cdclk_state-
> >base.changed);
> 
> - intel_set_cdclk(i915, _cdclk_state->actual, pipe);
> + intel_set_cdclk(i915, _cdclk_state->actual,
> + new_cdclk_state->pipe);
>   }
>  }
> 
> @@ -2632,7 +2632,6 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
>   intel_atomic_get_old_cdclk_state(state);
>   const struct intel_cdclk_state *new_cdclk_state =
>   intel_atomic_get_new_cdclk_state(state);
> - enum pipe pipe = new_cdclk_state->pipe;
> 
>   if (!intel_cdclk_changed(_cdclk_state->actual,
>_cdclk_state->actual))
> @@ -2641,11 +2640,12 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
>   if (IS_DG2(i915))
>   intel_cdclk_pcode_post_notify(state);
> 
> - if (pipe != INVALID_PIPE &&
> + if (!new_cdclk_state->disable_pipes &&
>   old_cdclk_state->actual.cdclk > new_cdclk_state->actual.cdclk) {
>   drm_WARN_ON(>drm, !new_cdclk_state-
> >base.changed);
> 
> - intel_set_cdclk(i915, _cdclk_state->actual, pipe);
> + intel_set_cdclk(i915, _cdclk_state->actual,
> + new_cdclk_state->pipe);
>   }
>  }
> 
> @@ -3124,6 +3124,7 @@ static struct intel_global_state
> *intel_cdclk_duplicate_state(struct intel_globa
>   return NULL;
> 
>   cdclk_state->pipe = INVALID_PIPE;
> + cdclk_state->disable_pipes = false;
> 
>   return _state->base;
>  }
> @@ -3316,6 +3317,8 @@ int intel_modeset_calc_cdclk(struct
> intel_atomic_state *state)
>   if (ret)
>   return ret;
> 
> + new_cdclk_state->disable_pipes = true;
> +
>   drm_dbg_kms(_priv->drm,
>   "Modeset required for cdclk change\n");
>   }
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index 

RE: [PATCH v2 1/3] drm/i915/cdclk: Fix CDCLK programming order when pipes are active

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 27, 2024 3:40 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v2 1/3] drm/i915/cdclk: Fix CDCLK programming order when
> pipes are active
> 
> From: Ville Syrjälä 
> 
> Currently we always reprogram CDCLK from the
> intel_set_cdclk_pre_plane_update() when using squahs/crawl.

Nitpick: Typo in squash

Change Looks Good to me.
Reviewed-by: Uma Shankar 

> The code only works correctly for the cd2x update or full modeset cases, and 
> it
> was simply never updated to deal with squash/crawl.
> 
> If the CDCLK frequency is increasing we must reprogram it before we do 
> anything
> else that might depend on the new higher frequency, and conversely we must not
> decrease the frequency until everything that might still depend on the old 
> higher
> frequency has been dealt with.
> 
> Since cdclk_state->pipe is only relevant when doing a cd2x update we can't 
> use it
> to determine the correct sequence during squash/crawl. To that end introduce
> cdclk_state->disable_pipes which simply indicates that we must perform the
> update while the pipes are disable (ie. during
> intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new
> CDCLK frequency comparsiong as for cd2x updates.
> 
> The only remaining problem case is when the voltage_level needs to increase 
> due
> to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are 
> being
> disabled). The current approach will not bump the voltage level up until 
> after the
> port has already been enabled, which is too late.
> But we'll take care of that case separately.
> 
> v2: Don't break the "must disable pipes case"
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 15 +--
> drivers/gpu/drm/i915/display/intel_cdclk.h |  3 +++
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 31aaa9780dfc..619529dba095 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2600,7 +2600,6 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
>   intel_atomic_get_old_cdclk_state(state);
>   const struct intel_cdclk_state *new_cdclk_state =
>   intel_atomic_get_new_cdclk_state(state);
> - enum pipe pipe = new_cdclk_state->pipe;
> 
>   if (!intel_cdclk_changed(_cdclk_state->actual,
>_cdclk_state->actual))
> @@ -2609,11 +2608,12 @@ intel_set_cdclk_pre_plane_update(struct
> intel_atomic_state *state)
>   if (IS_DG2(i915))
>   intel_cdclk_pcode_pre_notify(state);
> 
> - if (pipe == INVALID_PIPE ||
> + if (new_cdclk_state->disable_pipes ||
>   old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
>   drm_WARN_ON(>drm, !new_cdclk_state-
> >base.changed);
> 
> - intel_set_cdclk(i915, _cdclk_state->actual, pipe);
> + intel_set_cdclk(i915, _cdclk_state->actual,
> + new_cdclk_state->pipe);
>   }
>  }
> 
> @@ -2632,7 +2632,6 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
>   intel_atomic_get_old_cdclk_state(state);
>   const struct intel_cdclk_state *new_cdclk_state =
>   intel_atomic_get_new_cdclk_state(state);
> - enum pipe pipe = new_cdclk_state->pipe;
> 
>   if (!intel_cdclk_changed(_cdclk_state->actual,
>_cdclk_state->actual))
> @@ -2641,11 +2640,12 @@ intel_set_cdclk_post_plane_update(struct
> intel_atomic_state *state)
>   if (IS_DG2(i915))
>   intel_cdclk_pcode_post_notify(state);
> 
> - if (pipe != INVALID_PIPE &&
> + if (!new_cdclk_state->disable_pipes &&
>   old_cdclk_state->actual.cdclk > new_cdclk_state->actual.cdclk) {
>   drm_WARN_ON(>drm, !new_cdclk_state-
> >base.changed);
> 
> - intel_set_cdclk(i915, _cdclk_state->actual, pipe);
> + intel_set_cdclk(i915, _cdclk_state->actual,
> + new_cdclk_state->pipe);
>   }
>  }
> 
> @@ -3124,6 +3124,7 @@ static struct intel_global_state
> *intel_cdclk_duplicate_state(struct intel_globa
>   return NULL;
> 
>   cdclk_state->pipe = INVALID_PIPE;
> + cdclk_state->disable_pipes = false;
> 
>   return _state->base;
>  }
> @@ -3316,6 +3317,8 @@ int intel_modeset_calc_cdclk(struct
> intel_atomic_state *state)
>   if (ret)
>   return ret;
> 
> + new_cdclk_state->disable_pipes = true;
> +
>   drm_dbg_kms(_priv->drm,
>   "Modeset required for cdclk change\n");
>   }
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index 

RE: [PATCH v3 4/4] drm/i915/display: tie DMC wakelock to DC5/6 state transitions

[Shankar, Uma]

> -Original Message-
> From: Coelho, Luciano 
> Sent: Monday, March 18, 2024 7:08 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani 
> Subject: [PATCH v3 4/4] drm/i915/display: tie DMC wakelock to DC5/6 state
> transitions
> 
> We only need DMC wakelocks when we allow DC5 and DC6 states.  Add the calls
> to enable and disable DMC wakelock accordingly.

> Signed-off-by: Luca Coelho 
> ---
>  drivers/gpu/drm/i915/display/intel_display_power_well.c | 7 +++
>  drivers/gpu/drm/i915/display/intel_dmc.c| 4 
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> index 217f82f1da84..367464f5c5cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> @@ -17,6 +17,7 @@
>  #include "intel_dkl_phy.h"
>  #include "intel_dkl_phy_regs.h"
>  #include "intel_dmc.h"
> +#include "intel_dmc_wl.h"
>  #include "intel_dp_aux_regs.h"
>  #include "intel_dpio_phy.h"
>  #include "intel_dpll.h"
> @@ -821,6 +822,8 @@ void gen9_enable_dc5(struct drm_i915_private
> *dev_priv)
>   intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
>0, SKL_SELECT_ALTERNATE_DC_EXIT);
> 
> + intel_dmc_wl_enable(dev_priv);

We can have platform checks here and call only when its supported.
No strong objection but doing it here seems better than calling for all
and then checking for platform inside.

>   gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC5);  }
> 
> @@ -850,6 +853,8 @@ void skl_enable_dc6(struct drm_i915_private *dev_priv)
>   intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
>0, SKL_SELECT_ALTERNATE_DC_EXIT);
> 
> + intel_dmc_wl_enable(dev_priv);
> +
>   gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);  }
> 
> @@ -970,6 +975,8 @@ void gen9_disable_dc_states(struct drm_i915_private
> *dev_priv)
>   if (!HAS_DISPLAY(dev_priv))
>   return;
> 
> + intel_dmc_wl_disable(dev_priv);
> +
>   intel_cdclk_get_cdclk(dev_priv, _config);
>   /* Can't read out voltage_level so can't use intel_cdclk_changed() */
>   drm_WARN_ON(_priv->drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 3fa851b5c7a6..b20cc018b9a8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -550,6 +550,8 @@ void intel_dmc_disable_program(struct
> drm_i915_private *i915)
>   pipedmc_clock_gating_wa(i915, true);
>   disable_all_event_handlers(i915);
>   pipedmc_clock_gating_wa(i915, false);
> +
> + intel_dmc_wl_disable(i915);
>  }
> 
>  void assert_dmc_loaded(struct drm_i915_private *i915) @@ -1079,6 +1081,8
> @@ void intel_dmc_suspend(struct drm_i915_private *i915)
>   if (dmc)
>   flush_work(>work);
> 
> + intel_dmc_wl_disable(i915);
> +
>   /* Drop the reference held in case DMC isn't loaded. */
>   if (!intel_dmc_has_payload(i915))
>   intel_dmc_runtime_pm_put(i915);
> --
> 2.39.2

RE: [PATCH v3 3/4] drm/i915/display: add module parameter to enable DMC wakelock

[Shankar, Uma]

> -Original Message-
> From: Coelho, Luciano 
> Sent: Monday, March 18, 2024 7:08 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani 
> Subject: [PATCH v3 3/4] drm/i915/display: add module parameter to enable DMC
> wakelock
> 
> This feature should be disabled by default until properly tested and mature.  
> Add
> a module parameter to enable the feature for testing, while keeping it 
> disabled by
> default for now.
> 
> Signed-off-by: Luca Coelho 
> ---
>  drivers/gpu/drm/i915/display/intel_display_params.c |  5 +
> drivers/gpu/drm/i915/display/intel_display_params.h |  1 +
>  drivers/gpu/drm/i915/display/intel_dmc_wl.c | 12 
>  3 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c
> b/drivers/gpu/drm/i915/display/intel_display_params.c
> index 11e03cfb774d..f40b223cc8a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_params.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_params.c
> @@ -116,6 +116,11 @@
> intel_display_param_named_unsafe(enable_psr2_sel_fetch, bool, 0400,
>   "(0=disabled, 1=enabled) "
>   "Default: 1");
> 
> +intel_display_param_named_unsafe(enable_dmc_wl, bool, 0400,
> + "Enable DMC wakelock "
> + "(0=disabled, 1=enabled) "
> + "Default: 0");
> +
>  __maybe_unused
>  static void _param_print_bool(struct drm_printer *p, const char *driver_name,
> const char *name, bool val)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_params.h
> b/drivers/gpu/drm/i915/display/intel_display_params.h
> index 6206cc51df04..bf8dbbdb20a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_params.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_params.h
> @@ -46,6 +46,7 @@ struct drm_i915_private;
>   param(int, enable_psr, -1, 0600) \
>   param(bool, psr_safest_params, false, 0400) \
>   param(bool, enable_psr2_sel_fetch, true, 0400) \
> + param(bool, enable_dmc_wl, false, 0400) \
> 
>  #define MEMBER(T, member, ...) T member;  struct intel_display_params { diff 
> --
> git a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> index 7c991e22c616..84d054bcb2c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> @@ -120,7 +120,8 @@ void intel_dmc_wl_enable(struct drm_i915_private
> *i915)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> - if (DISPLAY_VER(i915) < 20)
> + if (!i915->display.params.enable_dmc_wl ||
> + DISPLAY_VER(i915) < 20)

Extend this check to init as well. Else it looks ok to protect under a module 
parameter.
Reviewed-by: Uma Shankar 

>   return;
> 
>   spin_lock_irqsave(>lock, flags);
> @@ -146,7 +147,8 @@ void intel_dmc_wl_disable(struct drm_i915_private
> *i915)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> - if (DISPLAY_VER(i915) < 20)
> + if (!i915->display.params.enable_dmc_wl ||
> + DISPLAY_VER(i915) < 20)
>   return;
> 
>   flush_delayed_work(>work);
> @@ -177,7 +179,8 @@ void intel_dmc_wl_get(struct drm_i915_private *i915,
> i915_reg_t reg)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> - if (DISPLAY_VER(i915) < 20)
> + if (!i915->display.params.enable_dmc_wl ||
> + DISPLAY_VER(i915) < 20)
>   return;
> 
>   if (!intel_dmc_wl_check_range(reg.reg))
> @@ -212,7 +215,8 @@ void intel_dmc_wl_put(struct drm_i915_private *i915,
> i915_reg_t reg)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> - if (DISPLAY_VER(i915) < 20)
> + if (!i915->display.params.enable_dmc_wl ||
> + DISPLAY_VER(i915) < 20)
>   return;
> 
>   if (!intel_dmc_wl_check_range(reg.reg))
> --
> 2.39.2

RE: [PATCH v3 2/4] drm/i915/display: don't allow DMC wakelock on older hardware

[Shankar, Uma]

> -Original Message-
> From: Coelho, Luciano 
> Sent: Monday, March 18, 2024 7:08 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani 
> Subject: [PATCH v3 2/4] drm/i915/display: don't allow DMC wakelock on older
> hardware
> 
> Only allow running DMC wakelock code if the display version is 20 or greater.

One for previous one, don't do intel_dmc_wl_init unconditionally but protect it 
with
Platform check.

> Signed-off-by: Luca Coelho 
> ---
>  drivers/gpu/drm/i915/display/intel_dmc_wl.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> index 5c3d8204ae7e..7c991e22c616 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> @@ -120,6 +120,9 @@ void intel_dmc_wl_enable(struct drm_i915_private
> *i915)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> + if (DISPLAY_VER(i915) < 20)
> + return;
> +
>   spin_lock_irqsave(>lock, flags);
> 
>   if (wl->enabled)
> @@ -143,6 +146,9 @@ void intel_dmc_wl_disable(struct drm_i915_private
> *i915)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> + if (DISPLAY_VER(i915) < 20)
> + return;

There can be case where DMC is not loaded, address that as well.
We should not do wakelock in that case.

>   flush_delayed_work(>work);
> 
>   spin_lock_irqsave(>lock, flags);
> @@ -171,6 +177,9 @@ void intel_dmc_wl_get(struct drm_i915_private *i915,
> i915_reg_t reg)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> + if (DISPLAY_VER(i915) < 20)
> + return;
> +
>   if (!intel_dmc_wl_check_range(reg.reg))
>   return;
> 
> @@ -203,6 +212,9 @@ void intel_dmc_wl_put(struct drm_i915_private *i915,
> i915_reg_t reg)
>   struct intel_dmc_wl *wl = >display.wl;
>   unsigned long flags;
> 
> + if (DISPLAY_VER(i915) < 20)
> + return;
> +
>   if (!intel_dmc_wl_check_range(reg.reg))
>   return;
> 
> --
> 2.39.2

RE: [PATCH v3 1/4] drm/i915/display: add support for DMC wakelocks

[Shankar, Uma]

> -Original Message-
> From: Coelho, Luciano 
> Sent: Monday, March 18, 2024 7:08 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Shankar, Uma ;
> ville.syrj...@linux.intel.com; Nikula, Jani 
> Subject: [PATCH v3 1/4] drm/i915/display: add support for DMC wakelocks
> 
> In order to reduce the DC5->DC2 restore time, wakelocks have been introduced
> in DMC so the driver can tell it when registers and other memory areas are 
> going
> to be accessed and keep their respective blocks awake.
> 
> Implement this in the driver by adding the concept of DMC wakelocks.
> When the driver needs to access memory which lies inside pre-defined ranges, 
> it
> will tell DMC to set the wakelock, access the memory, then wait for a while 
> and
> clear the wakelock.
> 
> The wakelock state is protected in the driver with spinlocks to prevent
> concurrency issues.
> 
> BSpec: 71583

These are internal links, not sure how useful they will be for upstream 
discussions.
Give the relevant details here which is better I believe instead of an internal 
link.

> Signed-off-by: Luca Coelho 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_de.h   |  97 +++-
>  .../gpu/drm/i915/display/intel_display_core.h |   2 +
>  .../drm/i915/display/intel_display_driver.c   |   1 +
>  drivers/gpu/drm/i915/display/intel_dmc_regs.h |   6 +
>  drivers/gpu/drm/i915/display/intel_dmc_wl.c   | 226 ++
>  drivers/gpu/drm/i915/display/intel_dmc_wl.h   |  30 +++
>  drivers/gpu/drm/xe/Makefile   |   1 +
>  8 files changed, 356 insertions(+), 8 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_dmc_wl.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dmc_wl.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 3ef6ed41e62b..af83ea94c771 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -270,6 +270,7 @@ i915-y += \
>   display/intel_display_rps.o \
>   display/intel_display_wa.o \
>   display/intel_dmc.o \
> + display/intel_dmc_wl.o \
>   display/intel_dpio_phy.o \
>   display/intel_dpll.o \
>   display/intel_dpll_mgr.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_de.h
> b/drivers/gpu/drm/i915/display/intel_de.h
> index 42552d8c151e..6728a0077793 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.h
> +++ b/drivers/gpu/drm/i915/display/intel_de.h
> @@ -13,52 +13,125 @@
>  static inline u32
>  intel_de_read(struct drm_i915_private *i915, i915_reg_t reg)  {
> - return intel_uncore_read(>uncore, reg);
> + u32 val;
> +
> + intel_dmc_wl_get(i915, reg);

I think one fundamental issue in taking the lock at the granularity of
every MMIO, we risk adding latency here. We should profile the time
it adds.

For modeset for ex, we will end up programming multiple MMIO's from 1 place
But every MMIO call will take the wakelock. This is overkill, instead we can 
just take
the lock once, do our stuff and then release it. 

> +
> + val = intel_uncore_read(>uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
>  }
> 
>  static inline u8
>  intel_de_read8(struct drm_i915_private *i915, i915_reg_t reg)  {
> - return intel_uncore_read8(>uncore, reg);
> + u8 val;
> +
> + intel_dmc_wl_get(i915, reg);
> +
> + val = intel_uncore_read8(>uncore, reg);

Same here and all similar functions.

> + intel_dmc_wl_put(i915, reg);
> +
> + return val;
>  }
> 
>  static inline u64
>  intel_de_read64_2x32(struct drm_i915_private *i915,
>i915_reg_t lower_reg, i915_reg_t upper_reg)  {
> - return intel_uncore_read64_2x32(>uncore, lower_reg,
> upper_reg);
> + u64 val;
> +
> + intel_dmc_wl_get(i915, lower_reg);
> + intel_dmc_wl_get(i915, upper_reg);

I guess if the register falls in the range, taking just 1 wakelock should be 
enough.

> +
> + val = intel_uncore_read64_2x32(>uncore, lower_reg, upper_reg);
> +
> + intel_dmc_wl_put(i915, upper_reg);
> + intel_dmc_wl_put(i915, lower_reg);
> +
> + return val;
>  }
> 
>  static inline void
>  intel_de_posting_read(struct drm_i915_private *i915, i915_reg_t reg)  {
> + intel_dmc_wl_get(i915, reg);
> +
>   intel_uncore_posting_read(>uncore, reg);
> +
> + intel_dmc_wl_put(i915, reg);
>  }
> 
>  static inline void
>  intel_de_write(struct drm_i915_private *i915, i915_reg_t reg, u32 val)  {
> + intel_dmc_wl_get(i915, reg);
> +
>   intel_uncore_write(>uncore, reg, val);
> +
> + intel_dmc_wl

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

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Subject: [PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation
> 
> Add support to enable the DP tunnel BW allocation mode. Follow-up patches will
> call the required helpers added here to prepare for a modeset on a link with 
> DP
> tunnels, the last change in the patchset actually enabling BWA.
> 
> With BWA enabled, the driver will expose the full mode list a display 
> supports,
> regardless of any BW limitation on a shared (Thunderbolt) link. Such BW 
> limits will
> be checked against only during a modeset, when the driver has the full 
> knowledge
> of each display's BW requirement.
> 
> If the link BW changes in a way that a connector's modelist may also change,
> userspace will get a hotplug notification for all the connectors sharing the 
> same
> link (so it can adjust the mode used for a display).
> 
> The BW limitation can change at any point, asynchronously to modesets on a
> given connector, so a modeset can fail even though the atomic check for it
> passed. In such scenarios userspace will get a bad link notification and in
> response is supposed to retry the modeset.
> 
> v2:
> - Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state().
>   (Ville)
> - Fix propagating the error from
>   intel_dp_tunnel_atomic_compute_stream_bw(). (Ville)
> - Move tunnel==NULL checks from driver to DRM core helpers. (Ville)
> - Simplify return flow from intel_dp_tunnel_detect(). (Ville)
> - s/dp_tunnel_state/inherited_dp_tunnels (Ville)
> - Simplify struct intel_dp_tunnel_inherited_state. (Ville)
> - Unconstify object pointers (vs. states) where possible. (Ville)
> - Init crtc_state while declaring it in check_group_state(). (Ville)
> - Join obj->base.id, obj->name arg lines in debug prints to reduce LOC.
>   (Ville)
> - Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the
>   BW allocation from encoder hooks up to intel_atomic_commit_tail()
>   later in the patchset.
> - Disable BW alloc mode during system suspend.
> - Allocate the required BW for all tunnels during system resume.
> - Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded
>   sequence in a follow-up patch.
> - Add function documentation to all exported functions.
> - Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL.

Changes look good to me.
Reviewed-by: Uma Shankar 

> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/Kconfig  |  14 +
>  drivers/gpu/drm/i915/Kconfig.debug|   1 +
>  drivers/gpu/drm/i915/Makefile |   3 +
>  drivers/gpu/drm/i915/display/intel_atomic.c   |   2 +
>  drivers/gpu/drm/i915/display/intel_crtc.c |  25 +
>  drivers/gpu/drm/i915/display/intel_crtc.h |   1 +
>  .../gpu/drm/i915/display/intel_display_core.h |   1 +
>  .../drm/i915/display/intel_display_types.h|   9 +
>  .../gpu/drm/i915/display/intel_dp_tunnel.c| 815 ++
>  .../gpu/drm/i915/display/intel_dp_tunnel.h| 133 +++
>  10 files changed, 1004 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index
> 3089029abba48..5932024f8f954 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -155,6 +155,20 @@ config DRM_I915_PXP
> protected session and manage the status of the alive software session,
> as well as its life cycle.
> 
> +config DRM_I915_DP_TUNNEL
> + bool "Enable DP tunnel support"
> + depends on DRM_I915
> + depends on USB4
> + select DRM_DISPLAY_DP_TUNNEL
> + default y
> + help
> +   Choose this option to detect DP tunnels and enable the Bandwidth
> +   Allocation mode for such tunnels. This allows using the maximum
> +   resolution allowed by the link BW on all displays sharing the
> +   link BW, for instance on a Thunderbolt link.
> +
> +   If in doubt, say "Y".
> +
>  menu "drm/i915 Debugging"
>  depends on DRM_I915
>  depends on EXPERT
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 5b7162076850c..bc18e2d9ea05d 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -28,6 +28,7 @@ config DRM_I915_DEBUG
>   select STACKDEPOT
>   select STACKTRACE
>   select DRM_DP_AUX_CHARDEV
> + select DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE if
> DRM_I915_DP_TUNNEL
>   select X86_MSR # used by igt/pm_rpm
>   select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
>   select DRM_DEBUG_MM if DRM=y
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 

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

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
> 
> Detect DP tunnels and enable the BW allocation mode on them. Send a hotplug
> notification to userspace in response to a BW change.

Looks Good to me.
Reviewed-by: Uma Shankar 

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

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

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
> 
> The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager
> depends on the GFX driver reading out the sink's DPRX capabilities in 
> response to
> a long HPD pulse. Since in i915 this read-out can be blocked by another
> connector's/encoder's hotplug event handling (which is serialized by
> drm_mode_config::connection_mutex), do a dummy DPRX read-out in the
> encoder's HPD pulse handler (which is not blocked by other encoders).

Looks Good to me.
Reviewed-by: Uma Shankar 

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

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

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
> 
> Suspend and resume DP tunnels during system suspend/resume, disabling the BW
> allocation mode during suspend, re-enabling it after resume. This reflects the
> link's BW management component (Thunderbolt CM) disabling BWA during
> suspend. Before any BW requests the driver must read the sink's DPRX
> capabilities (since the BW manager requires this information, so snoops for 
> it on
> AUX), so ensure this read takes place.

Looks Good to me.
Reviewed-by: Uma Shankar 

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

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

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
> 
> Handle DP tunnel IRQs a sink (or rather a BW management component like the
> Thunderbolt Connection Manager) raises to signal the completion of a BW
> request by the driver, or to signal any state change related to the link BW.

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

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

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Subject: [PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check
> BW limit
> 
> Add the atomic state during a modeset required to enable the DP tunnel BW
> allocation mode on links where such a tunnel was detected. This state applies 
> to
> an already enabled output, the state added for a newly enabled output will be
> computed and added/cleared to/from the atomic state in a follow-up patch.
> 
> v2:
> - s/old_crtc_state/crtc_state in intel_crtc_duplicate_state().
> - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up
>   patch adding the corresponding state. (Ville)
> - Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up
>   patch adding the corresponding state.

Looks Good to me.
Reviewed-by: Uma Shankar 

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

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

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Subject: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with 
> syncing
> commits
> 
> Add a way to get the active pipes through a given DP port by syncing against a
> related pending non-blocking commit. Atm
> intel_dp_get_active_pipes() will only try to sync a given pipe and if that 
> would
> block ignore the pipe. A follow-up change enabling the DP tunnel BW allocation
> mode will need to ensure that all active pipes are returned.
> 
> This change will use intel_crtc_state::uapi.commit instead of the 
> corresponding
> commit in the connector state. This shouldn't make a difference, since the two
> commit objects match for an active pipe.
> 
> A follow-up patchset will remove syncing during TC port reset, which should 
> reset
> a port/pipe even if syncing against a commit would block.
> Syncing OTOH is not needed there, since the commit used for the reset implies 
> a
> sync already. For now add a TODO comment for this.
> 
> v2:
> - Add a separate function to try-sync the pipes. (Ville)

Looks Good to me.
Reviewed-by: Uma Shankar 

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

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

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:48 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Hogander, Jouni 
> Subject: [PATCH v2 04/21] drm/i915/dp: Add support to notify MST connectors to
> retry modesets
> 
> On shared (Thunderbolt) links with DP tunnels, the modeset may need to be
> retried on all connectors on the link due to a link BW limitation arising 
> only after
> the atomic check phase. To support this add a helper function queuing a work 
> to
> retry the modeset on a given port's connector and at the same time any MST
> connector with streams through the same port. A follow-up change enabling the
> DP tunnel Bandwidth Allocation Mode will take this into use.
> 
> v2:
> - Send the uevent only to enabled MST connectors. (Jouni)

Looks Good to me.
Reviewed-by: Uma Shankar 

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

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

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:48 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 03/21] drm/i915: Fix display bpp limit computation during
> system resume
> 
> The system resume display mode restoration should happen with an output
> configuration matching that of the suspend time saved mode. Since the restored
> mode configuration is subject to the bpp fallback logic, starting out with an
> unlimited bpp and reducing the bpp as required by any (MST) link BW limit, the
> resulting bpp will match the one during suspend only if the BW limit checks 
> during
> suspend and resume are applied in an identical way. The latter is not 
> guaranteed
> at the moment, since the pre-suspend MST topology may not be in place during
> resume (for instance if the MST sink was disconnected while being suspended),
> which makes the MST link BW check accept the unlimited bpp mode
> configuration unconditionally without ensuring that the required BW fits into 
> the
> available MST link BW.
> 
> To fix the above, initialize the bpp fallback logic with the max link bpp / 
> force-FEC
> limits left behind by the suspend time mode save.

Looks Good to me.
Reviewed-by: Uma Shankar 

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

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

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:48 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Subject: [PATCH v2 02/21] drm/dp: Add support for DP tunneling
> 
> Add support for Display Port tunneling. For now this includes the
> support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay
> support for later.
> 
> BWA allows using displays that share the same (Thunderbolt) link with
> their maximum resolution. Atm, this may not be possible due to the
> coarse granularity of partitioning the link BW among the displays on the
> link: the BW allocation policy is in a SW/FW/HW component on the link
> (on Thunderbolt it's the SW or FW Connection Manager), independent of
> the driver. This policy will set the DPRX maximum rate and lane count
> DPCD registers the GFX driver will see (0x0, 0x1, 0x02200,
> 0x02201) based on the available link BW.
> 
> The granularity of the current BW allocation policy is coarse, based on
> the required link rate in the 1.62Gbs..8.1Gbps range and it may prevent
> using higher resolutions all together: the display connected first will
> get a share of the link BW which corresponds to its full DPRX capability
> (regardless of the actual mode it uses). A subsequent display connected
> will only get the remaining BW, which could be well below its full
> capability.
> 
> BWA solves the above coarse granularity (reducing it to a 250Mbs..1Gps
> range) and first-come/first-served issues by letting the driver request
> the BW for each display on a link which reflects the actual modes the
> displays use.
> 
> This patch adds the DRM core helper functions, while a follow-up change
> in the patchset takes them into use in the i915 driver.
> 
> v2:
> - Fix prepare_to_wait vs. wake-up cond check order in
>   allocate_tunnel_bw(). (Ville)
> - Move tunnel==NULL checks from callers in drivers to here. (Ville)
> - Avoid var inits in declaration blocks that can fail or have
>   side-effects. (Ville)
> - Use u8 for driver and group IDs. (Ville)
> - Simplify API removing drm_dp_tunnel_get/put_untracked(). (Ville)
> - Reuse str_yes_no() instead of a local yes_no_chr(). (Ville)
> - s/drm_dp_tunnel_atomic_clear_state()/free_tunnel_state() and unexport
>   the function. (Ville)
> - s/clear_tunnel_group_state()/free_group_state() and move kfree() to
>   this function. (Ville)
> - Add separate group_free_bw() helper and describe what the tunnel
>   estimated BW includes. (Ville)
> - Improve help text for CONFIG_DRM_DISPLAY_DP_TUNNEL. (Ville)
> - Add code comment explaining the purpose of DPCD reg read helpers.
>   (Ville)
> - Add code comment describing the tunnel group name prefix format.
>   (Ville)
> - Report the allocated BW as undetermined until the first allocation
>   request.
> - Skip allocation requests matching the previous request.
> - Clear any stale BW request status flags before a new request.
> - Add missing error return check of drm_dp_tunnel_atomic_get_group_state()
>   in drm_dp_tunnel_atomic_set_stream_bw().
> - Add drm_dp_tunnel_get_allocated_bw().
> -
> s/drm_dp_tunnel_atomic_get_tunnel_bw/drm_dp_tunnel_atomic_get_required_
> bw
> - Fix return value description in function doc of drm_dp_tunnel_detect().
> - Add function documentation to all exported functions.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/display/Kconfig |   21 +
>  drivers/gpu/drm/display/Makefile|2 +
>  drivers/gpu/drm/display/drm_dp_tunnel.c | 1929 +++
>  include/drm/display/drm_dp.h|   60 +
>  include/drm/display/drm_dp_tunnel.h |  248 +++
>  5 files changed, 2260 insertions(+)
>  create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c
>  create mode 100644 include/drm/display/drm_dp_tunnel.h
> 
> diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig
> index 09712b88a5b83..c0f56888c3280 100644
> --- a/drivers/gpu/drm/display/Kconfig
> +++ b/drivers/gpu/drm/display/Kconfig
> @@ -17,6 +17,27 @@ config DRM_DISPLAY_DP_HELPER
>   help
> DRM display helpers for DisplayPort.
> 
> +config DRM_DISPLAY_DP_TUNNEL
> + bool
> + select DRM_DISPLAY_DP_HELPER
> + help
> +   Enable support for DisplayPort tunnels. This allows drivers to use
> +   DP tunnel features like the Bandwidth Allocation mode to maximize the
> +   BW utilization for display streams on Thunderbolt links.
> +
> +config DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE
> + bool "Enable debugging the DP tunnel state"
> + depends on REF_TRACKER
> + depends on DRM_DISPLAY_DP_TUNNEL
> + depends on DEBUG_KERNEL
> + depends on EXPERT
> + help
> +   Enables debugging the DP tunnel manager's state, including the
> +   consistency of all managed tunnels' reference counting and the state 
> of
> +   streams contained in tunnels.
> +
> +   If in doubt, say "N".
> 

RE: [PATCH 00/28] Plane Color Pipeline support for Intel platforms

[Shankar, Uma]

> -Original Message-
> From: Harry Wentland 
> Sent: Saturday, February 17, 2024 3:17 AM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; 
> dri-
> de...@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; m...@igalia.com; jad...@redhat.com;
> sebastian.w...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run; Borah,
> Chaitanya Kumar 
> Subject: Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
> 
> 
> 
> On 2024-02-13 01:48, Uma Shankar wrote:
> > This series intends to add support for Plane Color Management for
> > Intel platforms. This is based on the design which has been agreed
> > upon by the community. Series implementing the design for generic DRM
> > core has been sent out by Harry Wentland and is under review
> > below:
> > https://patchwork.freedesktop.org/series/123446/
> >
> > The base work of above series is squashed under 1 patch and support
> > for Intel platform is added on top of it.
> > Any reviews on the original core design is expected to be done in
> > Harry's series to avoid any forking of the discussion.
> >
> > We have added some changes/fixes to the Harry's core DRM changes,
> > being put up as separate patches on top of squashed patch. These are
> > expected to get included in the main series from Harry once agreed upon.
> >
> > Changes added on core design:
> > 1. Below patches implement some fixes on original series
> > drm: Add missing function declarations
> > drm: handle NULL next colorop in drm_colorop_set_next_property
> > drm: Fix error logging in set Color Pipeline
> >
> > 2. Implemented a HW capability property to expose segmented luts.
> > drm: Add Color lut range attributes
> > drm: Add Color ops capability property
> > drm: Define helper to create color ops capability property
> > drm: Define helper for adding capability property for 1D LUT
> >
> > This helps in generically defining the hardware lut capabilities, lut
> > distribution, precision, segmented or PWL LUTS.
> >
> > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT:
> > drm: Add Enhanced LUT precision structure
> > drm: Add support for 3x3 CTM
> > drm: Add 1D LUT color op
> >
> > On top of this base work for DRM core plane color pipeline design,
> > implementation is done for Intel hardware platforms. Below patches
> > include the same:
> >
> > drm/i915: Add identifiers for intel color blocks
> > drm/i915: Add intel_color_op
> > drm/i915/color: Add helper to allocate intel colorop
> > drm/i915/color: Add helper to create intel colorop
> > drm/i915/color: Create a transfer function color pipeline
> > drm/i915/color: Add and attach COLORPIPELINE plane property
> > drm/i915/color: Add framework to set colorop
> > drm/i915/color: Add callbacks to set plane CTM
> > drm/i915/color: Add framework to program PRE/POST CSC LUT
> > FIXME: force disable legacy plane color properties for TGL and beyond
> > drm/i915/color: Enable Plane Color Pipelines
> > drm/i915: Define segmented Lut and add capabilities to colorop
> > drm/i915/color: Add plane CTM callback for TGL and beyond
> > drm/i915: Add register definitions for Plane Degamma
> > drm/i915: Add register definitions for Plane Post CSC
> > drm/i915/color: Program Pre-CSC registers
> > drm/i915/xelpd: Program Plane Post CSC Registers
> >
> > Bhanu from Intel will be sending out the igt changes to help test the
> > color pipeline implementation based on the current igt changes sent
> > out by Harry.
> > https://patchwork.freedesktop.org/series/123448/
> >
> > Planned Next Steps:
> > 1. Work with Harry and community and get DRM core changes for color
> > pipeline merged.
> 
> We'll need a userspace to implement support before merging, but we're working
> to enabling all color properties gamescope currently uses for the SteamDeck 
> color
> management to the Color Pipeline API, which should help us get there. It's 
> still a
> journey but I think the path is clear.

Yeah, thanks Harry for driving it.

> I'll send a new version of my patch series next week, including some AMD
> implementation (not the entire AMD pipeline yet).

Oh ok, Nice.

One more input which can be considered:

RE: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop

[Shankar, Uma]

> -Original Message-
> From: Pekka Paalanen 
> Sent: Wednesday, February 14, 2024 2:34 PM
> To: Shankar, Uma 
> Cc: ville.syrj...@linux.intel.com; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run
> Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities
> to colorop
> 
> On Wed, 14 Feb 2024 07:28:37 +
> "Shankar, Uma"  wrote:
> 
> > > -Original Message-
> > > From: dri-devel  On Behalf
> > > Of Pekka Paalanen
> > > Sent: Tuesday, February 13, 2024 3:07 PM
> > > To: Shankar, Uma 
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> > > cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> > > jad...@redhat.com; sebastian.w...@redhat.com;
> > > shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> > > mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> > > victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> > > quic_cbr...@quicinc.com; quic_abhin...@quicinc.com;
> > > arthurgri...@riseup.net; mar...@marcan.st; liviu.du...@arm.com;
> > > sashamcint...@google.com; s...@poorly.run
> > > Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add
> > > capabilities to colorop
> > >
> > > On Tue, 13 Feb 2024 12:18:24 +0530
> > > Uma Shankar  wrote:
> > >
> > > > This defines the lut segments and create the color pipeline
> > > >
> > > > Signed-off-by: Uma Shankar 
> > > > Signed-off-by: Chaitanya Kumar Borah
> > > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_color.c | 109
> > > > +
> > > >  1 file changed, 109 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > > index e223edbe4c13..223cd1ff7291 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > > @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs
> > > ilk_color_funcs = {
> > > > .get_config = ilk_get_config,
> > > >  };
> > > >
> > > > +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> > > > +   /* segment 1 */
> > > > +   {
> > > > +   .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > > +   DRM_MODE_LUT_INTERPOLATE |
> > > > +   DRM_MODE_LUT_NON_DECREASING),
> > >
> > > Hi Uma,
> > >
> > > is it a good idea to have these flags per-segment?
> > >
> > > I would find it very strange, unusable really, if REFLECT_NEGATIVE
> > > applied on some but not all segments, for example. Is such
> > > flexibility really necessary in the hardware description?
> >
> > Hi Pekka,
> > Idea to have these flags is to just have some option in case there are
> > some differences across segments. Most cases this should not be the
> > case, just helps to future proof the implementation.
> >
> > Based on how the community feels on the usability of it, we can take a
> > call on the flags and the expected interpretation for the same. We are open 
> > for
> suggestions on the same.
> >
> > >
> > > > +   .count = 128,
> > > > +   .input_bpc = 24, .output_bpc = 16,
> > >
> > > The same question about input_bpc and output_bpc.
> >
> > Same for these as well, userspace can just ignore these if no usage.
> > However, for some clients it may help in Lut computations.
> > The original idea for the structure came from Ville (missed to mention
> > that in cover letter, will get that updated in next version).
> >
> > @ville.syrj...@linux.intel.com Please share your inputs on the usability of 
> > these
> attributes.
> 
> Userspace will al

RE: [PATCH 09/28] drm: Add Color ops capability property

[Shankar, Uma]

> -Original Message-
> From: Sebastian Wick 
> Sent: Tuesday, February 13, 2024 5:35 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 09/28] drm: Add Color ops capability property
> 
> On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> > Add capability property which a colorop can expose it's hardware's
> > abilities. It's a blob property that can be filled with respective
> > data structures depending on the colorop. The user space is expected
> > to read this property and program the colorop accordingly.
> >
> > Signed-off-by: Uma Shankar 
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c |  3 +++
> >  include/drm/drm_colorop.h | 13 +
> >  2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9f6a3a1c8020..95f1df73209c 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> > *val = state->curve_1d_type;
> > } else if (property == colorop->data_property) {
> > *val = (state->data) ? state->data->base.id : 0;
> > +   } else if (property == colorop->hw_caps_property) {
> > +   *val = state->hw_caps ?
> > +   state->hw_caps->base.id : 0;
> > } else {
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> > index 5b8c36538491..f417e109c40a 100644
> > --- a/include/drm/drm_colorop.h
> > +++ b/include/drm/drm_colorop.h
> > @@ -59,6 +59,12 @@ struct drm_colorop_state {
> >  */
> > enum drm_colorop_curve_1d_type curve_1d_type;
> >
> > +   /**
> > +* @hw_caps:
> > +*
> > +*/
> > +   struct drm_property_blob *hw_caps;
> > +
> 
> Is this supposed to be generic for any colorop or specifically for
> DRM_COLOROP_1D_LUT?

We have intentionally kept it generic so that it can be used for any kind
of hardware color block (1D LUT, 3D LUT etc.). Differentiation can be done
by using the Color op type.

Regards,
Uma Shankar

> > /**
> >  * @data:
> >  *
> > @@ -167,6 +173,13 @@ struct drm_colorop {
> >  */
> > struct drm_property *bypass_property;
> >
> > +   /**
> > +* @hwlut_caps_property:
> > +*
> > +* Property to expose hardware lut capbilities.
> > +*/
> > +   struct drm_property *hw_caps_property;
> > +
> > /**
> >  * @curve_1d_type:
> >  *
> > --
> > 2.42.0
> >

RE: [PATCH 08/28] drm: Add Color lut range attributes

[Shankar, Uma]

> -Original Message-
> From: Sebastian Wick 
> Sent: Tuesday, February 13, 2024 5:34 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 08/28] drm: Add Color lut range attributes
> 
> On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> > This defines a new structure to define color lut ranges, along with
> > related macro definitions and enums. This will help describe segmented
> > lut ranges/PWL LUTs in the hardware.
> >
> > Signed-off-by: Uma Shankar 
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  include/uapi/drm/drm_mode.h | 58
> > +
> >  1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index af67f32e0087..376498715d0e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
> >   DRM_MODE_PAGE_FLIP_ASYNC | \
> >   DRM_MODE_PAGE_FLIP_TARGET)
> >
> 
> All of this uses DRM_MODE_LUT namespace but it seems specifically for the drm
> colorop of type DRM_COLOROP_1D_LUT. Let's be consistent with the naming.

Yeah Sebastian, we will update this and get it aligned.
Thanks for pointing out.

Regards,
Uma Shankar

> > +/**
> > + * DRM_MODE_LUT_INTERPOLATE
> > + *
> > + * linearly interpolate between the points  */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(0)
> > +
> > +/**
> > + * DRM_MODE_LUT_REUSE_LAST
> > + *
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(1)
> > +
> > +/**
> > + * DRM_MODE_LUT_NON_DECREASING
> > + *
> > + * the curve must be non-decreasing
> > + */
> > +#define DRM_MODE_LUT_NON_DECREASING BIT(2)
> > +
> > +/**
> > + * DRM_MODE_LUT_REFLECT_NEGATIVE
> > + *
> > + *  the curve is reflected across origin for negative inputs  */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
> > +
> > +/**
> > + * DRM_MODE_LUT_SINGLE_CHANNEL
> > + *
> > + * the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
> > +
> > +/**
> > + * struct drm_color_lut_range
> > + *
> > + * structure to advertise capability of a color hardware
> > + * block that accepts LUT values.  It can represent LUTs with
> > + * varied number of entries and distributions
> > + * (Multi segmented, Logarithmic etc).
> > + */
> > +
> > +struct drm_color_lut_range {
> > +   /* DRM_MODE_LUT_* */
> > +   __u32 flags;
> > +   /* number of points on the curve */
> > +   __u16 count;
> > +   /* input/output bits per component */
> > +   __u8 input_bpc, output_bpc;
> > +   /* input start/end values */
> > +   __s32 start, end;
> > +   /* output min/max values */
> > +   __s32 min, max;
> > +};
> > +
> >  /*
> >   * Request a page flip on the specified crtc.
> >   *
> > --
> > 2.42.0
> >

RE: [PATCH 00/28] Plane Color Pipeline support for Intel platforms

[Shankar, Uma]

> -Original Message-
> From: Pekka Paalanen 
> Sent: Tuesday, February 13, 2024 4:32 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run; Borah, Chaitanya Kumar 
> Subject: Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
> 
> On Tue, 13 Feb 2024 12:18:07 +0530
> Uma Shankar  wrote:
> 
> > This series intends to add support for Plane Color Management for
> > Intel platforms. This is based on the design which has been agreed
> > upon by the community. Series implementing the design for generic DRM
> > core has been sent out by Harry Wentland and is under review
> > below:
> > https://patchwork.freedesktop.org/series/123446/
> >
> > The base work of above series is squashed under 1 patch and support
> > for Intel platform is added on top of it.
> > Any reviews on the original core design is expected to be done in
> > Harry's series to avoid any forking of the discussion.
> >
> > We have added some changes/fixes to the Harry's core DRM changes,
> > being put up as separate patches on top of squashed patch. These are
> > expected to get included in the main series from Harry once agreed upon.
> >
> > Changes added on core design:
> > 1. Below patches implement some fixes on original series
> > drm: Add missing function declarations
> > drm: handle NULL next colorop in drm_colorop_set_next_property
> > drm: Fix error logging in set Color Pipeline
> >
> > 2. Implemented a HW capability property to expose segmented luts.
> > drm: Add Color lut range attributes
> > drm: Add Color ops capability property
> > drm: Define helper to create color ops capability property
> > drm: Define helper for adding capability property for 1D LUT
> >
> > This helps in generically defining the hardware lut capabilities, lut
> > distribution, precision, segmented or PWL LUTS.
> >
> > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT:
> > drm: Add Enhanced LUT precision structure
> > drm: Add support for 3x3 CTM
> > drm: Add 1D LUT color op
> >
> > On top of this base work for DRM core plane color pipeline design,
> > implementation is done for Intel hardware platforms. Below patches
> > include the same:
> >
> > drm/i915: Add identifiers for intel color blocks
> > drm/i915: Add intel_color_op
> > drm/i915/color: Add helper to allocate intel colorop
> > drm/i915/color: Add helper to create intel colorop
> > drm/i915/color: Create a transfer function color pipeline
> > drm/i915/color: Add and attach COLORPIPELINE plane property
> > drm/i915/color: Add framework to set colorop
> > drm/i915/color: Add callbacks to set plane CTM
> > drm/i915/color: Add framework to program PRE/POST CSC LUT
> > FIXME: force disable legacy plane color properties for TGL and beyond
> > drm/i915/color: Enable Plane Color Pipelines
> > drm/i915: Define segmented Lut and add capabilities to colorop
> > drm/i915/color: Add plane CTM callback for TGL and beyond
> > drm/i915: Add register definitions for Plane Degamma
> > drm/i915: Add register definitions for Plane Post CSC
> > drm/i915/color: Program Pre-CSC registers
> > drm/i915/xelpd: Program Plane Post CSC Registers
> >
> > Bhanu from Intel will be sending out the igt changes to help test the
> > color pipeline implementation based on the current igt changes sent
> > out by Harry.
> > https://patchwork.freedesktop.org/series/123448/
> >
> > Planned Next Steps:
> > 1. Work with Harry and community and get DRM core changes for color
> > pipeline merged.
> > 2. Implement pipe color management (post blending) based on the
> > current color pipeline design.
> > 3. Work with compositor maintainers to get color processing
> > implemented using display hardware, thereby avoid any GL or GPU shaders.
> >
> > Thanks to all the community maintainers and contributors who have
> > helped to get this support in upstream Linux. Looking forward to
> > collaborate, work together and get this merged.
> >
> 
> ...
> 
> > Chaitanya Kumar Bor

RE: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Pekka
> Paalanen
> Sent: Tuesday, February 13, 2024 3:07 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run
> Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities
> to colorop
> 
> On Tue, 13 Feb 2024 12:18:24 +0530
> Uma Shankar  wrote:
> 
> > This defines the lut segments and create the color pipeline
> >
> > Signed-off-by: Uma Shankar 
> > Signed-off-by: Chaitanya Kumar Borah 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 109
> > +
> >  1 file changed, 109 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index e223edbe4c13..223cd1ff7291 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs
> ilk_color_funcs = {
> > .get_config = ilk_get_config,
> >  };
> >
> > +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> > +   /* segment 1 */
> > +   {
> > +   .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > +   DRM_MODE_LUT_INTERPOLATE |
> > +   DRM_MODE_LUT_NON_DECREASING),
> 
> Hi Uma,
> 
> is it a good idea to have these flags per-segment?
> 
> I would find it very strange, unusable really, if REFLECT_NEGATIVE applied on
> some but not all segments, for example. Is such flexibility really necessary 
> in the
> hardware description?

Hi Pekka,
Idea to have these flags is to just have some option in case there are some 
differences
across segments. Most cases this should not be the case, just helps to future 
proof
the implementation.

Based on how the community feels on the usability of it, we can take a call on 
the flags
and the expected interpretation for the same. We are open for suggestions on 
the same.

> 
> > +   .count = 128,
> > +   .input_bpc = 24, .output_bpc = 16,
> 
> The same question about input_bpc and output_bpc.

Same for these as well, userspace can just ignore these if no usage. However, 
for some clients
it may help in Lut computations.
The original idea for the structure came from Ville (missed to mention that in 
cover letter, will get that
updated in next version).

@ville.syrj...@linux.intel.com Please share your inputs on the usability of 
these attributes.


> > +   .start = 0, .end = (1 << 24) - 1,
> > +   .min = 0, .max = (1 << 24) - 1,
> > +   },
> > +   /* segment 2 */
> > +   {
> > +   .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > +   DRM_MODE_LUT_INTERPOLATE |
> > +   DRM_MODE_LUT_REUSE_LAST |
> > +   DRM_MODE_LUT_NON_DECREASING),
> > +   .count = 1,
> > +   .input_bpc = 24, .output_bpc = 16,
> > +   .start = (1 << 24) - 1, .end = 1 << 24,
> 
> What if there is a gap or overlap between the previous segment .end and the 
> next
> segment .start? Is it forbidden? Will the kernel common code verify that 
> drivers
> don't make mistakes? Or IGT?

This is just to help give some reference to userspace.  As of now, driver 
trusts the values
coming from userspace if it sends wrong values its on him and driver can't help 
much.
However, we surely can have some sanity check like non decreasing luts etc. to 
driver.

Ideally LUT values should not overlap, but we can indicate this explicitly with 
flag to
hint the userspace (for overlap or otherwise) and also get a check in driver 
for the same.

Regards,
Uma Shankar

> 
> Thanks,
> pq
> 
> > +   .min = 0, .max = (1 << 27) - 1,
> > +   },
> > +   /* Segment 3 */
> > +   {
> > +   .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > +   DRM_MODE_LUT_INTERPOLATE |
> > +   DRM_MODE_LUT_REUSE_LAST |
> > +   DRM_MODE_LUT_NON_DECREASING),
> > +  

RE: [PATCH 05/28] drm: Add support for 3x3 CTM

[Shankar, Uma]

> -Original Message-
> From: Pekka Paalanen 
> Sent: Tuesday, February 13, 2024 2:45 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run; Borah, Chaitanya Kumar 
> Subject: Re: [PATCH 05/28] drm: Add support for 3x3 CTM
> 
> On Tue, 13 Feb 2024 12:18:12 +0530
> Uma Shankar  wrote:
> 
> > From: Chaitanya Kumar Borah 
> >
> > Add support for 3x3 Color Transformation Matrices in Color Pipeline.
> >
> > Signed-off-by: Chaitanya Kumar Borah 
> > Signed-off-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> >  drivers/gpu/drm/drm_colorop.c | 2 +-
> >  include/uapi/drm/drm_mode.h   | 1 +
> >  3 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index e7bf1fb054af..c54b0d6c133e 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -716,6 +716,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_colorop *colorop,
> > case DRM_COLOROP_CTM_3X4:
> > size = sizeof(struct drm_color_ctm_3x4);
> > break;
> > +   case DRM_COLOROP_CTM_3X3:
> > +   size = sizeof(struct drm_color_ctm);
> > +   break;
> > default:
> > /* should never get here */
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/drm_colorop.c
> > b/drivers/gpu/drm/drm_colorop.c index 462ffec42cdf..6bae6dc8e54b
> > 100644
> > --- a/drivers/gpu/drm/drm_colorop.c
> > +++ b/drivers/gpu/drm/drm_colorop.c
> > @@ -107,7 +107,7 @@ int drm_colorop_init(struct drm_device *dev, struct
> drm_colorop *colorop,
> >0);
> >
> > /* data */
> > -   if (type == DRM_COLOROP_CTM_3X4) {
> > +   if (type == DRM_COLOROP_CTM_3X4 || type ==
> DRM_COLOROP_CTM_3X3) {
> > prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
> DRM_MODE_PROP_BLOB,
> >"DATA", 0);
> > if (!prop)
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index f16318f1785f..68696253867e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -868,6 +868,7 @@ struct drm_color_lut {
> >
> >  enum drm_colorop_type {
> > DRM_COLOROP_1D_CURVE,
> > +   DRM_COLOROP_CTM_3X3,
> > DRM_COLOROP_CTM_3X4,
> >  };
> >
> 
> Hi,
> 
> where are the docs for DRM_COLOROP_CTM_3X3?

Hi Pekka,
Sorry, we missed this in the current version. Will update the same in next 
revision.

Regards,
Uma Shankar

> 
> Thanks,
> pq

RE: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs

[Shankar, Uma]

> -Original Message-
> From: Rodrigo Vivi 
> Sent: Tuesday, February 13, 2024 8:26 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; Lisovskiy, Stanislav
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com
> Subject: Re: [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
> 
> On Mon, Feb 12, 2024 at 06:20:11PM +0530, Uma Shankar wrote:
> > From: Stanislav Lisovskiy 
> >
> > For validation purposes, it might be useful to be able to force
> > Bigjoiner mode, even if current dotclock/resolution do not require
> > that.
> > Lets add such to option to debugfs.
> >
> > v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> >   debugfs entry is created so lets just check manually
> >   the DISPLAY_VER.
> >
> > v3: - Switch to intel_connector from drm_connector(Jani Nikula)
> > - Remove redundant modeset lock(Jani Nikula)
> > - Use kstrtobool_from_user for boolean value(Jani Nikula)
> >
> > v4: - Apply the changes to proper function(Jani Nikula)
> >
> > v5: - Removed unnecessary check from i915_bigjoiner_enable_show
> >   (Ville Syrjälä)
> > - Added eDP connector check to intel_connector_debugfs_add
> >   (Ville Syrjälä)
> > - Removed debug message in order to prevent dmesg flooding
> >   (Ville Syrjälä)
> >
> > v6: - Assume now always that m->private is intel_connector
> > - Fixed other similar conflicts
> >
> > v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
> > - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
> >   manually.(Ville Syrjälä)
> >
> > v8: - Pass intel_connector to debugfs_create_file, instead of drm_connector.
> >   (Jani Nikula)
> >
> > Signed-off-by: Stanislav Lisovskiy 
> 
> please remind to sign-off when sending someone else's patch.

Oh yeah, sorry missed it. Was filling in for Stan while he was OOO.
@Lisovskiy, Stanislav Please address rest of the comments raised by Rodrigo.

Regards,
Uma Shankar

> > ---
> >  .../drm/i915/display/intel_display_debugfs.c  | 47 +++
> >  .../drm/i915/display/intel_display_types.h|  2 +
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  4 +-
> >  3 files changed, 52 insertions(+), 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 6f2d13c8ccf7..a962b48bcf13 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -1391,6 +1391,20 @@ out: drm_modeset_unlock(
> >drm.mode_config.connection_mutex);
> > return ret;
> >  }
> >
> > +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> > +{
> > +   struct intel_connector *connector = m->private;
> > +   struct drm_crtc *crtc;
> > +
> > +   crtc = connector->base.state->crtc;
> > +   if (connector->base.status != connector_status_connected || !crtc)
> > +   return -ENODEV;
> > +
> > +   seq_printf(m, "Bigjoiner enable: %d\n",
> > +connector->force_bigjoiner_enable);
> 
> probably better with a yes_or_no string?
> 
> > +
> > +   return 0;
> > +}
> > +
> >  static ssize_t i915_dsc_output_format_write(struct file *file,
> > const char __user *ubuf,
> > size_t len, loff_t *offp)
> > @@ -1412,6 +1426,30 @@ static ssize_t i915_dsc_output_format_write(struct
> file *file,
> > return len;
> >  }
> >
> > +static ssize_t i915_bigjoiner_enable_write(struct file *file,
> > +  const char __user *ubuf,
> > +  size_t len, loff_t *offp)
> > +{
> > +   struct seq_file *m = file->private_data;
> > +   struct intel_connector *connector = m->private;
> > +   struct drm_crtc *crtc;
> > +   bool bigjoiner_en = 0;
> > +   int ret;
> > +
> > +   crtc = connector->base.state->crtc;
> > +   if (connector->base.status != connector_status_connected || !crtc)
> > +   return -ENODEV;
> > +
> > +   ret = kstrtobool_from_user(ubuf, len, _en);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   connector->force_bigjoiner_enable = bigjoiner_en;
> > +   *offp += len;
> > +
> > +   return len;
> > +}
> > +
> >  static int i915_dsc_output

RE: [PATCH 17/19] drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 17/19] drm/i915/dp: Call intel_dp_sync_state() always for DDI
> DP encoders
> 
> A follow-up change will need to resume DP tunnels during system resume, so 
> call
> intel_dp_sync_state() always for DDI encoders, so this function can resume the
> tunnels for all DP connectors.

Looks good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index aa6e7da08fbce..1e26e62b82d48 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4131,7 +4131,7 @@ static void intel_ddi_sync_state(struct intel_encoder
> *encoder,
>   intel_tc_port_sanitize_mode(enc_to_dig_port(encoder),
>   crtc_state);
> 
> - if (crtc_state && intel_crtc_has_dp_encoder(crtc_state))
> + if (intel_encoder_is_dp(encoder))
>   intel_dp_sync_state(encoder, crtc_state);  }
> 
> --
> 2.39.2

RE: [PATCH 15/19] drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable hooks

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 15/19] drm/i915/dp: Allocate/free DP tunnel BW in the encoder
> enable/disable hooks
> 
> Allocate and free the DP tunnel BW required by a stream while 
> enabling/disabling
> the stream during a modeset.

Looks good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/g4x_dp.c| 28 
>  drivers/gpu/drm/i915/display/intel_ddi.c |  7 ++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index dfe0b07a122d1..1e498e1510adf 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -19,6 +19,7 @@
>  #include "intel_dp.h"
>  #include "intel_dp_aux.h"
>  #include "intel_dp_link_training.h"
> +#include "intel_dp_tunnel.h"
>  #include "intel_dpio_phy.h"
>  #include "intel_fifo_underrun.h"
>  #include "intel_hdmi.h"
> @@ -729,6 +730,24 @@ static void vlv_enable_dp(struct intel_atomic_state
> *state,
>   encoder->audio_enable(encoder, pipe_config, conn_state);  }
> 
> +static void g4x_dp_pre_pll_enable(struct intel_atomic_state *state,
> +   struct intel_encoder *encoder,
> +   const struct intel_crtc_state *new_crtc_state,
> +   const struct drm_connector_state
> *new_conn_state) {
> + intel_dp_tunnel_atomic_alloc_bw(state, encoder,
> + new_crtc_state, new_conn_state);
> +}
> +
> +static void g4x_dp_post_pll_disable(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state 
> *old_crtc_state,
> + const struct drm_connector_state
> *old_conn_state) {
> + intel_dp_tunnel_atomic_free_bw(state, encoder,
> +old_crtc_state, old_conn_state); }
> +
>  static void g4x_pre_enable_dp(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config, @@ -
> 762,6 +781,8 @@ static void vlv_dp_pre_pll_enable(struct intel_atomic_state
> *state,
>   intel_dp_prepare(encoder, pipe_config);
> 
>   vlv_phy_pre_pll_enable(encoder, pipe_config);
> +
> + g4x_dp_pre_pll_enable(state, encoder, pipe_config, conn_state);
>  }
> 
>  static void chv_pre_enable_dp(struct intel_atomic_state *state, @@ -785,6
> +806,8 @@ static void chv_dp_pre_pll_enable(struct intel_atomic_state *state,
>   intel_dp_prepare(encoder, pipe_config);
> 
>   chv_phy_pre_pll_enable(encoder, pipe_config);
> +
> + g4x_dp_pre_pll_enable(state, encoder, pipe_config, conn_state);
>  }
> 
>  static void chv_dp_post_pll_disable(struct intel_atomic_state *state, @@ 
> -792,6
> +815,8 @@ static void chv_dp_post_pll_disable(struct intel_atomic_state 
> *state,
>   const struct intel_crtc_state 
> *old_crtc_state,
>   const struct drm_connector_state
> *old_conn_state)  {
> + g4x_dp_post_pll_disable(state, encoder, old_crtc_state,
> +old_conn_state);
> +
>   chv_phy_post_pll_disable(encoder, old_crtc_state);  }
> 
> @@ -1349,11 +1374,14 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
>   intel_encoder->enable = vlv_enable_dp;
>   intel_encoder->disable = vlv_disable_dp;
>   intel_encoder->post_disable = vlv_post_disable_dp;
> + intel_encoder->post_pll_disable = g4x_dp_post_pll_disable;
>   } else {
> + intel_encoder->pre_pll_enable = g4x_dp_pre_pll_enable;
>   intel_encoder->pre_enable = g4x_pre_enable_dp;
>   intel_encoder->enable = g4x_enable_dp;
>   intel_encoder->disable = g4x_disable_dp;
>   intel_encoder->post_disable = g4x_post_disable_dp;
> + intel_encoder->post_pll_disable = g4x_dp_post_pll_disable;
>   }
>   intel_encoder->audio_enable = g4x_dp_audio_enable;
>   intel_encoder->audio_disable = g4x_dp_audio_disable; diff --git
> a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 922194b957be2..aa6e7da08fbce 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -54,6 +54,7 @@
>  #include "intel_dp_aux.h"
>  #include "intel_dp_link_training.h"
>  #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
>  #include "intel_dpio_phy.h"
>  #include "intel_dsi.h"
>  #include "intel_fdi.h"
> @@ -3141,6 +3142,9 @@ static void intel_ddi_post_pll_disable(struct
> intel_atomic_state *state,
> 
>   

RE: [PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state computation

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state
> computation
> 
> Compute the BW required through a DP tunnel on links with such tunnels
> detected and add the corresponding atomic state during a modeset.

Looks good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 16 +---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 13 +
>  2 files changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 78dfe8be6031d..6968fdb7ffcdf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2880,6 +2880,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   struct drm_connector_state *conn_state)  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_atomic_state *state =
> +to_intel_atomic_state(conn_state->state);
>   struct drm_display_mode *adjusted_mode = _config-
> >hw.adjusted_mode;
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>   const struct drm_display_mode *fixed_mode; @@ -2980,6 +2981,9 @@
> intel_dp_compute_config(struct intel_encoder *encoder,
>   intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
>   intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config,
> conn_state);
> 
> + intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, connector,
> +  pipe_config);
> +
>   return 0;
>  }
> 
> @@ -6087,6 +6091,15 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
>   return ret;
>   }
> 
> + if (!intel_connector_needs_modeset(state, conn))
> + return 0;
> +
> + ret = intel_dp_tunnel_atomic_check_state(state,
> +  intel_dp,
> +  intel_conn);
> + if (ret)
> + return ret;
> +
>   /*
>* We don't enable port sync on BDW due to missing w/as and
>* due to not having adjusted the modeset sequence appropriately.
> @@ -6094,9 +6107,6 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
>   if (DISPLAY_VER(dev_priv) < 9)
>   return 0;
> 
> - if (!intel_connector_needs_modeset(state, conn))
> - return 0;
> -
>   if (conn->has_tile) {
>   ret = intel_modeset_tile_group(state, conn->tile_group->id);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 520393dc8b453..cbfab3173b9ef 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -42,6 +42,7 @@
>  #include "intel_dp.h"
>  #include "intel_dp_hdcp.h"
>  #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
>  #include "intel_dpio_phy.h"
>  #include "intel_hdcp.h"
>  #include "intel_hotplug.h"
> @@ -523,6 +524,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>  struct drm_connector_state *conn_state)  
> {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_atomic_state *state =
> +to_intel_atomic_state(conn_state->state);
>   struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
>   struct intel_dp *intel_dp = _mst->primary->dp;
>   const struct intel_connector *connector = @@ -619,6 +621,9 @@ static
> int intel_dp_mst_compute_config(struct intel_encoder *encoder,
> 
>   intel_psr_compute_config(intel_dp, pipe_config, conn_state);
> 
> + intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, connector,
> +  pipe_config);
> +
>   return 0;
>  }
> 
> @@ -876,6 +881,14 @@ intel_dp_mst_atomic_check(struct drm_connector
> *connector,
>   if (ret)
>   return ret;
> 
> + if (intel_connector_needs_modeset(state, connector)) {
> + ret = intel_dp_tunnel_atomic_check_state(state,
> +  intel_connector-
> >mst_port,
> +  intel_connector);
> + if (ret)
> + return ret;
> + }
> +
>   return drm_dp_atomic_release_time_slots(>base,
>   _connector->mst_port-
> >mst_mgr,
>   intel_connector->port);
> --
> 2.39.2

RE: [PATCH 13/19] drm/i915/dp: Account for tunnel BW limit in intel_dp_max_link_data_rate()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 13/19] drm/i915/dp: Account for tunnel BW limit in
> intel_dp_max_link_data_rate()
> 
> Take any link BW limitation into account in intel_dp_max_link_data_rate(). 
> Such a
> limitation can be due to multiple displays on (Thunderbolt) links with DP 
> tunnels
> sharing the link BW.

Looks good to me.
Reviewed-by: Uma Shankar 

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

RE: [PATCH 09/19] drm/i915/dp: Add intel_dp_max_link_data_rate()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 09/19] drm/i915/dp: Add intel_dp_max_link_data_rate()
> 
> Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX BW used
> by a follow-up patch enabling the DP tunnel BW allocation mode.
> The link BW can be below the DPRX BW due to a BW limitation on a link shared
> by multiple sinks.

Looks good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
>  drivers/gpu/drm/i915/display/intel_dp.h |  2 ++
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  3 +-
>  3 files changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 23434d0aba188..9cd675c6d0ee8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -383,6 +383,22 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
>   100 * 16 * 8);
>  }
> 
> +/**
> + * intel_dp_max_link_data_rate: Calculate the maximum rate for the
> +given link params
> + * @intel_dp: Intel DP object
> + * @max_dprx_rate: Maximum data rate of the DPRX
> + * @max_dprx_lanes: Maximum lane count of the DPRX
> + *
> + * Calculate the maximum data rate for the provided link parameters.
> + *
> + * Returns the maximum data rate in kBps units.
> + */
> +int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> + int max_dprx_rate, int max_dprx_lanes) {
> + return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes); }
> +
>  bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); @@
> -612,7 +628,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct
> intel_dp *intel_dp,
>   int mode_rate, max_rate;
> 
>   mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
> - max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
> + max_rate = intel_dp_max_link_data_rate(intel_dp, link_rate,
> +lane_count);
>   if (mode_rate > max_rate)
>   return false;
> 
> @@ -1214,7 +1230,8 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
>   max_link_clock = intel_dp_max_link_rate(intel_dp);
>   max_lanes = intel_dp_max_lane_count(intel_dp);
> 
> - max_rate = drm_dp_max_dprx_data_rate(max_link_clock, max_lanes);
> + max_rate = intel_dp_max_link_data_rate(intel_dp, max_link_clock,
> +max_lanes);
> +
>   mode_rate = intel_dp_link_required(target_clock,
> 
> intel_dp_mode_min_output_bpp(connector, mode));
> 
> @@ -1564,8 +1581,10 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
>   for (lane_count = limits->min_lane_count;
>lane_count <= limits->max_lane_count;
>lane_count <<= 1) {
> - link_avail =
> drm_dp_max_dprx_data_rate(link_rate,
> -
> lane_count);
> + link_avail =
> intel_dp_max_link_data_rate(intel_dp,
> +
> link_rate,
> +
> lane_count);
> +
> 
>   if (mode_rate <= link_avail) {
>   pipe_config->lane_count = lane_count;
> @@ -2422,8 +2441,9 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
>   pipe_config->pipe_bpp,
>   BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
>   intel_dp_config_required_rate(pipe_config),
> - drm_dp_max_dprx_data_rate(pipe_config->port_clock,
> -   pipe_config->lane_count));
> + intel_dp_max_link_data_rate(intel_dp,
> + pipe_config->port_clock,
> + pipe_config->lane_count));
> 
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 49553e43add22..8b0dfbf06afff 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -117,6 +117,8 @@ bool intel_dp_get_colorimetry_status(struct intel_dp
> *intel_dp);  int intel_dp_link_required(int pixel_clock, int bpp);  int
> intel_dp_effective_data_rate(int pixel_clock, int bpp_x16,
>int bw_overhead);
> +int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> + int max_dprx_rate, int max_dprx_lanes);
>  bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp);  bool
> intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
>   const struct drm_connector_state *conn_state); diff 
> --
> git 

RE: [PATCH 08/19] drm/i915/dp: Factor out intel_dp_read_dprx_caps()

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 08/19] drm/i915/dp: Factor out intel_dp_read_dprx_caps()
> 
> Factor out a function to read the sink's DPRX capabilities used by a follow-up
> patch enabling the DP tunnel BW allocation mode.

Looks good to me.
Reviewed-by: Uma Shankar 

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

RE: [PATCH 07/19] drm/i915/dp: Factor out intel_dp_update_sink_caps()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 07/19] drm/i915/dp: Factor out intel_dp_update_sink_caps()
> 
> Factor out a function updating the sink's link rate and lane count 
> capabilities, used
> by a follow-up patch enabling the DP tunnel BW allocation mode.

Looks good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
> drivers/gpu/drm/i915/display/intel_dp.h |  1 +
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f40706c5d1aad..23434d0aba188 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3949,6 +3949,13 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
> _dp->desc);
>  }
> 
> +void intel_dp_update_sink_caps(struct intel_dp *intel_dp) {
> + intel_dp_set_sink_rates(intel_dp);
> + intel_dp_set_max_sink_lane_count(intel_dp);
> + intel_dp_set_common_rates(intel_dp);
> +}
> +
>  static bool
>  intel_dp_get_dpcd(struct intel_dp *intel_dp)  { @@ -3965,9 +3972,7 @@
> intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   drm_dp_read_desc(_dp->aux, _dp->desc,
>drm_dp_is_branch(intel_dp->dpcd));
> 
> - intel_dp_set_sink_rates(intel_dp);
> - intel_dp_set_max_sink_lane_count(intel_dp);
> - intel_dp_set_common_rates(intel_dp);
> + intel_dp_update_sink_caps(intel_dp);
>   }
> 
>   if (intel_dp_has_sink_count(intel_dp)) { diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index a7906d8738c4a..49553e43add22 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -106,6 +106,7 @@ int intel_dp_config_required_rate(const struct
> intel_crtc_state *crtc_state);  int intel_dp_rate_select(struct intel_dp 
> *intel_dp,
> int rate);  int intel_dp_max_common_rate(struct intel_dp *intel_dp);  int
> intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
> +void intel_dp_update_sink_caps(struct intel_dp *intel_dp);
> 
>  void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
>  u8 *link_bw, u8 *rate_select);
> --
> 2.39.2

RE: [PATCH 06/19] drm/i915/dp: Export intel_dp_max_common_rate/lane_count()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 06/19] drm/i915/dp: Export
> intel_dp_max_common_rate/lane_count()
> 
> Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by a
> follow-up patch enabling the DP tunnel BW allocation mode.

Looks good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0a5c60428ffb7..f40706c5d1aad 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -309,7 +309,7 @@ static int intel_dp_common_rate(struct intel_dp
> *intel_dp, int index)  }
> 
>  /* Theoretical max between source and sink */ -static int
> intel_dp_max_common_rate(struct intel_dp *intel_dp)
> +int intel_dp_max_common_rate(struct intel_dp *intel_dp)
>  {
>   return intel_dp_common_rate(intel_dp, intel_dp->num_common_rates -
> 1);  } @@ -326,7 +326,7 @@ static int intel_dp_max_source_lane_count(struct
> intel_digital_port *dig_port)  }
> 
>  /* Theoretical max between source and sink */ -static int
> intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
> +int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   int source_max = intel_dp_max_source_lane_count(dig_port);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 37274e3c2902f..a7906d8738c4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -104,6 +104,8 @@ int intel_dp_max_link_rate(struct intel_dp *intel_dp);  
> int
> intel_dp_max_lane_count(struct intel_dp *intel_dp);  int
> intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state);  int
> intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
> +int intel_dp_max_common_rate(struct intel_dp *intel_dp); int
> +intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
> 
>  void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
>  u8 *link_bw, u8 *rate_select);
> --
> 2.39.2

RE: [PATCH 05/19] drm/i915/dp: Factor out intel_dp_config_required_rate()

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 05/19] drm/i915/dp: Factor out intel_dp_config_required_rate()
> 
> Factor out intel_dp_config_required_rate() used by a follow-up patch enabling 
> the
> DP tunnel BW allocation mode.

Looks good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 43 +++--
> drivers/gpu/drm/i915/display/intel_dp.h |  1 +
>  2 files changed, 20 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c7b06a9b197cc..0a5c60428ffb7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2338,6 +2338,17 @@ intel_dp_compute_config_limits(struct intel_dp
> *intel_dp,
>  limits);
>  }
> 
> +int intel_dp_config_required_rate(const struct intel_crtc_state
> +*crtc_state) {
> + const struct drm_display_mode *adjusted_mode =
> + _state->hw.adjusted_mode;
> + int bpp = crtc_state->dsc.compression_enable ?
> + to_bpp_int_roundup(crtc_state->dsc.compressed_bpp_x16) :
> + crtc_state->pipe_bpp;
> +
> + return intel_dp_link_required(adjusted_mode->crtc_clock, bpp); }
> +
>  static int
>  intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config, @@ -2405,31
> +2416,15 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>   return ret;
>   }
> 
> - if (pipe_config->dsc.compression_enable) {
> - drm_dbg_kms(>drm,
> - "DP lane count %d clock %d Input bpp %d Compressed
> bpp " BPP_X16_FMT "\n",
> - pipe_config->lane_count, pipe_config->port_clock,
> - pipe_config->pipe_bpp,
> - BPP_X16_ARGS(pipe_config-
> >dsc.compressed_bpp_x16));
> + drm_dbg_kms(>drm,
> + "DP lane count %d clock %d bpp input %d compressed "
> BPP_X16_FMT " link rate required %d available %d\n",
> + pipe_config->lane_count, pipe_config->port_clock,
> + pipe_config->pipe_bpp,
> + BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
> + intel_dp_config_required_rate(pipe_config),
> + drm_dp_max_dprx_data_rate(pipe_config->port_clock,
> +   pipe_config->lane_count));
> 
> - drm_dbg_kms(>drm,
> - "DP link rate required %i available %i\n",
> - intel_dp_link_required(adjusted_mode->crtc_clock,
> -
> to_bpp_int_roundup(pipe_config->dsc.compressed_bpp_x16)),
> - drm_dp_max_dprx_data_rate(pipe_config-
> >port_clock,
> -   pipe_config->lane_count));
> - } else {
> - drm_dbg_kms(>drm, "DP lane count %d clock %d bpp
> %d\n",
> - pipe_config->lane_count, pipe_config->port_clock,
> - pipe_config->pipe_bpp);
> -
> - drm_dbg_kms(>drm,
> - "DP link rate required %i available %i\n",
> - intel_dp_link_required(adjusted_mode->crtc_clock,
> -pipe_config->pipe_bpp),
> - drm_dp_max_dprx_data_rate(pipe_config-
> >port_clock,
> -   pipe_config->lane_count));
> - }
>   return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 46f79747f807d..37274e3c2902f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -102,6 +102,7 @@ void intel_dp_mst_suspend(struct drm_i915_private
> *dev_priv);  void intel_dp_mst_resume(struct drm_i915_private *dev_priv);  int
> intel_dp_max_link_rate(struct intel_dp *intel_dp);  int
> intel_dp_max_lane_count(struct intel_dp *intel_dp);
> +int intel_dp_config_required_rate(const struct intel_crtc_state
> +*crtc_state);
>  int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
> 
>  void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> --
> 2.39.2

RE: [PATCH 04/19] drm/i915/dp: Use drm_dp_max_dprx_data_rate()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH 04/19] drm/i915/dp: Use drm_dp_max_dprx_data_rate()
> 
> Instead of intel_dp_max_data_rate() use the equivalent
> drm_dp_max_dprx_data_rate() which was copied from the former one in a
> previous patch.

Looks good to me.
Reviewed-by: Uma Shankar 

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

RE: [PATCH 01/19] drm/dp: Add drm_dp_max_dprx_data_rate()

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Imre
> Deak
> Sent: Friday, January 26, 2024 6:58 PM
> To: Ville Syrjälä 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH 01/19] drm/dp: Add drm_dp_max_dprx_data_rate()
> 
> On Fri, Jan 26, 2024 at 01:36:02PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2024 at 12:28:32PM +0200, Imre Deak wrote:
> > > Copy intel_dp_max_data_rate() to DRM core. It will be needed by a
> > > follow-up DP tunnel patch, checking the maximum rate the DPRX (sink)
> > > supports. Accordingly use the drm_dp_max_dprx_data_rate() name for
> > > clarity. This patchset will also switch calling the new DRM function
> > > in i915 instead of intel_dp_max_data_rate().
> > >
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/display/drm_dp_helper.c | 58
> +
> > >  include/drm/display/drm_dp_helper.h |  2 +
> > >  2 files changed, 60 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > > b/drivers/gpu/drm/display/drm_dp_helper.c
> > > index b1ca3a1100dab..24911243d4d3a 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > > @@ -4058,3 +4058,61 @@ int drm_dp_bw_channel_coding_efficiency(bool
> is_uhbr)
> > >   return 80;
> > >  }
> > >  EXPORT_SYMBOL(drm_dp_bw_channel_coding_efficiency);
> > > +
> > > +/*
> > > + * Given a link rate and lanes, get the data bandwidth.
> > > + *
> > > + * Data bandwidth is the actual payload rate, which depends on the
> > > +data
> > > + * bandwidth efficiency and the link rate.
> > > + *
> > > + * For 8b/10b channel encoding, SST and non-FEC, the data bandwidth
> > > +efficiency
> > > + * is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80
> > > +* (1/8) =
> > > + * 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol
> > > +clock. Just by
> > > + * coincidence, the port clock in kHz matches the data bandwidth in
> > > +kBps, and
> > > + * they equal the link bit rate in Gbps multiplied by 10. (Note
> > > +that this no
> > > + * longer holds for data bandwidth as soon as FEC or MST is taken
> > > +into account!)
> > > + *
> > > + * For 128b/132b channel encoding, the data bandwidth efficiency is
> > > +96.71%. For
> > > + * example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) =
> > > +1208875
> > > + * kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The
> > > +value 100
> > > + * does not match the symbol clock, the port clock (not even if you
> > > +think in
> > > + * terms of a byte clock), nor the data bandwidth. It only matches
> > > +the link bit
> > > + * rate in units of 1 bps.
> > > + *
> > > + * Note that protocol layers above the DPRX link level considered
> > > +here can
> > > + * further limit the maximum data rate. Such layers are the MST
> > > +topology (with
> > > + * limits on the link between the source and first branch device as
> > > +well as on
> > > + * the whole MST path until the DPRX link) and (Thunderbolt) DP
> > > +tunnels -
> > > + * which in turn can encapsulate an MST link with its own limit -
> > > +with each
> > > + * SST or MST encapsulated tunnel sharing the BW of a tunnel group.
> > > + *
> > > + * TODO: Add support for querying the max data rate with the above
> > > +limits as
> > > + * well.
> > > + *
> > > + * Returns the maximum data rate in kBps units.
> > > + */
> > > +int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes) {
> > > + int ch_coding_efficiency =
> > > +
>   drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_
> rate));
> > > + int max_link_rate_kbps = max_link_rate * 10;
> >
> > That x10 value seems rather pointless.
> 
> I suppose the point was to make the units clearer, but it could be clarified 
> instead
> in max_link_rates' documentation, which is missing atm.
> 
> > > +
> > > + /*
> > > +  * UHBR rates always use 128b/132b channel encoding, and have
> > > +  * 97.71% data bandwidth efficiency. Consider max_link_rate the
> > > +  * link bit rate in units of 1 bps.
> > > +  */
> > > + /*
> > > +  * Lower than UHBR rates always use 8b/10b channel encoding, and have
> > > +  * 80% data bandwidth efficiency for SST non-FEC. However, this turns
> > > +  * out to be a nop by coincidence:
> > > +  *
> > > +  *  int max_link_rate_kbps = max_link_rate * 10;
> > > +  *  max_link_rate_kbps =
> DIV_ROUND_DOWN_ULL(max_link_rate_kbps * 8, 10);
> > > +  *  max_link_rate = max_link_rate_kbps / 8;
> > > +  */
> >
> > Not sure why we are repeating the nuts and bolts detils in the
> > comments so much? Doesn't drm_dp_bw_channel_coding_efficiency()
> > explain all this already?
> 
> I simply copied the function, but yes in this context there is duplication, 
> thanks for
> reading through all that. Will consolidate both the above and the bigger 
> comment
> before the function with the existing docs here.

Changes look good to me. 

RE: [PATCH] drm/i915/fbc: Allow FBC with CCS modifiers on SKL+

[Shankar, Uma]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, January 24, 2024 9:13 AM
> To: Vivi, Rodrigo 
> Cc: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/fbc: Allow FBC with CCS modifiers on SKL+
> 
> On Tue, Jan 23, 2024 at 05:44:06PM -0500, Rodrigo Vivi wrote:
> > On Tue, Jan 23, 2024 at 11:02:44AM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > >
> > > Only display workarounds 0391 and 0475 call for disabling FBC with
> > > render compression, and those are listed only for pre-prod SKL
> > > steppings. So it should be safe to enable
> > > FB+CCS on production hardware.
> > >
> > > AFAIK CCS is limited to 50% bandwidth reduction (perhaps clear color
> > > can do better?). FBC can exceed that number by quite a bit, given
> > > the right kind of framebuffer contents. So piling on both kinds of
> > > compressions could still make sense.
> >
> > yeap, I think so.
> > The risk is to hit a workaround that is not ducumented in the BSpec
> > cases after gen11...
> >
> > Uma, do you recall having seen lately any workaround with FBC and
> > render compression?

Sorry missed to reply earlier. 
I don't see any restriction called out on this, so we should be good enabling
them both.

Let's enable and uncover bugs if any  (have been a touchy area anyways)

Regards,
Uma Shankar

> > >
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10125
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_fbc.c | 13 +
> > >  1 file changed, 1 insertion(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > index f17a1afb4929..b453fcbd67da 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > @@ -1087,18 +1087,7 @@ static bool i8xx_fbc_tiling_valid(const
> > > struct intel_plane_state *plane_state)
> > >
> > >  static bool skl_fbc_tiling_valid(const struct intel_plane_state
> > > *plane_state)  {
> > > - const struct drm_framebuffer *fb = plane_state->hw.fb;
> > > -
> > > - switch (fb->modifier) {
> > > - case DRM_FORMAT_MOD_LINEAR:
> > > - case I915_FORMAT_MOD_Y_TILED:
> > > - case I915_FORMAT_MOD_Yf_TILED:
> > > - case I915_FORMAT_MOD_4_TILED:
> > > - case I915_FORMAT_MOD_X_TILED:
> > > - return true;
> > > - default:
> > > - return false;
> > > - }
> > > + return true;
> >
> > we could also simply kill this function... the compiler does the right
> > thing, but users navigating on the code needs to do an extra
> > ctag/cscope inspections to see that it is a simple return.  But well,
> > the code do gets prettier with the function :)
> 
> I've been thinking of converting a bunch of this stuff to vfuncs, so keeping 
> the
> function around in anticipation of that seemed semi-reasonable.
> 
> > So, up to you:
> >
> > Reviewed-by: Rodrigo Vivi 
> 
> Thanks.
> 
> >
> > >  }
> > >
> > >  static bool tiling_is_valid(const struct intel_plane_state
> > > *plane_state)
> > > --
> > > 2.43.0
> > >
> 
> --
> Ville Syrjälä
> Intel

RE: [PATCH v3 16/16] drm/i915: Annotate more of the BIOS fb takeover failure paths

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Tuesday, January 16, 2024 1:27 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v3 16/16] drm/i915: Annotate more of the BIOS fb takeover
> failure paths
> 
> From: Ville Syrjälä 
> 
> Annotate a few more of the failure paths on the initial BIOS fb takeover to 
> avoid
> having to guess why things aren't working the way we expect.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_plane_initial.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index 00e194ee129a..d9a356d5661b 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -167,14 +167,19 @@ initial_plane_vma(struct drm_i915_private *i915,
>*/
>   if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) &&
>   mem == i915->mm.stolen_region &&
> - size * 2 > i915->dsm.usable_size)
> + size * 2 > i915->dsm.usable_size) {
> + drm_dbg_kms(>drm, "Initial FB size exceeds half of stolen,
> +discarding\n");
>   return NULL;
> + }
> 
>   obj = i915_gem_object_create_region_at(mem, phys_base, size,
>  I915_BO_ALLOC_USER |
>  I915_BO_PREALLOC);
> - if (IS_ERR(obj))
> + if (IS_ERR(obj)) {
> + drm_dbg_kms(>drm, "Failed to preallocate initial FB in
> %s\n",
> + mem->region.name);
>   return NULL;
> + }
> 
>   /*
>* Mark it WT ahead of time to avoid changing the
> --
> 2.41.0

RE: [PATCH v3 08/16] drm/i915: Fix region start during initial plane readout

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Tuesday, January 16, 2024 1:26 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v3 08/16] drm/i915: Fix region start during initial plane 
> readout
> 
> From: Ville Syrjälä 
> 
> On MTL the stolen region starts at offset 8MiB from the start of LMEMBAR. The
> dma addresses are thus also offset by 8MiB. However the mm_node/etc. is zero
> based, and i915_pages_create_for_stolen() will add the appropriate 
> region.start
> into the sg dma address. So when we do the readout we need to convert the dma
> address read from the PTE to be zero based as well.
> 
> Note that currently we don't take this path on MTL, but we should and thus 
> this
> needs to be fixed. For lmem this works correctly already as the lmem
> region.start==0.
> 
> While at it let's also make sure the address points to somewhere within the
> memory region. We don't need to check the size as
> i915_gem_object_create_region_at() should later fail if the object size 
> exceeds
> the region size.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Cc: Paz Zcharya 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_plane_initial.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index ffc92b18fcf5..db594ccf0323 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -79,16 +79,18 @@ initial_plane_vma(struct drm_i915_private *i915,
>* We don't currently expect this to ever be placed in the
>* stolen portion.
>*/
> - if (phys_base >= resource_size(>region)) {
> + if (phys_base < mem->region.start || phys_base > mem-
> >region.end) {
>   drm_err(>drm,
> - "Initial plane programming using invalid range,
> phys_base=%pa\n",
> - _base);
> + "Initial plane programming using invalid range,
> phys_base=%pa (%s [%pa-%pa])\n",
> + _base, mem->region.name, 
> >region.start,
> +>region.end);
>   return NULL;
>   }
> 
>   drm_dbg(>drm,
>   "Using phys_base=%pa, based on initial plane
> programming\n",
>   _base);
> +
> + phys_base -= mem->region.start;
>   } else {
>   phys_base = base;
>   mem = i915->mm.stolen_region;
> --
> 2.41.0

RE: [PATCH v3 09/16] drm/i915: Fix MTL initial plane readout

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Tuesday, January 16, 2024 1:26 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v3 09/16] drm/i915: Fix MTL initial plane readout
> 
> From: Ville Syrjälä 
> 
> MTL stolen memory looks more like local memory, so use the (now fixed) lmem
> path when doing the initial plane readout.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Cc: Paz Zcharya 
> Signed-off-by: Ville Syrjälä 
> ---
>  .../drm/i915/display/intel_plane_initial.c| 25 +--
>  1 file changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index db594ccf0323..c72d4cacf631 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -59,7 +59,7 @@ initial_plane_vma(struct drm_i915_private *i915,
>   return NULL;
> 
>   base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);
> - if (IS_DGFX(i915)) {
> + if (IS_DGFX(i915) || HAS_LMEMBAR_SMEM_STOLEN(i915)) {
>   gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
>   gen8_pte_t pte;
> 
> @@ -73,11 +73,20 @@ initial_plane_vma(struct drm_i915_private *i915,
>   }
> 
>   phys_base = pte & GEN12_GGTT_PTE_ADDR_MASK;
> - mem = i915->mm.regions[INTEL_REGION_LMEM_0];
> +
> + if (IS_DGFX(i915))
> + mem = i915->mm.regions[INTEL_REGION_LMEM_0];
> + else
> + mem = i915->mm.stolen_region;
> + if (!mem) {
> + drm_dbg_kms(>drm,
> + "Initial plane memory region not
> initialized\n");
> + return NULL;
> + }
> 
>   /*
> -  * We don't currently expect this to ever be placed in the
> -  * stolen portion.
> +  * On lmem we don't currently expect this to
> +  * ever be placed in the stolen portion.
>*/
>   if (phys_base < mem->region.start || phys_base > mem-
> >region.end) {
>   drm_err(>drm,
> @@ -94,11 +103,13 @@ initial_plane_vma(struct drm_i915_private *i915,
>   } else {
>   phys_base = base;
>   mem = i915->mm.stolen_region;
> + if (!mem) {
> + drm_dbg_kms(>drm,
> + "Initial plane memory region not
> initialized\n");
> + return NULL;
> + }
>   }
> 
> - if (!mem)
> - return NULL;
> -
>   size = round_up(plane_config->base + plane_config->size,
>   mem->min_page_size);
>   size -= base;
> --
> 2.41.0

RE: [PATCH 0/9] drm/i915: Cursor vblank evasion

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 0/9] drm/i915: Cursor vblank evasion
> 
> From: Ville Syrjälä 
> 
> MTL seems very good at racing the cursor mailbox updates against the vblank,
> causing things to not latch for long enough to cause GTT faults. Attempt to 
> hook
> up vblank evasions into the legacy cursor path to avoid this.
> 
> Also revert a dangerous wm/ddb change related to cursors.

I have already RB'ed the changes in the series but somehow patchwork had issues 
and
not reflecting the same.

FWIW, this series is
Reviewed-by: Uma Shankar 

Please merge once the CI results show green, seems one test
igt@kms_cursor_legacy@torture-move@pipe-a throwing some warnings.

Regards,
Uma Shankar

> Ville Syrjälä (9):
>   drm/i915: Decouple intel_crtc_vblank_evade_scanlines() from atomic
> commits
>   drm/i915: Reorder drm_vblank_put() vs. need_vlv_dsi_wa
>   drm/i915: Introduce struct intel_vblank_evade_ctx
>   drm/i915: Include need_vlv_dsi_wa in intel_vblank_evade_ctx
>   drm/i915: Extract intel_vblank_evade()
>   drm/i915: Move the min/max scanline sanity check into
> intel_vblank_evade()
>   drm/i915: Move intel_vblank_evade() & co. into intel_vblank.c
>   drm/i915: Perform vblank evasion around legacy cursor updates
>   Revert "drm/i915/xe2lpd: Treat cursor plane as regular plane for DDB
> allocation"
> 
>  .../gpu/drm/i915/display/intel_atomic_plane.c |   6 +-
>  drivers/gpu/drm/i915/display/intel_crtc.c | 128 ++---
>  drivers/gpu/drm/i915/display/intel_cursor.c   |  16 ++-
>  drivers/gpu/drm/i915/display/intel_vblank.c   | 130 ++
>  drivers/gpu/drm/i915/display/intel_vblank.h   |  12 ++
>  drivers/gpu/drm/i915/display/skl_watermark.c  |  16 +--
>  6 files changed, 170 insertions(+), 138 deletions(-)
> 
> --
> 2.41.0

RE: [PATCH 8/9] drm/i915: Perform vblank evasion around legacy cursor updates

[Shankar, Uma]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, December 20, 2023 8:19 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 8/9] drm/i915: Perform vblank evasion around legacy cursor
> updates
> 
> On Wed, Dec 20, 2023 at 11:45:44AM +, Shankar, Uma wrote:
> >
> >
> > > -----Original Message-
> > > From: Shankar, Uma
> > > Sent: Wednesday, December 20, 2023 5:11 PM
> > > To: Ville Syrjala ;
> > > intel-gfx@lists.freedesktop.org
> > > Subject: RE: [PATCH 8/9] drm/i915: Perform vblank evasion around
> > > legacy cursor updates
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Intel-gfx  On
> > > > Behalf Of Ville Syrjala
> > > > Sent: Wednesday, December 13, 2023 3:55 PM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Subject: [PATCH 8/9] drm/i915: Perform vblank evasion around
> > > > legacy cursor updates
> > > >
> > > > From: Ville Syrjälä 
> > > >
> > > > Our legacy cursor updates are actually mailbox updates.
> > > > Ie. the hardware latches things once per frame on start of vblank,
> > > > but we issue an number of updates per frame, withough any attempt
> > > > to synchronize against the vblank in software. So in theory only
> > > > the last update issued during the frame will latch, and the previous 
> > > > ones are
> discarded.
> > > >
> > > > However this can lead to problems with maintaining the ggtt/iommu
> > > > mappings as we have no idea which updates will actually latch.
> > > >
> > > > The problem is exacerbated by the hardware's annoying disarming
> > > > behaviour; any non-arming register write will disarm an already
> > > > armed update, only to be rearmed later by the arming register
> > > > (CURBASE in case of cursors). If a disarming write happens just
> > > > before the start of vblank, and the arming write happens after
> > > > start of vblank we have effectively prevented the hardware from
> > > > latching anything. And if we manage to straddle multiple
> > > > sequential vblank starts in this manner we effectively prevent the
> > > > hardware from latching any new registers for an arbitrary amount
> > > > of time. This provides more time for the (potentially still in
> > > use by the hardware) gtt/iommu mappings to be torn down.
> > > >
> > > > A partial solution, of course, is to use vblank evasion to avoid
> > > > the register writes from spreading on both sides of the start of vblank.
> > > >
> > > > I've previously highlighted this problem as a general issue
> > > > affecting mailbox updates. I even added some notes to the
> > > > {i9xx,skl}_crtc_planes_update_arm() to remind us that the noarm
> > > > and arm phases both need to pulled into the vblank evasion
> > > > critical section if we actually decided to implement mailbox
> > > > updates in general. But as I never impelemented the
> > > > noarm+arm split for cursors we don't have to worry about that for the
> moment.
> > > >
> > > > We've been lucky enough so far that this hasn't really caused
> > > > problems. One thing that does help is that Xorg generally sticks
> > > > to the same cursor BO. But igt seems pretty good at hitting this
> > > > on MTL now, so apparently we have to start thinking about this.
> > >
> > > Was not aware that a disarming update will disarm an armed update
> > > and make the vblank sync irrelevant. Thanks for a good writeup
> > > highlighting the issue, really helps.
> > >
> > > Yeah, this should help maintain consistency with cursor updates and
> > > ensure the sync at vblank. Change looks Good to me.
> > > Reviewed-by: Uma Shankar 
> > >
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_cursor.c | 16 ++--
> > > >  1 file changed, 10 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > > > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > > > index 926e2de00eb5..77531838001f 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > >

RE: [PATCH 8/9] drm/i915: Perform vblank evasion around legacy cursor updates

[Shankar, Uma]

> -Original Message-
> From: Shankar, Uma
> Sent: Wednesday, December 20, 2023 5:11 PM
> To: Ville Syrjala ; 
> intel-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 8/9] drm/i915: Perform vblank evasion around legacy cursor
> updates
> 
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Ville Syrjala
> > Sent: Wednesday, December 13, 2023 3:55 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [PATCH 8/9] drm/i915: Perform vblank evasion around legacy
> > cursor updates
> >
> > From: Ville Syrjälä 
> >
> > Our legacy cursor updates are actually mailbox updates.
> > Ie. the hardware latches things once per frame on start of vblank, but
> > we issue an number of updates per frame, withough any attempt to
> > synchronize against the vblank in software. So in theory only the last
> > update issued during the frame will latch, and the previous ones are 
> > discarded.
> >
> > However this can lead to problems with maintaining the ggtt/iommu
> > mappings as we have no idea which updates will actually latch.
> >
> > The problem is exacerbated by the hardware's annoying disarming
> > behaviour; any non-arming register write will disarm an already armed
> > update, only to be rearmed later by the arming register (CURBASE in
> > case of cursors). If a disarming write happens just before the start
> > of vblank, and the arming write happens after start of vblank we have
> > effectively prevented the hardware from latching anything. And if we
> > manage to straddle multiple sequential vblank starts in this manner we
> > effectively prevent the hardware from latching any new registers for
> > an arbitrary amount of time. This provides more time for the (potentially 
> > still in
> use by the hardware) gtt/iommu mappings to be torn down.
> >
> > A partial solution, of course, is to use vblank evasion to avoid the
> > register writes from spreading on both sides of the start of vblank.
> >
> > I've previously highlighted this problem as a general issue affecting
> > mailbox updates. I even added some notes to the
> > {i9xx,skl}_crtc_planes_update_arm() to remind us that the noarm and
> > arm phases both need to pulled into the vblank evasion critical
> > section if we actually decided to implement mailbox updates in
> > general. But as I never impelemented the
> > noarm+arm split for cursors we don't have to worry about that for the 
> > moment.
> >
> > We've been lucky enough so far that this hasn't really caused
> > problems. One thing that does help is that Xorg generally sticks to
> > the same cursor BO. But igt seems pretty good at hitting this on MTL
> > now, so apparently we have to start thinking about this.
> 
> Was not aware that a disarming update will disarm an armed update and make
> the vblank sync irrelevant. Thanks for a good writeup highlighting the issue, 
> really
> helps.
> 
> Yeah, this should help maintain consistency with cursor updates and ensure the
> sync at vblank. Change looks Good to me.
> Reviewed-by: Uma Shankar 
> 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cursor.c | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > index 926e2de00eb5..77531838001f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > @@ -22,6 +22,7 @@
> >  #include "intel_frontbuffer.h"
> >  #include "intel_psr.h"
> >  #include "intel_psr_regs.h"
> > +#include "intel_vblank.h"
> >  #include "skl_watermark.h"
> >
> >  #include "gem/i915_gem_object.h"
> > @@ -647,12 +648,14 @@ intel_legacy_cursor_update(struct drm_plane
> > *_plane, {
> > struct intel_plane *plane = to_intel_plane(_plane);
> > struct intel_crtc *crtc = to_intel_crtc(_crtc);
> > +   struct drm_i915_private *i915 = to_i915(plane->base.dev);
> > struct intel_plane_state *old_plane_state =
> > to_intel_plane_state(plane->base.state);
> > struct intel_plane_state *new_plane_state;
> > struct intel_crtc_state *crtc_state =
> > to_intel_crtc_state(crtc->base.state);
> > struct intel_crtc_state *new_crtc_state;
> > +   struct intel_vblank_evade_ctx evade;
> > int ret;
> >
> > /*
> > @@ -745,14 +748,15 @@ intel_legac

RE: [PATCH 8/9] drm/i915: Perform vblank evasion around legacy cursor updates

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 8/9] drm/i915: Perform vblank evasion around legacy cursor
> updates
> 
> From: Ville Syrjälä 
> 
> Our legacy cursor updates are actually mailbox updates.
> Ie. the hardware latches things once per frame on start of vblank, but we 
> issue an
> number of updates per frame, withough any attempt to synchronize against the
> vblank in software. So in theory only the last update issued during the frame 
> will
> latch, and the previous ones are discarded.
> 
> However this can lead to problems with maintaining the ggtt/iommu mappings as
> we have no idea which updates will actually latch.
> 
> The problem is exacerbated by the hardware's annoying disarming behaviour; any
> non-arming register write will disarm an already armed update, only to be
> rearmed later by the arming register (CURBASE in case of cursors). If a 
> disarming
> write happens just before the start of vblank, and the arming write happens 
> after
> start of vblank we have effectively prevented the hardware from latching
> anything. And if we manage to straddle multiple sequential vblank starts in 
> this
> manner we effectively prevent the hardware from latching any new registers for
> an arbitrary amount of time. This provides more time for the (potentially 
> still in
> use by the hardware) gtt/iommu mappings to be torn down.
> 
> A partial solution, of course, is to use vblank evasion to avoid the register 
> writes
> from spreading on both sides of the start of vblank.
> 
> I've previously highlighted this problem as a general issue affecting mailbox
> updates. I even added some notes to the
> {i9xx,skl}_crtc_planes_update_arm() to remind us that the noarm and arm phases
> both need to pulled into the vblank evasion critical section if we actually 
> decided
> to implement mailbox updates in general. But as I never impelemented the
> noarm+arm split for cursors we don't have to worry about that for the moment.
> 
> We've been lucky enough so far that this hasn't really caused problems. One 
> thing
> that does help is that Xorg generally sticks to the same cursor BO. But igt 
> seems
> pretty good at hitting this on MTL now, so apparently we have to start 
> thinking
> about this.

Was not aware that a disarming update will disarm an armed update and make the 
vblank sync
irrelevant. Thanks for a good writeup highlighting the issue, really helps.

Yeah, this should help maintain consistency with cursor updates and ensure the 
sync at
vblank. Change looks Good to me.
Reviewed-by: Uma Shankar 
 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index 926e2de00eb5..77531838001f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -22,6 +22,7 @@
>  #include "intel_frontbuffer.h"
>  #include "intel_psr.h"
>  #include "intel_psr_regs.h"
> +#include "intel_vblank.h"
>  #include "skl_watermark.h"
> 
>  #include "gem/i915_gem_object.h"
> @@ -647,12 +648,14 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> {
>   struct intel_plane *plane = to_intel_plane(_plane);
>   struct intel_crtc *crtc = to_intel_crtc(_crtc);
> + struct drm_i915_private *i915 = to_i915(plane->base.dev);
>   struct intel_plane_state *old_plane_state =
>   to_intel_plane_state(plane->base.state);
>   struct intel_plane_state *new_plane_state;
>   struct intel_crtc_state *crtc_state =
>   to_intel_crtc_state(crtc->base.state);
>   struct intel_crtc_state *new_crtc_state;
> + struct intel_vblank_evade_ctx evade;
>   int ret;
> 
>   /*
> @@ -745,14 +748,15 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
>*/
>   crtc_state->active_planes = new_crtc_state->active_planes;
> 
> - /*
> -  * Technically we should do a vblank evasion here to make
> -  * sure all the cursor registers update on the same frame.
> -  * For now just make sure the register writes happen as
> -  * quickly as possible to minimize the race window.
> -  */
> + intel_vblank_evade_init(crtc_state, crtc_state, );
> +
>   local_irq_disable();
> 
> + if (!drm_WARN_ON(>drm, drm_crtc_vblank_get(>base))) {
> + intel_vblank_evade();
> + drm_crtc_vblank_put(>base);
> + }
> +
>   if (new_plane_state->uapi.visible) {
>   intel_plane_update_noarm(plane, crtc_state, new_plane_state);
>   intel_plane_update_arm(plane, crtc_state, new_plane_state);
> --
> 2.41.0

RE: [PATCH 7/9] drm/i915: Move intel_vblank_evade() & co. into intel_vblank.c

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 7/9] drm/i915: Move intel_vblank_evade() & co. into
> intel_vblank.c
> 
> From: Ville Syrjälä 
> 
> intel_vblank.c seems like the appropriate place for the core vblank evasion 
> code.
> Move it there.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c   | 135 
>  drivers/gpu/drm/i915/display/intel_vblank.c | 130 +++
> drivers/gpu/drm/i915/display/intel_vblank.h |  12 ++
>  3 files changed, 142 insertions(+), 135 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 11a6a4b0a258..25593f6aae7d 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -461,141 +461,6 @@ int intel_usecs_to_scanlines(const struct
> drm_display_mode *adjusted_mode,
>   1000 * adjusted_mode->crtc_htotal);  }
> 
> -static int intel_mode_vblank_start(const struct drm_display_mode *mode) -{
> - int vblank_start = mode->crtc_vblank_start;
> -
> - if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> - vblank_start = DIV_ROUND_UP(vblank_start, 2);
> -
> - return vblank_start;
> -}
> -
> -struct intel_vblank_evade_ctx {
> - struct intel_crtc *crtc;
> - int min, max, vblank_start;
> - bool need_vlv_dsi_wa;
> -};
> -
> -static void intel_vblank_evade_init(const struct intel_crtc_state 
> *old_crtc_state,
> - const struct intel_crtc_state 
> *new_crtc_state,
> - struct intel_vblank_evade_ctx *evade)
> -{
> - struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> - struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> - const struct intel_crtc_state *crtc_state;
> - const struct drm_display_mode *adjusted_mode;
> -
> - evade->crtc = crtc;
> -
> - evade->need_vlv_dsi_wa = (IS_VALLEYVIEW(i915) ||
> IS_CHERRYVIEW(i915)) &&
> - intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
> -
> - /*
> -  * During fastsets/etc. the transcoder is still
> -  * running with the old timings at this point.
> -  *
> -  * TODO: maybe just use the active timings here?
> -  */
> - if (intel_crtc_needs_modeset(new_crtc_state))
> - crtc_state = new_crtc_state;
> - else
> - crtc_state = old_crtc_state;
> -
> - adjusted_mode = _state->hw.adjusted_mode;
> -
> - if (crtc->mode_flags & I915_MODE_FLAG_VRR) {
> - /* timing changes should happen with VRR disabled */
> - drm_WARN_ON(crtc->base.dev,
> intel_crtc_needs_modeset(new_crtc_state) ||
> - new_crtc_state->update_m_n || new_crtc_state-
> >update_lrr);
> -
> - if (intel_vrr_is_push_sent(crtc_state))
> - evade->vblank_start =
> intel_vrr_vmin_vblank_start(crtc_state);
> - else
> - evade->vblank_start =
> intel_vrr_vmax_vblank_start(crtc_state);
> - } else {
> - evade->vblank_start =
> intel_mode_vblank_start(adjusted_mode);
> - }
> -
> - /* FIXME needs to be calibrated sensibly */
> - evade->min = evade->vblank_start -
> intel_usecs_to_scanlines(adjusted_mode,
> -
>   VBLANK_EVASION_TIME_US);
> - evade->max = evade->vblank_start - 1;
> -
> - /*
> -  * M/N and TRANS_VTOTAL are double buffered on the transcoder's
> -  * undelayed vblank, so with seamless M/N and LRR we must evade
> -  * both vblanks.
> -  *
> -  * DSB execution waits for the transcoder's undelayed vblank,
> -  * hence we must kick off the commit before that.
> -  */
> - if (new_crtc_state->dsb || new_crtc_state->update_m_n ||
> new_crtc_state->update_lrr)
> - evade->min -= adjusted_mode->crtc_vblank_start -
> adjusted_mode->crtc_vdisplay;
> -}
> -
> -/* must be called with vblank interrupt already enabled! */ -static int
> intel_vblank_evade(struct intel_vblank_evade_ctx *evade) -{
> - struct intel_crtc *crtc = evade->crtc;
> - struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> - long timeout = msecs_to_jiffies_timeout(1);
> - wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
> - DEFINE_WAIT(wait);
> - int scanline;
> -
> - if (evade->min <= 0 || evade->max <= 0)
> - return 0;
> -
> - for (;;) {
> - /*
> -  * prepare_to_wait() has a memory barrier, which guarantees
> -  * other CPUs can see the task state update by the time we
> -  * read the scanline.
> -  */
> - prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
> -
> - scanline = intel_get_crtc_scanline(crtc);
> - 

RE: [PATCH 6/9] drm/i915: Move the min/max scanline sanity check into intel_vblank_evade()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 6/9] drm/i915: Move the min/max scanline sanity check into
> intel_vblank_evade()
> 
> From: Ville Syrjälä 
> 
> There isn't really any reason to make the caller suffer through checking the 
> vblank
> evasion min/max scanlines. If we somehow ended up with bogus values (which
> really shouldn't happen) then just skip the actual vblank evasion loop but
> otherwise plow ahead as normal.
> 
> The only "real" change is that we now get+put a vblank reference even if the
> min/max values are bogus, previously we skipped directly to the end.

Looks fine to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 26a07b2219bf..11a6a4b0a258 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -544,6 +544,9 @@ static int intel_vblank_evade(struct
> intel_vblank_evade_ctx *evade)
>   DEFINE_WAIT(wait);
>   int scanline;
> 
> + if (evade->min <= 0 || evade->max <= 0)
> + return 0;
> +
>   for (;;) {
>   /*
>* prepare_to_wait() has a memory barrier, which guarantees
> @@ -633,8 +636,6 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>   intel_crtc_vblank_work_init(new_crtc_state);
> 
>   intel_vblank_evade_init(old_crtc_state, new_crtc_state, );
> - if (evade.min <= 0 || evade.max <= 0)
> - goto irq_disable;
> 
>   if (drm_WARN_ON(_priv->drm, drm_crtc_vblank_get(
> >base)))
>   goto irq_disable;
> --
> 2.41.0

RE: [PATCH 5/9] drm/i915: Extract intel_vblank_evade()

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 5/9] drm/i915: Extract intel_vblank_evade()
> 
> From: Ville Syrjälä 
> 
> Pull the core vblank evasion loop into its own function, so that we can reuse 
> it
> elsewhere later.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 135 --
>  1 file changed, 75 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 92cfb7c8eadb..26a07b2219bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -472,6 +472,7 @@ static int intel_mode_vblank_start(const struct
> drm_display_mode *mode)  }
> 
>  struct intel_vblank_evade_ctx {
> + struct intel_crtc *crtc;
>   int min, max, vblank_start;
>   bool need_vlv_dsi_wa;
>  };
> @@ -485,6 +486,8 @@ static void intel_vblank_evade_init(const struct
> intel_crtc_state *old_crtc_stat
>   const struct intel_crtc_state *crtc_state;
>   const struct drm_display_mode *adjusted_mode;
> 
> + evade->crtc = crtc;
> +
>   evade->need_vlv_dsi_wa = (IS_VALLEYVIEW(i915) ||
> IS_CHERRYVIEW(i915)) &&
>   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
> 
> @@ -531,67 +534,15 @@ static void intel_vblank_evade_init(const struct
> intel_crtc_state *old_crtc_stat
>   evade->min -= adjusted_mode->crtc_vblank_start -
> adjusted_mode->crtc_vdisplay;  }
> 
> -/**
> - * intel_pipe_update_start() - start update of a set of display registers
> - * @state: the atomic state
> - * @crtc: the crtc
> - *
> - * Mark the start of an update to pipe registers that should be updated
> - * atomically regarding vblank. If the next vblank will happens within
> - * the next 100 us, this function waits until the vblank passes.
> - *
> - * After a successful call to this function, interrupts will be disabled
> - * until a subsequent call to intel_pipe_update_end(). That is done to
> - * avoid random delays.
> - */
> -void intel_pipe_update_start(struct intel_atomic_state *state,
> -  struct intel_crtc *crtc)
> +/* must be called with vblank interrupt already enabled! */ static int
> +intel_vblank_evade(struct intel_vblank_evade_ctx *evade)
>  {
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - const struct intel_crtc_state *old_crtc_state =
> - intel_atomic_get_old_crtc_state(state, crtc);
> - struct intel_crtc_state *new_crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
> + struct intel_crtc *crtc = evade->crtc;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>   long timeout = msecs_to_jiffies_timeout(1);
> - int scanline;
>   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
> - struct intel_vblank_evade_ctx evade;
>   DEFINE_WAIT(wait);
> -
> - intel_psr_lock(new_crtc_state);
> -
> - if (new_crtc_state->do_async_flip) {
> - spin_lock_irq(>base.dev->event_lock);
> - /* arm the event for the flip done irq handler */
> - crtc->flip_done_event = new_crtc_state->uapi.event;
> - spin_unlock_irq(>base.dev->event_lock);
> -
> - new_crtc_state->uapi.event = NULL;
> - return;
> - }
> -
> - if (intel_crtc_needs_vblank_work(new_crtc_state))
> - intel_crtc_vblank_work_init(new_crtc_state);
> -
> - intel_vblank_evade_init(old_crtc_state, new_crtc_state, );
> - if (evade.min <= 0 || evade.max <= 0)
> - goto irq_disable;
> -
> - if (drm_WARN_ON(_priv->drm, drm_crtc_vblank_get(
> >base)))
> - goto irq_disable;
> -
> - /*
> -  * Wait for psr to idle out after enabling the VBL interrupts
> -  * VBL interrupts will start the PSR exit and prevent a PSR
> -  * re-entry as well.
> -  */
> - intel_psr_wait_for_idle_locked(new_crtc_state);
> -
> - local_irq_disable();
> -
> - crtc->debug.min_vbl = evade.min;
> - crtc->debug.max_vbl = evade.max;
> - trace_intel_pipe_update_start(crtc);
> + int scanline;
> 
>   for (;;) {
>   /*
> @@ -602,11 +553,11 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>   prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
> 
>   scanline = intel_get_crtc_scanline(crtc);
> - if (scanline < evade.min || scanline > evade.max)
> + if (scanline < evade->min || scanline > evade->max)
>   break;
> 
>   if (!timeout) {
> - drm_err(_priv->drm,
> + drm_err(>drm,
>   "Potential atomic update failure on pipe %c\n",
>   

RE: [PATCH 4/9] drm/i915: Include need_vlv_dsi_wa in intel_vblank_evade_ctx

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 4/9] drm/i915: Include need_vlv_dsi_wa in
> intel_vblank_evade_ctx
> 
> From: Ville Syrjälä 
> 
> Pull the need_vlv_dsi_wa details into intel_vblank_evade_init() so that caller
> doesn't have to care about it.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 93474fc9e502..92cfb7c8eadb 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -473,6 +473,7 @@ static int intel_mode_vblank_start(const struct
> drm_display_mode *mode)
> 
>  struct intel_vblank_evade_ctx {
>   int min, max, vblank_start;
> + bool need_vlv_dsi_wa;
>  };
> 
>  static void intel_vblank_evade_init(const struct intel_crtc_state 
> *old_crtc_state,
> @@ -480,9 +481,13 @@ static void intel_vblank_evade_init(const struct
> intel_crtc_state *old_crtc_stat
>   struct intel_vblank_evade_ctx *evade)  {
>   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>   const struct intel_crtc_state *crtc_state;
>   const struct drm_display_mode *adjusted_mode;
> 
> + evade->need_vlv_dsi_wa = (IS_VALLEYVIEW(i915) ||
> IS_CHERRYVIEW(i915)) &&
> + intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
> +
>   /*
>* During fastsets/etc. the transcoder is still
>* running with the old timings at this point.
> @@ -550,8 +555,6 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>   long timeout = msecs_to_jiffies_timeout(1);
>   int scanline;
>   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
> - bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) ||
> IS_CHERRYVIEW(dev_priv)) &&
> - intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
>   struct intel_vblank_evade_ctx evade;
>   DEFINE_WAIT(wait);
> 
> @@ -633,7 +636,7 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>*
>* FIXME figure out if BXT+ DSI suffers from this as well
>*/
> - while (need_vlv_dsi_wa && scanline == evade.vblank_start)
> + while (evade.need_vlv_dsi_wa && scanline == evade.vblank_start)
>   scanline = intel_get_crtc_scanline(crtc);
> 
>   drm_crtc_vblank_put(>base);
> --
> 2.41.0

RE: [PATCH 3/9] drm/i915: Introduce struct intel_vblank_evade_ctx

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 3/9] drm/i915: Introduce struct intel_vblank_evade_ctx
> 
> From: Ville Syrjälä 
> 
> Collect the information needed for vblank evasions into a structure that we 
> can
> pass around more easily.
> 
> And let's rename intel_crtc_vblank_evade_scanlines() to just
> intel_vblank_evade_init() so that better describes the intended usage of
> initializing the context.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 40 +--
>  1 file changed, 22 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 4df8927bb062..93474fc9e502 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -471,9 +471,13 @@ static int intel_mode_vblank_start(const struct
> drm_display_mode *mode)
>   return vblank_start;
>  }
> 
> -static void intel_crtc_vblank_evade_scanlines(const struct intel_crtc_state
> *old_crtc_state,
> -   const struct intel_crtc_state
> *new_crtc_state,
> -   int *min, int *max, int 
> *vblank_start)
> +struct intel_vblank_evade_ctx {
> + int min, max, vblank_start;
> +};
> +
> +static void intel_vblank_evade_init(const struct intel_crtc_state 
> *old_crtc_state,
> + const struct intel_crtc_state 
> *new_crtc_state,
> + struct intel_vblank_evade_ctx *evade)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>   const struct intel_crtc_state *crtc_state; @@ -498,17 +502,17 @@
> static void intel_crtc_vblank_evade_scanlines(const struct intel_crtc_state 
> *old
>   new_crtc_state->update_m_n || new_crtc_state-
> >update_lrr);
> 
>   if (intel_vrr_is_push_sent(crtc_state))
> - *vblank_start = intel_vrr_vmin_vblank_start(crtc_state);
> + evade->vblank_start =
> intel_vrr_vmin_vblank_start(crtc_state);
>   else
> - *vblank_start =
> intel_vrr_vmax_vblank_start(crtc_state);
> + evade->vblank_start =
> intel_vrr_vmax_vblank_start(crtc_state);
>   } else {
> - *vblank_start = intel_mode_vblank_start(adjusted_mode);
> + evade->vblank_start =
> intel_mode_vblank_start(adjusted_mode);
>   }
> 
>   /* FIXME needs to be calibrated sensibly */
> - *min = *vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> -
>   VBLANK_EVASION_TIME_US);
> - *max = *vblank_start - 1;
> + evade->min = evade->vblank_start -
> intel_usecs_to_scanlines(adjusted_mode,
> +
>   VBLANK_EVASION_TIME_US);
> + evade->max = evade->vblank_start - 1;
> 
>   /*
>* M/N and TRANS_VTOTAL are double buffered on the transcoder's @@
> -519,7 +523,7 @@ static void intel_crtc_vblank_evade_scanlines(const struct
> intel_crtc_state *old
>* hence we must kick off the commit before that.
>*/
>   if (new_crtc_state->dsb || new_crtc_state->update_m_n ||
> new_crtc_state->update_lrr)
> - *min -= adjusted_mode->crtc_vblank_start - adjusted_mode-
> >crtc_vdisplay;
> + evade->min -= adjusted_mode->crtc_vblank_start -
> +adjusted_mode->crtc_vdisplay;
>  }
> 
>  /**
> @@ -544,10 +548,11 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>   struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(state, crtc);
>   long timeout = msecs_to_jiffies_timeout(1);
> - int scanline, min, max, vblank_start;
> + int scanline;
>   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
>   bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) ||
> IS_CHERRYVIEW(dev_priv)) &&
>   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
> + struct intel_vblank_evade_ctx evade;
>   DEFINE_WAIT(wait);
> 
>   intel_psr_lock(new_crtc_state);
> @@ -565,9 +570,8 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>   if (intel_crtc_needs_vblank_work(new_crtc_state))
>   intel_crtc_vblank_work_init(new_crtc_state);
> 
> - intel_crtc_vblank_evade_scanlines(old_crtc_state, new_crtc_state,
> -   , , _start);
> - if (min <= 0 || max <= 0)
> + intel_vblank_evade_init(old_crtc_state, new_crtc_state, );
> + if (evade.min <= 0 || evade.max <= 0)
>   goto irq_disable;
> 
>   if (drm_WARN_ON(_priv->drm, drm_crtc_vblank_get(
> >base)))
> @@ -582,8 +586,8 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
> 
>   local_irq_disable();
> 
> - 

RE: [PATCH 2/9] drm/i915: Reorder drm_vblank_put() vs. need_vlv_dsi_wa

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 2/9] drm/i915: Reorder drm_vblank_put() vs. need_vlv_dsi_wa
> 
> From: Ville Syrjälä 
> 
> Drop the vblank reference only after we've done the hideous need_vlv_dsi_wa
> stuff. This will make it easier to reuse the the vblank evasion machinery
> elsewhere.
> 
> Keeping the vblank reference for a bit longer is not a problem. In fact we 
> might
> want to not drop it at all until intel_pipe_update_end(), but we'll leave 
> that idea
> for later.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index d5c3f6078e42..4df8927bb062 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -614,8 +614,6 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
> 
>   finish_wait(wq, );
> 
> - drm_crtc_vblank_put(>base);
> -
>   /*
>* On VLV/CHV DSI the scanline counter would appear to
>* increment approx. 1/3 of a scanline before start of vblank.
> @@ -634,6 +632,8 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>   while (need_vlv_dsi_wa && scanline == vblank_start)
>   scanline = intel_get_crtc_scanline(crtc);
> 
> + drm_crtc_vblank_put(>base);
> +
>   crtc->debug.scanline_start = scanline;
>   crtc->debug.start_vbl_time = ktime_get();
>   crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
> --
> 2.41.0

RE: [PATCH 1/9] drm/i915: Decouple intel_crtc_vblank_evade_scanlines() from atomic commits

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, December 13, 2023 3:55 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 1/9] drm/i915: Decouple intel_crtc_vblank_evade_scanlines()
> from atomic commits
> 
> From: Ville Syrjälä 
> 
> We'll be needing to do vblank evasion around legacy cursor updates, which 
> don't
> have the intel_atomic_state around. So let's remove this dependency on a full
> commit and pass the crtc state in by hand.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 8a84a31c7b48..d5c3f6078e42 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -471,14 +471,11 @@ static int intel_mode_vblank_start(const struct
> drm_display_mode *mode)
>   return vblank_start;
>  }
> 
> -static void intel_crtc_vblank_evade_scanlines(struct intel_atomic_state 
> *state,
> -   struct intel_crtc *crtc,
> +static void intel_crtc_vblank_evade_scanlines(const struct intel_crtc_state
> *old_crtc_state,
> +   const struct intel_crtc_state
> *new_crtc_state,
> int *min, int *max, int 
> *vblank_start)
> {
> - const struct intel_crtc_state *old_crtc_state =
> - intel_atomic_get_old_crtc_state(state, crtc);
> - const struct intel_crtc_state *new_crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
> + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>   const struct intel_crtc_state *crtc_state;
>   const struct drm_display_mode *adjusted_mode;
> 
> @@ -497,7 +494,7 @@ static void intel_crtc_vblank_evade_scanlines(struct
> intel_atomic_state *state,
> 
>   if (crtc->mode_flags & I915_MODE_FLAG_VRR) {
>   /* timing changes should happen with VRR disabled */
> - drm_WARN_ON(state->base.dev,
> intel_crtc_needs_modeset(new_crtc_state) ||
> + drm_WARN_ON(crtc->base.dev,
> intel_crtc_needs_modeset(new_crtc_state)
> +||
>   new_crtc_state->update_m_n || new_crtc_state-
> >update_lrr);
> 
>   if (intel_vrr_is_push_sent(crtc_state))
> @@ -542,6 +539,8 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
>   struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(state, crtc);
>   long timeout = msecs_to_jiffies_timeout(1); @@ -566,7 +565,8 @@ void
> intel_pipe_update_start(struct intel_atomic_state *state,
>   if (intel_crtc_needs_vblank_work(new_crtc_state))
>   intel_crtc_vblank_work_init(new_crtc_state);
> 
> - intel_crtc_vblank_evade_scanlines(state, crtc, , ,
> _start);
> + intel_crtc_vblank_evade_scanlines(old_crtc_state, new_crtc_state,
> +   , , _start);
>   if (min <= 0 || max <= 0)
>   goto irq_disable;
> 
> --
> 2.41.0

Re: [Intel-gfx] [topic/core-for-CI] Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Chaitanya Kumar Borah
> Sent: Wednesday, December 6, 2023 12:17 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [topic/core-for-CI] Revert "debugfs: annotate debugfs
> handlers vs. removal with lockdep"
> 
> From: Johannes Berg 
> 
> This reverts commit f4acfcd4deb1 ("debugfs: annotate debugfs handlers vs.
> removal with lockdep"), it appears to have false positives and really 
> shouldn't
> have been in the -rc series with the fixes anyway.

Acked-by: Uma Shankar 

Hi Chaitanya,
Please get the full CI run executed with this change, once its green we can
plan merge.

Regards,
Uma Shankar

> Link:https://patchwork.kernel.org/project/linux-
> fsdevel/patch/20231202114936.fd55431ab160.I911aa53abeeca138126f69
> 0d383a89b13eb05667@changeid/
> Reference: https://gitlab.freedesktop.org/drm/intel/-/issues/9802
> Signed-off-by: Johannes Berg 
> Acked-by: Greg Kroah-Hartman 
> ---
>  fs/debugfs/file.c | 10 --
>  fs/debugfs/inode.c|  7 ---
>  fs/debugfs/internal.h |  6 --
>  3 files changed, 23 deletions(-)
> 
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c index
> a5ade8c16375..5063434be0fc 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -108,12 +108,6 @@ int debugfs_file_get(struct dentry *dentry)
>   kfree(fsd);
>   fsd = READ_ONCE(dentry->d_fsdata);
>   }
> -#ifdef CONFIG_LOCKDEP
> - fsd->lock_name = kasprintf(GFP_KERNEL, "debugfs:%pd",
> dentry);
> - lockdep_register_key(>key);
> - lockdep_init_map(>lockdep_map, fsd->lock_name ?:
> "debugfs",
> -  >key, 0);
> -#endif
>   INIT_LIST_HEAD(>cancellations);
>   mutex_init(>cancellations_mtx);
>   }
> @@ -132,8 +126,6 @@ int debugfs_file_get(struct dentry *dentry)
>   if (!refcount_inc_not_zero(>active_users))
>   return -EIO;
> 
> - lock_map_acquire_read(>lockdep_map);
> -
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(debugfs_file_get);
> @@ -151,8 +143,6 @@ void debugfs_file_put(struct dentry *dentry)  {
>   struct debugfs_fsdata *fsd = READ_ONCE(dentry->d_fsdata);
> 
> - lock_map_release(>lockdep_map);
> -
>   if (refcount_dec_and_test(>active_users))
>   complete(>active_users_drained);
>  }
> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c index
> e4e7fe1bd9fb..034a617cb1a5 100644
> --- a/fs/debugfs/inode.c
> +++ b/fs/debugfs/inode.c
> @@ -243,10 +243,6 @@ static void debugfs_release_dentry(struct dentry
> *dentry)
> 
>   /* check it wasn't a dir (no fsdata) or automount (no real_fops) */
>   if (fsd && fsd->real_fops) {
> -#ifdef CONFIG_LOCKDEP
> - lockdep_unregister_key(>key);
> - kfree(fsd->lock_name);
> -#endif
>   WARN_ON(!list_empty(>cancellations));
>   mutex_destroy(>cancellations_mtx);
>   }
> @@ -755,9 +751,6 @@ static void __debugfs_file_removed(struct dentry
> *dentry)
>   if ((unsigned long)fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT)
>   return;
> 
> - lock_map_acquire(>lockdep_map);
> - lock_map_release(>lockdep_map);
> -
>   /* if we hit zero, just wait for all to finish */
>   if (!refcount_dec_and_test(>active_users)) {
>   wait_for_completion(>active_users_drained);
> diff --git a/fs/debugfs/internal.h b/fs/debugfs/internal.h index
> 0c4c68cf161f..dae80c2a469e 100644
> --- a/fs/debugfs/internal.h
> +++ b/fs/debugfs/internal.h
> @@ -7,7 +7,6 @@
> 
>  #ifndef _DEBUGFS_INTERNAL_H_
>  #define _DEBUGFS_INTERNAL_H_
> -#include 
>  #include 
> 
>  struct file_operations;
> @@ -25,11 +24,6 @@ struct debugfs_fsdata {
>   struct {
>   refcount_t active_users;
>   struct completion active_users_drained; -#ifdef
> CONFIG_LOCKDEP
> - struct lockdep_map lockdep_map;
> - struct lock_class_key key;
> - char *lock_name;
> -#endif
> 
>   /* protect cancellations */
>   struct mutex cancellations_mtx;
> --
> 2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

[Shankar, Uma]

> -Original Message-
> From: Shankar, Uma
> Sent: Monday, December 4, 2023 10:23 PM
> To: Nikula, Jani ; Ville Syrjälä
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET
> when using rate select
> 
> 
> 
> > -Original Message-
> > From: Nikula, Jani 
> > Sent: Monday, December 4, 2023 10:18 PM
> > To: Shankar, Uma ; Ville Syrjälä
> > 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: RE: [Intel-gfx] [PATCH] drm/i915/edp: don't write to
> > DP_LINK_BW_SET when using rate select
> >
> > On Mon, 04 Dec 2023, "Shankar, Uma"  wrote:
> > >> -Original Message-
> > >> From: Intel-gfx  On Behalf
> > >> Of Jani Nikula
> > >> Sent: Monday, December 4, 2023 3:28 PM
> > >> To: Ville Syrjälä 
> > >> Cc: intel-gfx@lists.freedesktop.org
> > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to
> > >> DP_LINK_BW_SET when using rate select
> > >>
> > >> On Fri, 01 Dec 2023, Ville Syrjälä  wrote:
> > >> > On Fri, Dec 01, 2023 at 03:41:41PM +0200, Jani Nikula wrote:
> > >> >> The eDP 1.5 spec adds a clarification for eDP 1.4x:
> > >> >>
> > >> >> > For eDP v1.4x, if the Source device chooses the Main-Link rate
> > >> >> > by way of DPCD 00100h, the Sink device shall ignore DPCD 
> > >> >> > 00115h[2:0].
> > >> >>
> > >> >> We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
> > >> >> DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause
> > >> >> the panel to ignore the rate set method.
> > >> >
> > >> > What a terrible way to specify this :( This means the device must
> > >> > hav some internal state to keep track of whethe BW_SET was ever 
> > >> > written.
> > >>
> > >> Indeed.
> > >>
> > >> Additionally, eDP 1.5 specifies LINK_CONFIGURATION_STATUS (DPCD
> > >> 0020Ch) which exposes the internal state as link rate set status,
> > >> and whether that status is valid or not.
> > >>
> > >> Overall the spec looks like that's just for status, but the
> > >> register is annotated Write/Read so who knows.
> > >>
> > >> >
> > >> >>
> > >> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
> > >> >> Tested-by: Animesh Manna 
> > >> >> Signed-off-by: Jani Nikula 
> > >> >> ---
> > >> >>  .../drm/i915/display/intel_dp_link_training.c | 23
> > >> >> +++
> > >> >>  1 file changed, 13 insertions(+), 10 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 dbc1b66c8ee4..6336a39030a4 100644
> > >> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > >> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > >> >> @@ -650,19 +650,22 @@ intel_dp_update_link_bw_set(struct
> > >> >> intel_dp
> > >> *intel_dp,
> > >> >>const struct intel_crtc_state *crtc_state,
> > >> >>u8 link_bw, u8 rate_select)  {
> > >> >> -  u8 link_config[2];
> > >> >> +  u8 lane_count = crtc_state->lane_count;
> > >> >>
> > >> >> -  /* Write the link configuration data */
> > >> >> -  link_config[0] = link_bw;
> > >> >> -  link_config[1] = crtc_state->lane_count;
> > >> >>if (crtc_state->enhanced_framing)
> > >> >> -  link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> > >> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET,
> > >> >> link_config, 2);
> > >> >> +  lane_count |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> > >> >> +
> > >> >> +  if (link_bw) {
> > >> >> +  /* eDP 1.3 and earlier link bw set method. */
> > >> >> +  u8 link_config[] = { link_bw, lane_count };
> > >> >>
> > >> >> -  /* eDP 1.4 rate select method. */
> 

Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

[Shankar, Uma]

> -Original Message-
> From: Nikula, Jani 
> Sent: Monday, December 4, 2023 10:18 PM
> To: Shankar, Uma ; Ville Syrjälä
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET
> when using rate select
> 
> On Mon, 04 Dec 2023, "Shankar, Uma"  wrote:
> >> -Original Message-
> >> From: Intel-gfx  On Behalf
> >> Of Jani Nikula
> >> Sent: Monday, December 4, 2023 3:28 PM
> >> To: Ville Syrjälä 
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to
> >> DP_LINK_BW_SET when using rate select
> >>
> >> On Fri, 01 Dec 2023, Ville Syrjälä  wrote:
> >> > On Fri, Dec 01, 2023 at 03:41:41PM +0200, Jani Nikula wrote:
> >> >> The eDP 1.5 spec adds a clarification for eDP 1.4x:
> >> >>
> >> >> > For eDP v1.4x, if the Source device chooses the Main-Link rate
> >> >> > by way of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
> >> >>
> >> >> We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
> >> >> DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the
> >> >> panel to ignore the rate set method.
> >> >
> >> > What a terrible way to specify this :( This means the device must
> >> > hav some internal state to keep track of whethe BW_SET was ever written.
> >>
> >> Indeed.
> >>
> >> Additionally, eDP 1.5 specifies LINK_CONFIGURATION_STATUS (DPCD
> >> 0020Ch) which exposes the internal state as link rate set status, and
> >> whether that status is valid or not.
> >>
> >> Overall the spec looks like that's just for status, but the register
> >> is annotated Write/Read so who knows.
> >>
> >> >
> >> >>
> >> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
> >> >> Tested-by: Animesh Manna 
> >> >> Signed-off-by: Jani Nikula 
> >> >> ---
> >> >>  .../drm/i915/display/intel_dp_link_training.c | 23
> >> >> +++
> >> >>  1 file changed, 13 insertions(+), 10 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 dbc1b66c8ee4..6336a39030a4 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> >> @@ -650,19 +650,22 @@ intel_dp_update_link_bw_set(struct intel_dp
> >> *intel_dp,
> >> >>const struct intel_crtc_state *crtc_state,
> >> >>u8 link_bw, u8 rate_select)  {
> >> >> -  u8 link_config[2];
> >> >> +  u8 lane_count = crtc_state->lane_count;
> >> >>
> >> >> -  /* Write the link configuration data */
> >> >> -  link_config[0] = link_bw;
> >> >> -  link_config[1] = crtc_state->lane_count;
> >> >>if (crtc_state->enhanced_framing)
> >> >> -  link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET, link_config, 2);
> >> >> +  lane_count |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> >> +
> >> >> +  if (link_bw) {
> >> >> +  /* eDP 1.3 and earlier link bw set method. */
> >> >> +  u8 link_config[] = { link_bw, lane_count };
> >> >>
> >> >> -  /* eDP 1.4 rate select method. */
> >> >> -  if (!link_bw)
> >> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_RATE_SET,
> >> >> -_select, 1);
> >> >> +  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET,
> >> link_config,
> >> >> +ARRAY_SIZE(link_config));
> >> >> +  } else {
> >> >> +  /* eDP 1.4 rate select method. */
> >> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LANE_COUNT_SET,
> >> lane_count);
> >> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LINK_RATE_SET,
> >> rate_select);
> >> >
> >> > Doesn't look there's anything in the spec that specifies when the
> >> > device is supposed to

Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Monday, December 4, 2023 3:28 PM
> To: Ville Syrjälä 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: don't write to DP_LINK_BW_SET
> when using rate select
> 
> On Fri, 01 Dec 2023, Ville Syrjälä  wrote:
> > On Fri, Dec 01, 2023 at 03:41:41PM +0200, Jani Nikula wrote:
> >> The eDP 1.5 spec adds a clarification for eDP 1.4x:
> >>
> >> > For eDP v1.4x, if the Source device chooses the Main-Link rate by
> >> > way of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
> >>
> >> We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
> >> DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the
> >> panel to ignore the rate set method.
> >
> > What a terrible way to specify this :( This means the device must hav
> > some internal state to keep track of whethe BW_SET was ever written.
> 
> Indeed.
> 
> Additionally, eDP 1.5 specifies LINK_CONFIGURATION_STATUS (DPCD 0020Ch)
> which exposes the internal state as link rate set status, and whether that 
> status is
> valid or not.
> 
> Overall the spec looks like that's just for status, but the register is 
> annotated
> Write/Read so who knows.
> 
> >
> >>
> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
> >> Tested-by: Animesh Manna 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  .../drm/i915/display/intel_dp_link_training.c | 23
> >> +++
> >>  1 file changed, 13 insertions(+), 10 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 dbc1b66c8ee4..6336a39030a4 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> @@ -650,19 +650,22 @@ intel_dp_update_link_bw_set(struct intel_dp
> *intel_dp,
> >>const struct intel_crtc_state *crtc_state,
> >>u8 link_bw, u8 rate_select)
> >>  {
> >> -  u8 link_config[2];
> >> +  u8 lane_count = crtc_state->lane_count;
> >>
> >> -  /* Write the link configuration data */
> >> -  link_config[0] = link_bw;
> >> -  link_config[1] = crtc_state->lane_count;
> >>if (crtc_state->enhanced_framing)
> >> -  link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET, link_config, 2);
> >> +  lane_count |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> >> +
> >> +  if (link_bw) {
> >> +  /* eDP 1.3 and earlier link bw set method. */
> >> +  u8 link_config[] = { link_bw, lane_count };
> >>
> >> -  /* eDP 1.4 rate select method. */
> >> -  if (!link_bw)
> >> -  drm_dp_dpcd_write(_dp->aux, DP_LINK_RATE_SET,
> >> -_select, 1);
> >> +  drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET,
> link_config,
> >> +ARRAY_SIZE(link_config));
> >> +  } else {
> >> +  /* eDP 1.4 rate select method. */
> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LANE_COUNT_SET,
> lane_count);
> >> +  drm_dp_dpcd_writeb(_dp->aux, DP_LINK_RATE_SET,
> rate_select);
> >
> > Doesn't look there's anything in the spec that specifies when the
> > device is supposed to reset its internal state to stop ignoring
> DP_LINK_RATE_SET.
> > Do we know when this panel does it? When VDD is removed?
> 
> No idea. Animesh?
> 
> I think it's just crazy writing 0 to explicitly disable DP_LINK_BW_SET renders
> DP_LINK_RATE_SET unusable. Pretty sure we've seen panels where this works as
> you'd expect.
> 
> And the above depends on pre-os using the same logic as us for choosing
> DP_LINK_RATE_SET. GOP seems to do that. But if it or some other pre-os used
> DP_LINK_BW_SET, we'd fail. With some other panels, writing the 0 might recover
> from that.

The spec does leave it a bit open on this one:

115h: LINK_RATE_SET and TX_GTC_CAPABILITY
• DPCD 1h = 00h/DPCD 02201h = 00h – Source device shall use this field to 
choose
the link rate, and the Sink device shall ignore DPCD 00100h
• DPCD 1h/DPCD 02201h = Valid link rate – Source device may optionally 
choose
a link rate associated with HBR3, HBR2,HBR, –or– RBR by writing to DPCD 00100h

So the 2nd point here does mentions that sinks can optionally use value of 
00100h
if 2201h is not 00. So programming a value to this DPCD is not right unless we 
program
the right value (not 0). 

I feel safe way would be be to go with LINK_BW_SET for DP1.3 and for DP1.4+ 
always use
LINK_RATE_SET and have it mutually exclusive. 

Some TCONs would have ignored and we got lucky but we can't leave it ambiguous, 
we will be compliant
to spec if we don't write 0x100. So let's go with this change.

Regards,
Uma Shankar

> No r-b, so do you have any better ideas?
> 
> 
> BR,
> Jani.
> 
> 
> >
> >> +  }
> >>  }
> >>
> >>  /*
> >> --
> >> 2.39.2
> 
> --
> Jani Nikula, Intel

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use a different vblank worker for atomic unpin

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Maarten
> Lankhorst
> Sent: Thursday, November 9, 2023 9:05 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915: Use a different vblank worker for
> atomic unpin
> 
> For the atomic codepath we unpin_work in old_plane_state to unpin the old fb. 
> As
> this happened after swapping state, this is allowed.
> 
> Use the unpin_work only as a barrier, and keep doing the actual unpinning in 
> the
> atomic path.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  .../gpu/drm/i915/display/intel_atomic_plane.c | 18 
> .../gpu/drm/i915/display/intel_atomic_plane.h |  2 ++
>  drivers/gpu/drm/i915/display/intel_crtc.c | 28 +++
>  3 files changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 06c2455bdd788..6ddb4f4ec79ac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -1164,6 +1164,9 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
>   intel_display_rps_mark_interactive(dev_priv, state, false);
> 
>   /* Should only be called after a successful intel_prepare_plane_fb()! */
> + if (old_plane_state->unpin_work.vblank)
> + drm_vblank_work_flush(_plane_state->unpin_work);
> +
>   intel_plane_unpin_fb(old_plane_state);
>  }
> 
> @@ -1176,3 +1179,18 @@ void intel_plane_helper_add(struct intel_plane
> *plane)  {
>   drm_plane_helper_add(>base, _plane_helper_funcs);  }
> +
> +/* Completion is enough */
> +static void intel_plane_cursor_vblank_work(struct kthread_work *base) {
> +}

Not quite clear the role of this worker here. Can you elaborate a bit more.
Once we set a work and schedule it, what is the expectation from the worker 
here.

Regards,
Uma Shankar

> +
> +void intel_plane_init_cursor_vblank_work(struct intel_plane_state
> *old_plane_state,
> +  struct intel_plane_state
> *new_plane_state) {
> + if (!old_plane_state->ggtt_vma ||
> + old_plane_state->ggtt_vma == new_plane_state->ggtt_vma)
> + return;
> +
> + drm_vblank_work_init(_plane_state->unpin_work, old_plane_state-
> >uapi.crtc,
> +  intel_plane_cursor_vblank_work); }
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> index 191dad0efc8e6..5a897cf6fa021 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> @@ -66,5 +66,7 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state);  void intel_plane_set_invisible(struct
> intel_crtc_state *crtc_state,
>  struct intel_plane_state *plane_state);  void
> intel_plane_helper_add(struct intel_plane *plane);
> +void intel_plane_init_cursor_vblank_work(struct intel_plane_state
> *old_plane_state,
> +  struct intel_plane_state
> *new_plane_state);
> 
>  #endif /* __INTEL_ATOMIC_PLANE_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 1fd068e6e26ca..755c40fd0ac13 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -559,6 +559,19 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
>   if (intel_crtc_needs_vblank_work(new_crtc_state))
>   intel_crtc_vblank_work_init(new_crtc_state);
> 
> + if (state->base.legacy_cursor_update) {
> + struct intel_plane *plane;
> + struct intel_plane_state *old_plane_state, *new_plane_state;
> + int i;
> +
> + for_each_oldnew_intel_plane_in_state(state, plane,
> old_plane_state,
> +  new_plane_state, i) {
> + if (old_plane_state->uapi.crtc == >base)
> +
>   intel_plane_init_cursor_vblank_work(old_plane_state,
> +
> new_plane_state);
> + }
> + }
> +
>   intel_crtc_vblank_evade_scanlines(state, crtc, , ,
> _start);
>   if (min <= 0 || max <= 0)
>   goto irq_disable;
> @@ -721,6 +734,21 @@ void intel_pipe_update_end(struct intel_atomic_state
> *state,
>   new_crtc_state->uapi.event = NULL;
>   }
> 
> + if (state->base.legacy_cursor_update) {
> + struct intel_plane *plane;
> + struct intel_plane_state *old_plane_state;
> + int i;
> +
> + for_each_old_intel_plane_in_state(state, plane,
> old_plane_state, i) {
> + if (old_plane_state->uapi.crtc == >base &&
> + old_plane_state->unpin_work.vblank) {
> + drm_vblank_work_schedule(_plane_state-
> >unpin_work,
> +
> drm_crtc_accurate_vblank_count(>base) + 1,
> 

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use vblank worker to unpin old legacy cursor fb safely

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Maarten
> Lankhorst
> Sent: Thursday, November 9, 2023 9:05 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 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
> 
> Cc: Maarten Lankhorst 
> Signed-off-by: Ville Syrjälä 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c   | 37 ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  3 ++
>  .../drm/i915/display/intel_display_types.h|  3 ++
>  3 files changed, 38 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index b342fad180ca5..1728ecd5cc782 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -603,6 +603,17 @@ static bool intel_cursor_format_mod_supported(struct
> drm_plane *_plane,
>   return format == DRM_FORMAT_ARGB;
>  }
> 
> +static void intel_cursor_unpin_work(struct kthread_work *base) {
> + struct drm_vblank_work *work = to_drm_vblank_work(base);
> + struct intel_plane_state *plane_state =
> + container_of(work, typeof(*plane_state), unpin_work);
> + struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
> +
> + intel_plane_unpin_fb(plane_state);
> + intel_plane_destroy_state(>base, _state->uapi); }
> +
>  static int
>  intel_legacy_cursor_update(struct drm_plane *_plane,
>  struct drm_crtc *_crtc,
> @@ -688,9 +699,14 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
>   if (ret)
>   goto out_free;
> 
> - ret = intel_plane_pin_fb(new_plane_state);
> - if (ret)
> - goto out_free;
> + if (new_plane_state->uapi.fb != old_plane_state->uapi.fb) {
> + ret = intel_plane_pin_fb(new_plane_state);
> + if (ret)
> + goto out_free;
> + } else {
> + /* magic trick */

Please add some comment on the rationale for change

> + swap(new_plane_state->ggtt_vma, old_plane_state->ggtt_vma);
> + }
> 
>   intel_frontbuffer_flush(to_intel_frontbuffer(new_plane_state->hw.fb),
>   ORIGIN_CURSOR_UPDATE);
> @@ -730,14 +746,25 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> 
>   local_irq_enable();
> 
> - intel_plane_unpin_fb(old_plane_state);
> + if (old_plane_state->uapi.fb != new_plane_state->uapi.fb) {
> + drm_vblank_work_init(_plane_state->unpin_work, 
> >base,
> +  intel_cursor_unpin_work);
> +
> + drm_vblank_work_schedule(_plane_state->unpin_work,
> +
> drm_crtc_accurate_vblank_count(>base) + 1,
> +  false);
> +
> + old_plane_state = NULL;
> + } else {
> + intel_plane_unpin_fb(old_plane_state);

Could it not cause an issue with reference counts, here we are invoking the
unpin_fb but its respective pin call is replaced with a gggtt_vma swap 
operation.
intel_unpin_fb_vma will get called which will try to lower the ref count.

> + }
> 
>  out_free:
>   if (new_crtc_state)
>   intel_crtc_destroy_state(>base, _crtc_state->uapi);
>   if (ret)
>   intel_plane_destroy_state(>base, _plane_state-
> >uapi);
> - else
> + else if (old_plane_state)
>   intel_plane_destroy_state(>base, _plane_state-
> >uapi);
>   return ret;
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3effafcbb411a..9b43810f9a934 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -64,6 +64,7 @@
>  #include "intel_crt.h"
>  #include "intel_crtc.h"
>  #include "intel_crtc_state_dump.h"
> +#include "intel_cursor.h"

This can be dropped.

>  #include "intel_ddi.h"
>  #include "intel_de.h"
>  #include "intel_display_driver.h"
> @@ -6883,6 +6884,8 @@ static void intel_commit_modeset_disables(struct
> intel_atomic_state *state)
> 
>   intel_pre_plane_update(state, crtc);
>   

Re: [Intel-gfx] [PATCH 1/3] drm: Add drm_vblank_work_flush_all().

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Maarten
> Lankhorst
> Sent: Thursday, November 9, 2023 9:05 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/3] drm: Add drm_vblank_work_flush_all().

Drop the "."

Looks good to me.
Reviewed-by: Uma Shankar 

> In some cases we want to flush all vblank work, right before vblank_off for
> example. Add a simple function to make this possible.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_vblank_work.c | 22 ++
>  include/drm/drm_vblank_work.h |  2 ++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_vblank_work.c
> b/drivers/gpu/drm/drm_vblank_work.c
> index bd481fdd6b870..27c8646a79c8e 100644
> --- a/drivers/gpu/drm/drm_vblank_work.c
> +++ b/drivers/gpu/drm/drm_vblank_work.c
> @@ -229,6 +229,28 @@ void drm_vblank_work_flush(struct drm_vblank_work
> *work)  }  EXPORT_SYMBOL(drm_vblank_work_flush);
> 
> +/**
> + * drm_vblank_work_flush_all - flush all currently pending vblank work on 
> crtc.
> + * @crtc: crtc for which vblank work to flush
> + *
> + * Wait until all currently queued vblank work on @crtc
> + * has finished executing once.
> + */
> +void drm_vblank_work_flush_all(struct drm_crtc *crtc) {
> + struct drm_device *dev = crtc->dev;
> + struct drm_vblank_crtc *vblank = >vblank[drm_crtc_index(crtc)];
> +
> + spin_lock_irq(>event_lock);
> + wait_event_lock_irq(vblank->work_wait_queue,
> + waitqueue_active(>work_wait_queue),
> + dev->event_lock);
> + spin_unlock_irq(>event_lock);
> +
> + kthread_flush_worker(vblank->worker);
> +}
> +EXPORT_SYMBOL(drm_vblank_work_flush_all);
> +
>  /**
>   * drm_vblank_work_init - initialize a vblank work item
>   * @work: vblank work item
> diff --git a/include/drm/drm_vblank_work.h b/include/drm/drm_vblank_work.h
> index eb41d0810c4ff..e04d436b72973 100644
> --- a/include/drm/drm_vblank_work.h
> +++ b/include/drm/drm_vblank_work.h
> @@ -17,6 +17,7 @@ struct drm_crtc;
>   * drm_vblank_work_init()
>   * drm_vblank_work_cancel_sync()
>   * drm_vblank_work_flush()
> + * drm_vblank_work_flush_all()
>   */
>  struct drm_vblank_work {
>   /**
> @@ -67,5 +68,6 @@ void drm_vblank_work_init(struct drm_vblank_work *work,
> struct drm_crtc *crtc,
> void (*func)(struct kthread_work *work));  bool
> drm_vblank_work_cancel_sync(struct drm_vblank_work *work);  void
> drm_vblank_work_flush(struct drm_vblank_work *work);
> +void drm_vblank_work_flush_all(struct drm_crtc *crtc);
> 
>  #endif /* !_DRM_VBLANK_WORK_H_ */
> --
> 2.39.2

Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: In intel_framebuffer_init switch to use intel_bo_to_drm_bo

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Juha-
> Pekka Heikkila
> Sent: Tuesday, November 14, 2023 2:03 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915/display: In intel_framebuffer_init
> switch to use intel_bo_to_drm_bo
> 
> Use intel_bo_to_drm_bo instead of >base.

Can you elaborate the reasoning why this was introduced and what is the
rationale for switch.

With that added, for the whole series
Reviewed-by: Uma Shankar 

> Signed-off-by: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/display/intel_fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index c1777ea35761..6d48aa3af95a 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -2093,7 +2093,7 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
>   }
>   }
> 
> - fb->obj[i] = >base;
> + fb->obj[i] = intel_bo_to_drm_bo(obj);
>   }
> 
>   ret = intel_fill_fb_info(dev_priv, intel_fb);
> --
> 2.25.1

Re: [Intel-gfx] [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline

[Shankar, Uma]

> -Original Message-
> From: Christopher Braga 
> Sent: Friday, September 8, 2023 1:39 AM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; 
> dri-
> de...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; wayland-
> de...@lists.freedesktop.org
> Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane
> Color Pipeline
> 
> 
> 
> On 8/29/2023 12:03 PM, Uma Shankar wrote:
> > Add the documentation for the new proposed Plane Color Pipeline.
> >
> > Co-developed-by: Chaitanya Kumar Borah
> > 
> > Signed-off-by: Chaitanya Kumar Borah 
> > Signed-off-by: Uma Shankar 
> > ---
> >   .../gpu/rfc/plane_color_pipeline.rst  | 394 ++
> >   1 file changed, 394 insertions(+)
> >   create mode 100644 Documentation/gpu/rfc/plane_color_pipeline.rst
> >
> > diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst
> > b/Documentation/gpu/rfc/plane_color_pipeline.rst
> > new file mode 100644
> > index ..60ce515b6ea7
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/plane_color_pipeline.rst
> > @@ -0,0 +1,394 @@
> > +===
> > + Plane Color Pipeline: A UAPI proposal
> > +===
> > +
> > +To build the proposal on, lets take the premise of a color pipeline
> > +as shown below.
> > +
> Hi Uma,
> Thanks for posting this. A few comments, with some echoing the sentiments of
> other commenters on the patch set.

Hi Christopher,
Thanks for your inputs on the series and my apologies for a late reply.

> > + +---+
> > + |RAM|
> > + |  +--++-++-+   |
> > + |  | FB 1 ||  FB 2   || FB N|   |
> > + |  +--++-++-+   |
> > + +---+
> > +   |  Plane Color Hardware Block |
> > + ++
> > + | +---v-+   +---v---+   +---v--+ |
> > + | | Plane A |   | Plane B   |   | Plane N  | |
> > + | | Pre-CSC |   | Pre-CSC   |   | Pre-CSC  | |
> > + | +---+-+   +---+---+   +---+--+ |
> > + | | |   ||
> > + | +---v-+   +---v---+   +---v--+ |
> > + | |Plane A  |   | Plane B   |   | Plane N  | |
> > + | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
> > + | +---+-+   ++--+   ++-+ |
> > + | |  |   |   |
> > + | +---v-+   +v--+   +v-+ |
> > + | | Plane A |   | Plane B   |   | Plane N  | |
> > + | |Post-CSC |   | Post-CSC  |   | Post-CSC | |
> > + | +---+-+   ++--+   ++-+ |
> > + | |  |   |   |
> > + ++
> > ++--v--v---v---|
> > +||   ||
> > +||   Pipe Blender||
> > ++++
> > +|||
> > +|+---v--+ |
> > +||  Pipe Pre-CSC| |
> > +||  | |
> > +|+---+--+ |
> > +||Pipe Color  |
> > +|+---v--+ Hardware|
> > +||  Pipe CSC/CTM| |
> > +||  | |
> > +|+---+--+ |
> > +|||
> > +|+---v--+ |
> > +||  Pipe Post-CSC   | |
> > +||  | |
> > +|+---+--+ |
> > +|||
> > ++-+
> > + |
> > + v
> > +Pipe Output
> > +
> > +Each plane consists of the following color blocks
> > + * Pre-CSC : This block can used to linearize the input frame buffer data.
> > + The linear data then can be further acted on by the following
> > + color hardware blocks in the display hardware pipeline
> > +
> > + * CSC/CTM: Used to program color transformation matrix, this block is used
> > +to perform color space conversions like BT2020 to BT709 or 
> &g

Re: [Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB command buffer cache coherency settings

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Monday, October 9, 2023 6:52 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB command buffer
> cache coherency settings
> 
> From: Ville Syrjälä 
> 
> The display engine does not snoop the caches so shoukd to mark the DSB

Nit: Typo here

I am not sure on the cache behaviour so someone from core can also ack.
To me , looks logically correct.
Reviewed-by: Uma Shankar 

> command buffer as I915_CACHE_NONE.
> i915_gem_object_create_internal() always gives us I915_CACHE_LLC on LLC
> platforms. And to make things 100% correct we should also clflush at the end, 
> if
> necessary.
> 
> Note that currently this is a non-issue as we always write the command buffer
> through a WC mapping, so a cache flush is not actually needed. But we might
> actually want to consider a WB mapping since we also end up reading from the
> command buffer (in the indexed reg write handling). Either that or we should 
> do
> something else to avoid those reads (might actually be even more sensible on
> DGFX since we end up reading over PCIe). But we should measure the overhead
> first...
> 
> Anyways, no real harm in adding the belts and suspenders here so that the code
> will work correctly regardless of how we map the buffer. If we do get a WC
> mapping (as we request)
> i915_gem_object_flush_map() will be a nop. Well, apart form a wmb() which may
> just flush the WC buffer a bit earlier than would otherwise happen (at the 
> latest
> the mmio accesses would trigger the WC flush).
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dsb.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 7410ba3126f9..78b6fe24dcd8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -316,6 +316,8 @@ void intel_dsb_finish(struct intel_dsb *dsb)
>  DSB_FORCE_DEWAKE, 0);
> 
>   intel_dsb_align_tail(dsb);
> +
> + i915_gem_object_flush_map(dsb->vma->obj);
>  }
> 
>  static int intel_dsb_dewake_scanline(const struct intel_crtc_state 
> *crtc_state)
> @@ -462,13 +464,18 @@ struct intel_dsb *intel_dsb_prepare(const struct
> intel_crtc_state *crtc_state,
>   /* ~1 qword per instruction, full cachelines */
>   size = ALIGN(max_cmds * 8, CACHELINE_BYTES);
> 
> - if (HAS_LMEM(i915))
> + if (HAS_LMEM(i915)) {
>   obj = i915_gem_object_create_lmem(i915, PAGE_ALIGN(size),
> 
> I915_BO_ALLOC_CONTIGUOUS);
> - else
> + if (IS_ERR(obj))
> + goto out_put_rpm;
> + } else {
>   obj = i915_gem_object_create_internal(i915, PAGE_ALIGN(size));
> - if (IS_ERR(obj))
> - goto out_put_rpm;
> + if (IS_ERR(obj))
> + goto out_put_rpm;
> +
> + i915_gem_object_set_cache_coherency(obj,
> I915_CACHE_NONE);
> + }
> 
>   vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
>   if (IS_ERR(vma)) {
> --
> 2.41.0

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dsb: Allocate command buffer from local memory

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Monday, October 9, 2023 6:52 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/4] drm/i915/dsb: Allocate command buffer from
> local memory
> 
> From: Ville Syrjälä 
> 
> Using system memory for the DSB command buffer doesn't appear to work.
> On DG2 it seems like the hardware internally replaces the actual memory reads
> with zeroes, and so we end up executing a bunch of NOOPs instead of whatever
> commands we put in the buffer. To determine that I measured the time it takes 
> to
> execute the instructions, and the results are always more or less consistent 
> with
> executing a buffer full of NOOPs from local memory.
> 
> Another theory I considered was some kind of cache coherency issue.
> Looks like i915_gem_object_pin_map_unlocked() will in fact give you a WB
> mapping for system memory on DGFX regardless of what mapping mode was
> requested (WC in case of the DSB code). But clflush did not change the 
> behaviour
> at all, so that theory seems moot.
> 
> On DG1 it looks like the hardware might actually be fetching data from system
> memory as the logs indicate that we just get underruns. But that is equally 
> bad, so
> doens't look like we can really use system memory on
> DG1 either.
> 
> Thus always allocate the DSB command buffer from local memory on discrete
> GPUs.

This seems fair to do,
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dsb.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 3e32aa49b8eb..7410ba3126f9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -5,6 +5,7 @@
>   */
> 
>  #include "gem/i915_gem_internal.h"
> +#include "gem/i915_gem_lmem.h"
> 
>  #include "i915_drv.h"
>  #include "i915_irq.h"
> @@ -461,7 +462,11 @@ struct intel_dsb *intel_dsb_prepare(const struct
> intel_crtc_state *crtc_state,
>   /* ~1 qword per instruction, full cachelines */
>   size = ALIGN(max_cmds * 8, CACHELINE_BYTES);
> 
> - obj = i915_gem_object_create_internal(i915, PAGE_ALIGN(size));
> + if (HAS_LMEM(i915))
> + obj = i915_gem_object_create_lmem(i915, PAGE_ALIGN(size),
> +
> I915_BO_ALLOC_CONTIGUOUS);
> + else
> + obj = i915_gem_object_create_internal(i915, PAGE_ALIGN(size));
>   if (IS_ERR(obj))
>   goto out_put_rpm;
> 
> --
> 2.41.0

Re: [Intel-gfx] [PATCH] drm/i915: Remove the module parameter 'fastboot'

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Arun R
> Murthy
> Sent: Tuesday, September 26, 2023 2:42 PM
> To: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: [Intel-gfx] [PATCH] drm/i915: Remove the module parameter 'fastboot'
> 
> By default fastboot is enabled on all Display 9+ platforms and disabled on 
> older
> platforms. Its not necessary to retain this as a module parameter.

Pushed to drm-intel-next. Thanks for the patch and reviews.
@Arun R Murthy Please work on the follow-up patch as highlighted by Ville.

Regards,
Uma Shankar

> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 3 ---
>  drivers/gpu/drm/i915/i915_params.c   | 5 -
>  drivers/gpu/drm/i915/i915_params.h   | 1 -
>  3 files changed, 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index edbcf5968804..9d6e2d19d636 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4986,9 +4986,6 @@ pipe_config_mismatch(bool fastset, const struct
> intel_crtc *crtc,
> 
>  static bool fastboot_enabled(struct drm_i915_private *dev_priv)  {
> - if (dev_priv->params.fastboot != -1)
> - return dev_priv->params.fastboot;
> -
>   /* Enable fastboot by default on Skylake and newer */
>   if (DISPLAY_VER(dev_priv) >= 9)
>   return true;
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 0a171b57fd8f..036c4c3ed6ed 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -137,11 +137,6 @@ i915_param_named_unsafe(enable_ips, int, 0400,
> "Enable IPS (default: true)");  i915_param_named_unsafe(enable_dpt, bool, 
> 0400,
>   "Enable display page table (DPT) (default: true)");
> 
> -i915_param_named(fastboot, int, 0400,
> - "Try to skip unnecessary mode sets at boot time "
> - "(0=disabled, 1=enabled) "
> - "Default: -1 (use per-chip default)");
> -
>  i915_param_named_unsafe(load_detect_test, bool, 0400,
>   "Force-enable the VGA load detect code for testing (default:false). "
>   "For developers only.");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 68abf0ad6c00..d5194b039aab 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -72,7 +72,6 @@ struct drm_printer;
>   param(int, edp_vswing, 0, 0400) \
>   param(unsigned int, reset, 3, 0600) \
>   param(unsigned int, inject_probe_failure, 0, 0) \
> - param(int, fastboot, -1, 0600) \
>   param(int, enable_dpcd_backlight, -1, 0600) \
>   param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \
>   param(unsigned int, request_timeout_ms,
> CONFIG_DRM_I915_REQUEST_TIMEOUT,
> CONFIG_DRM_I915_REQUEST_TIMEOUT ? 0600 : 0) \
> --
> 2.25.1

Re: [Intel-gfx] [PATCH v5 0/2] Refactor i915 HDCP for XE

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Wednesday, October 11, 2023 6:41 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 0/2] Refactor i915 HDCP for XE
> 
> On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> > This patch series contains some refactors for i915 side of things
> > which will help with a cleaner code and maximum reuse of code for XE
> > going forward.
> >
> > Signed-off-by: Suraj Kandpal 
> 
> Acked-by: Jani Nikula 

Pushed to drm-intel-next. Thanks for the patch and reviews.

Regards,
Uma Shankar

> 
> >
> > Suraj Kandpal (2):
> >   drm/i915/hdcp: Move checks for gsc health status
> >   drm/i915/hdcp: Move common message filling function to its own file
> >
> >  drivers/gpu/drm/i915/Makefile |   1 +
> >  drivers/gpu/drm/i915/display/intel_hdcp.c |   8 +-
> >  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 617 +-
> >  drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |   1 +
> >  .../drm/i915/display/intel_hdcp_gsc_message.c | 592 +
> > .../drm/i915/display/intel_hdcp_gsc_message.h |  72 ++
> >  6 files changed, 692 insertions(+), 599 deletions(-)  create mode
> > 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c
> >  create mode 100644
> > drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> 
> --
> Jani Nikula, Intel

Re: [Intel-gfx] [PATCH] drm/i915: Add wrapper for getting display step

[Shankar, Uma]

> -Original Message-
> From: Shankar, Uma
> Sent: Monday, October 9, 2023 3:06 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: Manna, Animesh 
> Subject: RE: [PATCH] drm/i915: Add wrapper for getting display step
> 
> 
> 
> > -Original Message-
> > From: Borah, Chaitanya Kumar 
> > Sent: Tuesday, October 3, 2023 12:22 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Shankar, Uma ; Borah, Chaitanya Kumar
> > ; Manna, Animesh
> > 
> > Subject: [PATCH] drm/i915: Add wrapper for getting display step
> >
> > Add a wrapper around intel_step_name that takes in driver data as an
> argument.
> > This wrapper will help maintain compatibility with the proposed xe driver.
> 
> Looks Good to me.
> Reviewed-by: Uma Shankar 

Pushed to drm-intel-next. Thanks for the patch.

Regards,
Uma Shankar

> > Signed-off-by: Chaitanya Kumar Borah 
> > Signed-off-by: Animesh Manna 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
> >  drivers/gpu/drm/i915/intel_step.c| 5 +
> >  drivers/gpu/drm/i915/intel_step.h| 1 +
> >  3 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> > b/drivers/gpu/drm/i915/display/intel_dmc.c
> > index 1623c0c5e8a1..63e080e07023 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > @@ -309,7 +309,7 @@ static const struct stepping_info *
> > intel_get_stepping_info(struct drm_i915_private *i915,
> > struct stepping_info *si)
> >  {
> > -   const char *step_name = intel_step_name(RUNTIME_INFO(i915)-
> > >step.display_step);
> > +   const char *step_name = intel_display_step_name(i915);
> >
> > si->stepping = step_name[0];
> > si->substepping = step_name[1];
> > diff --git a/drivers/gpu/drm/i915/intel_step.c
> > b/drivers/gpu/drm/i915/intel_step.c
> > index ee4e5a2c0220..b4162f1be765 100644
> > --- a/drivers/gpu/drm/i915/intel_step.c
> > +++ b/drivers/gpu/drm/i915/intel_step.c
> > @@ -353,3 +353,8 @@ const char *intel_step_name(enum intel_step step)
> > return "**";
> > }
> >  }
> > +
> > +const char *intel_display_step_name(struct drm_i915_private *i915) {
> > +   return intel_step_name(RUNTIME_INFO(i915)->step.display_step);
> > +}
> > diff --git a/drivers/gpu/drm/i915/intel_step.h
> > b/drivers/gpu/drm/i915/intel_step.h
> > index 96dfca4cba73..b6f43b624774 100644
> > --- a/drivers/gpu/drm/i915/intel_step.h
> > +++ b/drivers/gpu/drm/i915/intel_step.h
> > @@ -78,5 +78,6 @@ enum intel_step {
> >
> >  void intel_step_init(struct drm_i915_private *i915);  const char
> > *intel_step_name(enum intel_step step);
> > +const char *intel_display_step_name(struct drm_i915_private *i915);
> >
> >  #endif /* __INTEL_STEP_H__ */
> > --
> > 2.25.1

Re: [Intel-gfx] [PATCH] drm/i915: Add wrapper for getting display step

[Shankar, Uma]

> -Original Message-
> From: Borah, Chaitanya Kumar 
> Sent: Tuesday, October 3, 2023 12:22 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Borah, Chaitanya Kumar
> ; Manna, Animesh
> 
> Subject: [PATCH] drm/i915: Add wrapper for getting display step
> 
> Add a wrapper around intel_step_name that takes in driver data as an argument.
> This wrapper will help maintain compatibility with the proposed xe driver.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Chaitanya Kumar Borah 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
>  drivers/gpu/drm/i915/intel_step.c| 5 +
>  drivers/gpu/drm/i915/intel_step.h| 1 +
>  3 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 1623c0c5e8a1..63e080e07023 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -309,7 +309,7 @@ static const struct stepping_info *
> intel_get_stepping_info(struct drm_i915_private *i915,
>   struct stepping_info *si)
>  {
> - const char *step_name = intel_step_name(RUNTIME_INFO(i915)-
> >step.display_step);
> + const char *step_name = intel_display_step_name(i915);
> 
>   si->stepping = step_name[0];
>   si->substepping = step_name[1];
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index ee4e5a2c0220..b4162f1be765 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -353,3 +353,8 @@ const char *intel_step_name(enum intel_step step)
>   return "**";
>   }
>  }
> +
> +const char *intel_display_step_name(struct drm_i915_private *i915) {
> + return intel_step_name(RUNTIME_INFO(i915)->step.display_step);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_step.h
> b/drivers/gpu/drm/i915/intel_step.h
> index 96dfca4cba73..b6f43b624774 100644
> --- a/drivers/gpu/drm/i915/intel_step.h
> +++ b/drivers/gpu/drm/i915/intel_step.h
> @@ -78,5 +78,6 @@ enum intel_step {
> 
>  void intel_step_init(struct drm_i915_private *i915);  const char
> *intel_step_name(enum intel_step step);
> +const char *intel_display_step_name(struct drm_i915_private *i915);
> 
>  #endif /* __INTEL_STEP_H__ */
> --
> 2.25.1