date:20230725

== Series Details ==

Series: MTL Degamma implementation (rev3)
URL   : https://patchwork.freedesktop.org/series/119844/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13419_full -> Patchwork_119844v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH] drm/i915/hotplug: Reduce SHPD_FILTER to 250us

2023-07-25 Thread Shankar, Uma




> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Shankar,
> Uma
> Sent: Thursday, July 20, 2023 3:41 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/hotplug: Reduce SHPD_FILTER to 250us
> 
> 
> 
> > -Original Message-
> > From: Kandpal, Suraj 
> > Sent: Monday, July 17, 2023 2:54 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Kandpal, Suraj ; Shankar, Uma
> > ; Ville Syrjala 
> > Subject: [PATCH] drm/i915/hotplug: Reduce SHPD_FILTER to 250us
> >
> > On TGP, the RTC (always running) was reduced from 3MHz to 32KHz.
> > As a result of this change, when HPD active going low pulse or HPD IRQ
> > is presented and the refclk (19.2MHz) is not toggling already
> > toggling, there is a 60 to 90us synchronization delay which
> > effectively reduces the duration of the IRQ pulse to less than the 
> > programmed
> 500us filter value and the hot plug interrupt is NOT registered.
> > Solution was to Reduce SHPD_FILTER to 250us for ADL and above.
> > This solution was derived when the below patch was floated.
> > [1]https://patchwork.freedesktop.org/patch/532187
> > and after some internal discussion Ville's suggestion made sense.
> 
> Looks Good to me. Just add also a Suggested-By tag mentioning Ville.
> Reviewed-by: Uma Shankar 

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

Regards,
Uma Shankar

> > Bspec: 68970
> >
> > Cc: Uma Shankar 
> > Cc: Ville Syrjala 
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_hotplug_irq.c | 4 +++-
> >  drivers/gpu/drm/i915/i915_reg.h  | 1 +
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> > index f95fa793fabb..95a7ea94f417 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> > @@ -842,6 +842,8 @@ static void icp_hpd_irq_setup(struct
> > drm_i915_private
> > *dev_priv)
> >
> > if (INTEL_PCH_TYPE(dev_priv) <= PCH_TGP)
> > intel_uncore_write(&dev_priv->uncore, SHPD_FILTER_CNT,
> > SHPD_FILTER_CNT_500_ADJ);
> > +   else
> > +   intel_uncore_write(&dev_priv->uncore, SHPD_FILTER_CNT,
> > +SHPD_FILTER_CNT_250);
> >
> > ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
> >
> > @@ -1049,7 +1051,7 @@ static void mtp_hpd_irq_setup(struct
> > drm_i915_private
> > *i915)
> > enabled_irqs = intel_hpd_enabled_irqs(i915, 
> > i915->display.hotplug.pch_hpd);
> > hotplug_irqs = intel_hpd_hotplug_irqs(i915,
> > i915->display.hotplug.pch_hpd);
> >
> > -   intel_de_write(i915, SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ);
> > +   intel_de_write(i915, SHPD_FILTER_CNT, SHPD_FILTER_CNT_250);
> >
> > mtp_hpd_invert(i915);
> > ibx_display_interrupt_update(i915, hotplug_irqs, enabled_irqs); diff
> > --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index dcf64e32cd54..aefad14ab27a
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4939,6 +4939,7 @@
> >
> >  #define SHPD_FILTER_CNT_MMIO(0xc4038)
> >  #define   SHPD_FILTER_CNT_500_ADJ  0x001D9
> > +#define   SHPD_FILTER_CNT_250  0x000F8
> >
> >  #define _PCH_DPLL_A  0xc6014
> >  #define _PCH_DPLL_B  0xc6018
> > --
> > 2.25.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for MTL Degamma implementation (rev3)

== Series Details ==

Series: MTL Degamma implementation (rev3)
URL   : https://patchwork.freedesktop.org/series/119844/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13419_full -> Patchwork_119844v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@flip-vs-modeset-vs-hang@b-vga1:
- shard-snb:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-snb7/igt@kms_flip@flip-vs-modeset-vs-h...@b-vga1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/shard-snb7/igt@kms_flip@flip-vs-modeset-vs-h...@b-vga1.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

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

2023-07-25 Thread Murthy, Arun R

Any comments?

Thanks and Regards,
Arun R Murthy


> -Original Message-
> From: Murthy, Arun R 
> Sent: Friday, July 14, 2023 11:08 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: [PATCH] drm/i915/dp: Fix LT debug print in SDP CRC enable
> 
> The debug print for enabling SDP CRC16 is applicable only for DP2.0, but this
> debug print was not within the uhbr check and was always printed.
> Fis this by adding proper checks and returning.
> 
> Signed-off-by: Arun R Murthy 
> ---
>  .../gpu/drm/i915/display/intel_dp_link_training.c| 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index a263773f4d68..4485ef4f8ec6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -1390,11 +1390,13 @@ void intel_dp_128b132b_sdp_crc16(struct
> intel_dp *intel_dp,
>* Default value of bit 31 is '0' hence discarding the write
>* TODO: Corrective actions on SDP corruption yet to be defined
>*/
> - if (intel_dp_is_uhbr(crtc_state))
> - /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
> - drm_dp_dpcd_writeb(&intel_dp->aux,
> -
> DP_SDP_ERROR_DETECTION_CONFIGURATION,
> -DP_SDP_CRC16_128B132B_EN);
> + if (!intel_dp_is_uhbr(crtc_state))
> + return;
> +
> + /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
> + drm_dp_dpcd_writeb(&intel_dp->aux,
> +DP_SDP_ERROR_DETECTION_CONFIGURATION,
> +DP_SDP_CRC16_128B132B_EN);
> 
>   lt_dbg(intel_dp, DP_PHY_DPRX, "DP2.0 SDP CRC16 for 128b/132b
> enabled\n");  }
> --
> 2.25.1

Re: [Intel-gfx] [PATCH v2] drm/i915/tv: avoid possible division by zero

2023-07-25 Thread Dan Carpenter

On Wed, Jul 26, 2023 at 09:21:50AM +0800, Su Hui wrote:
> On 2023/7/25 13:51, Dan Carpenter wrote:
> > The reason why the first five attempts had bugs is because we are
> > trying to write it in the most complicated way possible, shifting by
> > logical not what?
> Wonderful! Should I add your name as signed-of-by?

Sure.  Or you can put it as a Suggested-by.

regards,
dan carpenter

[Intel-gfx] ✗ Fi.CI.IGT: failure for Fix C10/C20 implementation w.r.t. owned PHY lanes

== Series Details ==

Series: Fix C10/C20 implementation w.r.t. owned PHY lanes
URL   : https://patchwork.freedesktop.org/series/121334/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13422_full -> Patchwork_121334v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_spin_batch@legacy@bsd1:
- shard-snb:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/shard-snb4/igt@gem_spin_batch@leg...@bsd1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-snb7/igt@gem_spin_batch@leg...@bsd1.html

  * igt@kms_cursor_crc@cursor-suspend@pipe-d-hdmi-a-3:
- shard-dg1:  NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-dg1-13/igt@kms_cursor_crc@cursor-susp...@pipe-d-hdmi-a-3.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@drm_fdinfo@virtual-busy:
- shard-dg2:  NOTRUN -> [SKIP][5] ([i915#8414])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-dg2-11/igt@drm_fdi...@virtual-busy.html

  * igt@feature_discovery@display-4x:
- shard-mtlp: NOTRUN -> [SKIP][6] ([i915#1839])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-mtlp-3/igt@feature_discov...@display-4x.html

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-dg1:  [PASS][7] -> [ABORT][8] ([i915#7461] / [i915#8234])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/shard-dg1-18/igt@gem_barrier_race@remote-requ...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-dg1-12/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_ccs@block-copy-compressed:
- shard-mtlp: NOTRUN -> [SKIP][9] ([i915#5325])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-mtlp-3/igt@gem_...@block-copy-compressed.html

  * igt@gem_close_race@multigpu-basic-process:
- shard-dg2:  NOTRUN -> [SKIP][10] ([i915#7697])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-dg2-11/igt@gem_close_r...@multigpu-basic-process.html

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

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

  * igt@gem_eio@in-flight-suspend:
- shard-dg2:  [PASS][13] -> [FAIL][14] ([fdo#103375])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/shard-dg2-3/igt@gem_...@in-flight-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-dg2-5/igt@gem_...@in-flight-suspend.html

  * igt@gem_eio@unwedge-stress:
- shard-snb:  NOTRUN -> [FAIL][15] ([i915#8898])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-snb2/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_endless@dispatch@rcs0:
- shard-rkl:  [PASS][16] -> [TIMEOUT][17] ([i915#3778])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/shard-rkl-1/igt@gem_exec_endless@dispa...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-rkl-2/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@gem_exec_fair@basic-pace:
- shard-dg2:  NOTRUN -> [SKIP][18] ([i915#3539])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-dg2-11/igt@gem_exec_f...@basic-pace.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  NOTRUN -> [FAIL][19] ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.ht

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

2023-07-25 Thread Borah, Chaitanya Kumar

Hello Tvrtko,

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

Thank you.

Regards

Chaitanya

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

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

2023-07-25 Thread Borah, Chaitanya Kumar

Hello Alistair,

Thank you for the quick fix.

Regards

Chaitanya

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc/slpc: Restore efficient freq earlier (rev2)

== Series Details ==

Series: drm/i915/guc/slpc: Restore efficient freq earlier (rev2)
URL   : https://patchwork.freedesktop.org/series/121150/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13422 -> Patchwork_121150v2


Summary
---

  **FAILURE**

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

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

Participating hosts (44 -> 42)
--

  Missing(2): fi-kbl-soraka fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@module-reload:
- bat-dg2-8:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-dg2-8/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-dg2-8/igt@i915_pm_...@module-reload.html
- bat-dg1-7:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-dg1-7/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-dg1-7/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_pm:
- bat-rpls-2: [PASS][5] -> [DMESG-FAIL][6] ([i915#4258] / 
[i915#7913])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@mman:
- bat-rpls-2: [PASS][7] -> [TIMEOUT][8] ([i915#6794] / [i915#7392])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-2/igt@i915_selftest@l...@mman.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-rpls-2/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: [PASS][9] -> [WARN][10] ([i915#8747])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-jsl-3:  NOTRUN -> [SKIP][11] ([i915#7828])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][12] ([i915#1845] / [i915#5354]) +2 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [SKIP][13] ([i915#1072]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [ABORT][14] ([i915#8260] / [i915#8668])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-jsl-3:  [ABORT][15] ([i915#5122]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-9: [FAIL][17] ([i915#7940]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-adlp-9/igt@i915_pm_...@basic-pci-d3-state.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/bat-adlp-9/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-skl-guc: [FAIL][19] ([i915#7940]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121150v2/fi-skl-guc/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-rkl-11600:   [FAIL][21] ([i915#7940]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/

[Intel-gfx] [PATCH v2] drm/i915/guc/slpc: Restore efficient freq earlier

2023-07-25 Thread Vinay Belgaumkar

This should be done before the soft min/max frequencies are restored.
When we disable the "Ignore efficient frequency" flag, GuC does not
actually bring the requested freq down to RPn.

Specifically, this scenario-

- ignore efficient freq set to true
- reduce min to RPn (from efficient)
- suspend
- resume (includes GuC load, restore soft min/max, restore efficient freq)
- validate min freq has been resored to RPn

This will fail if we didn't first restore(disable, in this case) efficient
freq flag before setting the soft min frequency.

v2: Bring the min freq down to RPn when we disable efficient freq (Rodrigo)
Also made the change to set the min softlimit to RPn at init. Otherwise, we
were storing RPe there.

Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq")
Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 22 +
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index ee9f83af7cf6..477df260ae3a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -470,12 +470,19 @@ int intel_guc_slpc_set_ignore_eff_freq(struct 
intel_guc_slpc *slpc, bool val)
ret = slpc_set_param(slpc,
 SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
 val);
-   if (ret)
+   if (ret) {
guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient 
freq(%d): %pe\n",
val, ERR_PTR(ret));
-   else
+   } else {
slpc->ignore_eff_freq = val;
 
+   /* Set min to RPn when we disable efficient freq */
+   if (val)
+   ret = slpc_set_param(slpc,
+
SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+slpc->min_freq);
+   }
+
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
mutex_unlock(&slpc->lock);
return ret;
@@ -602,9 +609,8 @@ static int slpc_set_softlimits(struct intel_guc_slpc *slpc)
return ret;
 
if (!slpc->min_freq_softlimit) {
-   ret = intel_guc_slpc_get_min_freq(slpc, 
&slpc->min_freq_softlimit);
-   if (unlikely(ret))
-   return ret;
+   /* Min softlimit is initialized to RPn */
+   slpc->min_freq_softlimit = slpc->min_freq;
slpc_to_gt(slpc)->defaults.min_freq = slpc->min_freq_softlimit;
} else {
return intel_guc_slpc_set_min_freq(slpc,
@@ -755,6 +761,9 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
return ret;
}
 
+   /* Set cached value of ignore efficient freq */
+   intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
+
/* Revert SLPC min/max to softlimits if necessary */
ret = slpc_set_softlimits(slpc);
if (unlikely(ret)) {
@@ -765,9 +774,6 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
/* Set cached media freq ratio mode */
intel_guc_slpc_set_media_ratio_mode(slpc, slpc->media_ratio_mode);
 
-   /* Set cached value of ignore efficient freq */
-   intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
-
return 0;
 }
 
-- 
2.38.1

[Intel-gfx] ✗ Fi.CI.BAT: failure for Update AUX invalidation sequence (rev12)

== Series Details ==

Series: Update AUX invalidation sequence (rev12)
URL   : https://patchwork.freedesktop.org/series/119798/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13422 -> Patchwork_119798v12


Summary
---

  **FAILURE**

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

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

Participating hosts (44 -> 43)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/fi-kbl-soraka/igt@kms_f...@basic-flip-vs-dpms.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-9: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-adlp-9/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-1115g4:  [PASS][3] -> [FAIL][4] ([i915#7940])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/fi-tgl-1115g4/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/fi-tgl-1115g4/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-7567u:   [PASS][5] -> [FAIL][6] ([i915#7940])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-9: NOTRUN -> [FAIL][7] ([i915#7940])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-adlp-9/igt@i915_pm_...@module-reload.html

  * igt@i915_pm_rps@basic-api:
- bat-adlp-9: NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-adlp-9/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_pm:
- bat-rpls-2: [PASS][9] -> [DMESG-FAIL][10] ([i915#4258] / 
[i915#7913])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@requests:
- bat-rpls-2: [PASS][11] -> [ABORT][12] ([i915#7913])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-rpls-2/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][13] -> [ABORT][14] ([i915#4983] / [i915#7461] 
/ [i915#8347] / [i915#8384])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-adlp-9: NOTRUN -> [SKIP][15] ([i915#7828])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-adlp-9/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-jsl-3:  NOTRUN -> [SKIP][16] ([i915#7828])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [ABORT][17] ([i915#8434] / [i915#8442] / 
[i915#8668])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_psr@sprite_plane_onoff:
- bat-rplp-1: NOTRUN -> [SKIP][18] ([i915#1072])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html

  * igt@prime_vgem@basic-fence-read:
- bat-adlp-9: NOTRUN -> [SKIP][19] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v12/bat-adlp-9/igt@prime_v...@basic-fence-read.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update AUX invalidation sequence (rev12)

== Series Details ==

Series: Update AUX invalidation sequence (rev12)
URL   : https://patchwork.freedesktop.org/series/119798/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update AUX invalidation sequence (rev12)

== Series Details ==

Series: Update AUX invalidation sequence (rev12)
URL   : https://patchwork.freedesktop.org/series/119798/
State : warning

== Summary ==

Error: dim checkpatch failed
94aa9fabe7a4 drm/i915/gt: Cleanup aux invalidation registers
ff01e99c38e6 drm/i915: Add the gen12_needs_ccs_aux_inv helper
5e33bc7dd30e drm/i915/gt: Ensure memory quiesced before invalidation
7f9e02563fbd drm/i915/gt: Rename flags with bit_group_X according to the 
datasheet
1c118e195107 drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control and in 
the CS
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#15: 
Requires: 8da173db894a ("drm/i915/gt: Rename flags with bit_group_X according 
to the datasheet")

-:61: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#61: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:302:
+#define   PIPE_CONTROL_CCS_FLUSH   (1<<13) /* MTL+ */
  ^

total: 0 errors, 1 warnings, 1 checks, 30 lines checked
fbe7c0f746d6 drm/i915/gt: Poll aux invalidation register bit on invalidation
fdead80a3782 drm/i915/gt: Support aux invalidation on all engines

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix C10/C20 implementation w.r.t. owned PHY lanes

== Series Details ==

Series: Fix C10/C20 implementation w.r.t. owned PHY lanes
URL   : https://patchwork.freedesktop.org/series/121334/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13422 -> Patchwork_121334v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (44 -> 43)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_pm:
- bat-rpls-2: [PASS][1] -> [DMESG-FAIL][2] ([i915#4258] / 
[i915#7913])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-8: [PASS][3] -> [DMESG-FAIL][4] ([i915#7699])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-mtlp-8/igt@i915_selftest@l...@migrate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#7911] / [i915#7920])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: [PASS][7] -> [DMESG-WARN][8] ([i915#6367])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-jsl-3:  NOTRUN -> [SKIP][9] ([i915#7828])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [ABORT][10] ([i915#8434])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_psr@sprite_plane_onoff:
- bat-rplp-1: NOTRUN -> [SKIP][11] ([i915#1072])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-jsl-3:  [ABORT][12] ([i915#5122]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-8700k:   [FAIL][14] ([i915#7940]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/fi-cfl-8700k/igt@i915_pm_...@basic-rte.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/fi-cfl-8700k/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-rkl-11600:   [FAIL][16] ([i915#7940]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/fi-rkl-11600/igt@i915_pm_...@module-reload.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/fi-rkl-11600/igt@i915_pm_...@module-reload.html
- fi-tgl-1115g4:  [FAIL][18] ([i915#7940]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-jsl-3:  [FAIL][20] ([fdo#103375]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][22] ([fdo#109271]) -> [FAIL][23] ([i915#7691])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121334v1/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [DMESG-FAIL][24] ([i915#8497]) -> [DMESG-FAIL][25] 
([i915#7269])
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13422/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [25]: 
https://in

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap (rev3)

== Series Details ==

Series: drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap 
(rev3)
URL   : https://patchwork.freedesktop.org/series/121236/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13420_full -> Patchwork_121236v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_fdinfo@most-busy-check-all@bcs0:
- shard-dg1:  NOTRUN -> [SKIP][1] ([i915#8414]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-dg1-19/igt@drm_fdinfo@most-busy-check-...@bcs0.html

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl:  [PASS][2] -> [FAIL][3] ([i915#7742])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

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

  * igt@gem_eio@in-flight-suspend:
- shard-snb:  NOTRUN -> [DMESG-WARN][5] ([i915#8841]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-snb2/igt@gem_...@in-flight-suspend.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglu: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-tglu-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-tglu-9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fence@submit3:
- shard-mtlp: NOTRUN -> [SKIP][10] ([i915#4812])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-mtlp-4/igt@gem_exec_fe...@submit3.html

  * igt@gem_exec_reloc@basic-cpu-gtt-active:
- shard-dg1:  NOTRUN -> [SKIP][11] ([i915#3281]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-dg1-19/igt@gem_exec_re...@basic-cpu-gtt-active.html

  * igt@gem_exec_reloc@basic-cpu-read-noreloc:
- shard-mtlp: NOTRUN -> [SKIP][12] ([i915#3281]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-mtlp-4/igt@gem_exec_re...@basic-cpu-read-noreloc.html

  * igt@gem_exec_schedule@preempt-queue-contexts:
- shard-dg1:  NOTRUN -> [SKIP][13] ([i915#4812]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-dg1-19/igt@gem_exec_sched...@preempt-queue-contexts.html

  * igt@gem_exec_suspend@basic-s4-devices@lmem0:
- shard-dg1:  [PASS][14] -> [ABORT][15] ([i915#7975] / [i915#8213])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-dg1-16/igt@gem_exec_suspend@basic-s4-devi...@lmem0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-dg1-14/igt@gem_exec_suspend@basic-s4-devi...@lmem0.html

  * igt@gem_exec_suspend@basic-s4-devices@smem:
- shard-tglu: [PASS][16] -> [ABORT][17] ([i915#7975] / [i915#8213])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-tglu-7/igt@gem_exec_suspend@basic-s4-devi...@smem.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html

  * igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [PASS][18] -> [TIMEOUT][19] ([i915#8628])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-mtlp-1/igt@gem_exec_whis...@basic-contexts-forked-all.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-mtlp-7/igt@gem_exec_whis...@basic-contexts-forked-all.html

  * igt@gem_mmap@bad-size:
- shard-mtlp: NOTRUN -> [SKIP][20] ([i915#4083]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/shard-mtlp-8/igt@gem_m...@bad-size.html

  * igt@gem_mmap_gtt@basic-read-write-distinct:
- shard-dg1:  NOTRUN -> [SKIP][21] ([i915#4077]) +5 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12123

Re: [Intel-gfx] [PATCH 15/17] cgroup/drm: Expose GPU utilisation

2023-07-25 Thread Tejun Heo

Hello,

On Tue, Jul 25, 2023 at 03:08:40PM +0100, Tvrtko Ursulin wrote:
> > Also, shouldn't this be keyed by the drm device?
>
> It could have that too, or it could come later. Fun with GPUs that it not
> only could be keyed by the device, but also by the type of the GPU engine.
> (Which are a) vendor specific and b) some aree fully independent, some
> partially so, and some not at all - so it could get complicated semantics
> wise really fast.)

I see.

> If for now I'd go with drm.stat/usage_usec containing the total time spent
> how would you suggest adding per device granularity? Files as documented
> are either flag or nested, not both at the same time. So something like:
> 
> usage_usec 10
> card0 usage_usec 5
> card1 usage_usec 5
> 
> Would or would not fly? Have two files along the lines of drm.stat and 
> drm.dev_stat?

Please follow one of the pre-defined formats. If you want to have card
identifier and field key, it should be a nested keyed file like io.stat.

> While on this general topic, you will notice that for memory stats I have
> _sort of_ nested keyed per device format, for example on integrated Intel
> GPU:
> 
>   $ cat drm.memory.stat
>   card0 region=system total=12898304 shared=0 active=0 resident=12111872 
> purgeable=167936
>   card0 region=stolen-system total=0 shared=0 active=0 resident=0 purgeable=0
> 
> If one a discrete Intel GPU two more lines would appear with memory
> regions of local and local-system. But then on some server class
> multi-tile GPUs even further regions with more than one device local
> memory region. And users do want to see this granularity for container use
> cases at least.
> 
> Anyway, this may not be compatible with the nested key format as
> documented in cgroup-v2.rst, although it does not explicitly say.
> 
> Should I cheat and create key names based on device and memory region name
> and let userspace parse it? Like:
> 
>   $ cat drm.memory.stat
>   card0.system total=12898304 shared=0 active=0 resident=12111872 
> purgeable=167936
>   card0.stolen-system total=0 shared=0 active=0 resident=0 purgeable=0

Yeah, this looks better to me. If they're reporting different values for the
same fields, they're separate keys.

Thanks.

-- 
tejun

Re: [Intel-gfx] [PATCH v3 0/9] PCI/VGA: Improve the default VGA device selection

2023-07-25 Thread Bjorn Helgaas

On Mon, Jul 24, 2023 at 08:47:48PM +0800, suijingfeng wrote:
> On 2023/7/20 03:32, Bjorn Helgaas wrote:
> > "drm/loongson: Add an implement for ..." also solves a problem, but it
> > lacks a commit log, so I don't know what the problem is.
> 
> I have already telling you one yeas ago.

The patch itself must be self-contained, including a commit log that
justifies the change.  You may have told me a year ago, but that
doesn't help somebody looking at these changes next year.

Bjorn

Re: [Intel-gfx] [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection

2023-07-25 Thread Bjorn Helgaas

On Mon, Jul 24, 2023 at 08:16:18PM +0800, suijingfeng wrote:
> On 2023/7/20 03:32, Bjorn Helgaas wrote:
> > > 2) It does not take the PCI Bar may get relocated into consideration.
> > > 3) It is not effective for the PCI device without a dedicated VRAM Bar.
> > > 4) It is device-agnostic, thus it has to waste the effort to iterate all
> > > of the PCI Bar to find the VRAM aperture.
> > > 5) It has invented lots of methods to determine which one is the default
> > > boot device, but this is still a policy because it doesn't give the
> > > user a choice to override.
> > I don't think we need a list of*potential*  problems.  We need an
> > example of the specific problem this will solve, i.e., what currently
> > does not work?
> 
> 
> This version do allow the arbitration service works on non-x86 arch,
> which also allow me remove a arch-specific workaround.
> I will give more detail at the next version.

Yes.  This part I think we want.

> But I want to provide one more drawback of vgaarb here:
> 
> (6) It does not works for non VGA-compatible PCI(e) display controllers.
> 
> Because, currently, vgaarb deal with PCI VGA compatible devices only.
> 
> See another my patch set [1] for more elaborate discussion.
> 
> It also ignore PCI_CLASS_NOT_DEFINED_VGA as Maciej puts it[2].
> 
> While my approach do not required the display controller to be
> VGA-compatible to enjoy the arbitration service.

I think vgaarb is really only for dealing with the problem of the
legacy VGA address space routing.  For example, there may be VGA
devices that require the [pci 0xa-0xb] range but they don't
describe that via a BAR.  There may also be VGA option ROMs that
depend on that range so they can initialize the device.

The [pci 0xa-0xb] range can only be routed to one device at a
time, and vgaarb is what takes care of that by manipulating the VGA
Enable bits in bridges.

I don't think we should extend vgaarb to deal with non-VGA GPUs in
general, i.e., I don't think it should be concerned with devices and
option ROMs that do not require the [pci 0xa-0xb] range.

I think a strict reading of the PCI Class Code spec would be that only
devices with Programming Interface  b can depend on that
legacy range.

If that's what vgaarb currently enforces, great.  If it currently
deals with more than just  b devices, and there's some value
in restricting it to only  b, we could try that, but I would
suggest doing that in a tiny patch all by itself.  Then if we trip
over a problem, it's easy to bisect and revert it.

> [1] https://patchwork.freedesktop.org/patch/546690/?series=120548&rev=1
> 
> [2] https://lkml.org/lkml/2023/6/18/315
>

[Intel-gfx] [PATCH 2/4] drm/i915: Simplify intel_cx0_program_phy_lane() with loop

It is possible to generalize the "disable" value for the transmitters to
be a bit mask based on the port width and the port reversal boolean,
with a small exception for DP-alt mode with "x1" port width.

Simplify the code by using such a mask and a for-loop instead of using
switch-case statements.

BSpec: 64539
Signed-off-by: Gustavo Sousa 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 79 +---
 1 file changed, 20 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index b903ceb0b56a..f10ebdfd696a 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2604,7 +2604,8 @@ static void intel_cx0_program_phy_lane(struct 
drm_i915_private *i915,
   struct intel_encoder *encoder, int 
lane_count,
   bool lane_reversal)
 {
-   u8 l0t1, l0t2, l1t1, l1t2;
+   int i;
+   u8 disables;
bool dp_alt_mode = 
intel_tc_port_in_dp_alt_mode(enc_to_dig_port(encoder));
enum port port = encoder->port;
 
@@ -2614,66 +2615,26 @@ static void intel_cx0_program_phy_lane(struct 
drm_i915_private *i915,
  C10_VDR_CTRL_MSGBUS_ACCESS,
  MB_WRITE_COMMITTED);
 
-   /* TODO: DP-alt MFD case where only one PHY lane should be programmed. 
*/
-   l0t1 = intel_cx0_read(i915, port, INTEL_CX0_LANE0, 
PHY_CX0_TX_CONTROL(1, 2));
-   l0t2 = intel_cx0_read(i915, port, INTEL_CX0_LANE0, 
PHY_CX0_TX_CONTROL(2, 2));
-   l1t1 = intel_cx0_read(i915, port, INTEL_CX0_LANE1, 
PHY_CX0_TX_CONTROL(1, 2));
-   l1t2 = intel_cx0_read(i915, port, INTEL_CX0_LANE1, 
PHY_CX0_TX_CONTROL(2, 2));
-
-   l0t1 |= CONTROL2_DISABLE_SINGLE_TX;
-   l0t2 |= CONTROL2_DISABLE_SINGLE_TX;
-   l1t1 |= CONTROL2_DISABLE_SINGLE_TX;
-   l1t2 |= CONTROL2_DISABLE_SINGLE_TX;
-
-   if (lane_reversal) {
-   switch (lane_count) {
-   case 4:
-   l0t1 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   fallthrough;
-   case 3:
-   l0t2 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   fallthrough;
-   case 2:
-   l1t1 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   fallthrough;
-   case 1:
-   l1t2 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   break;
-   default:
-   MISSING_CASE(lane_count);
-   }
-   } else {
-   switch (lane_count) {
-   case 4:
-   l1t2 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   fallthrough;
-   case 3:
-   l1t1 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   fallthrough;
-   case 2:
-   l0t2 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   l0t1 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   break;
-   case 1:
-   if (dp_alt_mode)
-   l0t2 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   else
-   l0t1 &= ~CONTROL2_DISABLE_SINGLE_TX;
-   break;
-   default:
-   MISSING_CASE(lane_count);
-   }
+   if (lane_reversal)
+   disables = REG_GENMASK8(3, 0) >> lane_count;
+   else
+   disables = REG_GENMASK8(3, 0) << lane_count;
+
+   if (dp_alt_mode && lane_count == 1) {
+   disables &= ~REG_GENMASK8(1, 0);
+   disables |= REG_FIELD_PREP8(REG_GENMASK8(1, 0), 0x1);
}
 
-   /* disable MLs */
-   intel_cx0_write(i915, port, INTEL_CX0_LANE0, PHY_CX0_TX_CONTROL(1, 2),
-   l0t1, MB_WRITE_COMMITTED);
-   intel_cx0_write(i915, port, INTEL_CX0_LANE0, PHY_CX0_TX_CONTROL(2, 2),
-   l0t2, MB_WRITE_COMMITTED);
-   intel_cx0_write(i915, port, INTEL_CX0_LANE1, PHY_CX0_TX_CONTROL(1, 2),
-   l1t1, MB_WRITE_COMMITTED);
-   intel_cx0_write(i915, port, INTEL_CX0_LANE1, PHY_CX0_TX_CONTROL(2, 2),
-   l1t2, MB_WRITE_COMMITTED);
+   /* TODO: DP-alt MFD case where only one PHY lane should be programmed. 
*/
+   for (i = 0; i < 4; i++) {
+   int tx = i % 2 + 1;
+   u8 lane_mask = i / 2 == 0 ? INTEL_CX0_LANE0 : INTEL_CX0_LANE1;
+
+   intel_cx0_rmw(i915, port, lane_mask, PHY_CX0_TX_CONTROL(tx, 2),
+ CONTROL2_DISABLE_SINGLE_TX,
+ disables & BIT(i) ? CONTROL2_DISABLE_SINGLE_TX : 
0,
+ MB_WRITE_COMMITTED);
+   }
 
if (intel_is_c10phy(i915, intel_port_to_phy(i915, port)))
intel_cx0_rmw(i915, port, INTEL_CX0_BOTH_LANES,
-- 
2.41.0

[Intel-gfx] [PATCH 4/4] drm/i915/cx0: Program vswing only for owned lanes

According to the BSpec, voltage swing programming should be done for
owned PHY lanes. Do not program a not-owned PHY lane.

BSpec: 74103, 74104
Signed-off-by: Gustavo Sousa 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 25 +++-
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 236124786631..cfb2093feb3b 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -375,6 +375,7 @@ void intel_cx0_phy_set_signal_levels(struct intel_encoder 
*encoder,
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
const struct intel_ddi_buf_trans *trans;
enum phy phy = intel_port_to_phy(i915, encoder->port);
+   u8 owned_lane_mask = intel_cx0_get_owned_lane_mask(i915, encoder);
intel_wakeref_t wakeref;
int n_entries, ln;
 
@@ -387,13 +388,13 @@ void intel_cx0_phy_set_signal_levels(struct intel_encoder 
*encoder,
}
 
if (intel_is_c10phy(i915, phy)) {
-   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+   intel_cx0_rmw(i915, encoder->port, owned_lane_mask, 
PHY_C10_VDR_CONTROL(1),
  0, C10_VDR_CTRL_MSGBUS_ACCESS, 
MB_WRITE_COMMITTED);
-   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CMN(3),
+   intel_cx0_rmw(i915, encoder->port, owned_lane_mask, 
PHY_C10_VDR_CMN(3),
  C10_CMN3_TXVBOOST_MASK,
  
C10_CMN3_TXVBOOST(intel_c10_get_tx_vboost_lvl(crtc_state)),
  MB_WRITE_UNCOMMITTED);
-   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_TX(1),
+   intel_cx0_rmw(i915, encoder->port, owned_lane_mask, 
PHY_C10_VDR_TX(1),
  C10_TX1_TERMCTL_MASK,
  
C10_TX1_TERMCTL(intel_c10_get_tx_term_ctl(crtc_state)),
  MB_WRITE_COMMITTED);
@@ -401,32 +402,34 @@ void intel_cx0_phy_set_signal_levels(struct intel_encoder 
*encoder,
 
for (ln = 0; ln < crtc_state->lane_count; ln++) {
int level = intel_ddi_level(encoder, crtc_state, ln);
-   int lane, tx;
+   int lane = ln / 2;
+   int tx = ln % 2;
+   u8 lane_mask = lane == 0 ? INTEL_CX0_LANE0 : INTEL_CX0_LANE1;
 
-   lane = ln / 2;
-   tx = ln % 2;
+   if (!(lane_mask & owned_lane_mask))
+   continue;
 
-   intel_cx0_rmw(i915, encoder->port, BIT(lane), 
PHY_CX0_VDROVRD_CTL(lane, tx, 0),
+   intel_cx0_rmw(i915, encoder->port, lane_mask, 
PHY_CX0_VDROVRD_CTL(lane, tx, 0),
  C10_PHY_OVRD_LEVEL_MASK,
  
C10_PHY_OVRD_LEVEL(trans->entries[level].snps.pre_cursor),
  MB_WRITE_COMMITTED);
-   intel_cx0_rmw(i915, encoder->port, BIT(lane), 
PHY_CX0_VDROVRD_CTL(lane, tx, 1),
+   intel_cx0_rmw(i915, encoder->port, lane_mask, 
PHY_CX0_VDROVRD_CTL(lane, tx, 1),
  C10_PHY_OVRD_LEVEL_MASK,
  
C10_PHY_OVRD_LEVEL(trans->entries[level].snps.vswing),
  MB_WRITE_COMMITTED);
-   intel_cx0_rmw(i915, encoder->port, BIT(lane), 
PHY_CX0_VDROVRD_CTL(lane, tx, 2),
+   intel_cx0_rmw(i915, encoder->port, lane_mask, 
PHY_CX0_VDROVRD_CTL(lane, tx, 2),
  C10_PHY_OVRD_LEVEL_MASK,
  
C10_PHY_OVRD_LEVEL(trans->entries[level].snps.post_cursor),
  MB_WRITE_COMMITTED);
}
 
/* Write Override enables in 0xD71 */
-   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_OVRD,
+   intel_cx0_rmw(i915, encoder->port, owned_lane_mask, PHY_C10_VDR_OVRD,
  0, PHY_C10_VDR_OVRD_TX1 | PHY_C10_VDR_OVRD_TX2,
  MB_WRITE_COMMITTED);
 
if (intel_is_c10phy(i915, phy))
-   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+   intel_cx0_rmw(i915, encoder->port, owned_lane_mask, 
PHY_C10_VDR_CONTROL(1),
  0, C10_VDR_CTRL_UPDATE_CFG, MB_WRITE_COMMITTED);
 
intel_cx0_phy_transaction_end(encoder, wakeref);
-- 
2.41.0

[Intel-gfx] [PATCH 1/4] drm/i915/cx0: Add intel_cx0_get_owned_lane_mask()

There are more parts of C10/C20 programming that need to take owned
lanes into account. Define the function intel_cx0_get_owned_lane_mask()
and use it. There will be new users of that function in upcoming
changes.

BSpec: 64539
Signed-off-by: Gustavo Sousa 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 44 
 1 file changed, 27 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 1b00ef2c6185..b903ceb0b56a 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -46,6 +46,22 @@ static int lane_mask_to_lane(u8 lane_mask)
return ilog2(lane_mask);
 }
 
+static u8 intel_cx0_get_owned_lane_mask(struct drm_i915_private *i915,
+   struct intel_encoder *encoder)
+{
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+   if (!intel_tc_port_in_dp_alt_mode(dig_port))
+   return INTEL_CX0_BOTH_LANES;
+
+   /*
+* In DP-alt with pin assignment D, only PHY lane 0 is owned
+* by display and lane 1 is owned by USB.
+*/
+   return intel_tc_port_fia_max_lane_count(dig_port) > 2
+   ? INTEL_CX0_BOTH_LANES : INTEL_CX0_LANE0;
+}
+
 static void
 assert_dc_off(struct drm_i915_private *i915)
 {
@@ -2534,17 +2550,15 @@ static void intel_cx0_phy_lane_reset(struct 
drm_i915_private *i915,
 {
enum port port = encoder->port;
enum phy phy = intel_port_to_phy(i915, port);
-   bool both_lanes =  
intel_tc_port_fia_max_lane_count(enc_to_dig_port(encoder)) > 2;
-   u8 lane_mask = lane_reversal ? INTEL_CX0_LANE1 :
- INTEL_CX0_LANE0;
-   u32 lane_pipe_reset = both_lanes ?
- XELPDP_LANE_PIPE_RESET(0) |
- XELPDP_LANE_PIPE_RESET(1) :
- XELPDP_LANE_PIPE_RESET(0);
-   u32 lane_phy_current_status = both_lanes ?
- XELPDP_LANE_PHY_CURRENT_STATUS(0) |
- XELPDP_LANE_PHY_CURRENT_STATUS(1) :
- XELPDP_LANE_PHY_CURRENT_STATUS(0);
+   u8 owned_lane_mask = intel_cx0_get_owned_lane_mask(i915, encoder);
+   u8 lane_mask = lane_reversal ? INTEL_CX0_LANE1 : INTEL_CX0_LANE0;
+   u32 lane_pipe_reset = owned_lane_mask == INTEL_CX0_BOTH_LANES
+   ? XELPDP_LANE_PIPE_RESET(0) | 
XELPDP_LANE_PIPE_RESET(1)
+   : XELPDP_LANE_PIPE_RESET(0);
+   u32 lane_phy_current_status = owned_lane_mask == INTEL_CX0_BOTH_LANES
+   ? (XELPDP_LANE_PHY_CURRENT_STATUS(0) |
+  XELPDP_LANE_PHY_CURRENT_STATUS(1))
+   : XELPDP_LANE_PHY_CURRENT_STATUS(0);
 
if (__intel_de_wait_for_register(i915, XELPDP_PORT_BUF_CTL1(port),
 XELPDP_PORT_BUF_SOC_PHY_READY,
@@ -2564,15 +2578,11 @@ static void intel_cx0_phy_lane_reset(struct 
drm_i915_private *i915,
 phy_name(phy), XELPDP_PORT_RESET_START_TIMEOUT_US);
 
intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(port),
-intel_cx0_get_pclk_refclk_request(both_lanes ?
-  INTEL_CX0_BOTH_LANES :
-  INTEL_CX0_LANE0),
+intel_cx0_get_pclk_refclk_request(owned_lane_mask),
 intel_cx0_get_pclk_refclk_request(lane_mask));
 
if (__intel_de_wait_for_register(i915, XELPDP_PORT_CLOCK_CTL(port),
-
intel_cx0_get_pclk_refclk_ack(both_lanes ?
-  
INTEL_CX0_BOTH_LANES :
-  
INTEL_CX0_LANE0),
+
intel_cx0_get_pclk_refclk_ack(owned_lane_mask),
 
intel_cx0_get_pclk_refclk_ack(lane_mask),
 XELPDP_REFCLK_ENABLE_TIMEOUT_US, 0, 
NULL))
drm_warn(&i915->drm, "PHY %c failed to request refclk after 
%dus.\n",
-- 
2.41.0

[Intel-gfx] [PATCH 3/4] drm/i915/cx0: Enable/disable TX only for owned PHY lanes

Display must not enable or disable transmitters for not-owned PHY lanes.

BSpec: 64539
Signed-off-by: Gustavo Sousa 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index f10ebdfd696a..236124786631 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2607,10 +2607,11 @@ static void intel_cx0_program_phy_lane(struct 
drm_i915_private *i915,
int i;
u8 disables;
bool dp_alt_mode = 
intel_tc_port_in_dp_alt_mode(enc_to_dig_port(encoder));
+   u8 owned_lane_mask = intel_cx0_get_owned_lane_mask(i915, encoder);
enum port port = encoder->port;
 
if (intel_is_c10phy(i915, intel_port_to_phy(i915, port)))
-   intel_cx0_rmw(i915, port, INTEL_CX0_BOTH_LANES,
+   intel_cx0_rmw(i915, port, owned_lane_mask,
  PHY_C10_VDR_CONTROL(1), 0,
  C10_VDR_CTRL_MSGBUS_ACCESS,
  MB_WRITE_COMMITTED);
@@ -2625,11 +2626,13 @@ static void intel_cx0_program_phy_lane(struct 
drm_i915_private *i915,
disables |= REG_FIELD_PREP8(REG_GENMASK8(1, 0), 0x1);
}
 
-   /* TODO: DP-alt MFD case where only one PHY lane should be programmed. 
*/
for (i = 0; i < 4; i++) {
int tx = i % 2 + 1;
u8 lane_mask = i / 2 == 0 ? INTEL_CX0_LANE0 : INTEL_CX0_LANE1;
 
+   if (!(owned_lane_mask & lane_mask))
+   continue;
+
intel_cx0_rmw(i915, port, lane_mask, PHY_CX0_TX_CONTROL(tx, 2),
  CONTROL2_DISABLE_SINGLE_TX,
  disables & BIT(i) ? CONTROL2_DISABLE_SINGLE_TX : 
0,
@@ -2637,7 +2640,7 @@ static void intel_cx0_program_phy_lane(struct 
drm_i915_private *i915,
}
 
if (intel_is_c10phy(i915, intel_port_to_phy(i915, port)))
-   intel_cx0_rmw(i915, port, INTEL_CX0_BOTH_LANES,
+   intel_cx0_rmw(i915, port, owned_lane_mask,
  PHY_C10_VDR_CONTROL(1), 0,
  C10_VDR_CTRL_UPDATE_CFG,
  MB_WRITE_COMMITTED);
-- 
2.41.0

[Intel-gfx] [PATCH 0/4] Fix C10/C20 implementation w.r.t. owned PHY lanes

While 619a06dba6fa ("drm/i915/mtl: Reset only one lane in case of MFD")
fixes the problem for lane reset logic, there are also more parts of the
implementation that need to take owned PHY lanes into consideration.

This series provides fixes for such places. The changes to the logic
have been tested on a machine with a Type-C connection in DP-Alt mode
using pin assignment D. In that mode, only PHY lane 0 is owned by
display and, without these fixes, we get message bus timeout errors
because we try to perform reads/writes on registers for the not-owned
PHY.

Gustavo Sousa (4):
  drm/i915/cx0: Add intel_cx0_get_owned_lane_mask()
  drm/i915: Simplify intel_cx0_program_phy_lane() with loop
  drm/i915/cx0: Enable/disable TX only for owned PHY lanes
  drm/i915/cx0: Program vswing only for owned lanes

 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 155 ---
 1 file changed, 66 insertions(+), 89 deletions(-)

-- 
2.41.0

Re: [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing.

2023-07-25 Thread Rodrigo Vivi

On Tue, Jul 25, 2023 at 01:08:11AM -0400, Gupta, Anshuman wrote:
> 
> 
> > -Original Message-
> > From: Vivi, Rodrigo 
> > Sent: Saturday, July 22, 2023 12:30 AM
> > To: Gupta, Anshuman 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are
> > really allowing.
> > 
> > On Fri, Jul 21, 2023 at 03:39:35AM -0400, Gupta, Anshuman wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Vivi, Rodrigo 
> > > > Sent: Friday, July 21, 2023 2:34 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Vivi, Rodrigo ; Gupta, Anshuman
> > > > 
> > > > Subject: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are
> > > > really allowing.
> > > >
> > > > First of all it was strange to see:
> > > > if (allowed) {
> > > > ...
> > > > } else {
> > > >D3COLD_ENABLE
> > > > }
> > > >
> > > > But besides this misalignment, let's also use the pci d3cold_allowed
> > > > useful to us and know that we are not really allowing d3cold.
> > > >
> > > > Cc: Anshuman Gupta 
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > >  drivers/gpu/drm/xe/xe_pci.c | 3 +--
> > > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/xe/xe_pci.c
> > > > b/drivers/gpu/drm/xe/xe_pci.c index 78df43c20cd2..0c4051f4f746
> > > > 100644
> > > > --- a/drivers/gpu/drm/xe/xe_pci.c
> > > > +++ b/drivers/gpu/drm/xe/xe_pci.c
> > > > @@ -794,6 +794,7 @@ static int xe_pci_runtime_suspend(struct device
> > > > *dev)
> > > > pci_save_state(pdev);
> > > >
> > > > if (xe->d3cold.allowed) {
> > > > +   d3cold_toggle(pdev, D3COLD_ENABLE);
> > > > pci_disable_device(pdev);
> > > > pci_ignore_hotplug(pdev);
> > > > pci_set_power_state(pdev, PCI_D3cold); @@ -823,8 +824,6
> > @@ static
> > > > int xe_pci_runtime_resume(struct device *dev)
> > > > return err;
> > > >
> > > > pci_set_master(pdev);
> > > > -   } else {
> > > > -   d3cold_toggle(pdev, D3COLD_ENABLE);
> > > > }
> > > During s2idle , d3cold may get disabled if won't restore it's state in 
> > > runtime
> > resume.
> > 
> > I always forget about that case... please disregard this patch.
> I think , we can have this patch.
> I realized that system wide suspend/resume d3cold need some brainstorming.
> If device is already in runtime suspend state during system wide suspend, PM 
> core may smartly skip device suspend/resume callback on Xe driver.
> This wasn't the case on I915 driver as it explicitly disables those smart 
> optimization by 
> dev_pm_set_driver_flags(kdev, DPM_FLAG_NO_DIRECT_COMPLETE). 

so, it looks that we do need this as well anyway.

1. because we might not be in the runtime-d3cold, but on the system suspend
   we will lose power, hence the eviction/restore needs to happen.
2. because of the hda audio as documented in i915: "becaue the HDA driver
   may require us to enable the audio power domain during system suspend."

then, on device suspend we enable the d3cold and disable again on
device resume.

> Thanks,
> Anshuman.
> Thanks,
> Anshuman Gupta.
> > 
> > > Thanks,
> > > Anshuman Gupta.
> > > >
> > > > return xe_pm_runtime_resume(xe);
> > > > --
> > > > 2.41.0
> > >

[Intel-gfx] ✗ Fi.CI.IGT: failure for Update AUX invalidation sequence (rev11)

== Series Details ==

Series: Update AUX invalidation sequence (rev11)
URL   : https://patchwork.freedesktop.org/series/119798/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13420_full -> Patchwork_119798v11_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_mmap_wc@set-cache-level:
- shard-snb:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-snb5/igt@gem_mmap...@set-cache-level.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-snb2/igt@gem_mmap...@set-cache-level.html

  * igt@kms_rotation_crc@primary-x-tiled-reflect-x-180:
- shard-rkl:  [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-rkl-1/igt@kms_rotation_...@primary-x-tiled-reflect-x-180.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-rkl-2/igt@kms_rotation_...@primary-x-tiled-reflect-x-180.html

  
 Warnings 

  * igt@gem_mmap_wc@invalid-flags:
- shard-mtlp: [SKIP][5] ([i915#4083]) -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-mtlp-7/igt@gem_mmap...@invalid-flags.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-mtlp-2/igt@gem_mmap...@invalid-flags.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_fdinfo@most-busy-check-all@bcs0:
- shard-dg1:  NOTRUN -> [SKIP][7] ([i915#8414]) +4 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-dg1-13/igt@drm_fdinfo@most-busy-check-...@bcs0.html

  * igt@gem_ctx_persistence@engines-cleanup:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-snb4/igt@gem_ctx_persiste...@engines-cleanup.html

  * igt@gem_eio@in-flight-suspend:
- shard-snb:  NOTRUN -> [DMESG-WARN][9] ([i915#8841]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-snb5/igt@gem_...@in-flight-suspend.html

  * igt@gem_eio@kms:
- shard-dg2:  [PASS][10] -> [FAIL][11] ([i915#5784])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-dg2-8/igt@gem_...@kms.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-dg2-10/igt@gem_...@kms.html
- shard-apl:  [PASS][12] -> [FAIL][13] ([i915#8764])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-apl3/igt@gem_...@kms.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-apl1/igt@gem_...@kms.html

  * igt@gem_eio@unwedge-stress:
- shard-dg1:  [PASS][14] -> [FAIL][15] ([i915#5784]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-dg1-12/igt@gem_...@unwedge-stress.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-dg1-18/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-rkl:  [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-rkl-2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-rkl-6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl:  [PASS][18] -> [FAIL][19] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-apl1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk:  [PASS][20] -> [FAIL][21] ([i915#2842]) +1 similar 
issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/shard-glk1/igt@gem_exec_fair@basic-p...@rcs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/shard-glk9/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_reloc@basic-cpu-gtt-active:
- shard-dg1:  NOTRUN -> [SKIP][22] ([i915#3281]) +1 similar issue
   [22]:

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Swap ggtt_vma during legacy cursor update

2023-07-25 Thread Shankar, Uma




> -Original Message-
> From: Intel-gfx  On Behalf Of Maarten
> Lankhorst
> Sent: Thursday, June 29, 2023 9:05 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/2] drm/i915: Swap ggtt_vma during legacy cursor
> update
> 
> Xe is lacking the ability to re-use the ggtt_vma when updating cursor.
> Instead of pinning from the new plane_state, move the ggtt_vma from
> old_plane_state to new_plane_state.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index 4962247911d41..6f34098ea314d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -688,9 +688,8 @@ 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;
> + /* magic trick! */
> + swap(new_plane_state->ggtt_vma, old_plane_state->ggtt_vma);

There are failures in CI due to the change, this causes device busy issue.
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120018v1/shard-dg2-11/igt@kms_async_flips@test-cur...@pipe-b-dp-4.html

Please cross check once.

Regards,
Uma Shankar

>   intel_frontbuffer_flush(to_intel_frontbuffer(new_plane_state->hw.fb),
>   ORIGIN_CURSOR_UPDATE);
> --
> 2.39.2

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [dii-client,1/2] drm/i915: Make i915_coherent_map_type GT-centric

== Series Details ==

Series: series starting with [dii-client,1/2] drm/i915: Make 
i915_coherent_map_type GT-centric
URL   : https://patchwork.freedesktop.org/series/121324/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13421 -> Patchwork_121324v1


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 43)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +14 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

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

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u:   [PASS][5] -> [FAIL][6] ([i915#7940])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13421/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
- fi-kbl-7567u:   [PASS][7] -> [FAIL][8] ([i915#7940])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13421/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-rkl-11600:   [PASS][9] -> [FAIL][10] ([i915#7940])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13421/fi-rkl-11600/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/fi-rkl-11600/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-6: [PASS][11] -> [DMESG-FAIL][12] ([i915#7059])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13421/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html

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

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][14] -> [ABORT][15] ([i915#4983] / [i915#7461] 
/ [i915#7981] / [i915#8347] / [i915#8384])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13421/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#6645])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][17] ([i915#7828])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#7828])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121324v1/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][19] -> [ABORT][20] ([i915#8442] / [i915#8668])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13421/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-f

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [dii-client,1/2] drm/i915: Make i915_coherent_map_type GT-centric

== Series Details ==

Series: series starting with [dii-client,1/2] drm/i915: Make 
i915_coherent_map_type GT-centric
URL   : https://patchwork.freedesktop.org/series/121324/
State : warning

== Summary ==

Error: dim checkpatch failed
04b9b8deb0b7 drm/i915: Make i915_coherent_map_type GT-centric
-:225: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#225: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1195:
+
intel_gt_coherent_map_type(ce->engine->gt,
ce->state->obj,

-:259: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#259: FILE: drivers/gpu/drm/i915/gt/selftest_context.c:92:
+
intel_gt_coherent_map_type(engine->gt,

ce->state->obj, false));

-:294: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#294: FILE: drivers/gpu/drm/i915/gt/selftest_lrc.c:1296:
+  
intel_gt_coherent_map_type(engine->gt,
  
ce->state->obj,

-:378: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#378: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc.c:796:
+
intel_gt_coherent_map_type(guc_to_gt(guc),

vma->obj, true));

-:453: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#453: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_tee.c:249:
+   cmd = i915_gem_object_pin_map_unlocked(obj, 
intel_gt_coherent_map_type(pxp->ctrl_gt, obj, true));

total: 0 errors, 1 warnings, 4 checks, 329 lines checked
75d808bcaca2 drm/i915/gt: Apply workaround 22016122933 correctly

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [dii-client,1/2] drm/i915: Make i915_coherent_map_type GT-centric

== Series Details ==

Series: series starting with [dii-client,1/2] drm/i915: Make 
i915_coherent_map_type GT-centric
URL   : https://patchwork.freedesktop.org/series/121324/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH v15 00/26] Add vfio_device cdev for iommufd support

2023-07-25 Thread Alex Williamson

On Mon, 24 Jul 2023 13:09:22 -0600
Alex Williamson  wrote:

> On Tue, 18 Jul 2023 13:57:46 -0300
> Jason Gunthorpe  wrote:
> 
> > On Tue, Jul 18, 2023 at 06:55:25AM -0700, Yi Liu wrote:  
> > > Existing VFIO provides group-centric user APIs for userspace. Userspace
> > > opens the /dev/vfio/$group_id first before getting device fd and hence
> > > getting access to device. This is not the desired model for iommufd. Per
> > > the conclusion of community discussion[1], iommufd provides device-centric
> > > kAPIs and requires its consumer (like VFIO) to be device-centric user
> > > APIs. Such user APIs are used to associate device with iommufd and also
> > > the I/O address spaces managed by the iommufd.
> > > 
> > > This series first introduces a per device file structure to be prepared
> > > for further enhancement and refactors the kvm-vfio code to be prepared
> > > for accepting device file from userspace. After this, adds a mechanism for
> > > blocking device access before iommufd bind. Then refactors the vfio to be
> > > able to handle cdev paths (e.g. iommufd binding, no-iommufd, [de]attach 
> > > ioas).
> > > This refactor includes making the device_open exclusive between the group
> > > and the cdev path, only allow single device open in cdev path; 
> > > vfio-iommufd
> > > code is also refactored to support cdev. e.g. split the 
> > > vfio_iommufd_bind()
> > > into two steps. Eventually, adds the cdev support for vfio device and the
> > > new ioctls, then makes group infrastructure optional as it is not needed
> > > when vfio device cdev is compiled.
> > > 
> > > This series is based on some preparation works done to vfio emulated 
> > > devices[2]
> > > and vfio pci hot reset enhancements[3]. Per discussion[4], this series 
> > > does not
> > > support cdev for physical devices that do not have IOMMU. Such devices 
> > > only
> > > have group-centric user APIs.
> > > 
> > > This series is a prerequisite for iommu nesting for vfio device[5] [6].
> > > 
> > > The complete code can be found in below branch, simple tests done to the
> > > legacy group path and the cdev path. QEMU changes are in upstreaming[7]
> > > and the complete code can be found at[8]
> > > 
> > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v15
> > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)
> > 
> > Alex, if you are still good with this lets make this into a shared
> > branch, do you want to do it or would you like a PR from me?  
> 
> Sorry, was out much of last week.  Yes, my intent would be to put this
> both in a shared branch and my next branch for v6.6.  Given this is
> mostly vfio, it seems like it'd make sense for me to provide that
> branch but I may not get to it until tomorrow.  Thanks,

Both series are applied to my next branch for v6.6 and I've also
published them to the v6.6/vfio/cdev branch[1].  Thanks for all the
work and collaboration on this effort!

Alex

[1]https://github.com/awilliam/linux-vfio/tree/v6.6/vfio/cdev

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use the i915_vma_flush_writes helper (rev3)

== Series Details ==

Series: drm/i915: Use the i915_vma_flush_writes helper (rev3)
URL   : https://patchwork.freedesktop.org/series/121122/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13419_full -> Patchwork_121122v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][2] -> [FAIL][3] ([i915#2842])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@bcs0:
- shard-rkl:  [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-rkl-4/igt@gem_exec_fair@basic-n...@bcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-rkl-4/igt@gem_exec_fair@basic-n...@bcs0.html

  * igt@gem_exec_flush@basic-wb-ro-default:
- shard-dg2:  NOTRUN -> [SKIP][6] ([i915#3539] / [i915#4852])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-dg2-2/igt@gem_exec_fl...@basic-wb-ro-default.html

  * igt@gem_exec_reloc@basic-wc:
- shard-mtlp: NOTRUN -> [SKIP][7] ([i915#3281])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-mtlp-3/igt@gem_exec_re...@basic-wc.html

  * igt@gem_exec_schedule@preempt-queue:
- shard-mtlp: NOTRUN -> [SKIP][8] ([i915#4812])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-mtlp-3/igt@gem_exec_sched...@preempt-queue.html

  * igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [PASS][9] -> [ABORT][10] ([i915#8131])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-mtlp-1/igt@gem_exec_whis...@basic-contexts-forked-all.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-mtlp-4/igt@gem_exec_whis...@basic-contexts-forked-all.html

  * igt@gem_fenced_exec_thrash@no-spare-fences-busy-interruptible:
- shard-mtlp: NOTRUN -> [SKIP][11] ([i915#4860])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-mtlp-3/igt@gem_fenced_exec_thr...@no-spare-fences-busy-interruptible.html

  * igt@gem_lmem_swapping@smem-oom@lmem0:
- shard-dg2:  [PASS][12] -> [DMESG-WARN][13] ([i915#4936] / 
[i915#5493])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-dg2-7/igt@gem_lmem_swapping@smem-...@lmem0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-dg2-10/igt@gem_lmem_swapping@smem-...@lmem0.html

  * igt@gem_mmap_gtt@basic-read-write:
- shard-mtlp: NOTRUN -> [SKIP][14] ([i915#4077])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-mtlp-3/igt@gem_mmap_...@basic-read-write.html

  * igt@gem_mmap_wc@read-write:
- shard-mtlp: NOTRUN -> [SKIP][15] ([i915#4083]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-mtlp-3/igt@gem_mmap...@read-write.html

  * igt@gem_pxp@protected-raw-src-copy-not-readible:
- shard-mtlp: NOTRUN -> [SKIP][16] ([i915#4270])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-mtlp-1/igt@gem_...@protected-raw-src-copy-not-readible.html

  * igt@gem_pxp@reject-modify-context-protection-off-2:
- shard-tglu: NOTRUN -> [SKIP][17] ([i915#4270])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-tglu-3/igt@gem_...@reject-modify-context-protection-off-2.html

  * igt@gen3_render_tiledx_blits:
- shard-mtlp: NOTRUN -> [SKIP][18] ([fdo#109289])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-mtlp-3/igt@gen3_render_tiledx_blits.html

  * igt@gen9_exec_parse@allowed-single:
- shard-glk:  [PASS][19] -> [ABORT][20] ([i915#5566])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-glk2/igt@gen9_exec_pa...@allowed-single.html

  * igt@gen9_exec_parse@bb-large:
- shard-tglu: NOTRUN -> [SKIP][21] ([i915#2527] / [i915#2856])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/shard-tglu-3/igt@g

Re: [Intel-gfx] [PATCH dii-client 1/2] drm/i915: Make i915_coherent_map_type GT-centric

2023-07-25 Thread Cavitt, Jonathan

-Original Message-
From: Tvrtko Ursulin  
Sent: Tuesday, July 25, 2023 9:23 AM
To: Cavitt, Jonathan ; 
intel-gfx@lists.freedesktop.org
Cc: Shyti, Andi ; Roper, Matthew D 
; chris.p.wil...@linux.intel.com; Das, Nirmoy 

Subject: Re: [Intel-gfx] [PATCH dii-client 1/2] drm/i915: Make 
i915_coherent_map_type GT-centric
> 
> 
> On 25/07/2023 17:01, Jonathan Cavitt wrote:
> > Refactor i915_coherent_map_type to be GT-centric rather than
> > device-centric.  Each GT may require different coherency
> > handling due to hardware workarounds.
> > 
> > Since the function now takes a GT instead of the i915, the function is
> > renamed and moved to the gt folder.
> 
> What about the issue of fake gt passed to shmem_create_from_object I raised?

The function is, presently, only called in __engines_record_defaults, as a part 
of
intel_gt_init.  shmem_create_from_object uses i915_coherent_map_type to 
determine
the map_type to pass to i915_gem_object_pin_map_unlocked.  This creates a 
pointer
that we pass to shmem_create_from_data.  Aside from an i915_gem_object_is_shmem
check at the start, the function is otherwise just calling 
shmem_create_from_data...
which, itself, is only called by shmem_create_from_object.

I'd argue that any additional changes to shmem_create_from_object are 
unnecessary
as the function is only called from __engines_record_defaults.  Additionally, 
the function
is a part of the gt library (shmem_utils.h is in the gt folder), so taking a gt 
argument should
be expected.  However, if you still disagree, here's a few options for how we 
can rectify
this issue:

Debatably, we could just delete shmem_create_from_object and use the full 
expansion
in __engines_record_defaults.  Though this may come with some additional 
complications,
such as the lost helper function being desirable in the future and needing to 
expand the
definition of shmem_create_from_data to include an object pinning requirement.

The second option is that we pass the map_type to the shmem_create_from_object 
function
instead of the GT, bypassing the need for i915_coherent_map_type in the 
function by breaking
it out as a part of __engines_record_defaults.  I'll leave it to your judgement 
whether this would
be more or less confusing than just passing the GT.

Thirdly, we could just hard-code a specific map_type to use, though that seems 
ill-advised.

The last option is to rename the function to something more representative. 
Here's a few ideas
I can think of off the top of my head:

shmem_create
shmem_create_on_gt
shmem_create_from_gt
shmem_create_from_object_on_gt
intel_gt_create_shmem_from_object

If I had to recommend one approach over the rest, it would probably be the 
second option,
followed by the fourth.

-Jonathan Cavitt

>
> Regards,
> 
> Tvrtko
> 
> P.S. See if you can drop the dii-client part from the subject line going 
> forward.
> 
> > 
> > Suggested-by: Matt Roper 
> > Signed-off-by: Jonathan Cavitt 
> > ---
> >   drivers/gpu/drm/i915/display/intel_hdcp_gsc.c   |  3 ++-
> >   drivers/gpu/drm/i915/gem/i915_gem_object.h  |  4 
> >   drivers/gpu/drm/i915/gem/i915_gem_pages.c   | 15 ---
> >   .../drm/i915/gem/selftests/i915_gem_migrate.c   | 12 ++--
> >   drivers/gpu/drm/i915/gt/intel_engine_pm.c   |  2 +-
> >   drivers/gpu/drm/i915/gt/intel_gt.c  | 17 -
> >   drivers/gpu/drm/i915/gt/intel_gt.h  |  3 +++
> >   drivers/gpu/drm/i915/gt/intel_gtt.c |  4 ++--
> >   drivers/gpu/drm/i915/gt/intel_lrc.c |  2 +-
> >   drivers/gpu/drm/i915/gt/intel_ring.c|  3 ++-
> >   drivers/gpu/drm/i915/gt/selftest_context.c  |  2 +-
> >   drivers/gpu/drm/i915/gt/selftest_hangcheck.c|  4 ++--
> >   drivers/gpu/drm/i915/gt/selftest_lrc.c  |  2 +-
> >   drivers/gpu/drm/i915/gt/shmem_utils.c   |  7 ---
> >   drivers/gpu/drm/i915/gt/shmem_utils.h   |  4 +++-
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c   |  3 +--
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c  |  2 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c   |  3 +--
> >   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c|  3 ++-
> >   drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c  |  2 +-
> >   drivers/gpu/drm/i915/pxp/intel_pxp_tee.c|  3 ++-
> >   drivers/gpu/drm/i915/selftests/igt_spinner.c|  2 +-
> >   22 files changed, 53 insertions(+), 49 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > index ad0405375881..d753db3eef15 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > @@ -6,6 +6,7 @@
> >   #include 
> >   
> >   #include "gem/i915_gem_region.h"
> > +#include "gt/intel_gt.h"
> >   #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
> >   #include "i915_drv.h"
> >   #include "i915_utils.h"
> > @@ -632,7 +633,7 @@ static int intel_hdcp_gsc_initia

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915: Move abs_diff() to math.h

2023-07-25 Thread Greg Kroah-Hartman

On Mon, Jul 24, 2023 at 11:25:11AM +0300, Andy Shevchenko wrote:
> abs_diff() belongs to math.h. Move it there.
> This will allow others to use it.
> 
> Signed-off-by: Andy Shevchenko 
> Reviewed-by: Jiri Slaby  # tty/serial

Acked-by: Greg Kroah-Hartman

Re: [Intel-gfx] [PATCH] drm/i915: Replace i915->gt0 with to_gt(i915)

Hi,

On Tue, Jul 25, 2023 at 03:41:31PM +0200, Andrzej Hajda wrote:
> On 25.07.2023 12:33, Andi Shyti wrote:
> > Quite surprised to see that around i915 there are still i915->gt0
> > references. Replace them with the to_gt() helper.
> > 
> > Signed-off-by: Andi Shyti 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_stolen.c   | 2 +-
> >   drivers/gpu/drm/i915/gt/intel_gt.c   | 2 +-
> >   drivers/gpu/drm/i915/gt/intel_region_lmem.c  | 2 +-
> >   drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 
> >   drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> >   5 files changed, 8 insertions(+), 8 deletions(-)
> 
> Reviewed-by: Andrzej Hajda 

Thanks for your review! Pushed in drm-intel-gt-next.

Andi

Re: [Intel-gfx] [PATCH dii-client 1/2] drm/i915: Make i915_coherent_map_type GT-centric




On 25/07/2023 17:01, Jonathan Cavitt wrote:

Refactor i915_coherent_map_type to be GT-centric rather than
device-centric.  Each GT may require different coherency
handling due to hardware workarounds.

Since the function now takes a GT instead of the i915, the function is
renamed and moved to the gt folder.


What about the issue of fake gt passed to shmem_create_from_object I raised?

Regards,

Tvrtko

P.S. See if you can drop the dii-client part from the subject line going 
forward.




Suggested-by: Matt Roper 
Signed-off-by: Jonathan Cavitt 
---
  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c   |  3 ++-
  drivers/gpu/drm/i915/gem/i915_gem_object.h  |  4 
  drivers/gpu/drm/i915/gem/i915_gem_pages.c   | 15 ---
  .../drm/i915/gem/selftests/i915_gem_migrate.c   | 12 ++--
  drivers/gpu/drm/i915/gt/intel_engine_pm.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_gt.c  | 17 -
  drivers/gpu/drm/i915/gt/intel_gt.h  |  3 +++
  drivers/gpu/drm/i915/gt/intel_gtt.c |  4 ++--
  drivers/gpu/drm/i915/gt/intel_lrc.c |  2 +-
  drivers/gpu/drm/i915/gt/intel_ring.c|  3 ++-
  drivers/gpu/drm/i915/gt/selftest_context.c  |  2 +-
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c|  4 ++--
  drivers/gpu/drm/i915/gt/selftest_lrc.c  |  2 +-
  drivers/gpu/drm/i915/gt/shmem_utils.c   |  7 ---
  drivers/gpu/drm/i915/gt/shmem_utils.h   |  4 +++-
  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c   |  3 +--
  drivers/gpu/drm/i915/gt/uc/intel_guc.c  |  2 +-
  drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c   |  3 +--
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c|  3 ++-
  drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c  |  2 +-
  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c|  3 ++-
  drivers/gpu/drm/i915/selftests/igt_spinner.c|  2 +-
  22 files changed, 53 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index ad0405375881..d753db3eef15 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -6,6 +6,7 @@
  #include 
  
  #include "gem/i915_gem_region.h"

+#include "gt/intel_gt.h"
  #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
  #include "i915_drv.h"
  #include "i915_utils.h"
@@ -632,7 +633,7 @@ static int intel_hdcp_gsc_initialize_message(struct 
drm_i915_private *i915,
return PTR_ERR(obj);
}
  
-	cmd_in = i915_gem_object_pin_map_unlocked(obj, i915_coherent_map_type(i915, obj, true));

+   cmd_in = i915_gem_object_pin_map_unlocked(obj, 
intel_gt_coherent_map_type(gt, obj, true));
if (IS_ERR(cmd_in)) {
drm_err(&i915->drm, "Failed to map gsc message page!\n");
err = PTR_ERR(cmd_in);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 884a17275b3a..0c695b4c129f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -716,10 +716,6 @@ void *__must_check i915_gem_object_pin_map(struct 
drm_i915_gem_object *obj,
  void *__must_check i915_gem_object_pin_map_unlocked(struct 
drm_i915_gem_object *obj,
enum i915_map_type type);
  
-enum i915_map_type i915_coherent_map_type(struct drm_i915_private *i915,

- struct drm_i915_gem_object *obj,
- bool always_coherent);
-
  void __i915_gem_object_flush_map(struct drm_i915_gem_object *obj,
 unsigned long offset,
 unsigned long size);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 89fc8ea6bcfc..6d262d269c71 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -465,21 +465,6 @@ void *i915_gem_object_pin_map_unlocked(struct 
drm_i915_gem_object *obj,
return ret;
  }
  
-enum i915_map_type i915_coherent_map_type(struct drm_i915_private *i915,

- struct drm_i915_gem_object *obj,
- bool always_coherent)
-{
-   /*
-* Wa_22016122933: always return I915_MAP_WC for MTL
-*/
-   if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
-   return I915_MAP_WC;
-   if (HAS_LLC(i915) || always_coherent)
-   return I915_MAP_WB;
-   else
-   return I915_MAP_WC;
-}
-
  void __i915_gem_object_flush_map(struct drm_i915_gem_object *obj,
 unsigned long offset,
 unsigned long size)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
index a93a90b15907..d8f4a10d

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Replace several IS_METEORLAKE with proper IP version checks

On Tue, Jul 25, 2023 at 12:10:18PM +0200, Andi Shyti wrote:
> Hi Matt,
> 
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > @@ -470,9 +470,13 @@ enum i915_map_type i915_coherent_map_type(struct 
> > drm_i915_private *i915,
> >   bool always_coherent)
> >  {
> > /*
> > -* Wa_22016122933: always return I915_MAP_WC for MTL
> > +* Wa_22016122933: always return I915_MAP_WC for Xe_LPM+
> > +*
> > +* FIXME: The scope of this workaround is too wide right now and
> > +* is applying to objects used solely on the primary GT.  We need to
> > +* take into account which GT will be operating on the shared object.
> >  */
> > -   if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
> > +   if (i915_gem_object_is_lmem(obj) || MEDIA_VER_FULL(i915) == IP_VER(13, 
> > 0))
> > return I915_MAP_WC;
> > if (HAS_LLC(i915) || always_coherent)
> > return I915_MAP_WB;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > index 21af0ec52223..24060278e7a2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > @@ -21,7 +21,7 @@ static void intel_gsc_idle_msg_enable(struct 
> > intel_engine_cs *engine)
> >  {
> > struct drm_i915_private *i915 = engine->i915;
> >  
> > -   if (IS_METEORLAKE(i915) && engine->id == GSC0) {
> > +   if (MEDIA_VER(i915) >= 13 && engine->id == GSC0) {
> 
> this is a bit in countertrend... why isn't this
> 
>   MEDIA_VER_FULL(engine->i915) == IP_VER(13, 0)
> 
> Like all others?

Generally we always assume that future platforms will inherit the
behavior of the current platform.  The exceptions are things like
workarounds (for which every platform or IP has its own unique list and
we should never inherit) or things like TLB invalidation (where an
overlooked hardware change can go unnoticed in general system usage but
have serious consequences).


Matt

> 
> Andi

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap (rev3)

== Series Details ==

Series: drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap 
(rev3)
URL   : https://patchwork.freedesktop.org/series/121236/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13420 -> Patchwork_121236v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 43)
--

  Additional (2): fi-kbl-soraka fi-pnv-d510 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][3] ([i915#5334] / [i915#7872])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

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

  * igt@i915_selftest@live@requests:
- bat-mtlp-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#7269])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-mtlp-6/igt@i915_selftest@l...@requests.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/bat-mtlp-6/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-WARN][7] ([i915#6367])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-pnv-d510:NOTRUN -> [ABORT][8] ([i915#8844])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/fi-pnv-d510/igt@i915_susp...@basic-s3-without-i915.html
- bat-rpls-1: NOTRUN -> [ABORT][9] ([i915#6687] / [i915#7978] / 
[i915#8668])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271]) +15 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][11] -> [ABORT][12] ([i915#8442] / [i915#8668])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271]) +37 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-rte:
- fi-tgl-1115g4:  [FAIL][14] ([i915#7940]) -> [PASS][15] +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-6: [DMESG-FAIL][16] ([i915#7059]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [DMESG-FAIL][18] ([i915#8497]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/bat-mtlp-8/igt@i915_selftest@l...@requests.html
- bat-rpls-1: [ABORT][20] ([i915#7911] / [i915#7920] / [i915#7982]) 
-> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v3/bat-rpls-1/igt@i915_selftest@l...@

[Intel-gfx] [PATCH dii-client 1/2] drm/i915: Make i915_coherent_map_type GT-centric

2023-07-25 Thread Jonathan Cavitt

Refactor i915_coherent_map_type to be GT-centric rather than
device-centric.  Each GT may require different coherency
handling due to hardware workarounds.

Since the function now takes a GT instead of the i915, the function is
renamed and moved to the gt folder.

Suggested-by: Matt Roper 
Signed-off-by: Jonathan Cavitt 
---
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c   |  3 ++-
 drivers/gpu/drm/i915/gem/i915_gem_object.h  |  4 
 drivers/gpu/drm/i915/gem/i915_gem_pages.c   | 15 ---
 .../drm/i915/gem/selftests/i915_gem_migrate.c   | 12 ++--
 drivers/gpu/drm/i915/gt/intel_engine_pm.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c  | 17 -
 drivers/gpu/drm/i915/gt/intel_gt.h  |  3 +++
 drivers/gpu/drm/i915/gt/intel_gtt.c |  4 ++--
 drivers/gpu/drm/i915/gt/intel_lrc.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_ring.c|  3 ++-
 drivers/gpu/drm/i915/gt/selftest_context.c  |  2 +-
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c|  4 ++--
 drivers/gpu/drm/i915/gt/selftest_lrc.c  |  2 +-
 drivers/gpu/drm/i915/gt/shmem_utils.c   |  7 ---
 drivers/gpu/drm/i915/gt/shmem_utils.h   |  4 +++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c   |  3 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc.c  |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c   |  3 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c|  3 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c  |  2 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c|  3 ++-
 drivers/gpu/drm/i915/selftests/igt_spinner.c|  2 +-
 22 files changed, 53 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index ad0405375881..d753db3eef15 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -6,6 +6,7 @@
 #include 
 
 #include "gem/i915_gem_region.h"
+#include "gt/intel_gt.h"
 #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 #include "i915_drv.h"
 #include "i915_utils.h"
@@ -632,7 +633,7 @@ static int intel_hdcp_gsc_initialize_message(struct 
drm_i915_private *i915,
return PTR_ERR(obj);
}
 
-   cmd_in = i915_gem_object_pin_map_unlocked(obj, 
i915_coherent_map_type(i915, obj, true));
+   cmd_in = i915_gem_object_pin_map_unlocked(obj, 
intel_gt_coherent_map_type(gt, obj, true));
if (IS_ERR(cmd_in)) {
drm_err(&i915->drm, "Failed to map gsc message page!\n");
err = PTR_ERR(cmd_in);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 884a17275b3a..0c695b4c129f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -716,10 +716,6 @@ void *__must_check i915_gem_object_pin_map(struct 
drm_i915_gem_object *obj,
 void *__must_check i915_gem_object_pin_map_unlocked(struct drm_i915_gem_object 
*obj,
enum i915_map_type type);
 
-enum i915_map_type i915_coherent_map_type(struct drm_i915_private *i915,
- struct drm_i915_gem_object *obj,
- bool always_coherent);
-
 void __i915_gem_object_flush_map(struct drm_i915_gem_object *obj,
 unsigned long offset,
 unsigned long size);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 89fc8ea6bcfc..6d262d269c71 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -465,21 +465,6 @@ void *i915_gem_object_pin_map_unlocked(struct 
drm_i915_gem_object *obj,
return ret;
 }
 
-enum i915_map_type i915_coherent_map_type(struct drm_i915_private *i915,
- struct drm_i915_gem_object *obj,
- bool always_coherent)
-{
-   /*
-* Wa_22016122933: always return I915_MAP_WC for MTL
-*/
-   if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
-   return I915_MAP_WC;
-   if (HAS_LLC(i915) || always_coherent)
-   return I915_MAP_WB;
-   else
-   return I915_MAP_WC;
-}
-
 void __i915_gem_object_flush_map(struct drm_i915_gem_object *obj,
 unsigned long offset,
 unsigned long size)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
index a93a90b15907..d8f4a10d71de 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
@@ -13,12 +13,12 @@
 #include "selftests/igt_spinner.h"
 
 static int igt_fill_check_buffer(struct drm_i915_gem_object *obj,
+

[Intel-gfx] [PATCH dii-client 2/2] drm/i915/gt: Apply workaround 22016122933 correctly

2023-07-25 Thread Jonathan Cavitt

WA_22016122933 was recently applied to all MeteorLake engines, which is
simultaneously too broad (should only apply to Media engines) and too
specific (should apply to all platforms that use the same media engine
as MeteorLake).  Correct this in cases where coherency settings are
modified.

There were also two additional places where the workaround was applied
unconditionally.  The change was confirmed as necessary for all
platforms, so the workaround label was removed.

Signed-off-by: Jonathan Cavitt 
Suggested-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt.c| 5 +++--
 drivers/gpu/drm/i915/gt/intel_gt.h| 6 ++
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 7 ---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 4 
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 ---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 
 6 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 6faf1dae965f..207bfc0ff939 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1139,9 +1139,10 @@ enum i915_map_type intel_gt_coherent_map_type(struct 
intel_gt *gt,
  bool always_coherent)
 {
/*
-* Wa_22016122933: always return I915_MAP_WC for MTL
+* Wa_22016122933: always return I915_MAP_WC for Media
+* version 13.0 when the object is on the Media GT
 */
-   if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(gt->i915))
+   if (i915_gem_object_is_lmem(obj) || intel_gt_needs_wa_22016122933(gt))
return I915_MAP_WC;
if (HAS_LLC(gt->i915) || always_coherent)
return I915_MAP_WB;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index adb442aaa522..2444ceb42b1b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -6,6 +6,7 @@
 #ifndef __INTEL_GT__
 #define __INTEL_GT__
 
+#include "i915_drv.h"
 #include "intel_engine_types.h"
 #include "intel_gt_types.h"
 #include "intel_reset.h"
@@ -24,6 +25,11 @@ static inline bool gt_is_root(struct intel_gt *gt)
return !gt->info.id;
 }
 
+static inline bool intel_gt_needs_wa_22016122933(struct intel_gt *gt)
+{
+   return MEDIA_VER_FULL(gt->i915) == IP_VER(13, 0) && gt->type == 
GT_MEDIA;
+}
+
 static inline struct intel_gt *uc_to_gt(struct intel_uc *uc)
 {
return container_of(uc, struct intel_gt, uc);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e5a83d4932c8..9f0a2d828a2a 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1095,10 +1095,11 @@ __lrc_alloc_state(struct intel_context *ce, struct 
intel_engine_cs *engine)
if (IS_ERR(obj)) {
obj = i915_gem_object_create_shmem(engine->i915, context_size);
/*
-* Wa_22016122933: For MTL the shared memory needs to be mapped
-* as WC on CPU side and UC (PAT index 2) on GPU side
+* Wa_22016122933: For Media version 13.0, all Media GT shared
+* memory needs to be mapped as WC on CPU side and UC (PAT
+* index 2) on GPU side.
 */
-   if (IS_METEORLAKE(engine->i915))
+   if (intel_gt_needs_wa_22016122933(engine->gt))
i915_gem_object_set_cache_coherency(obj, 
I915_CACHE_NONE);
}
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 6efb86c93bfc..52652a0350c6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -284,10 +284,6 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
memcpy_toio(gsc->local_vaddr, src, gsc->fw.size);
memset_io(gsc->local_vaddr + gsc->fw.size, 0, gsc->local->size - 
gsc->fw.size);
 
-   /*
-* Wa_22016122933: Making sure the data in dst is
-* visible to GSC right away
-*/
intel_guc_write_barrier(>->uc.guc);
 
i915_gem_object_unpin_map(gsc->fw.obj);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index c0fa9d232205..63bdc000d76b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -745,10 +745,11 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
return ERR_CAST(obj);
 
/*
-* Wa_22016122933: For MTL the shared memory needs to be mapped
-* as WC on CPU side and UC (PAT index 2) on GPU side
+* Wa_22016122933: For Media version 13.0, all Media GT shared
+* memory needs to be mapped as WC on CPU side and UC (PAT
+* index 2) on GPU side.
 */
-   if (IS_METEORLAKE(gt->i915))
+   if (intel_gt_needs_wa_2201612293

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace i915->gt0 with to_gt(i915)

== Series Details ==

Series: drm/i915: Replace i915->gt0 with to_gt(i915)
URL   : https://patchwork.freedesktop.org/series/121302/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13419_full -> Patchwork_121302v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (1): shard-rkl0 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_eio@unwedge-stress:
- shard-dg1:  [PASS][2] -> [FAIL][3] ([i915#5784]) +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-dg1-13/igt@gem_...@unwedge-stress.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-dg1-19/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@bcs0:
- shard-rkl:  [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-rkl-4/igt@gem_exec_fair@basic-n...@bcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-rkl-2/igt@gem_exec_fair@basic-n...@bcs0.html

  * igt@gem_exec_flush@basic-wb-ro-default:
- shard-dg2:  NOTRUN -> [SKIP][8] ([i915#3539] / [i915#4852])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-dg2-6/igt@gem_exec_fl...@basic-wb-ro-default.html

  * igt@gem_exec_reloc@basic-wc:
- shard-mtlp: NOTRUN -> [SKIP][9] ([i915#3281])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-mtlp-2/igt@gem_exec_re...@basic-wc.html

  * igt@gem_exec_schedule@preempt-queue:
- shard-mtlp: NOTRUN -> [SKIP][10] ([i915#4812])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-mtlp-2/igt@gem_exec_sched...@preempt-queue.html

  * igt@gem_fenced_exec_thrash@no-spare-fences-busy-interruptible:
- shard-mtlp: NOTRUN -> [SKIP][11] ([i915#4860])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-mtlp-2/igt@gem_fenced_exec_thr...@no-spare-fences-busy-interruptible.html

  * igt@gem_mmap_gtt@basic-read-write:
- shard-mtlp: NOTRUN -> [SKIP][12] ([i915#4077])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-mtlp-2/igt@gem_mmap_...@basic-read-write.html

  * igt@gem_mmap_wc@read-write:
- shard-mtlp: NOTRUN -> [SKIP][13] ([i915#4083]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-mtlp-2/igt@gem_mmap...@read-write.html

  * igt@gem_pxp@protected-raw-src-copy-not-readible:
- shard-mtlp: NOTRUN -> [SKIP][14] ([i915#4270])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-mtlp-4/igt@gem_...@protected-raw-src-copy-not-readible.html

  * igt@gen3_render_tiledx_blits:
- shard-mtlp: NOTRUN -> [SKIP][15] ([fdo#109289])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-mtlp-2/igt@gen3_render_tiledx_blits.html

  * igt@i915_pm_rpm@debugfs-forcewake-user:
- shard-tglu: [PASS][16] -> [FAIL][17] ([i915#7940])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-tglu-3/igt@i915_pm_...@debugfs-forcewake-user.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-tglu-5/igt@i915_pm_...@debugfs-forcewake-user.html

  * igt@i915_pm_rpm@dpms-lpsp:
- shard-dg1:  [PASS][18] -> [SKIP][19] ([i915#1397]) +3 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-dg1-19/igt@i915_pm_...@dpms-lpsp.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-dg1-14/igt@i915_pm_...@dpms-lpsp.html

  * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- shard-dg2:  [PASS][20] -> [SKIP][21] ([i915#1397])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-dg2-8/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/shard-dg2-12/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html

  * igt@i915_pm_rpm@gem-execbuf-stress@smem0:
- shard-dg1:  [PASS][22] -> [FAIL][23] ([i915#7940]) +2 similar 
issues
   [22]: 
https://intel-gfx-ci.01.or

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/xelpg: Call Xe_LPG workaround functions based on IP version

On Tue, Jul 25, 2023 at 04:52:07PM +0100, Tvrtko Ursulin wrote:
> 
> On 25/07/2023 16:35, Matt Roper wrote:
> > On Tue, Jul 25, 2023 at 01:02:54PM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 25/07/2023 01:13, Matt Roper wrote:
> > > > Although some of our Xe_LPG workarounds were already being applied based
> > > > on IP version correctly, others were matching on MTL as a base platform,
> > > > which is incorrect.  Although MTL is the only platform right now that
> > > > uses Xe_LPG IP, this may not always be the case.  If a future platform
> > > > re-uses this graphics IP, the same workarounds should be applied, even
> > > > if it isn't a "MTL" platform.
> > > > 
> > > > We were also incorrectly applying Xe_LPG workarounds/tuning to the
> > > > Xe_LPM+ media IP in one or two places; we should make sure that we don't
> > > > try to apply graphics workarounds to the media GT and vice versa where
> > > > they don't belong.  A new helper macro IS_GT_IP_RANGE() is added to help
> > > > ensure this is handled properly -- it checks that the GT matches the IP
> > > > type being tested as well as the IP version falling in the proper range.
> > > > 
> > > > Note that many of the stepping-based workarounds are still incorrectly
> > > > checking for a MTL base platform; that will be remedied in a later
> > > > patch.
> > > > 
> > > > v2:
> > > >- Rework macro into a slightly more generic IS_GT_IP_RANGE() that can
> > > >  be used for either GFX or MEDIA checks.
> > > > 
> > > > Cc: Gustavo Sousa 
> > > > Cc: Tvrtko Ursulin 
> > > > Signed-off-by: Matt Roper 
> > > > ---
> > > >drivers/gpu/drm/i915/gt/intel_workarounds.c | 38 
> > > > +++--
> > > >drivers/gpu/drm/i915/i915_drv.h | 23 +
> > > >2 files changed, 43 insertions(+), 18 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > index d8a1eaa44e69..c4663541c5dd 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > @@ -805,8 +805,8 @@ static void dg2_ctx_workarounds_init(struct 
> > > > intel_engine_cs *engine,
> > > > wa_masked_en(wal, CACHE_MODE_1, 
> > > > MSAA_OPTIMIZATION_REDUC_DISABLE);
> > > >}
> > > > -static void mtl_ctx_gt_tuning_init(struct intel_engine_cs *engine,
> > > > -  struct i915_wa_list *wal)
> > > > +static void xelpg_ctx_gt_tuning_init(struct intel_engine_cs *engine,
> > > > +struct i915_wa_list *wal)
> > > >{
> > > > struct drm_i915_private *i915 = engine->i915;
> > > > @@ -817,12 +817,12 @@ static void mtl_ctx_gt_tuning_init(struct 
> > > > intel_engine_cs *engine,
> > > > wa_add(wal, DRAW_WATERMARK, VERT_WM_VAL, 0x3FF, 0, 
> > > > false);
> > > >}
> > > > -static void mtl_ctx_workarounds_init(struct intel_engine_cs *engine,
> > > > -struct i915_wa_list *wal)
> > > > +static void xelpg_ctx_workarounds_init(struct intel_engine_cs *engine,
> > > > +  struct i915_wa_list *wal)
> > > >{
> > > > struct drm_i915_private *i915 = engine->i915;
> > > > -   mtl_ctx_gt_tuning_init(engine, wal);
> > > > +   xelpg_ctx_gt_tuning_init(engine, wal);
> > > > if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > > > IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
> > > > @@ -931,8 +931,8 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs 
> > > > *engine,
> > > > if (engine->class != RENDER_CLASS)
> > > > goto done;
> > > > -   if (IS_METEORLAKE(i915))
> > > > -   mtl_ctx_workarounds_init(engine, wal);
> > > > +   if (IS_GT_IP_RANGE(GFX, engine->gt, IP_VER(12, 70), IP_VER(12, 
> > > > 71)))
> > > > +   xelpg_ctx_workarounds_init(engine, wal);
> > > > else if (IS_PONTEVECCHIO(i915))
> > > > ; /* noop; none at this time */
> > > > else if (IS_DG2(i915))
> > > > @@ -1790,10 +1790,8 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt, 
> > > > struct i915_wa_list *wal)
> > > > */
> > > >static void gt_tuning_settings(struct intel_gt *gt, struct 
> > > > i915_wa_list *wal)
> > > >{
> > > > -   if (IS_METEORLAKE(gt->i915)) {
> > > > -   if (gt->type != GT_MEDIA)
> > > > -   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
> > > > BLEND_FILL_CACHING_OPT_DIS);
> > > > -
> > > > +   if (IS_GT_IP_RANGE(GFX, gt, IP_VER(12, 70), IP_VER(12, 71))) {
> > > > +   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
> > > > BLEND_FILL_CACHING_OPT_DIS);
> > > > wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
> > > > }
> > > > @@ -1825,7 +1823,7 @@ gt_init_workarounds(struct intel_gt *gt, struct 
> > > > i915_wa_list *wal)
> > > > return;
> > > > }
>

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap (rev3)

== Series Details ==

Series: drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap 
(rev3)
URL   : https://patchwork.freedesktop.org/series/121236/
State : warning

== Summary ==

Error: dim checkpatch failed
aaa6028351e5 drm/i915: Avoid GGTT flushing on non-GGTT paths of 
i915_vma_pin_iomap
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")

-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d976521a995a ("drm/i915: extend 
i915_vma_pin_iomap()")'
#15: 
d976521a995a ("drm/i915: extend i915_vma_pin_iomap()").

-:64: WARNING:MEMORY_BARRIER: memory barrier without comment
#64: FILE: drivers/gpu/drm/i915/i915_vma.c:632:
+   wmb();

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

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

On Tue, Jul 25, 2023 at 01:10:24PM +0100, Tvrtko Ursulin wrote:
> 
> On 25/07/2023 01:13, Matt Roper wrote:
> > Several workarounds are guarded by IS_MTL_GRAPHICS_STEP.  However none
> > of these workarounds are actually tied to MTL as a platform; they only
> > relate to the Xe_LPG graphics IP, regardless of what platform it appears
> > in.  At the moment MTL is the only platform that uses Xe_LPG with IP
> > versions 12.70 and 12.71, but we can't count on this being true in the
> > future.  Switch these to use a new IS_GT_IP_STEP() macro instead that is
> > purely based on IP version.  IS_GT_IP_STEP() is also GT-based rather
> > than device-based, which will help prevent mistakes where we
> > accidentally try to apply Xe_LPG graphics workarounds to the Xe_LPM+
> > media GT and vice-versa.
> > 
> > v2:
> >   - Switch to a more generic and shorter IS_GT_IP_STEP macro that can be
> > used for both graphics and media IP (and any other kind of GTs that
> > show up in the future).
> > 
> > Cc: Gustavo Sousa 
> > Cc: Tvrtko Ursulin 
> > Signed-off-by: Matt Roper 
> > ---
> >   .../drm/i915/display/skl_universal_plane.c|  4 +-
> >   drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  9 ++--
> >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  4 +-
> >   drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
> >   drivers/gpu/drm/i915/gt/intel_reset.c |  2 +-
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c   | 52 ++-
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c|  2 +-
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +-
> >   drivers/gpu/drm/i915/i915_drv.h   | 30 +--
> >   9 files changed, 67 insertions(+), 42 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 6b01a0b68b97..5fd8a42b3ec1 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -2169,8 +2169,8 @@ static bool skl_plane_has_rc_ccs(struct 
> > drm_i915_private *i915,
> >  enum pipe pipe, enum plane_id plane_id)
> >   {
> > /* Wa_14017240301 */
> > -   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > -   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
> > +   if (IS_GT_IP_STEP(GFX, to_gt(i915), IP_VER(12, 70), A0, B0) ||
> > +   IS_GT_IP_STEP(GFX, to_gt(i915), IP_VER(12, 71), A0, B0))
> > return false;
> > /* Wa_22011186057 */
> > diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> > b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > index 3ba20ea030e8..9d04591f3b4a 100644
> > --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > @@ -180,8 +180,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
> > *cs, const i915_reg_t inv
> >   static int mtl_dummy_pipe_control(struct i915_request *rq)
> >   {
> > /* Wa_14016712196 */
> > -   if (IS_MTL_GRAPHICS_STEP(rq->i915, M, STEP_A0, STEP_B0) ||
> > -   IS_MTL_GRAPHICS_STEP(rq->i915, P, STEP_A0, STEP_B0)) {
> > +   if (IS_GT_IP_STEP(GFX, rq->engine->gt, IP_VER(12, 70), A0, B0) ||
> > +   IS_GT_IP_STEP(GFX, rq->engine->gt, IP_VER(12, 71), A0, B0)) {
> > u32 *cs;
> > /* dummy PIPE_CONTROL + depth flush */
> > @@ -755,6 +755,7 @@ u32 *gen12_emit_fini_breadcrumb_xcs(struct i915_request 
> > *rq, u32 *cs)
> >   u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
> >   {
> > struct drm_i915_private *i915 = rq->i915;
> > +   struct intel_gt *gt = rq->engine->gt;
> > u32 flags = (PIPE_CONTROL_CS_STALL |
> >  PIPE_CONTROL_TLB_INVALIDATE |
> >  PIPE_CONTROL_TILE_CACHE_FLUSH |
> > @@ -765,8 +766,8 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
> > *rq, u32 *cs)
> >  PIPE_CONTROL_FLUSH_ENABLE);
> > /* Wa_14016712196 */
> > -   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > -   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
> > +   if (IS_GT_IP_STEP(GFX, gt, IP_VER(12, 70), A0, B0) ||
> > +   IS_GT_IP_STEP(GFX, gt, IP_VER(12, 71), A0, B0))
> > /* dummy PIPE_CONTROL + depth flush */
> > cs = gen12_emit_pipe_control(cs, 0,
> >  PIPE_CONTROL_DEPTH_CACHE_FLUSH, 0);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index 0b414eae1683..c66373176f6c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > @@ -166,8 +166,8 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> > gt->steering_table[OADDRM] = xelpmp_oaddrm_steering_table;
> > } else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
> > /* Wa_14016747170 */
> > -   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > -   IS_MTL_GRAPHICS_

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/xelpg: Call Xe_LPG workaround functions based on IP version




On 25/07/2023 16:35, Matt Roper wrote:

On Tue, Jul 25, 2023 at 01:02:54PM +0100, Tvrtko Ursulin wrote:


On 25/07/2023 01:13, Matt Roper wrote:

Although some of our Xe_LPG workarounds were already being applied based
on IP version correctly, others were matching on MTL as a base platform,
which is incorrect.  Although MTL is the only platform right now that
uses Xe_LPG IP, this may not always be the case.  If a future platform
re-uses this graphics IP, the same workarounds should be applied, even
if it isn't a "MTL" platform.

We were also incorrectly applying Xe_LPG workarounds/tuning to the
Xe_LPM+ media IP in one or two places; we should make sure that we don't
try to apply graphics workarounds to the media GT and vice versa where
they don't belong.  A new helper macro IS_GT_IP_RANGE() is added to help
ensure this is handled properly -- it checks that the GT matches the IP
type being tested as well as the IP version falling in the proper range.

Note that many of the stepping-based workarounds are still incorrectly
checking for a MTL base platform; that will be remedied in a later
patch.

v2:
   - Rework macro into a slightly more generic IS_GT_IP_RANGE() that can
 be used for either GFX or MEDIA checks.

Cc: Gustavo Sousa 
Cc: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
---
   drivers/gpu/drm/i915/gt/intel_workarounds.c | 38 +++--
   drivers/gpu/drm/i915/i915_drv.h | 23 +
   2 files changed, 43 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index d8a1eaa44e69..c4663541c5dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -805,8 +805,8 @@ static void dg2_ctx_workarounds_init(struct intel_engine_cs 
*engine,
wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE);
   }
-static void mtl_ctx_gt_tuning_init(struct intel_engine_cs *engine,
-  struct i915_wa_list *wal)
+static void xelpg_ctx_gt_tuning_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
   {
struct drm_i915_private *i915 = engine->i915;
@@ -817,12 +817,12 @@ static void mtl_ctx_gt_tuning_init(struct intel_engine_cs 
*engine,
wa_add(wal, DRAW_WATERMARK, VERT_WM_VAL, 0x3FF, 0, false);
   }
-static void mtl_ctx_workarounds_init(struct intel_engine_cs *engine,
-struct i915_wa_list *wal)
+static void xelpg_ctx_workarounds_init(struct intel_engine_cs *engine,
+  struct i915_wa_list *wal)
   {
struct drm_i915_private *i915 = engine->i915;
-   mtl_ctx_gt_tuning_init(engine, wal);
+   xelpg_ctx_gt_tuning_init(engine, wal);
if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
@@ -931,8 +931,8 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
if (engine->class != RENDER_CLASS)
goto done;
-   if (IS_METEORLAKE(i915))
-   mtl_ctx_workarounds_init(engine, wal);
+   if (IS_GT_IP_RANGE(GFX, engine->gt, IP_VER(12, 70), IP_VER(12, 71)))
+   xelpg_ctx_workarounds_init(engine, wal);
else if (IS_PONTEVECCHIO(i915))
; /* noop; none at this time */
else if (IS_DG2(i915))
@@ -1790,10 +1790,8 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt, struct 
i915_wa_list *wal)
*/
   static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list *wal)
   {
-   if (IS_METEORLAKE(gt->i915)) {
-   if (gt->type != GT_MEDIA)
-   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
BLEND_FILL_CACHING_OPT_DIS);
-
+   if (IS_GT_IP_RANGE(GFX, gt, IP_VER(12, 70), IP_VER(12, 71))) {
+   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
BLEND_FILL_CACHING_OPT_DIS);
wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
}
@@ -1825,7 +1823,7 @@ gt_init_workarounds(struct intel_gt *gt, struct 
i915_wa_list *wal)
return;
}
-   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   if (IS_GT_IP_RANGE(GFX, gt, IP_VER(12, 70), IP_VER(12, 71)))
xelpg_gt_workarounds_init(gt, wal);
else if (IS_PONTEVECCHIO(i915))
pvc_gt_workarounds_init(gt, wal);
@@ -2293,7 +2291,7 @@ static void pvc_whitelist_build(struct intel_engine_cs 
*engine)
blacklist_trtt(engine);
   }
-static void mtl_whitelist_build(struct intel_engine_cs *engine)
+static void xelpg_whitelist_build(struct intel_engine_cs *engine)
   {
struct i915_wa_list *w = &engine->whitelist;
@@ -2315,8 +2313,10 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
*engine)
wa_init_start(w, engine->gt, "whitelist", engine->name);
-   if (IS_METEORLAKE(i915))
-   mtl_whitelist_build(engine);
+   if (engine->gt->typ

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

On Tue, Jul 25, 2023 at 12:04:43PM +0200, Andi Shyti wrote:
> Hi Matt,
> 
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -436,6 +436,9 @@ static inline struct intel_gt *to_gt(struct 
> > drm_i915_private *i915)
> >  #define __GT_VER_FULL(gt) (__IS_MEDIA_GT(gt) ? \
> >MEDIA_VER_FULL((gt)->i915) : \
> >GRAPHICS_VER_FULL((gt)->i915))
> > +#define __GT_STEP(gt) (__IS_MEDIA_GT(gt) ? \
> > +  INTEL_MEDIA_STEP((gt)->i915) : \
> > +  INTEL_GRAPHICS_STEP((gt)->i915))
> >  
> >  /*
> >   * Check that a GT contains IP of the specified type and within the 
> > specified
> > @@ -454,6 +457,29 @@ static inline struct intel_gt *to_gt(struct 
> > drm_i915_private *i915)
> >  __GT_VER_FULL(gt) >= (from) && \
> >  __GT_VER_FULL(gt) <= (until)))
> >  
> > +/*
> > + * Check whether a GT contains the specific IP version and a stepping 
> > within
> > + * the specified range [from, until).  The lower stepping bound is 
> > inclusive,
> > + * the upper bound is exclusive (corresponding to the first hardware 
> > stepping
> > + * at when the workaround is no longer needed).  E.g.,
> > + *
> > + *IS_GT_IP_STEP(GFX, IP_VER(12, 70), A0, B0)
> > + *IS_GT_IP_STEP(MEDIA, IP_VER(13, 00), B1, D0)
> > + *IS_GT_IP_STEP(GFX, IP_VER(12, 71), B1, FOREVER)
> > + *
> > + * "FOREVER" can be passed as the upper stepping bound for workarounds that
> > + * have no upper bound on steppings of the specified IP version.
> > + *
> > + * Note that media version checks with this macro will only work on 
> > platforms
> > + * with standalone media design (i.e., media version 13 and higher).
> > + */
> > +#define IS_GT_IP_STEP(type, gt, ipver, since, until) \
> > +   (BUILD_BUG_ON_ZERO(ipver < IP_VER(2, 0)) + \
> > +(__IS_##type##_GT(gt) && \
> > + __GT_VER_FULL(gt) == ipver && \
> > + __GT_STEP(gt) >= STEP_##since && \
> > + __GT_STEP(gt) <= STEP_##until))
> > +
> 
> Should this go in intel_gt.h?
> 
> >  #define MEDIA_VER(i915)
> > (RUNTIME_INFO(i915)->media.ip.ver)
> >  #define MEDIA_VER_FULL(i915)   
> > IP_VER(RUNTIME_INFO(i915)->media.ip.ver, \
> >RUNTIME_INFO(i915)->media.ip.rel)
> > @@ -710,10 +736,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >  #define IS_XEHPSDV_GRAPHICS_STEP(__i915, since, until) \
> > (IS_XEHPSDV(__i915) && IS_GRAPHICS_STEP(__i915, since, until))
> >  
> > -#define IS_MTL_GRAPHICS_STEP(__i915, variant, since, until) \
> > -   (IS_SUBPLATFORM(__i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_##variant) 
> > && \
> > -IS_GRAPHICS_STEP(__i915, since, until))
> > -
> 
> For completeness I would either leave this or remove all the
> above. Or I would make this a wrapper around IS_GT_IP_STEP() with
> a compile error if we are outside the MTL range.

If we leave this, then someone might try to use it in future patches.
Every single place this macro gets used will always be a driver bug,
which is the motivation for killing it off.

In contast, the ones for older platforms are correct and should remain.
Before the hardware switched to the disaggretated IP design, steppings
for each IP were directly tied to the base platform rather than the IP
version, and we inferred from the PCI revid.


Matt

> 
> Andi
> 
> >  #define IS_MTL_DISPLAY_STEP(__i915, since, until) \
> > (IS_METEORLAKE(__i915) && \
> >  IS_DISPLAY_STEP(__i915, since, until))
> > -- 
> > 2.41.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Update AUX invalidation sequence (rev11)

== Series Details ==

Series: Update AUX invalidation sequence (rev11)
URL   : https://patchwork.freedesktop.org/series/119798/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13420 -> Patchwork_119798v11


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 42)
--

  Additional (1): fi-pnv-d510 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-rpls-1: NOTRUN -> [FAIL][1] ([fdo#103375] / [i915#8011])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- bat-dg1-7:  [PASS][2] -> [FAIL][3] ([i915#7691])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-dg1-7/igt@i915_pm_...@basic-pci-d3-state.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-dg1-7/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-rkl-11600:   [PASS][4] -> [FAIL][5] ([i915#7940])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/fi-rkl-11600/igt@i915_pm_...@module-reload.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/fi-rkl-11600/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@mman:
- bat-rpls-1: NOTRUN -> [TIMEOUT][6] ([i915#6794] / [i915#7392])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-rpls-1/igt@i915_selftest@l...@mman.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: [PASS][7] -> [DMESG-WARN][8] ([i915#6367])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-1: NOTRUN -> [FAIL][9] ([fdo#103375]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-pnv-d510:NOTRUN -> [ABORT][10] ([i915#8844])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/fi-pnv-d510/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][11] ([i915#7828])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][12] ([i915#1845])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271]) +37 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-rte:
- fi-tgl-1115g4:  [FAIL][14] ([i915#7940]) -> [PASS][15] +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-6: [DMESG-FAIL][16] ([i915#7059]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [ABORT][18] ([i915#7911] / [i915#7920] / [i915#7982]) 
-> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-kbl-7567u:   [INCOMPLETE][20] ([i915#4817]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13420/fi-kbl-7567u/igt@i915_susp...@basic-s3-without-i915.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v11/fi-kbl-7567u/igt@i915_susp...@basic-s3-without-i915.html

  
 Warnings 

  * igt@i915_module_load@load:
- bat-adlp-11:[DMESG-WARN][22] ([i915#4423]) -> [ABORT][23] 
([i915#4423])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1342

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/xelpg: Call Xe_LPG workaround functions based on IP version

On Tue, Jul 25, 2023 at 01:02:54PM +0100, Tvrtko Ursulin wrote:
> 
> On 25/07/2023 01:13, Matt Roper wrote:
> > Although some of our Xe_LPG workarounds were already being applied based
> > on IP version correctly, others were matching on MTL as a base platform,
> > which is incorrect.  Although MTL is the only platform right now that
> > uses Xe_LPG IP, this may not always be the case.  If a future platform
> > re-uses this graphics IP, the same workarounds should be applied, even
> > if it isn't a "MTL" platform.
> > 
> > We were also incorrectly applying Xe_LPG workarounds/tuning to the
> > Xe_LPM+ media IP in one or two places; we should make sure that we don't
> > try to apply graphics workarounds to the media GT and vice versa where
> > they don't belong.  A new helper macro IS_GT_IP_RANGE() is added to help
> > ensure this is handled properly -- it checks that the GT matches the IP
> > type being tested as well as the IP version falling in the proper range.
> > 
> > Note that many of the stepping-based workarounds are still incorrectly
> > checking for a MTL base platform; that will be remedied in a later
> > patch.
> > 
> > v2:
> >   - Rework macro into a slightly more generic IS_GT_IP_RANGE() that can
> > be used for either GFX or MEDIA checks.
> > 
> > Cc: Gustavo Sousa 
> > Cc: Tvrtko Ursulin 
> > Signed-off-by: Matt Roper 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 38 +++--
> >   drivers/gpu/drm/i915/i915_drv.h | 23 +
> >   2 files changed, 43 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index d8a1eaa44e69..c4663541c5dd 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -805,8 +805,8 @@ static void dg2_ctx_workarounds_init(struct 
> > intel_engine_cs *engine,
> > wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE);
> >   }
> > -static void mtl_ctx_gt_tuning_init(struct intel_engine_cs *engine,
> > -  struct i915_wa_list *wal)
> > +static void xelpg_ctx_gt_tuning_init(struct intel_engine_cs *engine,
> > +struct i915_wa_list *wal)
> >   {
> > struct drm_i915_private *i915 = engine->i915;
> > @@ -817,12 +817,12 @@ static void mtl_ctx_gt_tuning_init(struct 
> > intel_engine_cs *engine,
> > wa_add(wal, DRAW_WATERMARK, VERT_WM_VAL, 0x3FF, 0, false);
> >   }
> > -static void mtl_ctx_workarounds_init(struct intel_engine_cs *engine,
> > -struct i915_wa_list *wal)
> > +static void xelpg_ctx_workarounds_init(struct intel_engine_cs *engine,
> > +  struct i915_wa_list *wal)
> >   {
> > struct drm_i915_private *i915 = engine->i915;
> > -   mtl_ctx_gt_tuning_init(engine, wal);
> > +   xelpg_ctx_gt_tuning_init(engine, wal);
> > if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
> > @@ -931,8 +931,8 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs 
> > *engine,
> > if (engine->class != RENDER_CLASS)
> > goto done;
> > -   if (IS_METEORLAKE(i915))
> > -   mtl_ctx_workarounds_init(engine, wal);
> > +   if (IS_GT_IP_RANGE(GFX, engine->gt, IP_VER(12, 70), IP_VER(12, 71)))
> > +   xelpg_ctx_workarounds_init(engine, wal);
> > else if (IS_PONTEVECCHIO(i915))
> > ; /* noop; none at this time */
> > else if (IS_DG2(i915))
> > @@ -1790,10 +1790,8 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt, 
> > struct i915_wa_list *wal)
> >*/
> >   static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list 
> > *wal)
> >   {
> > -   if (IS_METEORLAKE(gt->i915)) {
> > -   if (gt->type != GT_MEDIA)
> > -   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
> > BLEND_FILL_CACHING_OPT_DIS);
> > -
> > +   if (IS_GT_IP_RANGE(GFX, gt, IP_VER(12, 70), IP_VER(12, 71))) {
> > +   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
> > BLEND_FILL_CACHING_OPT_DIS);
> > wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
> > }
> > @@ -1825,7 +1823,7 @@ gt_init_workarounds(struct intel_gt *gt, struct 
> > i915_wa_list *wal)
> > return;
> > }
> > -   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
> > +   if (IS_GT_IP_RANGE(GFX, gt, IP_VER(12, 70), IP_VER(12, 71)))
> > xelpg_gt_workarounds_init(gt, wal);
> > else if (IS_PONTEVECCHIO(i915))
> > pvc_gt_workarounds_init(gt, wal);
> > @@ -2293,7 +2291,7 @@ static void pvc_whitelist_build(struct 
> > intel_engine_cs *engine)
> > blacklist_trtt(engine);
> >   }
> > -static void mtl_whitelist_build(struct intel_engine_cs *engine)
> > +static void xelpg_whitelist_build(struct intel_engine_cs *engine)
> >   {
> > struct i915_wa_list *w = &engine->whitelist;
> > @@ -2315,8 +2313,10 @@ void intel_engine_ini

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update AUX invalidation sequence (rev11)

== Series Details ==

Series: Update AUX invalidation sequence (rev11)
URL   : https://patchwork.freedesktop.org/series/119798/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update AUX invalidation sequence (rev11)

== Series Details ==

Series: Update AUX invalidation sequence (rev11)
URL   : https://patchwork.freedesktop.org/series/119798/
State : warning

== Summary ==

Error: dim checkpatch failed
ffd7dd1ce4c9 drm/i915/gt: Cleanup aux invalidation registers
bc25ba7824ec drm/i915: Add the gen12_needs_ccs_aux_inv helper
5bec5358768f drm/i915/gt: Ensure memory quiesced before invalidation
3e96464a5acd drm/i915/gt: Rename flags with bit_group_X according to the 
datasheet
fce1a9ab0baa drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control and in 
the CS
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#15: 
Requires: 8da173db894a ("drm/i915/gt: Rename flags with bit_group_X according 
to the datasheet")

-:61: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#61: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:302:
+#define   PIPE_CONTROL_CCS_FLUSH   (1<<13) /* MTL+ */
  ^

total: 0 errors, 1 warnings, 1 checks, 30 lines checked
3a43f4dd9ee3 drm/i915/gt: Poll aux invalidation register bit on invalidation
384f1f35f66c drm/i915/gt: Support aux invalidation on all engines

Re: [Intel-gfx] [PATCH v2 1/9] drm/i915: Consolidate condition for Wa_22011802037

On Tue, Jul 25, 2023 at 11:21:34AM +0200, Andi Shyti wrote:
> Hi Matt,
> 
> > +/*
> > + * Wa_22011802037 requires that we (or the GuC) ensure that no command
> > + * streamers are executing MI_FORCE_WAKE while an engine reset is 
> > initiated.
> > + */
> > +bool intel_engine_reset_needs_wa_22011802037(struct intel_gt *gt)
> 
> I've seen this format in a recent Jonathan's patch and I see it
> becoming a pattern in the future. Should we already agree on the
> naming? Would intel_needs_wa_22011802037() be sufficient? Or a

When a helper like this is static to one function, I usually just use
needs_wa_#() as a name.  But when it's exported and used in several
files, I think it's best to give it a meaningful prefix where possible.
In this case intel_reset.c doesn't use a consistent namespace like some
of our other files, but intel_engine_reset_* seemed like an appropriate
prefix that clarifies where this code comes from and what it's general
scope is.

> prefix as intel_wa_* for all the similar functions?

I had a series a year or two ago that disassociated workaround bounds
from workaround implementations and changed all workaround conditions
into something like 'if (I915_WA(foo))' but we ultimately abandoned that
on i915 and shifted the effort over to the Xe driver instead (where the
"OOB" workarounds follow a somewhat similar idea).

Matt

> 
> Andi
> 
> > +{
> > +   if (GRAPHICS_VER(gt->i915) < 11)
> > +   return false;
> > +
> > +   if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0))
> > +   return true;
> > +
> > +   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> > +   return false;
> > +
> > +   return true;
> > +}

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for MTL Degamma implementation (rev3)

== Series Details ==

Series: MTL Degamma implementation (rev3)
URL   : https://patchwork.freedesktop.org/series/119844/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13419_full -> Patchwork_119844v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@flip-vs-modeset-vs-hang@b-vga1:
- shard-snb:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-snb7/igt@kms_flip@flip-vs-modeset-vs-h...@b-vga1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/shard-snb7/igt@kms_flip@flip-vs-modeset-vs-h...@b-vga1.html

  * igt@kms_vblank@pipe-d-wait-busy:
- shard-dg1:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/shard-dg1-17/igt@kms_vbl...@pipe-d-wait-busy.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/shard-dg1-14/igt@kms_vbl...@pipe-d-wait-busy.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH 15/17] cgroup/drm: Expose GPU utilisation

On 21/07/2023 23:20, Tejun Heo wrote:

On Fri, Jul 21, 2023 at 12:19:32PM -1000, Tejun Heo wrote:

On Wed, Jul 12, 2023 at 12:46:03PM +0100, Tvrtko Ursulin wrote:

+ drm.active_us
+ GPU time used by the group recursively including all child groups.

Maybe instead add drm.stat and have "usage_usec" inside? That'd be more
consistent with cpu side.

Could be, but no strong opinion from my side either way. Perhaps it boils down
to what could be put in the file, I mean to decide whether keyed format makes
sense or not.

Also, shouldn't this be keyed by the drm device?

It could have that too, or it could come later. Fun with GPUs that it not only could be keyed by the device, but also by the type of the GPU engine. (Which are a) vendor specific and b) some aree fully independent, some partially so, and some not at all - so it could get complicated semantics wise really fast.)

If for now I'd go with drm.stat/usage_usec containing the total time spent how
would you suggest adding per device granularity? Files as documented are either
flag or nested, not both at the same time. So something like:

usage_usec 10
card0 usage_usec 5
card1 usage_usec 5

Would or would not fly? Have two files along the lines of drm.stat and
drm.dev_stat?

While on this general topic, you will notice that for memory stats I have _sort
of_ nested keyed per device format, for example on integrated Intel GPU:

$ cat drm.memory.stat
card0 region=system total=12898304 shared=0 active=0 resident=12111872
purgeable=167936
card0 region=stolen-system total=0 shared=0 active=0 resident=0 purgeable=0

If one a discrete Intel GPU two more lines would appear with memory regions of
local and local-system. But then on some server class multi-tile GPUs even
further regions with more than one device local memory region. And users do
want to see this granularity for container use cases at least.

Anyway, this may not be compatible with the nested key format as documented in
cgroup-v2.rst, although it does not explicitly say.

Should I cheat and create key names based on device and memory region name and
let userspace parse it? Like:

$ cat drm.memory.stat
card0.system total=12898304 shared=0 active=0 resident=12111872
purgeable=167936
card0.stolen-system total=0 shared=0 active=0 resident=0 purgeable=0

Regards,

Tvrtko

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap (rev2)

== Series Details ==

Series: drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap 
(rev2)
URL   : https://patchwork.freedesktop.org/series/121236/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13419 -> Patchwork_121236v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-kbl-soraka 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-rkl-11600:   [PASS][1] -> [FAIL][2] ([i915#7940])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-rkl-11600/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/fi-rkl-11600/igt@i915_pm_...@module-reload.html
- fi-tgl-1115g4:  [PASS][3] -> [FAIL][4] ([i915#7940])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@requests:
- bat-rpls-2: [PASS][5] -> [ABORT][6] ([i915#4983] / [i915#7913])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/bat-rpls-2/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-jsl-3:  NOTRUN -> [SKIP][7] ([i915#7828])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-jsl-3:  [ABORT][8] ([i915#5122]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-guc: [FAIL][10] ([i915#7940]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- bat-adlp-9: [FAIL][12] ([i915#7940]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-adlp-9/igt@i915_pm_...@basic-pci-d3-state.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/bat-adlp-9/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-guc: [FAIL][14] ([i915#7940]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-cfl-guc/igt@i915_pm_...@module-reload.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/fi-cfl-guc/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-6: [DMESG-FAIL][16] ([i915#7699]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-mtlp-6/igt@i915_selftest@l...@migrate.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/bat-mtlp-6/igt@i915_selftest@l...@migrate.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-jsl-3:  [FAIL][18] ([fdo#103375]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html

  
 Warnings 

  * igt@kms_psr@primary_page_flip:
- bat-rplp-1: [SKIP][20] ([i915#1072]) -> [ABORT][21] ([i915#8442] 
/ [i915#8668] / [i915#8860])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-rplp-1/igt@kms_psr@primary_page_flip.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v2/bat-rplp-1/igt@kms_psr@primary_page_flip.html

  
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7940]: https://gitlab.freedesktop.org/drm/intel/issues/7940
  [i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442
  [i915#8668]: https://gitlab.freedesktop.org/drm/i

Re: [Intel-gfx] [PATCH] drm/i915/huc: silence injected failure in the load via GSC path

Hi Daniele,

On Thu, Jul 20, 2023 at 04:05:05PM -0700, Daniele Ceraolo Spurio wrote:
> If we can't load the HuC due to an injected failure, we don't want
> to throw and error and trip CI. Using the gt_probe_error macro for
> logging ensure that the error is only printed if it wasn't explicitly
> injected.
> 
> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7061
> Signed-off-by: Daniele Ceraolo Spurio 

Reviewed-by: Andi Shyti  

Andi

intel-gfx@lists.freedesktop.org

Hi Uwe,

On Fri, Jul 21, 2023 at 11:21:33PM +0200, Uwe Kleine-König wrote:
> to_i915 is defined as
> 
>   container_of(dev, struct drm_i915_private, drm);
> 
> So for a struct drm_device *dev, to_i915(dev)->drm is just dev. Simplify
> accordingly.
> 
> Signed-off-by: Uwe Kleine-König 

pushed to drm-intel-next.

Thanks,
Andi

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap (rev2)

== Series Details ==

Series: drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap 
(rev2)
URL   : https://patchwork.freedesktop.org/series/121236/
State : warning

== Summary ==

Error: dim checkpatch failed
7f0658687535 drm/i915: Avoid GGTT flushing on non-GGTT paths of 
i915_vma_pin_iomap
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")

-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d976521a995a ("drm/i915: extend 
i915_vma_pin_iomap()")'
#15: 
d976521a995a ("drm/i915: extend i915_vma_pin_iomap()").

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

Re: [Intel-gfx] [PATCH 12/17] cgroup/drm: Introduce weight based drm cgroup control




On 21/07/2023 23:17, Tejun Heo wrote:

On Wed, Jul 12, 2023 at 12:46:00PM +0100, Tvrtko Ursulin wrote:

+DRM scheduling soft limits
+~~


Please don't say soft limits for this. It means something different for
memcg, so it gets really confusing. Call it "weight based CPU time control"
and maybe call the triggering points as thresholds.


Yes sorry, you said that before and I forgot to reword it all when 
re-spinning. I have now marked it as TODO in my email client so 
hopefully next time round I don't forget.


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH] drm/i915: Replace i915->gt0 with to_gt(i915)

2023-07-25 Thread Andrzej Hajda


On 25.07.2023 12:33, Andi Shyti wrote:

Quite surprised to see that around i915 there are still i915->gt0
references. Replace them with the to_gt() helper.

Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/gem/i915_gem_stolen.c   | 2 +-
  drivers/gpu/drm/i915/gt/intel_gt.c   | 2 +-
  drivers/gpu/drm/i915/gt/intel_region_lmem.c  | 2 +-
  drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 
  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
  5 files changed, 8 insertions(+), 8 deletions(-)


Reviewed-by: Andrzej Hajda 

Regards
Andrzej



diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 3b094d36a0b04..5b0a5cf9a98a8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -892,7 +892,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
} else {
resource_size_t lmem_range;
  
-		lmem_range = intel_gt_mcr_read_any(&i915->gt0, XEHP_TILE0_ADDR_RANGE) & 0x;

+   lmem_range = intel_gt_mcr_read_any(to_gt(i915), 
XEHP_TILE0_ADDR_RANGE) & 0x;
lmem_size = lmem_range >> XEHP_TILE_LMEM_RANGE_SHIFT;
lmem_size *= SZ_1G;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 9f64d61dd5fcd..02886c1eb0f17 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -887,7 +887,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt, 
phys_addr_t phys_addr)
  int intel_gt_probe_all(struct drm_i915_private *i915)
  {
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
-   struct intel_gt *gt = &i915->gt0;
+   struct intel_gt *gt = to_gt(i915);
const struct intel_gt_definition *gtdef;
phys_addr_t phys_addr;
unsigned int mmio_bar;
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 2a3217e2890fc..f8512aee58a83 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -220,7 +220,7 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
resource_size_t lmem_range;
u64 tile_stolen, flat_ccs_base;
  
-		lmem_range = intel_gt_mcr_read_any(&i915->gt0, XEHP_TILE0_ADDR_RANGE) & 0x;

+   lmem_range = intel_gt_mcr_read_any(to_gt(i915), 
XEHP_TILE0_ADDR_RANGE) & 0x;
lmem_size = lmem_range >> XEHP_TILE_LMEM_RANGE_SHIFT;
lmem_size *= SZ_1G;
  
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c b/drivers/gpu/drm/i915/pxp/intel_pxp.c

index bb2e15329f346..38ec754d0ec8e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -162,8 +162,8 @@ static struct intel_gt *find_gt_for_required_teelink(struct 
drm_i915_private *i9
 * for HuC authentication. For now, its limited to DG2.
 */
if (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && IS_ENABLED(CONFIG_INTEL_MEI_GSC) 
&&
-   intel_huc_is_loaded_by_gsc(&i915->gt0.uc.huc) && 
intel_uc_uses_huc(&i915->gt0.uc))
-   return &i915->gt0;
+   intel_huc_is_loaded_by_gsc(&to_gt(i915)->uc.huc) && 
intel_uc_uses_huc(&to_gt(i915)->uc))
+   return to_gt(i915);
  
  	return NULL;

  }
@@ -188,8 +188,8 @@ static struct intel_gt 
*find_gt_for_required_protected_content(struct drm_i915_p
 * Else we rely on mei-pxp module but only on legacy platforms
 * prior to having separate media GTs and has a valid VDBOX.
 */
-   if (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && !i915->media_gt && 
VDBOX_MASK(&i915->gt0))
-   return &i915->gt0;
+   if (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && !i915->media_gt && 
VDBOX_MASK(to_gt(i915)))
+   return to_gt(i915);
  
  	return NULL;

  }
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 12aa7fbb07481..da0b269606c51 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -114,7 +114,7 @@ static struct dev_pm_domain pm_domain = {
  
  static void mock_gt_probe(struct drm_i915_private *i915)

  {
-   i915->gt[0] = &i915->gt0;
+   i915->gt[0] = to_gt(i915);
i915->gt[0]->name = "Mock GT";
  }

[Intel-gfx] [PATCH v2] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

From: Tvrtko Ursulin 

Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")
added a code path which does not map via GGTT, but was still setting the
ggtt write bit, and so triggering the GGTT flushing.

Fix it by not setting that bit unless the GGTT mapping path was used, and
replace the flush with wmb() in i915_vma_flush_writes().

This also works for the i915_gem_object_pin_map path added in
d976521a995a ("drm/i915: extend i915_vma_pin_iomap()").

It is hard to say if the fix has any observable effect, given that the
write-combine buffer gets flushed from intel_gt_flush_ggtt_writes too, but
apart from code clarity, skipping the needless GGTT flushing could be
beneficial on platforms with non-coherent GGTT. (See the code flow in
intel_gt_flush_ggtt_writes().)

v2:
 * Improve comment in i915_vma_flush_writes(). (Andi)

Signed-off-by: Tvrtko Ursulin 
Fixes: 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")
References: d976521a995a ("drm/i915: extend i915_vma_pin_iomap()")
Cc: Radhakrishna Sripada 
Cc:  # v5.14+
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_vma.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index ffb425ba591c..7788b03b86d6 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -602,7 +602,9 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
if (err)
goto err_unpin;
 
-   i915_vma_set_ggtt_write(vma);
+   if (!i915_gem_object_is_lmem(vma->obj) &&
+   i915_vma_is_map_and_fenceable(vma))
+   i915_vma_set_ggtt_write(vma);
 
/* NB Access through the GTT requires the device to be awake. */
return page_mask_bits(ptr);
@@ -615,8 +617,19 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
 
 void i915_vma_flush_writes(struct i915_vma *vma)
 {
+   /*
+* i915_vma_iomap() could have mapped the underlying memory in one
+* of the three ways, depending on which we have to choose the most
+* appropriate flushing mechanism.
+*
+* If the mapping method was via the aperture the appropriate flag will
+* be set via i915_vma_set_ggtt_write(), and if not then we know it is
+* enough to simply flush the CPU side write-combine buffer.
+*/
if (i915_vma_unset_ggtt_write(vma))
intel_gt_flush_ggtt_writes(vma->vm->gt);
+   else
+   wmb();
 }
 
 void i915_vma_unpin_iomap(struct i915_vma *vma)
-- 
2.39.2

Re: [Intel-gfx] [PATCH] drm/i915: Use the i915_vma_flush_writes helper

Hi Tvrtko,

> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -68,10 +68,8 @@ flush_write_domain(struct drm_i915_gem_object *obj, 
> unsigned int flush_domains)
>   switch (obj->write_domain) {
>   case I915_GEM_DOMAIN_GTT:
>   spin_lock(&obj->vma.lock);
> - for_each_ggtt_vma(vma, obj) {
> - if (i915_vma_unset_ggtt_write(vma))
> - intel_gt_flush_ggtt_writes(vma->vm->gt);
> - }
> + for_each_ggtt_vma(vma, obj)
> + i915_vma_flush_writes(vma);

yes, that's some duplicated code removed here! Thanks! I believe
I'm in time to add my:

Reviewed-by: Andi Shyti  

Andi

>   spin_unlock(&obj->vma.lock);
>  
>   i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> -- 
> 2.39.2

Re: [Intel-gfx] [PATCH dii-client 1/2] drm/i915: Make i915_coherent_map_type GT-centric

Hi Jonathan,

On Fri, Jul 21, 2023 at 07:05:58AM -0700, Jonathan Cavitt wrote:
> Refactor i915_coherent_map_type to be GT-centric rather than
> device-centric.  Each GT may require different coherency
> handling due to hardware workarounds.

[...]

> -enum i915_map_type i915_coherent_map_type(struct drm_i915_private *i915,
> +enum i915_map_type i915_coherent_map_type(struct intel_gt *gt,
> struct drm_i915_gem_object *obj,
> bool always_coherent)
>  {
>   /*
>* Wa_22016122933: always return I915_MAP_WC for MTL
>*/
> - if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
> + if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(gt->i915))
>   return I915_MAP_WC;
> - if (HAS_LLC(i915) || always_coherent)
> + if (HAS_LLC(gt->i915) || always_coherent)
>   return I915_MAP_WB;
>   else
>   return I915_MAP_WC;

this doesn't fully look right to me as gt-centric stuff need to
be in the gt/ directory.

As for this patch, here we don't need any reference to the gt.
You could eventually add some wrapper inside gt/ that perform the
per 'gt' checks and at the end call this function here.

Andi

intel-gfx@lists.freedesktop.org

Hi Uwe,

On Fri, Jul 21, 2023 at 11:21:33PM +0200, Uwe Kleine-König wrote:
> to_i915 is defined as
> 
>   container_of(dev, struct drm_i915_private, drm);
> 
> So for a struct drm_device *dev, to_i915(dev)->drm is just dev. Simplify
> accordingly.
> 
> Signed-off-by: Uwe Kleine-König 

that's correct! Thanks for the cleanup.

Reviewed-by: Andi Shyti  

Andi

intel-gfx@lists.freedesktop.org

Hi Uwe,

> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_121164v1_full, please notify your bug team to 
> > allow them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.
> 
> I don't think my patch results in regressions. But I fail to understand
> the indications reported by patchwork, so I might miss something.

I think the failure is unrelated, you can ignore it.

For future patches in i915 (or drm in general), you can retrigger
the tests from patchwork yourself when the results don't look
convincing.

Andi

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915: Move abs_diff() to math.h

Hi Andy,

On Mon, Jul 24, 2023 at 11:25:11AM +0300, Andy Shevchenko wrote:
> abs_diff() belongs to math.h. Move it there.
> This will allow others to use it.
> 
> Signed-off-by: Andy Shevchenko 
> Reviewed-by: Jiri Slaby  # tty/serial

Reviewed-by: Andi Shyti 

Thanks,
Andi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the i915_vma_flush_writes helper (rev3)

== Series Details ==

Series: drm/i915: Use the i915_vma_flush_writes helper (rev3)
URL   : https://patchwork.freedesktop.org/series/121122/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13419 -> Patchwork_121122v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-kbl-soraka 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_tiled_pread_basic:
- bat-adlp-11:NOTRUN -> [SKIP][2] ([i915#3282])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-adlp-11/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rpm@module-reload:
- fi-rkl-11600:   [PASS][3] -> [FAIL][4] ([i915#7940])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-rkl-11600/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/fi-rkl-11600/igt@i915_pm_...@module-reload.html
- fi-tgl-1115g4:  [PASS][5] -> [FAIL][6] ([i915#7940])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#4983] / [i915#7461] / 
[i915#8347] / [i915#8384])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][9] ([i915#6367])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@kms_busy@basic@flip:
- bat-adlp-11:NOTRUN -> [ABORT][10] ([i915#4423])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-adlp-11/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][11] ([i915#7828])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][12] ([i915#1845])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@i915_module_load@load:
- bat-adlp-11:[ABORT][13] ([i915#4423]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-adlp-11/igt@i915_module_l...@load.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-adlp-11/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-6: [DMESG-FAIL][15] ([i915#7059]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-6: [DMESG-FAIL][17] ([i915#7699]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-mtlp-6/igt@i915_selftest@l...@migrate.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-mtlp-6/igt@i915_selftest@l...@migrate.html
- bat-rpls-2: [DMESG-FAIL][19] ([i915#7699] / [i915#7913]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-rpls-2/igt@i915_selftest@l...@migrate.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-rpls-2/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][21] ([i915#4983] / [i915#7461] / [i915#7913] 
/ [i915#8347]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-rpls-2/igt@i915_selftest@l...@reset.html

  
 Warnings 

  * igt@kms_psr@cursor_plane_move:
- bat-rplp-1: [SKIP][23] ([i915#1072]) -> [ABORT][24] ([i915#8434])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121122v3/bat-

Re: [Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

Hi Tvrtko,

> > > Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is 
> > > available")
> > > added a code path which does not map via GGTT, but was still setting the
> > > ggtt write bit, and so triggering the GGTT flushing.
> > > 
> > > Fix it by not setting that bit unless the GGTT mapping path was used, and
> > > replace the flush with wmb() in i915_vma_flush_writes().
> > > 
> > > This also works for the i915_gem_object_pin_map path added in
> > > d976521a995a ("drm/i915: extend i915_vma_pin_iomap()").
> > > 
> > > It is hard to say if the fix has any observable effect, given that the
> > > write-combine buffer gets flushed from intel_gt_flush_ggtt_writes too, but
> > > apart from code clarity, skipping the needless GGTT flushing could be
> > > beneficial on platforms with non-coherent GGTT. (See the code flow in
> > > intel_gt_flush_ggtt_writes().)
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Fixes: 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is 
> > > available")
> > > References: d976521a995a ("drm/i915: extend i915_vma_pin_iomap()")
> > > Cc: Radhakrishna Sripada 
> > > Cc:  # v5.14+
> > > ---
> > >   drivers/gpu/drm/i915/i915_vma.c | 6 +-
> > >   1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_vma.c 
> > > b/drivers/gpu/drm/i915/i915_vma.c
> > > index ffb425ba591c..f2b626cd2755 100644
> > > --- a/drivers/gpu/drm/i915/i915_vma.c
> > > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > > @@ -602,7 +602,9 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
> > >   if (err)
> > >   goto err_unpin;
> > > - i915_vma_set_ggtt_write(vma);
> > > + if (!i915_gem_object_is_lmem(vma->obj) &&
> > > + i915_vma_is_map_and_fenceable(vma))
> > > + i915_vma_set_ggtt_write(vma);
> > >   /* NB Access through the GTT requires the device to be awake. */
> > >   return page_mask_bits(ptr);
> > > @@ -617,6 +619,8 @@ void i915_vma_flush_writes(struct i915_vma *vma)
> > >   {
> > >   if (i915_vma_unset_ggtt_write(vma))
> > >   intel_gt_flush_ggtt_writes(vma->vm->gt);
> > > + else
> > > + wmb(); /* Just flush the write-combine buffer. */
> > 
> > is flush the right word? Can you expand more the explanation in
> > this comment and why this point of synchronization is needed
> > here? (I am even wondering if it is really needed).
> 
> If you are hinting flush isn't the right word then I am not remembering what
> else do we use for it?
> 
> It is needed because i915_flush_writes()'s point AFAIU is to make sure CPU
> writes after i915_vma_pin_iomap() have landed in RAM. All three methods the
> latter can map the buffer are WC, therefore "flushing" of the WC buffer is
> needed for former to do something (what it promises).
> 
> Currently the wmb() is in intel_gt_flush_ggtt_writes(). But only one of the
> three mapping paths is via GGTT. So my logic is that calling it for paths
> not interacting with GGTT is confusing and not needed.
> 
> > Anyway, it looks good:
> > 
> > Reviewed-by: Andi Shyti 
> 
> Thanks. If you don't see a hole in my logic I can improve the comment. I
> considered it initially but then thought it is obvious enough from looking
> at the i915_vma_pin_iomap. I can comment it more.

The logic looks linear... my questions were more aiming at
confirming my understanding and improving the comment around
wmb().

Thanks,
Andi

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tv: avoid possible division by zero (rev3)

== Series Details ==

Series: drm/i915/tv: avoid possible division by zero (rev3)
URL   : https://patchwork.freedesktop.org/series/120851/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13418_full -> Patchwork_120851v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 9)
--

  Missing(1): pig-kbl-iris 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@blit-reloc-purge-cache:
- shard-dg2:  NOTRUN -> [SKIP][1] ([i915#8411])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-dg2-7/igt@api_intel...@blit-reloc-purge-cache.html

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-glk:  [PASS][2] -> [ABORT][3] ([i915#7461] / [i915#8211])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-glk5/igt@gem_barrier_race@remote-requ...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-glk6/igt@gem_barrier_race@remote-requ...@rcs0.html
- shard-dg2:  [PASS][4] -> [ABORT][5] ([i915#6333])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-dg2-11/igt@gem_barrier_race@remote-requ...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-dg2-11/igt@gem_barrier_race@remote-requ...@rcs0.html
- shard-tglu: [PASS][6] -> [ABORT][7] ([i915#8211] / [i915#8234])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-tglu-9/igt@gem_barrier_race@remote-requ...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-tglu-3/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_ccs@block-multicopy-inplace:
- shard-tglu: NOTRUN -> [SKIP][8] ([i915#3555] / [i915#5325])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-tglu-3/igt@gem_...@block-multicopy-inplace.html

  * igt@gem_close_race@multigpu-basic-process:
- shard-dg2:  NOTRUN -> [SKIP][9] ([i915#7697])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-dg2-7/igt@gem_close_r...@multigpu-basic-process.html

  * igt@gem_ctx_persistence@engines-queued:
- shard-snb:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-snb5/igt@gem_ctx_persiste...@engines-queued.html

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

  * igt@gem_eio@in-flight-10ms:
- shard-mtlp: [PASS][12] -> [ABORT][13] ([i915#8503])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-mtlp-4/igt@gem_...@in-flight-10ms.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-mtlp-6/igt@gem_...@in-flight-10ms.html

  * igt@gem_exec_balancer@sliced:
- shard-dg2:  NOTRUN -> [SKIP][14] ([i915#4812]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-dg2-7/igt@gem_exec_balan...@sliced.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2846])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-glk4/igt@gem_exec_f...@basic-deadline.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-glk7/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo:
- shard-mtlp: NOTRUN -> [SKIP][17] ([i915#4473])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-mtlp-2/igt@gem_exec_f...@basic-none-solo.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl:  [PASS][20] -> [FAIL][21] ([i915#2842]) +1 similar 
issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-rkl-4/igt@gem_exec_fair@basic-p...@vecs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fair@basic-sync:
- shard-dg2:  NOTRUN -> [SKIP][22] ([i915#3539])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120851v3/shard-dg2-5/igt@gem_exec_f...@basic-sync.html

  * igt@gem_exec_reloc@basic-range-active:
- shard-dg2:  NOTRUN -> [SKIP][23] ([i915#3281]) +1 similar issue
   [23]: 
https://intel-gfx-ci.01.

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP




On 25/07/2023 01:13, Matt Roper wrote:

Several workarounds are guarded by IS_MTL_GRAPHICS_STEP.  However none
of these workarounds are actually tied to MTL as a platform; they only
relate to the Xe_LPG graphics IP, regardless of what platform it appears
in.  At the moment MTL is the only platform that uses Xe_LPG with IP
versions 12.70 and 12.71, but we can't count on this being true in the
future.  Switch these to use a new IS_GT_IP_STEP() macro instead that is
purely based on IP version.  IS_GT_IP_STEP() is also GT-based rather
than device-based, which will help prevent mistakes where we
accidentally try to apply Xe_LPG graphics workarounds to the Xe_LPM+
media GT and vice-versa.

v2:
  - Switch to a more generic and shorter IS_GT_IP_STEP macro that can be
used for both graphics and media IP (and any other kind of GTs that
show up in the future).

Cc: Gustavo Sousa 
Cc: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
---
  .../drm/i915/display/skl_universal_plane.c|  4 +-
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  9 ++--
  drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  4 +-
  drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
  drivers/gpu/drm/i915/gt/intel_reset.c |  2 +-
  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 52 ++-
  drivers/gpu/drm/i915/gt/uc/intel_guc.c|  2 +-
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +-
  drivers/gpu/drm/i915/i915_drv.h   | 30 +--
  9 files changed, 67 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 6b01a0b68b97..5fd8a42b3ec1 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2169,8 +2169,8 @@ static bool skl_plane_has_rc_ccs(struct drm_i915_private 
*i915,
 enum pipe pipe, enum plane_id plane_id)
  {
/* Wa_14017240301 */
-   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   if (IS_GT_IP_STEP(GFX, to_gt(i915), IP_VER(12, 70), A0, B0) ||
+   IS_GT_IP_STEP(GFX, to_gt(i915), IP_VER(12, 71), A0, B0))
return false;
  
  	/* Wa_22011186057 */

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 3ba20ea030e8..9d04591f3b4a 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -180,8 +180,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, 
const i915_reg_t inv
  static int mtl_dummy_pipe_control(struct i915_request *rq)
  {
/* Wa_14016712196 */
-   if (IS_MTL_GRAPHICS_STEP(rq->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->i915, P, STEP_A0, STEP_B0)) {
+   if (IS_GT_IP_STEP(GFX, rq->engine->gt, IP_VER(12, 70), A0, B0) ||
+   IS_GT_IP_STEP(GFX, rq->engine->gt, IP_VER(12, 71), A0, B0)) {
u32 *cs;
  
  		/* dummy PIPE_CONTROL + depth flush */

@@ -755,6 +755,7 @@ u32 *gen12_emit_fini_breadcrumb_xcs(struct i915_request 
*rq, u32 *cs)
  u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
  {
struct drm_i915_private *i915 = rq->i915;
+   struct intel_gt *gt = rq->engine->gt;
u32 flags = (PIPE_CONTROL_CS_STALL |
 PIPE_CONTROL_TLB_INVALIDATE |
 PIPE_CONTROL_TILE_CACHE_FLUSH |
@@ -765,8 +766,8 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs)
 PIPE_CONTROL_FLUSH_ENABLE);
  
  	/* Wa_14016712196 */

-   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   if (IS_GT_IP_STEP(GFX, gt, IP_VER(12, 70), A0, B0) ||
+   IS_GT_IP_STEP(GFX, gt, IP_VER(12, 71), A0, B0))
/* dummy PIPE_CONTROL + depth flush */
cs = gen12_emit_pipe_control(cs, 0,
 PIPE_CONTROL_DEPTH_CACHE_FLUSH, 0);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 0b414eae1683..c66373176f6c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -166,8 +166,8 @@ void intel_gt_mcr_init(struct intel_gt *gt)
gt->steering_table[OADDRM] = xelpmp_oaddrm_steering_table;
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
/* Wa_14016747170 */
-   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   if (IS_GT_IP_STEP(GFX, gt, IP_VER(12, 70), A0, B0) ||
+   IS_GT_IP_STEP(GFX, gt, IP_VER(12, 71), A0, B0))
fuse = REG_FIELD_GET(MTL_GT_L3_EXC_MASK,
 intel_uncore_read(gt->uncore,

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/xelpg: Call Xe_LPG workaround functions based on IP version




On 25/07/2023 01:13, Matt Roper wrote:

Although some of our Xe_LPG workarounds were already being applied based
on IP version correctly, others were matching on MTL as a base platform,
which is incorrect.  Although MTL is the only platform right now that
uses Xe_LPG IP, this may not always be the case.  If a future platform
re-uses this graphics IP, the same workarounds should be applied, even
if it isn't a "MTL" platform.

We were also incorrectly applying Xe_LPG workarounds/tuning to the
Xe_LPM+ media IP in one or two places; we should make sure that we don't
try to apply graphics workarounds to the media GT and vice versa where
they don't belong.  A new helper macro IS_GT_IP_RANGE() is added to help
ensure this is handled properly -- it checks that the GT matches the IP
type being tested as well as the IP version falling in the proper range.

Note that many of the stepping-based workarounds are still incorrectly
checking for a MTL base platform; that will be remedied in a later
patch.

v2:
  - Rework macro into a slightly more generic IS_GT_IP_RANGE() that can
be used for either GFX or MEDIA checks.

Cc: Gustavo Sousa 
Cc: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_workarounds.c | 38 +++--
  drivers/gpu/drm/i915/i915_drv.h | 23 +
  2 files changed, 43 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index d8a1eaa44e69..c4663541c5dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -805,8 +805,8 @@ static void dg2_ctx_workarounds_init(struct intel_engine_cs 
*engine,
wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE);
  }
  
-static void mtl_ctx_gt_tuning_init(struct intel_engine_cs *engine,

-  struct i915_wa_list *wal)
+static void xelpg_ctx_gt_tuning_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
  {
struct drm_i915_private *i915 = engine->i915;
  
@@ -817,12 +817,12 @@ static void mtl_ctx_gt_tuning_init(struct intel_engine_cs *engine,

wa_add(wal, DRAW_WATERMARK, VERT_WM_VAL, 0x3FF, 0, false);
  }
  
-static void mtl_ctx_workarounds_init(struct intel_engine_cs *engine,

-struct i915_wa_list *wal)
+static void xelpg_ctx_workarounds_init(struct intel_engine_cs *engine,
+  struct i915_wa_list *wal)
  {
struct drm_i915_private *i915 = engine->i915;
  
-	mtl_ctx_gt_tuning_init(engine, wal);

+   xelpg_ctx_gt_tuning_init(engine, wal);
  
  	if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||

IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
@@ -931,8 +931,8 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
if (engine->class != RENDER_CLASS)
goto done;
  
-	if (IS_METEORLAKE(i915))

-   mtl_ctx_workarounds_init(engine, wal);
+   if (IS_GT_IP_RANGE(GFX, engine->gt, IP_VER(12, 70), IP_VER(12, 71)))
+   xelpg_ctx_workarounds_init(engine, wal);
else if (IS_PONTEVECCHIO(i915))
; /* noop; none at this time */
else if (IS_DG2(i915))
@@ -1790,10 +1790,8 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt, struct 
i915_wa_list *wal)
   */
  static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list *wal)
  {
-   if (IS_METEORLAKE(gt->i915)) {
-   if (gt->type != GT_MEDIA)
-   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
BLEND_FILL_CACHING_OPT_DIS);
-
+   if (IS_GT_IP_RANGE(GFX, gt, IP_VER(12, 70), IP_VER(12, 71))) {
+   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
BLEND_FILL_CACHING_OPT_DIS);
wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
}
  
@@ -1825,7 +1823,7 @@ gt_init_workarounds(struct intel_gt *gt, struct i915_wa_list *wal)

return;
}
  
-	if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))

+   if (IS_GT_IP_RANGE(GFX, gt, IP_VER(12, 70), IP_VER(12, 71)))
xelpg_gt_workarounds_init(gt, wal);
else if (IS_PONTEVECCHIO(i915))
pvc_gt_workarounds_init(gt, wal);
@@ -2293,7 +2291,7 @@ static void pvc_whitelist_build(struct intel_engine_cs 
*engine)
blacklist_trtt(engine);
  }
  
-static void mtl_whitelist_build(struct intel_engine_cs *engine)

+static void xelpg_whitelist_build(struct intel_engine_cs *engine)
  {
struct i915_wa_list *w = &engine->whitelist;
  
@@ -2315,8 +2313,10 @@ void intel_engine_init_whitelist(struct intel_engine_cs *engine)
  
  	wa_init_start(w, engine->gt, "whitelist", engine->name);
  
-	if (IS_METEORLAKE(i915))

-   mtl_whitelist_build(engine);
+   if (engine->gt->type == GT_MEDIA)
+   ; /* none yet */
+   else if (IS_GT_IP_RANGE(GFX, engine->gt, IP_VER(12, 70)

Re: [Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap




On 24/07/2023 21:16, Andi Shyti wrote:

Hi Tvrtko,

On Mon, Jul 24, 2023 at 01:56:33PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")
added a code path which does not map via GGTT, but was still setting the
ggtt write bit, and so triggering the GGTT flushing.

Fix it by not setting that bit unless the GGTT mapping path was used, and
replace the flush with wmb() in i915_vma_flush_writes().

This also works for the i915_gem_object_pin_map path added in
d976521a995a ("drm/i915: extend i915_vma_pin_iomap()").

It is hard to say if the fix has any observable effect, given that the
write-combine buffer gets flushed from intel_gt_flush_ggtt_writes too, but
apart from code clarity, skipping the needless GGTT flushing could be
beneficial on platforms with non-coherent GGTT. (See the code flow in
intel_gt_flush_ggtt_writes().)

Signed-off-by: Tvrtko Ursulin 
Fixes: 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available")
References: d976521a995a ("drm/i915: extend i915_vma_pin_iomap()")
Cc: Radhakrishna Sripada 
Cc:  # v5.14+
---
  drivers/gpu/drm/i915/i915_vma.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index ffb425ba591c..f2b626cd2755 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -602,7 +602,9 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
if (err)
goto err_unpin;
  
-	i915_vma_set_ggtt_write(vma);

+   if (!i915_gem_object_is_lmem(vma->obj) &&
+   i915_vma_is_map_and_fenceable(vma))
+   i915_vma_set_ggtt_write(vma);
  
  	/* NB Access through the GTT requires the device to be awake. */

return page_mask_bits(ptr);
@@ -617,6 +619,8 @@ void i915_vma_flush_writes(struct i915_vma *vma)
  {
if (i915_vma_unset_ggtt_write(vma))
intel_gt_flush_ggtt_writes(vma->vm->gt);
+   else
+   wmb(); /* Just flush the write-combine buffer. */


is flush the right word? Can you expand more the explanation in
this comment and why this point of synchronization is needed
here? (I am even wondering if it is really needed).


If you are hinting flush isn't the right word then I am not remembering 
what else do we use for it?


It is needed because i915_flush_writes()'s point AFAIU is to make sure 
CPU writes after i915_vma_pin_iomap() have landed in RAM. All three 
methods the latter can map the buffer are WC, therefore "flushing" of 
the WC buffer is needed for former to do something (what it promises).


Currently the wmb() is in intel_gt_flush_ggtt_writes(). But only one of 
the three mapping paths is via GGTT. So my logic is that calling it for 
paths not interacting with GGTT is confusing and not needed.



Anyway, it looks good:

Reviewed-by: Andi Shyti 


Thanks. If you don't see a hole in my logic I can improve the comment. I 
considered it initially but then thought it is obvious enough from 
looking at the i915_vma_pin_iomap. I can comment it more.


Regards,

Tvrtko



Andi


  }
  
  void i915_vma_unpin_iomap(struct i915_vma *vma)

--
2.39.2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace i915->gt0 with to_gt(i915)

== Series Details ==

Series: drm/i915: Replace i915->gt0 with to_gt(i915)
URL   : https://patchwork.freedesktop.org/series/121302/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13419 -> Patchwork_121302v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-apl-guc 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- bat-adlp-11:NOTRUN -> [ABORT][1] ([i915#8011])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-adlp-11/igt@core_a...@basic-auth.html

  * igt@i915_pm_rpm@module-reload:
- fi-tgl-1115g4:  [PASS][2] -> [FAIL][3] ([i915#7940])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [PASS][4] -> [DMESG-FAIL][5] ([i915#5334] / 
[i915#7872])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [PASS][6] -> [ABORT][7] ([i915#4983])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][8] -> [DMESG-WARN][9] ([i915#7699])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][10] ([i915#7828])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-jsl-3:  NOTRUN -> [SKIP][11] ([i915#7828])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][12] ([i915#1845] / [i915#5354]) +3 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][13] ([i915#1845])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-jsl-3:  [ABORT][14] ([i915#5122]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@execlists:
- fi-kbl-soraka:  [INCOMPLETE][16] ([i915#7156] / [i915#7913]) -> 
[PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-8: [DMESG-FAIL][18] ([i915#7059]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-6: [DMESG-FAIL][20] ([i915#7699]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-mtlp-6/igt@i915_selftest@l...@migrate.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-mtlp-6/igt@i915_selftest@l...@migrate.html
- bat-rpls-2: [DMESG-FAIL][22] ([i915#7699] / [i915#7913]) -> 
[PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-rpls-2/igt@i915_selftest@l...@migrate.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121302v1/bat-rpls-2/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][24] ([i915#4

Re: [Intel-gfx] [PATCH 06/19] drm/i915/display: Account for DSC not split case while computing cdclk

2023-07-25 Thread Nautiyal, Ankit K




On 7/25/2023 3:40 PM, Lisovskiy, Stanislav wrote:

On Tue, Jul 25, 2023 at 11:22:52AM +0530, Nautiyal, Ankit K wrote:

On 7/20/2023 2:46 PM, Lisovskiy, Stanislav wrote:

On Thu, Jul 13, 2023 at 04:03:33PM +0530, Ankit Nautiyal wrote:

Currently we assume 2 Pixels Per Clock (PPC) while computing
plane cdclk and min_cdlck. In cases where DSC single engine
is used the throughput is 1 PPC.

So account for the above case, while computing cdclk.

v2: Use helper to get the adjusted pixel rate.

Signed-off-by: Ankit Nautiyal 
---
   drivers/gpu/drm/i915/display/intel_cdclk.c |  2 +-
   drivers/gpu/drm/i915/display/intel_vdsc.c  | 12 
   drivers/gpu/drm/i915/display/intel_vdsc.h  |  2 ++
   drivers/gpu/drm/i915/display/skl_universal_plane.c |  4 ++--
   4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index dcc1f6941b60..701909966545 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2508,7 +2508,7 @@ static int intel_pixel_rate_to_cdclk(const struct 
intel_crtc_state *crtc_state)
int pixel_rate = crtc_state->pixel_rate;
if (DISPLAY_VER(dev_priv) >= 10)
-   return DIV_ROUND_UP(pixel_rate, 2);
+   return intel_dsc_get_adjusted_pixel_rate(crtc_state, 
pixel_rate);
else if (DISPLAY_VER(dev_priv) == 9 ||
 IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
return pixel_rate;
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 9d76c2756784..bbfdbf06da68 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -1038,3 +1038,15 @@ void intel_dsc_get_config(struct intel_crtc_state 
*crtc_state)
   out:
intel_display_power_put(dev_priv, power_domain, wakeref);
   }
+
+int intel_dsc_get_adjusted_pixel_rate(const struct intel_crtc_state 
*crtc_state, int pixel_rate)
+{
+   /*
+* If single VDSC engine is used, it uses one pixel per clock
+* otherwise we use two pixels per clock.
+*/
+   if (crtc_state->dsc.compression_enable && !crtc_state->dsc.dsc_split)
+   return pixel_rate;
+
+   return DIV_ROUND_UP(pixel_rate, 2);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.h 
b/drivers/gpu/drm/i915/display/intel_vdsc.h
index 2cc41ff08909..3bb4b1980b6b 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.h
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.h
@@ -28,4 +28,6 @@ void intel_dsc_dsi_pps_write(struct intel_encoder *encoder,
   void intel_dsc_dp_pps_write(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
+int intel_dsc_get_adjusted_pixel_rate(const struct intel_crtc_state 
*crtc_state, int pixel_rate);
+
   #endif /* __INTEL_VDSC_H__ */
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 6b01a0b68b97..9eeb25ec4be9 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -17,6 +17,7 @@
   #include "intel_fb.h"
   #include "intel_fbc.h"
   #include "intel_psr.h"
+#include "intel_vdsc.h"
   #include "skl_scaler.h"
   #include "skl_universal_plane.h"
   #include "skl_watermark.h"
@@ -263,8 +264,7 @@ static int icl_plane_min_cdclk(const struct 
intel_crtc_state *crtc_state,
   {
unsigned int pixel_rate = intel_plane_pixel_rate(crtc_state, 
plane_state);
-   /* two pixels per clock */
-   return DIV_ROUND_UP(pixel_rate, 2);
+   return intel_dsc_get_adjusted_pixel_rate(crtc_state, pixel_rate);

Hi Ankit,

I think the thing what you are taking of is already handled here in 
intel_cdclk.c:

/*
   * When we decide to use only one VDSC engine, since
   * each VDSC operates with 1 ppc throughput, pixel clock
   * cannot be higher than the VDSC clock (cdclk)
   * If there 2 VDSC engines, then pixel clock can't be higher than
   * VDSC clock(cdclk) * 2 and so on.
   */
  if (crtc_state->dsc.compression_enable) {
  int num_vdsc_instances = 
intel_dsc_get_num_vdsc_instances(crtc_state);

  min_cdclk = max_t(int, min_cdclk,
DIV_ROUND_UP(crtc_state->pixel_rate,
 num_vdsc_instances));
  }

As far as I understand this condition is coming from the pixel clock
limitation as an input to the splitter (Bspec: 49259):

Pipe BW check:

Pixel clock < PPC * CDCLK frequency * Number of pipes joined

PPC = 1 or 2 depending on number of DSC engines used within the pipe.

So it implies CDCLK frequency > Pixel clock / (PPC * Number of pipes joined)

num_vdsc_instances is actually giving us (PPC * number of pipes joined).


I completely

Re: [Intel-gfx] [PATCH 05/19] drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp

2023-07-25 Thread Nautiyal, Ankit K




On 7/25/2023 3:43 PM, Lisovskiy, Stanislav wrote:

On Mon, Jul 24, 2023 at 05:49:11PM +0530, Nautiyal, Ankit K wrote:

Hi Stan,

Thanks for the reviews ans suggestions. Please my response inline:


On 7/20/2023 2:59 PM, Lisovskiy, Stanislav wrote:

On Thu, Jul 13, 2023 at 04:03:32PM +0530, Ankit Nautiyal wrote:

In Bigjoiner check for DSC, bigjoiner interface bits for DP for
DISPLAY > 13 is 36 (Bspec: 49259).

v2: Corrected Display ver to 13.

v3: Follow convention for conditional statement. (Ville)

v4: Fix check for display ver. (Ville)

Signed-off-by: Ankit Nautiyal 
Reviewed-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 19768ac658ba..c1fd448d80e1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -802,8 +802,9 @@ u16 intel_dp_dsc_get_max_compressed_bpp(struct 
drm_i915_private *i915,
bits_per_pixel = min(bits_per_pixel, max_bpp_small_joiner_ram);
if (bigjoiner) {
+   int bigjoiner_interface_bits = DISPLAY_VER(i915) >= 14 ? 36 : 
24;
u32 max_bpp_bigjoiner =
-   i915->display.cdclk.max_cdclk_freq * 48 /
+   i915->display.cdclk.max_cdclk_freq * 2 * 
bigjoiner_interface_bits /

Probably "num_vdsc_instances = intel_dsc_get_num_vdsc_instances(crtc_state);" 
again,
instead of "2"?

Currently intel_dsc_get_num_vdsc_instances will give total number of
vdsc_engines including joined pipes.

So with bigjoiner the function will return 4.

This was good to calculate Pipe BW check: (Pixel clock < PPC * CDCLK
frequency * Number of pipes joined

as we get PPC * number of pipes joined from
intel_dsc_get_num_vdsc_instances)

Or to calculate DSC_PIC_WIDTH PPS parameter.

But here we perhaps need intel_dsc_get_vdsc_engines_per_pipe that will just
return 2 if dsc_split 1 otherwise.

Thanks & Regards,

Ankit

Yes, I agree, unfortunately not applicable here.
May be yeah we need some function like that and then refactor
also the intel_dsc_get_num_vdsc_instances to use that one..

Stan


Alright, let me make the change in a separate patch and add to this series.

Thanks & Regards,

Ankit





With that clarified,

Reviewed-by: Stanislav Lisovskiy 


intel_dp_mode_to_fec_clock(mode_clock);
bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
--
2.40.1

Re: [Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap




On 25/07/2023 00:38, Sripada, Radhakrishna wrote:

Hi Tvrtko,

The changes makes sense and based on the description looks good.
I am bit skeptical about the exec buffer failure reported by ci hence,
withholding the r-b for now. If you believe the CI failure is unrelated
please feel free to add my r-b.


This failure:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121236v1/shard-snb7/igt@gem_pp...@blt-vs-render-ctxn.html

Test or machine is not entirely stable looking at it's history, but with 
a couple different failure signatures:


https://intel-gfx-ci.01.org/tree/drm-tip/igt@gem_pp...@blt-vs-render-ctxn.html

But agreed that we need to be careful. I requested a re-run for a start.


On a side note on platforms with non-coherent ggtt do we really
need to use the barriers twice under intel_gt_flush_ggtt_writes?


You mean:

intel_gt_flush_ggtt_writes()
{
...
wmb();
...
intel_gt_chipset_flush();
wmb();

?

I'd guess it is not needed twice on the intel_gt_flush_ggtt_writes() 
path, but happens to be like that for direct callers of 
intel_gt_chipset_flush().


Maybe there is scope to tidy this all, for instance the first direct 
caller I opened does this:


rpcs_query_batch()
{
...
__i915_gem_object_flush_map(rpcs, 0, 64);
i915_gem_object_unpin_map(rpcs);

intel_gt_chipset_flush(vma->vm->gt);

Where I think __i915_gem_object_flush_map() could actually do the right 
thing and issue a flush appropriate for the mapping that was used. But 
it is work and double flush does not really harm. I don't think it does 
at least.


Regards,

Tvrtko



--Radhakrishna(RK) Sripada


-Original Message-
From: Tvrtko Ursulin 
Sent: Monday, July 24, 2023 5:57 AM
To: Intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Ursulin, Tvrtko ; Sripada, Radhakrishna
; sta...@vger.kernel.org
Subject: [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of
i915_vma_pin_iomap

From: Tvrtko Ursulin 

Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is
available")
added a code path which does not map via GGTT, but was still setting the
ggtt write bit, and so triggering the GGTT flushing.

Fix it by not setting that bit unless the GGTT mapping path was used, and
replace the flush with wmb() in i915_vma_flush_writes().

This also works for the i915_gem_object_pin_map path added in
d976521a995a ("drm/i915: extend i915_vma_pin_iomap()").

It is hard to say if the fix has any observable effect, given that the
write-combine buffer gets flushed from intel_gt_flush_ggtt_writes too, but
apart from code clarity, skipping the needless GGTT flushing could be
beneficial on platforms with non-coherent GGTT. (See the code flow in
intel_gt_flush_ggtt_writes().)

Signed-off-by: Tvrtko Ursulin 
Fixes: 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is
available")
References: d976521a995a ("drm/i915: extend i915_vma_pin_iomap()")
Cc: Radhakrishna Sripada 
Cc:  # v5.14+
---
  drivers/gpu/drm/i915/i915_vma.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index ffb425ba591c..f2b626cd2755 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -602,7 +602,9 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma
*vma)
if (err)
goto err_unpin;

-   i915_vma_set_ggtt_write(vma);
+   if (!i915_gem_object_is_lmem(vma->obj) &&
+   i915_vma_is_map_and_fenceable(vma))
+   i915_vma_set_ggtt_write(vma);

/* NB Access through the GTT requires the device to be awake. */
return page_mask_bits(ptr);
@@ -617,6 +619,8 @@ void i915_vma_flush_writes(struct i915_vma *vma)
  {
if (i915_vma_unset_ggtt_write(vma))
intel_gt_flush_ggtt_writes(vma->vm->gt);
+   else
+   wmb(); /* Just flush the write-combine buffer. */
  }

  void i915_vma_unpin_iomap(struct i915_vma *vma)
--
2.39.2

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




On 25/07/2023 07:42, Borah, Chaitanya Kumar wrote:

Hello Alistair,

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

repository.
  
On next-20230720 [2], we are seeing the following error


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

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

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

Details log can be found in [3].

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

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

 mmu_notifiers: rename invalidate_range notifier

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

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

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

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


We also verified by reverting the patch in the tree.

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


Without checking out the whole tree but only looking at this patch in 
isolation, it could be that it is not considering NULL subscription can be 
passed to mmu_notifier_register. For instance from 
mmu_interval_notifier_insert, which i915 is calling. So the check patch added 
to __mmu_notifier_register causes a null pointer dereference:

@@ -616,6 +617,15 @@ int __mmu_notifier_register(struct mmu_notifier 
*subscription,
mmap_assert_write_locked(mm);
BUG_ON(atomic_read(&mm->mm_users) <= 0);
 
+   /*

+* Subsystems should only register for invalidate_secondary_tlbs() or
+* invalidate_range_start()/end() callbacks, not both.
+*/
+   if (WARN_ON_ONCE(subscription->ops->arch_invalidate_secondary_tlbs &&

---> subscription is NULL here <---

+   (subscription->ops->invalidate_range_start ||
+   subscription->ops->invalidate_range_end)))
+

[Intel-gfx] ✗ Fi.CI.IGT: failure for Update AUX invalidation sequence (rev10)

== Series Details ==

Series: Update AUX invalidation sequence (rev10)
URL   : https://patchwork.freedesktop.org/series/119798/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13418_full -> Patchwork_119798v10_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 11)
--

  Additional (1): shard-rkl0 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_create@hog-create@smem0:
- shard-snb:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-snb4/igt@gem_create@hog-cre...@smem0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-snb7/igt@gem_create@hog-cre...@smem0.html

  * igt@kms_rotation_crc@primary-x-tiled-reflect-x-180:
- shard-rkl:  [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-rkl-2/igt@kms_rotation_...@primary-x-tiled-reflect-x-180.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-rkl-6/igt@kms_rotation_...@primary-x-tiled-reflect-x-180.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@blit-reloc-purge-cache:
- shard-dg2:  NOTRUN -> [SKIP][5] ([i915#8411])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-dg2-3/igt@api_intel...@blit-reloc-purge-cache.html

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-glk:  [PASS][6] -> [ABORT][7] ([i915#7461] / [i915#8211])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-glk5/igt@gem_barrier_race@remote-requ...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-glk3/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_ccs@block-multicopy-inplace:
- shard-tglu: NOTRUN -> [SKIP][8] ([i915#3555] / [i915#5325])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-tglu-9/igt@gem_...@block-multicopy-inplace.html

  * igt@gem_close_race@multigpu-basic-process:
- shard-dg2:  NOTRUN -> [SKIP][9] ([i915#7697])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-dg2-3/igt@gem_close_r...@multigpu-basic-process.html

  * igt@gem_ctx_persistence@engines-queued:
- shard-snb:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-snb5/igt@gem_ctx_persiste...@engines-queued.html

  * igt@gem_ctx_persistence@hang:
- shard-dg2:  NOTRUN -> [SKIP][11] ([i915#8555])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-dg2-2/igt@gem_ctx_persiste...@hang.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-mtlp: [PASS][12] -> [ABORT][13] ([i915#8503])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-mtlp-5/igt@gem_...@in-flight-contexts-immediate.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-mtlp-3/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_eio@kms:
- shard-dg1:  [PASS][14] -> [FAIL][15] ([i915#5784])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-dg1-16/igt@gem_...@kms.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-dg1-15/igt@gem_...@kms.html

  * igt@gem_exec_balancer@sliced:
- shard-dg2:  NOTRUN -> [SKIP][16] ([i915#4812]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-dg2-3/igt@gem_exec_balan...@sliced.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#2846])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-glk4/igt@gem_exec_f...@basic-deadline.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-glk1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglu: [PASS][19] -> [FAIL][20] ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-tglu-7/igt@gem_exec_fair@basic-f...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v10/shard-tglu-10/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo:
- shard-mtlp: NOTR

[Intel-gfx] [PATCH] drm/i915: Replace i915->gt0 with to_gt(i915)

Quite surprised to see that around i915 there are still i915->gt0
references. Replace them with the to_gt() helper.

Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c   | 2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c   | 2 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c  | 2 +-
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 3b094d36a0b04..5b0a5cf9a98a8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -892,7 +892,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
} else {
resource_size_t lmem_range;
 
-   lmem_range = intel_gt_mcr_read_any(&i915->gt0, 
XEHP_TILE0_ADDR_RANGE) & 0x;
+   lmem_range = intel_gt_mcr_read_any(to_gt(i915), 
XEHP_TILE0_ADDR_RANGE) & 0x;
lmem_size = lmem_range >> XEHP_TILE_LMEM_RANGE_SHIFT;
lmem_size *= SZ_1G;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 9f64d61dd5fcd..02886c1eb0f17 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -887,7 +887,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt, 
phys_addr_t phys_addr)
 int intel_gt_probe_all(struct drm_i915_private *i915)
 {
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
-   struct intel_gt *gt = &i915->gt0;
+   struct intel_gt *gt = to_gt(i915);
const struct intel_gt_definition *gtdef;
phys_addr_t phys_addr;
unsigned int mmio_bar;
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 2a3217e2890fc..f8512aee58a83 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -220,7 +220,7 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
resource_size_t lmem_range;
u64 tile_stolen, flat_ccs_base;
 
-   lmem_range = intel_gt_mcr_read_any(&i915->gt0, 
XEHP_TILE0_ADDR_RANGE) & 0x;
+   lmem_range = intel_gt_mcr_read_any(to_gt(i915), 
XEHP_TILE0_ADDR_RANGE) & 0x;
lmem_size = lmem_range >> XEHP_TILE_LMEM_RANGE_SHIFT;
lmem_size *= SZ_1G;
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index bb2e15329f346..38ec754d0ec8e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -162,8 +162,8 @@ static struct intel_gt *find_gt_for_required_teelink(struct 
drm_i915_private *i9
 * for HuC authentication. For now, its limited to DG2.
 */
if (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && 
IS_ENABLED(CONFIG_INTEL_MEI_GSC) &&
-   intel_huc_is_loaded_by_gsc(&i915->gt0.uc.huc) && 
intel_uc_uses_huc(&i915->gt0.uc))
-   return &i915->gt0;
+   intel_huc_is_loaded_by_gsc(&to_gt(i915)->uc.huc) && 
intel_uc_uses_huc(&to_gt(i915)->uc))
+   return to_gt(i915);
 
return NULL;
 }
@@ -188,8 +188,8 @@ static struct intel_gt 
*find_gt_for_required_protected_content(struct drm_i915_p
 * Else we rely on mei-pxp module but only on legacy platforms
 * prior to having separate media GTs and has a valid VDBOX.
 */
-   if (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && !i915->media_gt && 
VDBOX_MASK(&i915->gt0))
-   return &i915->gt0;
+   if (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && !i915->media_gt && 
VDBOX_MASK(to_gt(i915)))
+   return to_gt(i915);
 
return NULL;
 }
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 12aa7fbb07481..da0b269606c51 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -114,7 +114,7 @@ static struct dev_pm_domain pm_domain = {
 
 static void mock_gt_probe(struct drm_i915_private *i915)
 {
-   i915->gt[0] = &i915->gt0;
+   i915->gt[0] = to_gt(i915);
i915->gt[0]->name = "Mock GT";
 }
 
-- 
2.40.1

Re: [Intel-gfx] [PATCH 05/19] drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp

2023-07-25 Thread Lisovskiy, Stanislav

On Mon, Jul 24, 2023 at 05:49:11PM +0530, Nautiyal, Ankit K wrote:
> Hi Stan,
> 
> Thanks for the reviews ans suggestions. Please my response inline:
> 
> 
> On 7/20/2023 2:59 PM, Lisovskiy, Stanislav wrote:
> > On Thu, Jul 13, 2023 at 04:03:32PM +0530, Ankit Nautiyal wrote:
> > > In Bigjoiner check for DSC, bigjoiner interface bits for DP for
> > > DISPLAY > 13 is 36 (Bspec: 49259).
> > > 
> > > v2: Corrected Display ver to 13.
> > > 
> > > v3: Follow convention for conditional statement. (Ville)
> > > 
> > > v4: Fix check for display ver. (Ville)
> > > 
> > > Signed-off-by: Ankit Nautiyal 
> > > Reviewed-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 19768ac658ba..c1fd448d80e1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -802,8 +802,9 @@ u16 intel_dp_dsc_get_max_compressed_bpp(struct 
> > > drm_i915_private *i915,
> > >   bits_per_pixel = min(bits_per_pixel, max_bpp_small_joiner_ram);
> > >   if (bigjoiner) {
> > > + int bigjoiner_interface_bits = DISPLAY_VER(i915) >= 14 ? 36 : 
> > > 24;
> > >   u32 max_bpp_bigjoiner =
> > > - i915->display.cdclk.max_cdclk_freq * 48 /
> > > + i915->display.cdclk.max_cdclk_freq * 2 * 
> > > bigjoiner_interface_bits /
> > Probably "num_vdsc_instances = 
> > intel_dsc_get_num_vdsc_instances(crtc_state);" again,
> > instead of "2"?
> 
> Currently intel_dsc_get_num_vdsc_instances will give total number of
> vdsc_engines including joined pipes.
> 
> So with bigjoiner the function will return 4.
> 
> This was good to calculate Pipe BW check: (Pixel clock < PPC * CDCLK
> frequency * Number of pipes joined
> 
> as we get PPC * number of pipes joined from
> intel_dsc_get_num_vdsc_instances)
> 
> Or to calculate DSC_PIC_WIDTH PPS parameter.
> 
> But here we perhaps need intel_dsc_get_vdsc_engines_per_pipe that will just
> return 2 if dsc_split 1 otherwise.
> 
> Thanks & Regards,
> 
> Ankit

Yes, I agree, unfortunately not applicable here.
May be yeah we need some function like that and then refactor
also the intel_dsc_get_num_vdsc_instances to use that one..

Stan

> 
> > 
> > With that clarified,
> > 
> > Reviewed-by: Stanislav Lisovskiy 
> > 
> > >   intel_dp_mode_to_fec_clock(mode_clock);
> > >   bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> > > -- 
> > > 2.40.1
> > >

Re: [Intel-gfx] [PATCH 06/19] drm/i915/display: Account for DSC not split case while computing cdclk

2023-07-25 Thread Lisovskiy, Stanislav

On Tue, Jul 25, 2023 at 11:22:52AM +0530, Nautiyal, Ankit K wrote:
> 
> On 7/20/2023 2:46 PM, Lisovskiy, Stanislav wrote:
> > On Thu, Jul 13, 2023 at 04:03:33PM +0530, Ankit Nautiyal wrote:
> > > Currently we assume 2 Pixels Per Clock (PPC) while computing
> > > plane cdclk and min_cdlck. In cases where DSC single engine
> > > is used the throughput is 1 PPC.
> > > 
> > > So account for the above case, while computing cdclk.
> > > 
> > > v2: Use helper to get the adjusted pixel rate.
> > > 
> > > Signed-off-by: Ankit Nautiyal 
> > > ---
> > >   drivers/gpu/drm/i915/display/intel_cdclk.c |  2 +-
> > >   drivers/gpu/drm/i915/display/intel_vdsc.c  | 12 
> > >   drivers/gpu/drm/i915/display/intel_vdsc.h  |  2 ++
> > >   drivers/gpu/drm/i915/display/skl_universal_plane.c |  4 ++--
> > >   4 files changed, 17 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index dcc1f6941b60..701909966545 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2508,7 +2508,7 @@ static int intel_pixel_rate_to_cdclk(const struct 
> > > intel_crtc_state *crtc_state)
> > >   int pixel_rate = crtc_state->pixel_rate;
> > >   if (DISPLAY_VER(dev_priv) >= 10)
> > > - return DIV_ROUND_UP(pixel_rate, 2);
> > > + return intel_dsc_get_adjusted_pixel_rate(crtc_state, 
> > > pixel_rate);
> > >   else if (DISPLAY_VER(dev_priv) == 9 ||
> > >IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
> > >   return pixel_rate;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
> > > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > index 9d76c2756784..bbfdbf06da68 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > @@ -1038,3 +1038,15 @@ void intel_dsc_get_config(struct intel_crtc_state 
> > > *crtc_state)
> > >   out:
> > >   intel_display_power_put(dev_priv, power_domain, wakeref);
> > >   }
> > > +
> > > +int intel_dsc_get_adjusted_pixel_rate(const struct intel_crtc_state 
> > > *crtc_state, int pixel_rate)
> > > +{
> > > + /*
> > > +  * If single VDSC engine is used, it uses one pixel per clock
> > > +  * otherwise we use two pixels per clock.
> > > +  */
> > > + if (crtc_state->dsc.compression_enable && !crtc_state->dsc.dsc_split)
> > > + return pixel_rate;
> > > +
> > > + return DIV_ROUND_UP(pixel_rate, 2);
> > > +}
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.h 
> > > b/drivers/gpu/drm/i915/display/intel_vdsc.h
> > > index 2cc41ff08909..3bb4b1980b6b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vdsc.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.h
> > > @@ -28,4 +28,6 @@ void intel_dsc_dsi_pps_write(struct intel_encoder 
> > > *encoder,
> > >   void intel_dsc_dp_pps_write(struct intel_encoder *encoder,
> > >   const struct intel_crtc_state *crtc_state);
> > > +int intel_dsc_get_adjusted_pixel_rate(const struct intel_crtc_state 
> > > *crtc_state, int pixel_rate);
> > > +
> > >   #endif /* __INTEL_VDSC_H__ */
> > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> > > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > index 6b01a0b68b97..9eeb25ec4be9 100644
> > > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > @@ -17,6 +17,7 @@
> > >   #include "intel_fb.h"
> > >   #include "intel_fbc.h"
> > >   #include "intel_psr.h"
> > > +#include "intel_vdsc.h"
> > >   #include "skl_scaler.h"
> > >   #include "skl_universal_plane.h"
> > >   #include "skl_watermark.h"
> > > @@ -263,8 +264,7 @@ static int icl_plane_min_cdclk(const struct 
> > > intel_crtc_state *crtc_state,
> > >   {
> > >   unsigned int pixel_rate = intel_plane_pixel_rate(crtc_state, 
> > > plane_state);
> > > - /* two pixels per clock */
> > > - return DIV_ROUND_UP(pixel_rate, 2);
> > > + return intel_dsc_get_adjusted_pixel_rate(crtc_state, pixel_rate);
> > Hi Ankit,
> > 
> > I think the thing what you are taking of is already handled here in 
> > intel_cdclk.c:
> > 
> > /*
> >   * When we decide to use only one VDSC engine, since
> >   * each VDSC operates with 1 ppc throughput, pixel clock
> >   * cannot be higher than the VDSC clock (cdclk)
> >   * If there 2 VDSC engines, then pixel clock can't be higher than
> >   * VDSC clock(cdclk) * 2 and so on.
> >   */
> >  if (crtc_state->dsc.compression_enable) {
> >  int num_vdsc_instances = 
> > intel_dsc_get_num_vdsc_instances(crtc_state);
> > 
> >  min_cdclk = max_t(int, min_cdclk,
> >DIV_ROUND_UP(crtc_state->pixel_rate,
> > num_v

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Replace several IS_METEORLAKE with proper IP version checks

Hi Matt,

> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -470,9 +470,13 @@ enum i915_map_type i915_coherent_map_type(struct 
> drm_i915_private *i915,
> bool always_coherent)
>  {
>   /*
> -  * Wa_22016122933: always return I915_MAP_WC for MTL
> +  * Wa_22016122933: always return I915_MAP_WC for Xe_LPM+
> +  *
> +  * FIXME: The scope of this workaround is too wide right now and
> +  * is applying to objects used solely on the primary GT.  We need to
> +  * take into account which GT will be operating on the shared object.
>*/
> - if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
> + if (i915_gem_object_is_lmem(obj) || MEDIA_VER_FULL(i915) == IP_VER(13, 
> 0))
>   return I915_MAP_WC;
>   if (HAS_LLC(i915) || always_coherent)
>   return I915_MAP_WB;
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 21af0ec52223..24060278e7a2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -21,7 +21,7 @@ static void intel_gsc_idle_msg_enable(struct 
> intel_engine_cs *engine)
>  {
>   struct drm_i915_private *i915 = engine->i915;
>  
> - if (IS_METEORLAKE(i915) && engine->id == GSC0) {
> + if (MEDIA_VER(i915) >= 13 && engine->id == GSC0) {

this is a bit in countertrend... why isn't this

MEDIA_VER_FULL(engine->i915) == IP_VER(13, 0)

Like all others?

Andi

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

Hi Matt,

> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -436,6 +436,9 @@ static inline struct intel_gt *to_gt(struct 
> drm_i915_private *i915)
>  #define __GT_VER_FULL(gt) (__IS_MEDIA_GT(gt) ? \
>  MEDIA_VER_FULL((gt)->i915) : \
>  GRAPHICS_VER_FULL((gt)->i915))
> +#define __GT_STEP(gt) (__IS_MEDIA_GT(gt) ? \
> +INTEL_MEDIA_STEP((gt)->i915) : \
> +INTEL_GRAPHICS_STEP((gt)->i915))
>  
>  /*
>   * Check that a GT contains IP of the specified type and within the specified
> @@ -454,6 +457,29 @@ static inline struct intel_gt *to_gt(struct 
> drm_i915_private *i915)
>__GT_VER_FULL(gt) >= (from) && \
>__GT_VER_FULL(gt) <= (until)))
>  
> +/*
> + * Check whether a GT contains the specific IP version and a stepping within
> + * the specified range [from, until).  The lower stepping bound is inclusive,
> + * the upper bound is exclusive (corresponding to the first hardware stepping
> + * at when the workaround is no longer needed).  E.g.,
> + *
> + *IS_GT_IP_STEP(GFX, IP_VER(12, 70), A0, B0)
> + *IS_GT_IP_STEP(MEDIA, IP_VER(13, 00), B1, D0)
> + *IS_GT_IP_STEP(GFX, IP_VER(12, 71), B1, FOREVER)
> + *
> + * "FOREVER" can be passed as the upper stepping bound for workarounds that
> + * have no upper bound on steppings of the specified IP version.
> + *
> + * Note that media version checks with this macro will only work on platforms
> + * with standalone media design (i.e., media version 13 and higher).
> + */
> +#define IS_GT_IP_STEP(type, gt, ipver, since, until) \
> + (BUILD_BUG_ON_ZERO(ipver < IP_VER(2, 0)) + \
> +  (__IS_##type##_GT(gt) && \
> +   __GT_VER_FULL(gt) == ipver && \
> +   __GT_STEP(gt) >= STEP_##since && \
> +   __GT_STEP(gt) <= STEP_##until))
> +

Should this go in intel_gt.h?

>  #define MEDIA_VER(i915)  
> (RUNTIME_INFO(i915)->media.ip.ver)
>  #define MEDIA_VER_FULL(i915) 
> IP_VER(RUNTIME_INFO(i915)->media.ip.ver, \
>  RUNTIME_INFO(i915)->media.ip.rel)
> @@ -710,10 +736,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define IS_XEHPSDV_GRAPHICS_STEP(__i915, since, until) \
>   (IS_XEHPSDV(__i915) && IS_GRAPHICS_STEP(__i915, since, until))
>  
> -#define IS_MTL_GRAPHICS_STEP(__i915, variant, since, until) \
> - (IS_SUBPLATFORM(__i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_##variant) 
> && \
> -  IS_GRAPHICS_STEP(__i915, since, until))
> -

For completeness I would either leave this or remove all the
above. Or I would make this a wrapper around IS_GT_IP_STEP() with
a compile error if we are outside the MTL range.

Andi

>  #define IS_MTL_DISPLAY_STEP(__i915, since, until) \
>   (IS_METEORLAKE(__i915) && \
>IS_DISPLAY_STEP(__i915, since, until))
> -- 
> 2.41.0

[Intel-gfx] ✓ Fi.CI.BAT: success for MTL Degamma implementation (rev3)

== Series Details ==

Series: MTL Degamma implementation (rev3)
URL   : https://patchwork.freedesktop.org/series/119844/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13419 -> Patchwork_119844v3


Summary
---

  **WARNING**

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

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-kbl-soraka 

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-9: [FAIL][1] ([i915#7940]) -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-adlp-9/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-adlp-9/igt@i915_pm_...@basic-pci-d3-state.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#7456])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-2: NOTRUN -> [ABORT][4] ([i915#6687] / [i915#7978] / 
[i915#8668])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_tiled_pread_basic:
- bat-adlp-11:NOTRUN -> [SKIP][5] ([i915#3282])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-adlp-11/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u:   [PASS][6] -> [FAIL][7] ([i915#7940])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][8] -> [DMESG-WARN][9] ([i915#7699])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][10] ([i915#6367])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@kms_busy@basic@flip:
- bat-adlp-11:NOTRUN -> [ABORT][11] ([i915#4423])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-adlp-11/igt@kms_busy@ba...@flip.html

  * igt@kms_busy@basic@modeset:
- bat-adlp-11:NOTRUN -> [DMESG-WARN][12] ([i915#4423])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-adlp-11/igt@kms_busy@ba...@modeset.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-jsl-3:  NOTRUN -> [SKIP][13] ([i915#7828])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-jsl-3:  [ABORT][14] ([i915#5122]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_module_load@load:
- bat-adlp-11:[ABORT][16] ([i915#4423]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-adlp-11/igt@i915_module_l...@load.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-adlp-11/igt@i915_module_l...@load.html

  * igt@i915_pm_rpm@basic-rte:
- fi-skl-guc: [FAIL][18] ([i915#7940]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/fi-skl-guc/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-6: [DMESG-FAIL][20] ([i915#7699]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13419/bat-mtlp-6/igt@i915_selftest@l...@migrate.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119844v3/bat-mtlp-6/igt@i915_selftest@l...@migrate.html
-

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/xelpg: Call Xe_LPG workaround functions based on IP version

Hi Matt,

[...]

all good

[...]

> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h

Is this the right place to define this? Maybe in
i915/gt/intel_gt.h?

> @@ -431,6 +431,29 @@ static inline struct intel_gt *to_gt(struct 
> drm_i915_private *i915)
>  #define IS_GRAPHICS_VER(i915, from, until) \
>   (GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
>  
> +#define __IS_MEDIA_GT(gt) ((gt)->type == GT_MEDIA)
> +#define __IS_GFX_GT(gt) (!__IS_MEDIA_GT(gt))
> +#define __GT_VER_FULL(gt) (__IS_MEDIA_GT(gt) ? \
> +MEDIA_VER_FULL((gt)->i915) : \
> +GRAPHICS_VER_FULL((gt)->i915))

I think you can remove the '__' they can be widely used all
around the gt/ code.

> +/*
> + * Check that a GT contains IP of the specified type and within the specified
> + * IP range.  E.g.,
> + *
> + *IS_GT_IP_RANGE(GFX, IP_VER(12, 70), IP_VER(12, 71))
> + *IS_GT_IP_RANGE(MEDIA, IP_VER(13, 00), IP_VER(18, 02))
> + *
> + * Note that media version checks with this macro will only work on platforms
> + * with standalone media design (i.e., media version 13 and higher).
> + */
> +#define IS_GT_IP_RANGE(type, gt, from, until) ( \
> + BUILD_BUG_ON_ZERO(from < IP_VER(2, 0)) + \
> + BUILD_BUG_ON_ZERO(until < from) + \
> + (__IS_##type##_GT(gt) && \
> +  __GT_VER_FULL(gt) >= (from) && \
> +  __GT_VER_FULL(gt) <= (until)))

This helper deservers its own patch :) Can we split it from the
rest?

Thanks,
Andi

>  #define MEDIA_VER(i915)  
> (RUNTIME_INFO(i915)->media.ip.ver)
>  #define MEDIA_VER_FULL(i915) 
> IP_VER(RUNTIME_INFO(i915)->media.ip.ver, \
>  RUNTIME_INFO(i915)->media.ip.rel)
> -- 
> 2.41.0

[Intel-gfx] ✗ Fi.CI.IGT: failure for Reduce MTL-specific platform checks (rev2)

== Series Details ==

Series: Reduce MTL-specific platform checks (rev2)
URL   : https://patchwork.freedesktop.org/series/120943/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13418_full -> Patchwork_120943v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-mtlp-2/igt@gem_exec_whis...@basic-contexts-forked-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-mtlp-2/igt@gem_exec_whis...@basic-contexts-forked-all.html

  * igt@kms_cursor_crc@cursor-random-128x42@pipe-a-edp-1:
- shard-mtlp: [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-mtlp-1/igt@kms_cursor_crc@cursor-random-128...@pipe-a-edp-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-mtlp-6/igt@kms_cursor_crc@cursor-random-128...@pipe-a-edp-1.html

  * igt@kms_flip@bo-too-big@b-vga1:
- shard-snb:  [PASS][5] -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-snb6/igt@kms_flip@bo-too-...@b-vga1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-snb7/igt@kms_flip@bo-too-...@b-vga1.html

  * igt@perf@gen12-invalid-class-instance:
- shard-apl:  [PASS][7] -> [ABORT][8] +12 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-apl3/igt@p...@gen12-invalid-class-instance.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-apl4/igt@p...@gen12-invalid-class-instance.html

  * igt@perf@gen12-mi-rpc@rcs0:
- shard-rkl:  [PASS][9] -> [ABORT][10] +16 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-rkl-6/igt@perf@gen12-mi-...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-rkl-2/igt@perf@gen12-mi-...@rcs0.html

  * igt@perf@global-sseu-config:
- shard-tglu: NOTRUN -> [ABORT][11]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-tglu-7/igt@p...@global-sseu-config.html
- shard-apl:  NOTRUN -> [ABORT][12]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-apl6/igt@p...@global-sseu-config.html
- shard-glk:  NOTRUN -> [ABORT][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-glk2/igt@p...@global-sseu-config.html
- shard-rkl:  NOTRUN -> [ABORT][14]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-rkl-2/igt@p...@global-sseu-config.html

  * igt@perf@missing-sample-flags:
- shard-tglu: [PASS][15] -> [ABORT][16] +16 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-tglu-3/igt@p...@missing-sample-flags.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-tglu-9/igt@p...@missing-sample-flags.html

  * igt@perf@non-system-wide-paranoid:
- shard-dg2:  [PASS][17] -> [ABORT][18] +14 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-dg2-7/igt@p...@non-system-wide-paranoid.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-dg2-8/igt@p...@non-system-wide-paranoid.html

  * igt@perf@non-zero-reason@0-rcs0:
- shard-glk:  [PASS][19] -> [ABORT][20] +12 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-glk5/igt@perf@non-zero-rea...@0-rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-glk1/igt@perf@non-zero-rea...@0-rcs0.html

  * igt@perf@oa-exponents@0-rcs0:
- shard-apl:  [PASS][21] -> [INCOMPLETE][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-apl3/igt@perf@oa-expone...@0-rcs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-apl3/igt@perf@oa-expone...@0-rcs0.html
- shard-glk:  [PASS][23] -> [INCOMPLETE][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13418/shard-glk9/igt@perf@oa-expone...@0-rcs0.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v2/shard-glk7/igt@perf@oa-expone...@0-rcs0.html

Re: [Intel-gfx] [PATCH v2 2/9] drm/i915/xelpmp: Don't assume workarounds extend to future platforms

Hi Matt,

On Mon, Jul 24, 2023 at 05:13:15PM -0700, Matt Roper wrote:
> The currently implemented Xe_LPM+ workarounds are specific to media
> version 13.00.  When new IP versions show up in the future, they'll need
> their own workaround lists.

Makes sense...

Reviewed-by: Andi Shyti  

Andi

> Signed-off-by: Matt Roper

Re: [Intel-gfx] [PATCH v2 1/9] drm/i915: Consolidate condition for Wa_22011802037

Hi Matt,

> +/*
> + * Wa_22011802037 requires that we (or the GuC) ensure that no command
> + * streamers are executing MI_FORCE_WAKE while an engine reset is initiated.
> + */
> +bool intel_engine_reset_needs_wa_22011802037(struct intel_gt *gt)

I've seen this format in a recent Jonathan's patch and I see it
becoming a pattern in the future. Should we already agree on the
naming? Would intel_needs_wa_22011802037() be sufficient? Or a
prefix as intel_wa_* for all the similar functions?

Andi

> +{
> + if (GRAPHICS_VER(gt->i915) < 11)
> + return false;
> +
> + if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0))
> + return true;
> +
> + if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> + return false;
> +
> + return true;
> +}

[Intel-gfx] [PATCH v2 2/2] drm/i915/color: Downscale degamma lut values read from hardware

2023-07-25 Thread Chaitanya Kumar Borah

For MTL and beyond, convert back the 24 bit lut values
read from HW to 16 bit values to maintain parity with
userspace values. This way we avoid pipe config mismatch
for pre-csc lut values.

v2: Add helper function to downscale values (Jani)

Signed-off-by: Chaitanya Kumar Borah 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_color.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 32182cdff928..d78e2715d419 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3457,6 +3457,14 @@ static struct drm_property_blob 
*glk_read_degamma_lut(struct intel_crtc *crtc)
for (i = 0; i < lut_size; i++) {
u32 val = intel_de_read_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe));
 
+   /*
+* For MTL and beyond, convert back the 24 bit lut values
+* read from HW to 16 bit values to maintain parity with
+* userspace values
+*/
+   if (DISPLAY_VER(dev_priv) >= 14)
+   val = change_lut_val_precision(val, 16, 24);
+
lut[i].red = val;
lut[i].green = val;
lut[i].blue = val;
-- 
2.25.1

[Intel-gfx] [PATCH v3 1/2] drm/i915/color: Upscale degamma values for MTL

2023-07-25 Thread Chaitanya Kumar Borah

MTL onwards Degamma LUT/PRE-CSC LUT precision has been increased from
16 bits to 24 bits. Currently, drm framework only supports LUTs up to 16
bit precision. Until a new uapi comes along to support higher bitdepth,
upscale the values sent from userland to 24 bit before writing into the
HW to continue supporting degamma on MTL.

Add helper function to upscale or downscale lut values. Parameters
'to' and 'from' needs to be less than 32. This should be sufficient
as currently there are no lut values exceeding 32 bit.

v2: (Jani)
- Reuse glk_load_degamma_lut()
- Create a helper function for upscaling values

v3: Fix multi line comment style (Uma)

Signed-off-by: Chaitanya Kumar Borah 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_color.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 8966e6560516..32182cdff928 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1453,6 +1453,17 @@ static int glk_degamma_lut_size(struct drm_i915_private 
*i915)
return 35;
 }
 
+/*
+ * change_lut_val_precision: helper function to upscale or downscale lut 
values.
+ * Parameters 'to' and 'from' needs to be less than 32. This should be 
sufficient
+ * as currently there are no lut values exceeding 32 bit.
+ */
+
+static u32 change_lut_val_precision(u32 lut_val, int to, int from)
+{
+   return mul_u32_u32(lut_val, (1 << to)) / (1 << from);
+}
+
 static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state,
 const struct drm_property_blob *blob)
 {
@@ -1487,8 +1498,15 @@ static void glk_load_degamma_lut(const struct 
intel_crtc_state *crtc_state,
 * ToDo: Extend to max 7.0. Enable 32 bit input value
 * as compared to just 16 to achieve this.
 */
+   u32 lut_val;
+
+   if (DISPLAY_VER(i915) >= 14)
+   lut_val = change_lut_val_precision(lut[i].green, 24, 
16);
+   else
+   lut_val = lut[i].green;
+
ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe),
- lut[i].green);
+ lut_val);
}
 
/* Clamp values > 1.0. */
-- 
2.25.1

[Intel-gfx] [PATCH 0/2] MTL Degamma implementation

2023-07-25 Thread Chaitanya Kumar Borah

MTL onwards Degamma LUT/PRE-CSC LUT precision has been increased from
16 bits to 24 bits. Currently, drm framework only supports LUTs up to 16
bit precision. Until a new uapi comes along to support higher bitdepth,
upscale the values sent from userland to 24 bit before writing into the
HW to continue supporting degamma on MTL.

To avoid pipe config mismatch between 24 bit HW lut values and 16 bit
userspace sent values, convert back the 24 bit lut values read from HW
to 16 bit values.

Chaitanya Kumar Borah (2):
  drm/i915/color: Upscale degamma values for MTL
  drm/i915/color: Downscale degamma lut values read from hardware

 drivers/gpu/drm/i915/display/intel_color.c | 28 +-
 1 file changed, 27 insertions(+), 1 deletion(-)

-- 
2.25.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tv: avoid possible division by zero (rev3)