Re: [Intel-gfx] refactor the i915 GVT support and move to the modern mdev API v2

[Christoph Hellwig]

On Thu, Nov 04, 2021 at 02:59:18PM +0200, Joonas Lahtinen wrote:
> The minimal we should do is to eliminate the double underscore
> prefixed functions. But I would prefer to have the symbol exports by
> default so that we can enable the functionality just by loading the
> module.

I'm fine with exporting by default, but just loading won't really work
even with that:

 - there are a bunch of IS_ENABLED conditionals in the i915 (although
   they look like minor optimizations to me).
 - the enable_gvt needs to be set, although after this refactor this
   option is completely pointless and should probably be enabled
 - the enable_guc option needs to be disable for gvt to work.

Re: [Intel-gfx] refactor the i915 GVT support and move to the modern mdev API v2

[Christoph Hellwig]

On Thu, Nov 04, 2021 at 02:51:28PM +, Wang, Zhi A wrote:
> Is it possible to separate the refactor part from the using new mdev API 
> stuff? So that the design opens in the re-factor patches wouldn’t block the 
> process of mdev API improvement?

Jason had an early patch for it, but it looks so horrible that I'd much
rather sort out the underlying issues first.

Re: [Intel-gfx] [PATCH] drm/i915/dsi: disable lpdt if it is not enabled

[Jani Nikula]

On Tue, 09 Nov 2021, William Tseng  wrote:
> Avoid setting LP_DATA_TRANSFER when enable_lpdt is false
>
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Lee Shawn C 
> Cc: Cooper Chiou 
> Signed-off-by: William Tseng 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 168c84a74d30..31cea17481b1 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -183,6 +183,8 @@ static int dsi_send_pkt_hdr(struct intel_dsi_host *host,
>  
>   if (enable_lpdt)
>   tmp |= LP_DATA_TRANSFER;
> + else
> + tmp &= ~LP_DATA_TRANSFER;
>  
>   tmp &= ~(PARAM_WC_MASK | VC_MASK | DT_MASK);
>   tmp |= ((packet->header[0] & VC_MASK) << VC_SHIFT);

The read-modify-write we do here is perhaps not the brightnest idea, but
the patch at hand probably is the most sensible first fix.

Thanks, pushed to drm-intel-next.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915/dsi: transmit brightness command in HS state

[Tseng, William]

Thank you, Jani.  Yes, it would be good to restore the flags afterwards.  I 
will modify the patch.

Regards
William

-Original Message-
From: Jani Nikula  
Sent: Tuesday, November 9, 2021 3:23 PM
To: Tseng, William ; intel-gfx@lists.freedesktop.org
Cc: Tseng, William ; Ville Syrjala 
; Kulkarni, Vandita 
; Lee, Shawn C ; Chiou, 
Cooper 
Subject: Re: [PATCH] drm/i915/dsi: transmit brightness command in HS state

On Tue, 09 Nov 2021, William Tseng  wrote:
> In Video Mode, if DSI transcoder is set to transmit packets in LP 
> Escape mode, screen flickering would be obseved when brightness 
> commands are continuously and quickly transmitted to a panel.
>
> The problem may be resolved by changing the mode to transmit packets 
> from Low Power to HS.
>
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Lee Shawn C 
> Cc: Cooper Chiou 
> Signed-off-by: William Tseng 
> ---
>  drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> index f61ed82e8867..a71ef1eb598c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> @@ -81,6 +81,7 @@ static void dcs_set_backlight(const struct 
> drm_connector_state *conn_state, u32
>  
>   for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
>   dsi_device = intel_dsi->dsi_hosts[port]->device;
> + dsi_device->mode_flags &= ~MIPI_DSI_MODE_LPM;

Frankly I forget how this is intended to be used, but feels like you should 
maybe restore the flags afterwards.

BR,
Jani.

>   mipi_dsi_dcs_write(dsi_device, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
>  &data, len);
>   }

--
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH v2] drm/i915/dsi: transmit brightness command in HS state

[William Tseng]

In Video Mode, if DSI transcoder is set to transmit packets
in LP Escape mode, screen flickering would be obseved when
brightness commands are continuously and quickly transmitted
to a panel.

The problem may be resolved by changing the mode to transmit
packets from Low Power to HS.

Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Vandita Kulkarni 
Cc: Lee Shawn C 
Cc: Cooper Chiou 
Signed-off-by: William Tseng 
---
 drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
index f61ed82e8867..2f788cb0f597 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
@@ -81,8 +81,10 @@ static void dcs_set_backlight(const struct 
drm_connector_state *conn_state, u32
 
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
dsi_device = intel_dsi->dsi_hosts[port]->device;
+   dsi_device->mode_flags &= ~MIPI_DSI_MODE_LPM;
mipi_dsi_dcs_write(dsi_device, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
   &data, len);
+   dsi_device->mode_flags |= MIPI_DSI_MODE_LPM;
}
 }
 
-- 
2.17.1

Re: [Intel-gfx] [PATCH] drm/i915/dsi: disable lpdt if it is not enabled

[Tseng, William]

Thank you for your consideration. It's my pleasure.

Regards
William

-Original Message-
From: Jani Nikula  
Sent: Tuesday, November 9, 2021 4:05 PM
To: Tseng, William ; intel-gfx@lists.freedesktop.org
Cc: Tseng, William ; Ville Syrjala 
; Kulkarni, Vandita 
; Lee, Shawn C ; Chiou, 
Cooper 
Subject: Re: [PATCH] drm/i915/dsi: disable lpdt if it is not enabled

On Tue, 09 Nov 2021, William Tseng  wrote:
> Avoid setting LP_DATA_TRANSFER when enable_lpdt is false
>
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Lee Shawn C 
> Cc: Cooper Chiou 
> Signed-off-by: William Tseng 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 168c84a74d30..31cea17481b1 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -183,6 +183,8 @@ static int dsi_send_pkt_hdr(struct intel_dsi_host 
> *host,
>  
>   if (enable_lpdt)
>   tmp |= LP_DATA_TRANSFER;
> + else
> + tmp &= ~LP_DATA_TRANSFER;
>  
>   tmp &= ~(PARAM_WC_MASK | VC_MASK | DT_MASK);
>   tmp |= ((packet->header[0] & VC_MASK) << VC_SHIFT);

The read-modify-write we do here is perhaps not the brightnest idea, but the 
patch at hand probably is the most sensible first fix.

Thanks, pushed to drm-intel-next.

BR,
Jani.



--
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsi: transmit brightness command in HS state

[Patchwork]

== Series Details ==

Series: drm/i915/dsi: transmit brightness command in HS state
URL   : https://patchwork.freedesktop.org/series/96702/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10855_full -> Patchwork_21542_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([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], [PASS][45], [PASS][46], [PASS][47], 
[FAIL][48], [PASS][49], [PASS][50]) ([i915#4392])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk9/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk8/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk1/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk2/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk2/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk3/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk9/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk9/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk5/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10855/shard-glk8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk7/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk5/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk5/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk5/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk4/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk4/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk3/boot.html
   [43]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21542/shard-glk3/boot.html
   [44]: 
https://intel-gfx-ci.01.org

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Daniel Vetter]

On Tue, Nov 09, 2021 at 09:40:08AM +0200, Jani Nikula wrote:
> On Sat, 06 Nov 2021, Stephen Rothwell  wrote:
> > Hi Jani,
> >
> > On Fri, 05 Nov 2021 13:03:43 +0200 Jani Nikula  
> > wrote:
> >>
> >> I probably should have pushed c4f08d7246a5 ("drm/locking: fix
> >> __stack_depot_* name conflict") to drm-misc-next-fixes.
> >
> > Please do so as builds will start failing otherwise :-(
> 
> Thomas/Maxime/Maarten, okay to cherry-pick that to drm-misc-next-fixes?

Yeah just do, for drm-misc this is considered in committer purview. I
think we should add a section to the docs about "What if a patch is in the
wrong branch" which tells you to just cherry-pick -x or whatever.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

[Christoph Hellwig]

On Tue, Nov 09, 2021 at 09:00:39AM +0200, Jani Nikula wrote:
> On Mon, 08 Nov 2021, Zhi Wang  wrote:
> > From: Zhi Wang 
> >
> > To support the new mdev interfaces and the re-factor patches from
> > Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> > MMIO snapshot still needs to be saved in i915 so that the inital clean HW
> > state can be used for the further vGPU. Seperate the tracked MMIO table
> > from GVT-g, so that GVT-g and i915 can both use it.
> 
> Do you really have to both put code in a header and then include that in
> multiple places?
> 
> I think you may need to rethink the whole approach, maybe make them
> actual tables instead of code.

I played around with this a bit and I can't think of anyting better,
especially given that a function (i915_mmio_reg_offset) is used to
get the offset.  So except for the cosmetic cleanup below I think this
is the best we can do for now:

diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 4e2fd564abea1..c1f5f3b8abb2c 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -295,8 +295,8 @@ struct intel_vgpu_type {
 };
 
 struct intel_gvt_hw_state {
-   void *cfg_space;
-   void *mmio;
+   u32 *cfg_space;
+   u32 *mmio;
 };
 
 struct intel_gvt {
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index 6a08d362bf664..41d1bb80aba40 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -2124,6 +2124,17 @@ static int csfe_chicken1_mmio_write(struct intel_vgpu 
*vgpu,
return 0;
 }
 
+/*
+ * Generate the MMIO handler hash table.
+ */
+#define MMIO_F(reg, s, f, am, rm, d, r, w) \
+do {   \
+   int ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
+   f, s, am, rm, d, r, w); \
+   if (ret)\
+   return ret; \
+} while (0)
+
 #include "mmio_table.h"
 
 static struct gvt_mmio_block *find_mmio_block(struct intel_gvt *gvt,
diff --git a/drivers/gpu/drm/i915/gvt/mmio_table.h 
b/drivers/gpu/drm/i915/gvt/mmio_table.h
index 39a4cb59695ae..2a17f7162224d 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_table.h
+++ b/drivers/gpu/drm/i915/gvt/mmio_table.h
@@ -25,20 +25,7 @@
 #ifndef _GVT_MMIO_TABLE_H_
 #define _GVT_MMIO_TABLE_H_
 
-#ifdef GENERATE_MMIO_TABLE_IN_I915
-#define MMIO_F(reg, s, f, am, rm, d, r, w) do { \
-   ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg)); \
-   if (ret) \
-   return ret; \
-} while (0)
-#else
-#define MMIO_F(reg, s, f, am, rm, d, r, w) do { \
-   ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
-   f, s, am, rm, d, r, w); \
-   if (ret) \
-   return ret; \
-} while (0)
-#endif
+#include "gvt/reg.h"
 
 #define MMIO_D(reg, d) \
MMIO_F(reg, 4, 0, 0, 0, d, NULL, NULL)
@@ -86,8 +73,6 @@ static int intel_gvt_init_generic_mmio_info(struct intel_gvt 
*gvt)
 {
struct drm_i915_private *dev_priv = gvt->gt->i915;
 
-   int ret;
-
MMIO_RING_DFH(RING_IMR, D_ALL, 0, NULL,
intel_vgpu_reg_imr_handler);
 
@@ -905,7 +890,6 @@ static int intel_gvt_init_generic_mmio_info(struct 
intel_gvt *gvt)
 static int intel_gvt_init_bdw_mmio_info(struct intel_gvt *gvt)
 {
struct drm_i915_private *dev_priv = gvt->gt->i915;
-   int ret;
 
MMIO_DH(GEN8_GT_IMR(0), D_BDW_PLUS, NULL, intel_vgpu_reg_imr_handler);
MMIO_DH(GEN8_GT_IER(0), D_BDW_PLUS, NULL, intel_vgpu_reg_ier_handler);
@@ -1095,7 +1079,6 @@ static int intel_gvt_init_bdw_mmio_info(struct intel_gvt 
*gvt)
 static int intel_gvt_init_skl_mmio_info(struct intel_gvt *gvt)
 {
struct drm_i915_private *dev_priv = gvt->gt->i915;
-   int ret;
 
MMIO_DH(FORCEWAKE_RENDER_GEN9, D_SKL_PLUS, NULL, mul_force_wake_write);
MMIO_DH(FORCEWAKE_ACK_RENDER_GEN9, D_SKL_PLUS, NULL, NULL);
@@ -1346,7 +1329,6 @@ static int intel_gvt_init_skl_mmio_info(struct intel_gvt 
*gvt)
 static int intel_gvt_init_bxt_mmio_info(struct intel_gvt *gvt)
 {
struct drm_i915_private *dev_priv = gvt->gt->i915;
-   int ret;
 
MMIO_F(_MMIO(0x8), 0x3000, 0, 0, 0, D_BXT, NULL, NULL);
 
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 4fd51974bd359..fa9d79815af26 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -86,19 +86,17 @@ void intel_gvt_sanitize_options(struct drm_i915_private 
*dev_priv)
dev_priv->params.enable_gvt = 0;
 }
 
-#define GENERATE_MMIO_TABLE_IN_I915
-static int new_mmio_info(struct intel_gvt *gvt, u32 offset)
-{
-   void *mmio = gvt->hw_state.mmio;
-
-   *(u32 *)(mmio + offset) = intel_uncore_read_notrace(gvt->gt->uncore,
-   _MMIO(offset));

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: transmit brightness command in HS state (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dsi: transmit brightness command in HS state (rev2)
URL   : https://patchwork.freedesktop.org/series/96702/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10856 -> Patchwork_21543


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 33)
--

  Additional (2): fi-tgl-1115g4 fi-icl-u2 
  Missing(5): bat-dg1-6 fi-tgl-u2 fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] ([fdo#109315])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([i915#1155])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-bdw-5557u:   [PASS][7] -> [DMESG-FAIL][8] ([i915#541])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html

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

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([fdo#111827]) +8 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  NOTRUN -> [SKIP][12] ([fdo#109278]) +2 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([fdo#109285])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([i915#3301])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-icl-u2/igt@prime_v...@basic-userptr.html
- fi-tgl-1115g4:  NOTRUN -> [SKIP][17] ([i915#3301])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}:   [DMESG-WARN][18] ([i915#4290]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of

Re: [Intel-gfx] [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

[Jani Nikula]

On Tue, 09 Nov 2021, "Wang, Zhi A"  wrote:
> On 11/9/2021 9:00 AM, Jani Nikula wrote:
>> On Mon, 08 Nov 2021, Zhi Wang  wrote:
>>> From: Zhi Wang 
>>>
>>> To support the new mdev interfaces and the re-factor patches from
>>> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
>>> MMIO snapshot still needs to be saved in i915 so that the inital clean HW
>>> state can be used for the further vGPU. Seperate the tracked MMIO table
>>> from GVT-g, so that GVT-g and i915 can both use it.
>> Do you really have to both put code in a header and then include that in
>> multiple places?
>>
>> I think you may need to rethink the whole approach, maybe make them
>> actual tables instead of code.
>>
> Hi Jani:
>
> Sadly we can't not use a static-defined struct for a MMIO table. (That's 
> actually how the code was before) Because:
>
> 1) We use the register defininations from i915.
>
> 2) Every MMIO register definiation in i915 is not a number. It's a macro 
> _MMIO(r), which can't be put in the static-defined struct. That's how 
> the code has been modified like this when it was merged upstream. The 
> MMIO table has to be created dynamically.

Right.

> The MMIO table in the current GVT-g contains handlers in GVT-g code, 
> which shouldn't be built into i915 after it was moved into a dedicated 
> module. That's the reason I think putting it in a common header would be 
> better.
>
> It would be nice to have some better ideas.  Currently what in my mind 
> is: 1) Start a new .c file in gvt which contains the code to build MMIO 
> table and let it be used both by i915 and gvt. 2) i915 builds the table 
> and only use it for HW state saving. GVT-g builds a superior table and 
> attach the handlers. Does that sounds better?

Having the functions defined in a single .c file and called (perhaps via
just one or two entry points) sounds much better than including code.

Perhaps you could pass in the function to call (new_mmio_info) as a
parameter in different situations instead of macro magic, to make the
code more readable?

Basically I want more clarity in the interfaces between the compilation
units everywhere in i915.


BR,
Jani.


>
> Thanks,
>
> Zhi.
>
>> BR,
>> Jani.
>>
>>
>>> Cc: Joonas Lahtinen 
>>> Cc: Jani Nikula 
>>> Cc: Rodrigo Vivi 
>>> Cc: Zhenyu Wang 
>>> Cc: Zhi Wang 
>>> Cc: Christoph Hellwig 
>>> Cc: Jason Gunthorpe 
>>> Signed-off-by: Zhi Wang 
>>> ---
>>>   drivers/gpu/drm/i915/gvt/handlers.c   | 1539 +---
>>>   drivers/gpu/drm/i915/gvt/mmio_table.h | 1570 +
>>>   drivers/gpu/drm/i915/gvt/reg.h|6 +
>>>   drivers/gpu/drm/i915/intel_gvt.c  |   11 +
>>>   4 files changed, 1592 insertions(+), 1534 deletions(-)
>>>   create mode 100644 drivers/gpu/drm/i915/gvt/mmio_table.h
>>>
>>> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
>>> b/drivers/gpu/drm/i915/gvt/handlers.c
>>> index cde0a477fb49..6a08d362bf66 100644
>>> --- a/drivers/gpu/drm/i915/gvt/handlers.c
>>> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
>>> @@ -41,13 +41,6 @@
>>>   #include "i915_pvinfo.h"
>>>   #include "display/intel_display_types.h"
>>>   
>>> -/* XXX FIXME i915 has changed PP_XXX definition */
>>> -#define PCH_PP_STATUS  _MMIO(0xc7200)
>>> -#define PCH_PP_CONTROL _MMIO(0xc7204)
>>> -#define PCH_PP_ON_DELAYS _MMIO(0xc7208)
>>> -#define PCH_PP_OFF_DELAYS _MMIO(0xc720c)
>>> -#define PCH_PP_DIVISOR _MMIO(0xc7210)
>>> -
>>>   unsigned long intel_gvt_get_device_type(struct intel_gvt *gvt)
>>>   {
>>> struct drm_i915_private *i915 = gvt->gt->i915;
>>> @@ -2131,1501 +2124,7 @@ static int csfe_chicken1_mmio_write(struct 
>>> intel_vgpu *vgpu,
>>> return 0;
>>>   }
>>>   
>>> -#define MMIO_F(reg, s, f, am, rm, d, r, w) do { \
>>> -   ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
>>> -   f, s, am, rm, d, r, w); \
>>> -   if (ret) \
>>> -   return ret; \
>>> -} while (0)
>>> -
>>> -#define MMIO_D(reg, d) \
>>> -   MMIO_F(reg, 4, 0, 0, 0, d, NULL, NULL)
>>> -
>>> -#define MMIO_DH(reg, d, r, w) \
>>> -   MMIO_F(reg, 4, 0, 0, 0, d, r, w)
>>> -
>>> -#define MMIO_DFH(reg, d, f, r, w) \
>>> -   MMIO_F(reg, 4, f, 0, 0, d, r, w)
>>> -
>>> -#define MMIO_GM(reg, d, r, w) \
>>> -   MMIO_F(reg, 4, F_GMADR, 0xF000, 0, d, r, w)
>>> -
>>> -#define MMIO_GM_RDR(reg, d, r, w) \
>>> -   MMIO_F(reg, 4, F_GMADR | F_CMD_ACCESS, 0xF000, 0, d, r, w)
>>> -
>>> -#define MMIO_RO(reg, d, f, rm, r, w) \
>>> -   MMIO_F(reg, 4, F_RO | f, 0, rm, d, r, w)
>>> -
>>> -#define MMIO_RING_F(prefix, s, f, am, rm, d, r, w) do { \
>>> -   MMIO_F(prefix(RENDER_RING_BASE), s, f, am, rm, d, r, w); \
>>> -   MMIO_F(prefix(BLT_RING_BASE), s, f, am, rm, d, r, w); \
>>> -   MMIO_F(prefix(GEN6_BSD_RING_BASE), s, f, am, rm, d, r, w); \
>>> -   MMIO_F(prefix(VEBOX_RING_BASE), s, f, am, rm, d, r, w); \
>>> -   if (HAS_ENGINE(gvt->gt, VCS1)) \
>>> -   MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, f, am, rm, d, r, w); \
>>> -} while (0)
>>> -
>>> -#define MMIO_RING_D(prefix, d) \
>>> 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Fix PSR2 handling of multiplanar format

[Hogander, Jouni]

On Mon, 2021-11-08 at 13:38 -0800, José Roberto de Souza wrote:
> When a plane with a multiplanar format is added to the state by
> drm_atomic_add_affected_planes(), only the UV plane is
> added, so a intel_atomic_get_new_plane_state() call to get the Y
> plane state can return a null pointer.

I don't understand how this could happen only sometimes? Were you able
to reproduce this somehow?

Generally: checking linked_new_plane_state being valid pointer makes
sense. I'm just wondering how and when this could happen and how that
should be handled. 

> To fix this, intel_atomic_get_plane_state() should be called and
> the return needs to be checked for errors, as it could return a
> EAGAIN
> as other atomic state could be holding the lock for the Y plane.
> 
> Other issue with the patch being fixed is that the Y plane is not
> being committed to hardware because the corresponded plane bit is not
> set in update_planes when UV and Y planes are added to the state by
> drm_atomic_add_affected_planes().

To my understanding this one is already set in
intel_display.c:icl_check_nv12_planes.

> 
> Cc: Jouni Högander 
> Cc: Mika Kahola 
> Fixes: 3809991ff5f4 ("drm/i915/display: Add initial selective fetch
> support for biplanar formats")
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9d589d471e335..a1a663f362e7d 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1732,13 +1732,17 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
>* same area for Y plane as well.
>*/
>   if (linked) {
> - struct intel_plane_state
> *linked_new_plane_state =
> -   intel_atomic_get_new_plane_state(state,
> linked);
> - struct drm_rect *linked_sel_fetch_area =
> -   &linked_new_plane_state->psr2_sel_fetch_area;
> + struct intel_plane_state
> *linked_new_plane_state;
> + struct drm_rect *linked_sel_fetch_area;
>  
> + linked_new_plane_state =
> intel_atomic_get_plane_state(state, linked);
> + if (IS_ERR(linked_new_plane_state))
> + return PTR_ERR(linked_new_plane_state);
> +
> + linked_sel_fetch_area =
> &linked_new_plane_state->psr2_sel_fetch_area;
>   linked_sel_fetch_area->y1 = sel_fetch_area->y1;
>   linked_sel_fetch_area->y2 = sel_fetch_area->y2;
> + crtc_state->update_planes |= BIT(linked->id);
>   }
>   }
>  

Re: [Intel-gfx] [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

[h...@lst.de]

On Tue, Nov 09, 2021 at 12:20:24PM +0200, Jani Nikula wrote:
> Having the functions defined in a single .c file and called (perhaps via
> just one or two entry points) sounds much better than including code.
> 
> Perhaps you could pass in the function to call (new_mmio_info) as a
> parameter in different situations instead of macro magic, to make the
> code more readable?
> 
> Basically I want more clarity in the interfaces between the compilation
> units everywhere in i915.

So as far as a I can tell the table is used for a few things:

 1) to store the golden state, this is a plain array of u32
 2) to attach special write (and sometimes read) handlers, and have
a mask for read-only fields even for writable registers
 3) to show the difference between the real and virtual registers in
debugfs
 4) to restore some registers on pm resume

Can we somehow handle 3 and 4 with the table built for 1?

In that case we only need special handling in the GVT for the registers
that are overriden, which is a tiny subset and this avoids the giant
duplication.

Btw, the mmio_info_table hash is only used to iterate over all entries,
which is a strange use for a hash. It might make sense to replace it
with a more suitable data structure and/or actually make use of the
hash in intel_gvt_find_mmio_info.
> 
> 
> BR,
> Jani.
> 
> 
> >
> > Thanks,
> >
> > Zhi.
> >
> >> BR,
> >> Jani.
> >>
> >>
> >>> Cc: Joonas Lahtinen 
> >>> Cc: Jani Nikula 
> >>> Cc: Rodrigo Vivi 
> >>> Cc: Zhenyu Wang 
> >>> Cc: Zhi Wang 
> >>> Cc: Christoph Hellwig 
> >>> Cc: Jason Gunthorpe 
> >>> Signed-off-by: Zhi Wang 
> >>> ---
> >>>   drivers/gpu/drm/i915/gvt/handlers.c   | 1539 +---
> >>>   drivers/gpu/drm/i915/gvt/mmio_table.h | 1570 +
> >>>   drivers/gpu/drm/i915/gvt/reg.h|6 +
> >>>   drivers/gpu/drm/i915/intel_gvt.c  |   11 +
> >>>   4 files changed, 1592 insertions(+), 1534 deletions(-)
> >>>   create mode 100644 drivers/gpu/drm/i915/gvt/mmio_table.h
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
> >>> b/drivers/gpu/drm/i915/gvt/handlers.c
> >>> index cde0a477fb49..6a08d362bf66 100644
> >>> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> >>> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> >>> @@ -41,13 +41,6 @@
> >>>   #include "i915_pvinfo.h"
> >>>   #include "display/intel_display_types.h"
> >>>   
> >>> -/* XXX FIXME i915 has changed PP_XXX definition */
> >>> -#define PCH_PP_STATUS  _MMIO(0xc7200)
> >>> -#define PCH_PP_CONTROL _MMIO(0xc7204)
> >>> -#define PCH_PP_ON_DELAYS _MMIO(0xc7208)
> >>> -#define PCH_PP_OFF_DELAYS _MMIO(0xc720c)
> >>> -#define PCH_PP_DIVISOR _MMIO(0xc7210)
> >>> -
> >>>   unsigned long intel_gvt_get_device_type(struct intel_gvt *gvt)
> >>>   {
> >>>   struct drm_i915_private *i915 = gvt->gt->i915;
> >>> @@ -2131,1501 +2124,7 @@ static int csfe_chicken1_mmio_write(struct 
> >>> intel_vgpu *vgpu,
> >>>   return 0;
> >>>   }
> >>>   
> >>> -#define MMIO_F(reg, s, f, am, rm, d, r, w) do { \
> >>> - ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
> >>> - f, s, am, rm, d, r, w); \
> >>> - if (ret) \
> >>> - return ret; \
> >>> -} while (0)
> >>> -
> >>> -#define MMIO_D(reg, d) \
> >>> - MMIO_F(reg, 4, 0, 0, 0, d, NULL, NULL)
> >>> -
> >>> -#define MMIO_DH(reg, d, r, w) \
> >>> - MMIO_F(reg, 4, 0, 0, 0, d, r, w)
> >>> -
> >>> -#define MMIO_DFH(reg, d, f, r, w) \
> >>> - MMIO_F(reg, 4, f, 0, 0, d, r, w)
> >>> -
> >>> -#define MMIO_GM(reg, d, r, w) \
> >>> - MMIO_F(reg, 4, F_GMADR, 0xF000, 0, d, r, w)
> >>> -
> >>> -#define MMIO_GM_RDR(reg, d, r, w) \
> >>> - MMIO_F(reg, 4, F_GMADR | F_CMD_ACCESS, 0xF000, 0, d, r, w)
> >>> -
> >>> -#define MMIO_RO(reg, d, f, rm, r, w) \
> >>> - MMIO_F(reg, 4, F_RO | f, 0, rm, d, r, w)
> >>> -
> >>> -#define MMIO_RING_F(prefix, s, f, am, rm, d, r, w) do { \
> >>> - MMIO_F(prefix(RENDER_RING_BASE), s, f, am, rm, d, r, w); \
> >>> - MMIO_F(prefix(BLT_RING_BASE), s, f, am, rm, d, r, w); \
> >>> - MMIO_F(prefix(GEN6_BSD_RING_BASE), s, f, am, rm, d, r, w); \
> >>> - MMIO_F(prefix(VEBOX_RING_BASE), s, f, am, rm, d, r, w); \
> >>> - if (HAS_ENGINE(gvt->gt, VCS1)) \
> >>> - MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, f, am, rm, d, r, w); \
> >>> -} while (0)
> >>> -
> >>> -#define MMIO_RING_D(prefix, d) \
> >>> - MMIO_RING_F(prefix, 4, 0, 0, 0, d, NULL, NULL)
> >>> -
> >>> -#define MMIO_RING_DFH(prefix, d, f, r, w) \
> >>> - MMIO_RING_F(prefix, 4, f, 0, 0, d, r, w)
> >>> -
> >>> -#define MMIO_RING_GM(prefix, d, r, w) \
> >>> - MMIO_RING_F(prefix, 4, F_GMADR, 0x, 0, d, r, w)
> >>> -
> >>> -#define MMIO_RING_GM_RDR(prefix, d, r, w) \
> >>> - MMIO_RING_F(prefix, 4, F_GMADR | F_CMD_ACCESS, 0x, 0, d, r, w)
> >>> -
> >>> -#define MMIO_RING_RO(prefix, d, f, rm, r, w) \
> >>> - MMIO_RING_F(prefix, 4, F_RO | f, 0, rm, d, r, w)
> >>> -
> >>> -static int init_generic_mmio_info(struct intel_gvt *gvt)
> >>> -{
> >>> - struct drm_i915_private *dev_priv = gvt->gt->i915;
> >>> - int

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: transmit brightness command in HS state

[Jani Nikula]

On Tue, 09 Nov 2021, William Tseng  wrote:
> In Video Mode, if DSI transcoder is set to transmit packets
> in LP Escape mode, screen flickering would be obseved when
> brightness commands are continuously and quickly transmitted
> to a panel.
>
> The problem may be resolved by changing the mode to transmit
> packets from Low Power to HS.
>
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Lee Shawn C 
> Cc: Cooper Chiou 
> Signed-off-by: William Tseng 
> ---
>  drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> index f61ed82e8867..2f788cb0f597 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> @@ -81,8 +81,10 @@ static void dcs_set_backlight(const struct 
> drm_connector_state *conn_state, u32
>  
>   for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
>   dsi_device = intel_dsi->dsi_hosts[port]->device;
> + dsi_device->mode_flags &= ~MIPI_DSI_MODE_LPM;
>   mipi_dsi_dcs_write(dsi_device, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
>  &data, len);
> + dsi_device->mode_flags |= MIPI_DSI_MODE_LPM;

Ah, but this doesn't *restore* the flags, it forces MIPI_DSI_MODE_LPM!

BR,
Jani.

>   }
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

[h...@lst.de]

On Tue, Nov 09, 2021 at 10:51:27AM +, Wang, Zhi A wrote:
> Can you elaborate more about this? We need the hash query from the table 
> ASAP when the hypervisor trapped a mmio access. It's a critical path and 
> we tried different data structure in the kernel and the hash table gives 
> the best performance.

Ok, I misunderstood the hashtable.h interface.  hash_for_each_possible
actually does a hash lookup instead of an interation despite the rather
misleading name.

Re: [Intel-gfx] [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

[Wang, Zhi A]

On 11/9/2021 12:58 PM, h...@lst.de wrote:
> On Tue, Nov 09, 2021 at 10:51:27AM +, Wang, Zhi A wrote:
>> Can you elaborate more about this? We need the hash query from the table
>> ASAP when the hypervisor trapped a mmio access. It's a critical path and
>> we tried different data structure in the kernel and the hash table gives
>> the best performance.
> Ok, I misunderstood the hashtable.h interface.  hash_for_each_possible
> actually does a hash lookup instead of an interation despite the rather
> misleading name.

Yes. Maybe with a keyword "lookup" in the name of the interface would be 
better since it's widely used in the kernel. :)

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Jani Nikula]

On Tue, 09 Nov 2021, Daniel Vetter  wrote:
> On Tue, Nov 09, 2021 at 09:40:08AM +0200, Jani Nikula wrote:
>> On Sat, 06 Nov 2021, Stephen Rothwell  wrote:
>> > Hi Jani,
>> >
>> > On Fri, 05 Nov 2021 13:03:43 +0200 Jani Nikula  
>> > wrote:
>> >>
>> >> I probably should have pushed c4f08d7246a5 ("drm/locking: fix
>> >> __stack_depot_* name conflict") to drm-misc-next-fixes.
>> >
>> > Please do so as builds will start failing otherwise :-(
>> 
>> Thomas/Maxime/Maarten, okay to cherry-pick that to drm-misc-next-fixes?
>
> Yeah just do, for drm-misc this is considered in committer purview. I
> think we should add a section to the docs about "What if a patch is in the
> wrong branch" which tells you to just cherry-pick -x or whatever.

Done.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH] drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj()

[Dan Carpenter]

The "ret" variable is checked on the previous line so we know it's
zero.  No need to check again.

Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/i915/display/intel_fb_pin.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c 
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index 3f77f3013584..3b20f69e0240 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -142,13 +142,11 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
if (ret)
goto err;
 
-   if (!ret) {
-   vma = i915_gem_object_pin_to_display_plane(obj, &ww, alignment,
-  view, pinctl);
-   if (IS_ERR(vma)) {
-   ret = PTR_ERR(vma);
-   goto err_unpin;
-   }
+   vma = i915_gem_object_pin_to_display_plane(obj, &ww, alignment,
+  view, pinctl);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
+   goto err_unpin;
}
 
if (uses_fence && i915_vma_is_map_and_fenceable(vma)) {
-- 
2.20.1

Re: [Intel-gfx] [PATCH] i915/selftest: Disable irq to calc eng timestamp

[Nilawar, Badal]

A couple of comments below, after addressing those this is:
Reviewed-by: Badal Nilawar 

On 26-10-2021 19:10, Anshuman Gupta wrote:

gt_pm selftest calculates engine ticks cycles and wall time
cycles by delta of respective engine elapsed TIMESTAMP and ktime
for period of 1000us.
It compares the engine ticks cycles with wall time cycles.

Disable local cpu interrupt so that interrupt handler
should not preempt the measure_clocks() to calculate
correct engine ticks cycles.

Suggested-by: Chris P Wilson
Signed-off-by: Anshuman Gupta
---
  drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
index b9441217ca3d..9cf76398bdf5 100644
--- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
@@ -43,6 +43,7 @@ static void measure_clocks(struct intel_engine_cs *engine,
int i;
  
  	for (i = 0; i < 5; i++) {

+   local_irq_disable();


How about saving interrupt state before disabling it.

Use local_irq_save here.


preempt_disable();
cycles[i] = -ENGINE_READ_FW(engine, RING_TIMESTAMP);
dt[i] = ktime_get();
@@ -52,6 +53,7 @@ static void measure_clocks(struct intel_engine_cs *engine,
dt[i] = ktime_sub(ktime_get(), dt[i]);
cycles[i] += ENGINE_READ_FW(engine, RING_TIMESTAMP);
preempt_enable();
+   local_irq_enable();

Use local_irq_restore here.

}
  
  	/* Use the median of both cycle/dt; close enough */

[Intel-gfx] [PATCH] Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"

[Vandita Kulkarni]

This reverts commit 991d9557b0c457fb92bc49ddde24a7d9ce6144a8.
The Bspec was updated recently with the pll ungate sequence
similar to that of icl dsi enable sequence.
Hence reverting.

Bspec:49187

Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/display/icl_dsi.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 2337c0b54586..edc38fbd2545 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -698,10 +698,7 @@ static void gen11_dsi_map_pll(struct intel_encoder 
*encoder,
intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
 
for_each_dsi_phy(phy, intel_dsi->phys) {
-   if (DISPLAY_VER(dev_priv) >= 12)
-   val |= ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
-   else
-   val &= ~ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
+   val &= ~ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
}
intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
 
@@ -1137,8 +1134,6 @@ static void
 gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state)
 {
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-
/* step 4a: power up all lanes of the DDI used by DSI */
gen11_dsi_power_up_lanes(encoder);
 
@@ -1164,8 +1159,7 @@ gen11_dsi_enable_port_and_phy(struct intel_encoder 
*encoder,
gen11_dsi_configure_transcoder(encoder, crtc_state);
 
/* Step 4l: Gate DDI clocks */
-   if (DISPLAY_VER(dev_priv) == 11)
-   gen11_dsi_gate_clocks(encoder);
+   gen11_dsi_gate_clocks(encoder);
 }
 
 static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)
-- 
2.32.0

Re: [Intel-gfx] [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Kulkarni, Vandita
> Sent: Tuesday, November 2, 2021 5:13 PM
> To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [V2 4/4] drm/i915/dsi: Ungate clock before enabling 
> the
> phy
> 
> > -Original Message-
> > From: Nikula, Jani 
> > Sent: Tuesday, November 2, 2021 3:13 PM
> > To: Kulkarni, Vandita ; intel-
> > g...@lists.freedesktop.org
> > Cc: Deak, Imre ; Roper, Matthew D
> > ; ville.syrj...@linux.intel.com
> > Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the
> > phy
> >
> > On Tue, 02 Nov 2021, "Kulkarni, Vandita" 
> > wrote:
> > >> -Original Message-
> > >> From: Nikula, Jani 
> > >> Sent: Monday, November 1, 2021 5:37 PM
> > >> To: Kulkarni, Vandita ; intel-
> > >> g...@lists.freedesktop.org
> > >> Cc: Deak, Imre ; Roper, Matthew D
> > >> ; ville.syrj...@linux.intel.com
> > >> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling
> > >> the phy
> > >>
> > >> On Thu, 28 Oct 2021, "Kulkarni, Vandita"
> > >> 
> > >> wrote:
> > >> >> -Original Message-
> > >> >> From: Nikula, Jani 
> > >> >> Sent: Thursday, October 28, 2021 8:06 PM
> > >> >> To: Kulkarni, Vandita ; intel-
> > >> >> g...@lists.freedesktop.org
> > >> >> Cc: Deak, Imre ; Roper, Matthew D
> > >> >> ; ville.syrj...@linux.intel.com
> > >> >> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling
> > >> >> the phy
> > >> >>
> > >> >> On Thu, 28 Oct 2021, "Kulkarni, Vandita"
> > >> >> 
> > >> >> wrote:
> > >> >> >> -Original Message-
> > >> >> >> From: Nikula, Jani 
> > >> >> >> Sent: Thursday, October 28, 2021 5:13 PM
> > >> >> >> To: Kulkarni, Vandita ; intel-
> > >> >> >> g...@lists.freedesktop.org
> > >> >> >> Cc: Deak, Imre ; Roper, Matthew D
> > >> >> >> ; ville.syrj...@linux.intel.com;
> > >> >> >> Kulkarni, Vandita 
> > >> >> >> Subject: Re: [V2 4/4] drm/i915/dsi: Ungate clock before
> > >> >> >> enabling the phy
> > >> >> >>
> > >> >> >> On Tue, 19 Oct 2021, Vandita Kulkarni
> > >> >> >> 
> > >> >> wrote:
> > >> >> >> > For the PHY enable/disable signalling to propagate between
> > >> >> >> > Dispaly and PHY, DDI clocks need to be running when
> > >> >> >> > enabling the
> > >> PHY.
> > >> >> >> >
> > >> >> >> > Bspec: 49188 says gate the clocks after enabling the
> > >> >> >> >DDI Buffer.
> > >> >> >> >We also have a commit 991d9557b0c4 ("drm/i915/tgl/dsi:
> > >> >> >> > Gate the
> > >> >> ddi
> > >> >> >> >clocks after pll mapping") which gates the clocks much 
> > >> >> >> > before,
> > >> >> >> >as per the older spec. This commit nullifies its
> > >> >> >> > effect and
> > makes
> > >> >> >> >sure that the clocks are not gated while we enable the DDI
> > >> >> >> >buffer.
> > >> >> >> > v2: Bspec ref, add a comment wrt earlier clock gating
> > >> >> >> > sequence
> > >> >> >> > (Jani)
> > >> >> >> >
> > >> >> >> > Signed-off-by: Vandita Kulkarni
> > >> >> >> > 
> > >> >> >> > ---
> > >> >> >> >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> > >> >> >> >  1 file changed, 3 insertions(+), 5 deletions(-)
> > >> >> >> >
> > >> >> >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > >> >> >> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > >> >> >> > index 63dd75c6448a..e5ef5c4a32d7 100644
> > >> >> >> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > >> >> >> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > >> >> >> > @@ -1135,8 +1135,6 @@ static void
> > >> >> >> > gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> > >> >> >> >const struct intel_crtc_state 
> > >> >> >> > *crtc_state)
> > >> {
> > >> >> >> > -struct drm_i915_private *dev_priv = to_i915(encoder-
> > >> >base.dev);
> > >> >> >> > -
> > >> >> >> >  /* step 4a: power up all lanes of the DDI used by DSI */
> > >> >> >> >  gen11_dsi_power_up_lanes(encoder);
> > >> >> >> >
> > >> >> >> > @@ -1146,6 +1144,8 @@
> > gen11_dsi_enable_port_and_phy(struct
> > >> >> >> intel_encoder *encoder,
> > >> >> >> >  /* step 4c: configure voltage swing and skew */
> > >> >> >> >  gen11_dsi_voltage_swing_program_seq(encoder);
> > >> >> >> >
> > >> >> >> > +gen11_dsi_ungate_clocks(encoder);
> > >> >> >> > +
> > >> >> >>
> > >> >> >> What about the changes to gen11_dsi_map_pll() in commit
> > >> >> >> 991d9557b0c4
> > >> >> >> ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping")?
> > >> >> >> It starts off with clocks gated for gen12+, ungated otherwise.
> > >> >> >
> > >> >> > Now the same spec is updated with the gate step after ddi
> > >> >> > buffer
> > >> enable.
> > >> >> > And the one before is marked with remove tag.
> > >> >> > That makes all gen12+ align with gen 11.
> > >> >> > You suggested to update the same in the commit message on v1.
> > >> >> > Should I still consider just reverting that commit?
> > >> >>
> > >> >> I'm just royally confused about the sequence

[Intel-gfx] [PATCH] drm/i915: Use per device iommu check

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
and probe presence of iommu domain per device to accurately reflect its
status.

Signed-off-by: Tvrtko Ursulin 
Cc: Lu Baolu 
---
Baolu, is my understanding here correct? Maybe I am confused by both
intel_iommu_gfx_mapped and dmar_map_gfx being globals in the intel_iommu
driver. But it certainly appears the setup can assign some iommu ops (and
assign the discrete i915 to iommu group) when those two are set to off.
---
 drivers/gpu/drm/i915/display/intel_bw.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_fbc.c |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c   |  2 +-
 drivers/gpu/drm/i915/gem/i915_gemfs.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  4 ++--
 drivers/gpu/drm/i915/i915_debugfs.c  |  1 +
 drivers/gpu/drm/i915/i915_drv.c  |  7 +++
 drivers/gpu/drm/i915/i915_drv.h  | 13 +++--
 drivers/gpu/drm/i915/i915_gpu_error.c|  5 +
 drivers/gpu/drm/i915/intel_device_info.c | 14 +-
 drivers/gpu/drm/i915/intel_pm.c  |  2 +-
 12 files changed, 25 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 8d9d888e9316..a4d8088e4f71 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -490,7 +490,7 @@ static unsigned int intel_bw_data_rate(struct 
drm_i915_private *dev_priv,
for_each_pipe(dev_priv, pipe)
data_rate += bw_state->data_rate[pipe];
 
-   if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active())
+   if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active(dev_priv))
data_rate = data_rate * 105 / 100;
 
return data_rate;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 29392dfc46c8..80d206f3e9da 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1315,7 +1315,7 @@ static bool needs_async_flip_vtd_wa(const struct 
intel_crtc_state *crtc_state)
 {
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
 
-   return crtc_state->uapi.async_flip && intel_vtd_active() &&
+   return crtc_state->uapi.async_flip && intel_vtd_active(i915) &&
(DISPLAY_VER(i915) == 9 || IS_BROADWELL(i915) || 
IS_HASWELL(i915));
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 834eb4cc7c10..0ccbfc9e4101 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1539,7 +1539,7 @@ static int intel_sanitize_fbc_option(struct 
drm_i915_private *dev_priv)
 static bool need_fbc_vtd_wa(struct drm_i915_private *dev_priv)
 {
/* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
-   if (intel_vtd_active() &&
+   if (intel_vtd_active(dev_priv) &&
(IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))) {
drm_info(&dev_priv->drm,
 "Disabling framebuffer compression (FBC) to prevent 
screen flicker with VT-d enabled\n");
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index ddd37ccb1362..cf100c0ea3b7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -399,7 +399,7 @@ static int i915_gem_init_stolen(struct intel_memory_region 
*mem)
return 0;
}
 
-   if (intel_vtd_active() && GRAPHICS_VER(i915) < 8) {
+   if (intel_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
drm_notice(&i915->drm,
   "%s, disabling use of stolen memory\n",
   "DMAR active");
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c 
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index dbdbdc344d87..11cd66d183e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -31,7 +31,7 @@ int i915_gemfs_init(struct drm_i915_private *i915)
 */
 
opts = NULL;
-   if (intel_vtd_active()) {
+   if (intel_vtd_active(i915)) {
if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
static char huge_opt[] = "huge=within_size"; /* r/w */
 
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1fb4a03d7ac3..ddb4a9d039d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -104,7 +104,7 @@ static bool needs_idle_maps(struct drm_i915_private *i915)
 * Query intel_iommu to see if we need the workaround. Presumably that
 * was loaded first.
 */
-   if (!intel_vtd_active())
+   if 

[Intel-gfx] [PATCH] drm/i915: Skip error capture when wedged on init

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Trying to capture uninitialised engines when we wedged on init ends in
tears. Skip that together with uC capture, since failure to initialise the
latter can actually be one of the reasons for wedging on init.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2a2d7643b551..aa2b3aad9643 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1866,10 +1866,14 @@ i915_gpu_coredump(struct intel_gt *gt, 
intel_engine_mask_t engine_mask)
}
 
gt_record_info(error->gt);
-   gt_record_engines(error->gt, engine_mask, compress);
 
-   if (INTEL_INFO(i915)->has_gt_uc)
-   error->gt->uc = gt_record_uc(error->gt, compress);
+   if (!intel_gt_has_unrecoverable_error(gt)) {
+   gt_record_engines(error->gt, engine_mask, compress);
+
+   if (INTEL_INFO(i915)->has_gt_uc)
+   error->gt->uc = gt_record_uc(error->gt,
+compress);
+   }
 
i915_vma_capture_finish(error->gt, compress);
 
-- 
2.30.2

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: transmit brightness command in HS state (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dsi: transmit brightness command in HS state (rev2)
URL   : https://patchwork.freedesktop.org/series/96702/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10856_full -> Patchwork_21543_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_sseu@full-enable:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-skl4/igt@i915_pm_s...@full-enable.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/shard-skl6/igt@i915_pm_s...@full-enable.html

  * igt@kms_atomic_transition@plane-all-transition@edp-1-pipe-a:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-tglb5/igt@kms_atomic_transition@plane-all-transit...@edp-1-pipe-a.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/shard-tglb5/igt@kms_atomic_transition@plane-all-transit...@edp-1-pipe-a.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([PASS][5], [PASS][6], [PASS][7], [PASS][8], 
[PASS][9], [PASS][10], [PASS][11], [FAIL][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]) ([i915#4386]) -> ([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], 
[PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl8/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl1/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl1/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl1/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl1/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl1/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl2/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl2/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl2/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl2/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl4/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl4/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl4/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl4/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl6/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl6/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl6/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10856/shard-apl7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/shard-apl1/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/shard-apl1/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/shard-apl1/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21543/shard-apl1/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj()

[Patchwork]

== Series Details ==

Series: drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj()
URL   : https://patchwork.freedesktop.org/series/96712/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10857 -> Patchwork_21544


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 34)
--

  Additional (3): fi-tgl-u2 fi-icl-u2 fi-pnv-d510 
  Missing(4): fi-ctg-p8600 fi-tgl-1115g4 bat-dg1-6 bat-adlp-4 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@core_hotunplug@unbind-rebind:
- fi-tgl-u2:  NOTRUN -> [INCOMPLETE][2] ([i915#4006])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-u2:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-tgl-u2:  NOTRUN -> [SKIP][5] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-u2:  NOTRUN -> [SKIP][7] ([i915#4103]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([fdo#109278]) +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-u2:  NOTRUN -> [SKIP][9] ([fdo#109285])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([fdo#109285])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][11] ([fdo#109271]) +53 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-pnv-d510/igt@prime_v...@basic-userptr.html
- fi-icl-u2:  NOTRUN -> [SKIP][12] ([i915#3301])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-icl-u2/igt@prime_v...@basic-userptr.html
- fi-tgl-u2:  NOTRUN -> [SKIP][13] ([i915#3301])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-tgl-u2/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-tgl-u2:  NOTRUN -> [FAIL][14] ([i915#1602] / [i915#2722] / 
[i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-tgl-u2/igt@run...@aborted.html

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][15] ([i915#295]) -> [PASS][16] +12 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3301

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Some fixes in HDMI2.1 PCON FRL configuration (rev2)

[Nautiyal, Ankit K]

Hi Lakshmi,

Seems like the below issue:

  *   igt@gem_exec_endless@dispatch@vcs1:
 *   shard-tglb: 
PASS
 -> 
INCOMPLETE
is a known issue https://gitlab.freedesktop.org/drm/intel/-/issues/3778
Recently seen : 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10854/shard-tglb8/igt@gem_exec_endless@dispa...@vecs0.html

Regards,
Ankit

From: Patchwork 
Sent: Monday, November 8, 2021 2:26 PM
To: Nautiyal, Ankit K 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for Some fixes in HDMI2.1 PCON FRL configuration 
(rev2)

Patch Details
Series:
Some fixes in HDMI2.1 PCON FRL configuration (rev2)
URL:
https://patchwork.freedesktop.org/series/96411/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/index.html
CI Bug Log - changes from CI_DRM_10853_full -> Patchwork_21531_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_21531_full absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21531_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Participating hosts (11 -> 11)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_exec_endless@dispatch@vcs1:
 *   shard-tglb: 
PASS
 -> 
INCOMPLETE

Suppressed

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

  *   igt@kms_mmap_write_crc@main:
 *   {shard-rkl}: NOTRUN -> 
SKIP

Known issues

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

CI changes
Issues hit

  *   boot:
 *   shard-apl: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
FAIL

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"
URL   : https://patchwork.freedesktop.org/series/96714/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10857 -> Patchwork_21545


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 32)
--

  Missing(3): fi-ctg-p8600 bat-dg1-6 bat-adlp-4 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [PASS][1] -> [FAIL][2] ([i915#1888])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][3] ([i915#295]) -> [PASS][4] +12 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

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

  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303


Build changes
-

  * Linux: CI_DRM_10857 -> Patchwork_21545

  CI-20190529: 20190529
  CI_DRM_10857: 2f005a829cd05b317c5b497a6941b88d981d22e6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6275: 6d172a5cf515f2780e2837860d613db5067f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21545: 03e24bc33e15df4ddb98d5c1114d24b0298bcca1 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

03e24bc33e15 Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"

== Logs ==

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

[Intel-gfx] [PATCH 2/3] i915/gvt: save the initial HW state snapshot in i915.

[Zhi Wang]

From: Zhi Wang 

Save the inital HW state snapshot in i915 so that the rest code of GVT-g
can be moved into a dedicated module while it can still get a clean
initial HW state saved at the correct time during the initialization of
i915. The futhrer vGPU created by GVT-g will use this HW state as the
initial HW state.

Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Christoph Hellwig 
Cc: Jason Gunthorpe 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/gvt/gvt.c   | 31 +
 drivers/gpu/drm/i915/gvt/gvt.h   |  6 +++
 drivers/gpu/drm/i915/intel_gvt.c | 75 ++--
 3 files changed, 80 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index cbac409f6c8a..4b3b47892453 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -63,23 +63,6 @@ static const struct intel_gvt_ops intel_gvt_ops = {
.emulate_hotplug = intel_vgpu_emulate_hotplug,
 };
 
-static void init_device_info(struct intel_gvt *gvt)
-{
-   struct intel_gvt_device_info *info = &gvt->device_info;
-   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
-
-   info->max_support_vgpus = 8;
-   info->cfg_space_size = PCI_CFG_SPACE_EXP_SIZE;
-   info->mmio_size = 2 * 1024 * 1024;
-   info->mmio_bar = 0;
-   info->gtt_start_offset = 8 * 1024 * 1024;
-   info->gtt_entry_size = 8;
-   info->gtt_entry_size_shift = 3;
-   info->gmadr_bytes_in_cmd = 8;
-   info->max_surface_size = 36 * 1024 * 1024;
-   info->msi_cap_offset = pdev->msi_cap;
-}
-
 static void intel_gvt_test_and_emulate_vblank(struct intel_gvt *gvt)
 {
struct intel_vgpu *vgpu;
@@ -188,27 +171,19 @@ void intel_gvt_clean_device(struct drm_i915_private *i915)
  */
 int intel_gvt_init_device(struct drm_i915_private *i915)
 {
-   struct intel_gvt *gvt;
+   struct intel_gvt *gvt = i915->gvt;
struct intel_vgpu *vgpu;
int ret;
 
-   if (drm_WARN_ON(&i915->drm, i915->gvt))
+   if (drm_WARN_ON(&i915->drm, !i915->gvt))
return -EEXIST;
 
-   gvt = kzalloc(sizeof(struct intel_gvt), GFP_KERNEL);
-   if (!gvt)
-   return -ENOMEM;
-
gvt_dbg_core("init gvt device\n");
 
idr_init_base(&gvt->vgpu_idr, 1);
spin_lock_init(&gvt->scheduler.mmio_context_lock);
mutex_init(&gvt->lock);
mutex_init(&gvt->sched_lock);
-   gvt->gt = &i915->gt;
-   i915->gvt = gvt;
-
-   init_device_info(gvt);
 
ret = intel_gvt_setup_mmio_info(gvt);
if (ret)
@@ -281,8 +256,6 @@ int intel_gvt_init_device(struct drm_i915_private *i915)
intel_gvt_clean_mmio_info(gvt);
 out_clean_idr:
idr_destroy(&gvt->vgpu_idr);
-   kfree(gvt);
-   i915->gvt = NULL;
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 0c0615602343..1defee730cf3 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -296,6 +296,11 @@ struct intel_vgpu_type {
enum intel_vgpu_edid resolution;
 };
 
+struct intel_gvt_hw_state {
+   void *cfg_space;
+   void *mmio;
+};
+
 struct intel_gvt {
/* GVT scope lock, protect GVT itself, and all resource currently
 * not yet protected by special locks(vgpu and scheduler lock).
@@ -311,6 +316,7 @@ struct intel_gvt {
struct intel_gvt_gm gm;
struct intel_gvt_fence fence;
struct intel_gvt_mmio mmio;
+   struct intel_gvt_hw_state hw_state;
struct intel_gvt_firmware firmware;
struct intel_gvt_irq irq;
struct intel_gvt_gtt gtt;
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 64846d9bff0b..4fd51974bd35 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -87,8 +87,12 @@ void intel_gvt_sanitize_options(struct drm_i915_private 
*dev_priv)
 }
 
 #define GENERATE_MMIO_TABLE_IN_I915
-static int new_mmio_info(struct intel_gvt *gvt, u64 offset)
+static int new_mmio_info(struct intel_gvt *gvt, u32 offset)
 {
+   void *mmio = gvt->hw_state.mmio;
+
+   *(u32 *)(mmio + offset) = intel_uncore_read_notrace(gvt->gt->uncore,
+   _MMIO(offset));
return 0;
 }
 
@@ -96,6 +100,22 @@ static int new_mmio_info(struct intel_gvt *gvt, u64 offset)
 #include "gvt/mmio_table.h"
 #undef GENERATE_MMIO_TABLE_IN_I915
 
+static void init_device_info(struct intel_gvt *gvt)
+{
+   struct intel_gvt_device_info *info = &gvt->device_info;
+   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
+
+   info->max_support_vgpus = 8;
+   info->cfg_space_size = PCI_CFG_SPACE_EXP_SIZE;
+   info->mmio_size = 2 * 1024 * 1024;
+   info->mmio_bar = 0;
+   info->gtt_start_offset = 8 * 1024 * 1024;
+   info->gtt_entry_size = 8;
+   info->gtt_entry_size_shift = 3;
+ 

[Intel-gfx] [PATCH 1/3] i915/gvt: seperate tracked MMIO table from handlers.c

[Zhi Wang]

From: Zhi Wang 

To support the new mdev interfaces and the re-factor patches from
Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
MMIO snapshot still needs to be saved in i915 so that the inital clean HW
state can be used for the further vGPU. Seperate the tracked MMIO table
from GVT-g, so that GVT-g and i915 can both use it.

Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Christoph Hellwig 
Cc: Jason Gunthorpe 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/gvt/handlers.c   | 1539 +---
 drivers/gpu/drm/i915/gvt/mmio_table.h | 1570 +
 drivers/gpu/drm/i915/gvt/reg.h|6 +
 drivers/gpu/drm/i915/intel_gvt.c  |   11 +
 4 files changed, 1592 insertions(+), 1534 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/mmio_table.h

diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index cde0a477fb49..6a08d362bf66 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -41,13 +41,6 @@
 #include "i915_pvinfo.h"
 #include "display/intel_display_types.h"
 
-/* XXX FIXME i915 has changed PP_XXX definition */
-#define PCH_PP_STATUS  _MMIO(0xc7200)
-#define PCH_PP_CONTROL _MMIO(0xc7204)
-#define PCH_PP_ON_DELAYS _MMIO(0xc7208)
-#define PCH_PP_OFF_DELAYS _MMIO(0xc720c)
-#define PCH_PP_DIVISOR _MMIO(0xc7210)
-
 unsigned long intel_gvt_get_device_type(struct intel_gvt *gvt)
 {
struct drm_i915_private *i915 = gvt->gt->i915;
@@ -2131,1501 +2124,7 @@ static int csfe_chicken1_mmio_write(struct intel_vgpu 
*vgpu,
return 0;
 }
 
-#define MMIO_F(reg, s, f, am, rm, d, r, w) do { \
-   ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
-   f, s, am, rm, d, r, w); \
-   if (ret) \
-   return ret; \
-} while (0)
-
-#define MMIO_D(reg, d) \
-   MMIO_F(reg, 4, 0, 0, 0, d, NULL, NULL)
-
-#define MMIO_DH(reg, d, r, w) \
-   MMIO_F(reg, 4, 0, 0, 0, d, r, w)
-
-#define MMIO_DFH(reg, d, f, r, w) \
-   MMIO_F(reg, 4, f, 0, 0, d, r, w)
-
-#define MMIO_GM(reg, d, r, w) \
-   MMIO_F(reg, 4, F_GMADR, 0xF000, 0, d, r, w)
-
-#define MMIO_GM_RDR(reg, d, r, w) \
-   MMIO_F(reg, 4, F_GMADR | F_CMD_ACCESS, 0xF000, 0, d, r, w)
-
-#define MMIO_RO(reg, d, f, rm, r, w) \
-   MMIO_F(reg, 4, F_RO | f, 0, rm, d, r, w)
-
-#define MMIO_RING_F(prefix, s, f, am, rm, d, r, w) do { \
-   MMIO_F(prefix(RENDER_RING_BASE), s, f, am, rm, d, r, w); \
-   MMIO_F(prefix(BLT_RING_BASE), s, f, am, rm, d, r, w); \
-   MMIO_F(prefix(GEN6_BSD_RING_BASE), s, f, am, rm, d, r, w); \
-   MMIO_F(prefix(VEBOX_RING_BASE), s, f, am, rm, d, r, w); \
-   if (HAS_ENGINE(gvt->gt, VCS1)) \
-   MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, f, am, rm, d, r, w); \
-} while (0)
-
-#define MMIO_RING_D(prefix, d) \
-   MMIO_RING_F(prefix, 4, 0, 0, 0, d, NULL, NULL)
-
-#define MMIO_RING_DFH(prefix, d, f, r, w) \
-   MMIO_RING_F(prefix, 4, f, 0, 0, d, r, w)
-
-#define MMIO_RING_GM(prefix, d, r, w) \
-   MMIO_RING_F(prefix, 4, F_GMADR, 0x, 0, d, r, w)
-
-#define MMIO_RING_GM_RDR(prefix, d, r, w) \
-   MMIO_RING_F(prefix, 4, F_GMADR | F_CMD_ACCESS, 0x, 0, d, r, w)
-
-#define MMIO_RING_RO(prefix, d, f, rm, r, w) \
-   MMIO_RING_F(prefix, 4, F_RO | f, 0, rm, d, r, w)
-
-static int init_generic_mmio_info(struct intel_gvt *gvt)
-{
-   struct drm_i915_private *dev_priv = gvt->gt->i915;
-   int ret;
-
-   MMIO_RING_DFH(RING_IMR, D_ALL, 0, NULL,
-   intel_vgpu_reg_imr_handler);
-
-   MMIO_DFH(SDEIMR, D_ALL, 0, NULL, intel_vgpu_reg_imr_handler);
-   MMIO_DFH(SDEIER, D_ALL, 0, NULL, intel_vgpu_reg_ier_handler);
-   MMIO_DFH(SDEIIR, D_ALL, 0, NULL, intel_vgpu_reg_iir_handler);
-   MMIO_D(SDEISR, D_ALL);
-
-   MMIO_RING_DFH(RING_HWSTAM, D_ALL, 0, NULL, NULL);
-
-
-   MMIO_DH(GEN8_GAMW_ECO_DEV_RW_IA, D_BDW_PLUS, NULL,
-   gamw_echo_dev_rw_ia_write);
-
-   MMIO_GM_RDR(BSD_HWS_PGA_GEN7, D_ALL, NULL, NULL);
-   MMIO_GM_RDR(BLT_HWS_PGA_GEN7, D_ALL, NULL, NULL);
-   MMIO_GM_RDR(VEBOX_HWS_PGA_GEN7, D_ALL, NULL, NULL);
-
-#define RING_REG(base) _MMIO((base) + 0x28)
-   MMIO_RING_DFH(RING_REG, D_ALL, F_CMD_ACCESS, NULL, NULL);
-#undef RING_REG
-
-#define RING_REG(base) _MMIO((base) + 0x134)
-   MMIO_RING_DFH(RING_REG, D_ALL, F_CMD_ACCESS, NULL, NULL);
-#undef RING_REG
-
-#define RING_REG(base) _MMIO((base) + 0x6c)
-   MMIO_RING_DFH(RING_REG, D_ALL, 0, mmio_read_from_hw, NULL);
-#undef RING_REG
-   MMIO_DH(GEN7_SC_INSTDONE, D_BDW_PLUS, mmio_read_from_hw, NULL);
-
-   MMIO_GM_RDR(_MMIO(0x2148), D_ALL, NULL, NULL);
-   MMIO_GM_RDR(CCID(RENDER_RING_BASE), D_ALL, NULL, NULL);
-   MMIO_GM_RDR(_MMIO(0x12198), D_ALL, NULL, NULL);
-   MMIO_D(GEN7_CXT_SIZE, D_ALL);
-
-   MMIO_RING_DFH(RING_TAIL, D_ALL, 0, NULL, NULL);
-   MMIO_RING_DFH(RING_HEAD, D_ALL, 0, NULL, NULL);
-

[Intel-gfx] [PATCH 3/3] i915/gvt: Use the initial HW state snapshot saved in i915

[Zhi Wang]

From: Zhi Wang 

The code of saving initial HW state snapshot has been moved into i915.
Let the GVT-g core logic use that snapshot.

Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Christoph Hellwig 
Cc: Jason Gunthorpe 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/gvt/cfg_space.c |  2 +-
 drivers/gpu/drm/i915/gvt/firmware.c  | 45 
 drivers/gpu/drm/i915/gvt/gvt.h   |  2 --
 drivers/gpu/drm/i915/gvt/mmio.c  |  2 +-
 4 files changed, 7 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index b490e3db2e38..51588ca95113 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -379,7 +379,7 @@ void intel_vgpu_init_cfg_space(struct intel_vgpu *vgpu,
u16 *gmch_ctl;
u8 next;
 
-   memcpy(vgpu_cfg_space(vgpu), gvt->firmware.cfg_space,
+   memcpy(vgpu_cfg_space(vgpu), gvt->hw_state.cfg_space,
   info->cfg_space_size);
 
if (!primary) {
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 1a8274a3f4b1..a98af544abca 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -66,13 +66,6 @@ static struct bin_attribute firmware_attr = {
.mmap = NULL,
 };
 
-static int mmio_snapshot_handler(struct intel_gvt *gvt, u32 offset, void *data)
-{
-   *(u32 *)(data + offset) = intel_uncore_read_notrace(gvt->gt->uncore,
-   _MMIO(offset));
-   return 0;
-}
-
 static int expose_firmware_sysfs(struct intel_gvt *gvt)
 {
struct intel_gvt_device_info *info = &gvt->device_info;
@@ -81,7 +74,7 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
void *firmware;
void *p;
unsigned long size, crc32_start;
-   int i, ret;
+   int ret;
 
size = sizeof(*h) + info->mmio_size + info->cfg_space_size;
firmware = vzalloc(size);
@@ -99,17 +92,11 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
 
p = firmware + h->cfg_space_offset;
 
-   for (i = 0; i < h->cfg_space_size; i += 4)
-   pci_read_config_dword(pdev, i, p + i);
-
-   memcpy(gvt->firmware.cfg_space, p, info->cfg_space_size);
+   memcpy(gvt->hw_state.cfg_space, p, info->cfg_space_size);
 
p = firmware + h->mmio_offset;
 
-   /* Take a snapshot of hw mmio registers. */
-   intel_gvt_for_each_tracked_mmio(gvt, mmio_snapshot_handler, p);
-
-   memcpy(gvt->firmware.mmio, p, info->mmio_size);
+   memcpy(gvt->hw_state.mmio, p, info->mmio_size);
 
crc32_start = offsetof(struct gvt_firmware_header, crc32) + 4;
h->crc32 = crc32_le(0, firmware + crc32_start, size - crc32_start);
@@ -142,9 +129,6 @@ void intel_gvt_free_firmware(struct intel_gvt *gvt)
 {
if (!gvt->firmware.firmware_loaded)
clean_firmware_sysfs(gvt);
-
-   kfree(gvt->firmware.cfg_space);
-   vfree(gvt->firmware.mmio);
 }
 
 static int verify_firmware(struct intel_gvt *gvt,
@@ -204,36 +188,17 @@ static int verify_firmware(struct intel_gvt *gvt,
  */
 int intel_gvt_load_firmware(struct intel_gvt *gvt)
 {
-   struct intel_gvt_device_info *info = &gvt->device_info;
struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct intel_gvt_firmware *firmware = &gvt->firmware;
struct gvt_firmware_header *h;
const struct firmware *fw;
char *path;
-   void *mem;
int ret;
 
path = kmalloc(PATH_MAX, GFP_KERNEL);
if (!path)
return -ENOMEM;
 
-   mem = kmalloc(info->cfg_space_size, GFP_KERNEL);
-   if (!mem) {
-   kfree(path);
-   return -ENOMEM;
-   }
-
-   firmware->cfg_space = mem;
-
-   mem = vmalloc(info->mmio_size);
-   if (!mem) {
-   kfree(path);
-   kfree(firmware->cfg_space);
-   return -ENOMEM;
-   }
-
-   firmware->mmio = mem;
-
sprintf(path, "%s/vid_0x%04x_did_0x%04x_rid_0x%02x.golden_hw_state",
 GVT_FIRMWARE_PATH, pdev->vendor, pdev->device,
 pdev->revision);
@@ -256,9 +221,9 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt)
 
h = (struct gvt_firmware_header *)fw->data;
 
-   memcpy(firmware->cfg_space, fw->data + h->cfg_space_offset,
+   memcpy(gvt->hw_state.cfg_space, fw->data + h->cfg_space_offset,
   h->cfg_space_size);
-   memcpy(firmware->mmio, fw->data + h->mmio_offset,
+   memcpy(gvt->hw_state.mmio, fw->data + h->mmio_offset,
   h->mmio_size);
 
release_firmware(fw);
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 1defee730cf3..4e2fd564abea 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -280,8 +280,6 @@ struct intel_gvt_mmio {
 

Re: [Intel-gfx] [PATCH] Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"

[Jani Nikula]

On Tue, 09 Nov 2021, Vandita Kulkarni  wrote:
> This reverts commit 991d9557b0c457fb92bc49ddde24a7d9ce6144a8.
> The Bspec was updated recently with the pll ungate sequence
> similar to that of icl dsi enable sequence.
> Hence reverting.
>
> Bspec:49187

Please add a space after : in the Bspec tag, and please add a Fixes: tag
while applying.

>
> Signed-off-by: Vandita Kulkarni 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 2337c0b54586..edc38fbd2545 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -698,10 +698,7 @@ static void gen11_dsi_map_pll(struct intel_encoder 
> *encoder,
>   intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
>  
>   for_each_dsi_phy(phy, intel_dsi->phys) {
> - if (DISPLAY_VER(dev_priv) >= 12)
> - val |= ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> - else
> - val &= ~ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> + val &= ~ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
>   }
>   intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
>  
> @@ -1137,8 +1134,6 @@ static void
>  gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state)
>  {
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> -
>   /* step 4a: power up all lanes of the DDI used by DSI */
>   gen11_dsi_power_up_lanes(encoder);
>  
> @@ -1164,8 +1159,7 @@ gen11_dsi_enable_port_and_phy(struct intel_encoder 
> *encoder,
>   gen11_dsi_configure_transcoder(encoder, crtc_state);
>  
>   /* Step 4l: Gate DDI clocks */
> - if (DISPLAY_VER(dev_priv) == 11)
> - gen11_dsi_gate_clocks(encoder);
> + gen11_dsi_gate_clocks(encoder);
>  }
>  
>  static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use per device iommu check

[Patchwork]

== Series Details ==

Series: drm/i915: Use per device iommu check
URL   : https://patchwork.freedesktop.org/series/96715/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10857 -> Patchwork_21546


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 34)
--

  Additional (2): fi-tgl-u2 fi-pnv-d510 
  Missing(3): fi-ctg-p8600 bat-dg1-6 bat-adlp-4 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@kms_chamelium@dp-hpd-fast:
- fi-tgl-u2:  NOTRUN -> [SKIP][6] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-u2:  NOTRUN -> [SKIP][7] ([i915#4103]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-u2:  NOTRUN -> [SKIP][8] ([fdo#109285])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +53 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/fi-pnv-d510/igt@prime_v...@basic-userptr.html
- fi-tgl-u2:  NOTRUN -> [SKIP][10] ([i915#3301])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/fi-tgl-u2/igt@prime_v...@basic-userptr.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103


Build changes
-

  * Linux: CI_DRM_10857 -> Patchwork_21546

  CI-20190529: 20190529
  CI_DRM_10857: 2f005a829cd05b317c5b497a6941b88d981d22e6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6275: 6d172a5cf515f2780e2837860d613db5067f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21546: 4fa0c25ec337523add2859b0cedb0ec78c1831f2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

4fa0c25ec337 drm/i915: Use per device iommu check

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj()

[Patchwork]

== Series Details ==

Series: drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj()
URL   : https://patchwork.freedesktop.org/series/96712/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10857_full -> Patchwork_21544_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_sseu@full-enable:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-skl3/igt@i915_pm_s...@full-enable.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-skl1/igt@i915_pm_s...@full-enable.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-iclb2/igt@feature_discov...@psr2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-iclb1/igt@feature_discov...@psr2.html

  * igt@gem_create@create-massive:
- shard-kbl:  NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-kbl7/igt@gem_cre...@create-massive.html
- shard-skl:  NOTRUN -> [DMESG-WARN][6] ([i915#3002])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-skl9/igt@gem_cre...@create-massive.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  NOTRUN -> [FAIL][7] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-kbl7/igt@gem_exec_f...@basic-deadline.html
- shard-skl:  NOTRUN -> [FAIL][8] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-skl9/igt@gem_exec_f...@basic-deadline.html

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

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-tglb6/igt@gem_exec_fair@basic-p...@bcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-tglb3/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-iclb4/igt@gem_exec_fair@basic-p...@vecs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-iclb2/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_whisper@basic-fds-forked:
- shard-glk:  [PASS][16] -> [DMESG-WARN][17] ([i915#118]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-glk9/igt@gem_exec_whis...@basic-fds-forked.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-glk2/igt@gem_exec_whis...@basic-fds-forked.html

  * igt@gem_pxp@regular-baseline-src-copy-readible:
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#4270]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-tglb3/igt@gem_...@regular-baseline-src-copy-readible.html

  * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#768])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-iclb6/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#3323])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21544/shard-iclb6/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen9_exec_parse@allowed-all:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#2856])

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] i915/gvt: seperate tracked MMIO table from handlers.c

[Patchwork]

== Series Details ==

Series: series starting with [1/3] i915/gvt: seperate tracked MMIO table from 
handlers.c
URL   : https://patchwork.freedesktop.org/series/96704/
State : failure

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Skip error capture when wedged on init

[Patchwork]

== Series Details ==

Series: drm/i915: Skip error capture when wedged on init
URL   : https://patchwork.freedesktop.org/series/96718/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10857 -> Patchwork_21547


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_21547 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_21547, 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_21547/index.html

Participating hosts (35 -> 33)
--

  Additional (1): fi-icl-u2 
  Missing(3): fi-ctg-p8600 bat-dg1-6 bat-adlp-4 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hugepages:
- fi-rkl-guc: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/fi-rkl-guc/igt@i915_selftest@l...@hugepages.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21547/fi-rkl-guc/igt@i915_selftest@l...@hugepages.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([fdo#109315]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21547/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

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

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

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

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21547/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([fdo#109278]) +2 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21547/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2:  NOTRUN -> [SKIP][11] ([fdo#109285])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21547/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  NOTRUN -> [SKIP][12] ([i915#3301])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21547/fi-icl-u2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [DMESG-WARN][13] ([i915#4269]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21547/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][15] ([i915#295]) -> [PASS][16] +12 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21547/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

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

  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues

[Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"
URL   : https://patchwork.freedesktop.org/series/96714/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10857_full -> Patchwork_21545_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_schedule@wide@rcs0:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-skl10/igt@gem_exec_schedule@w...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-skl9/igt@gem_exec_schedule@w...@rcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-iclb2/igt@feature_discov...@psr2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-iclb6/igt@feature_discov...@psr2.html

  * igt@gem_create@create-massive:
- shard-kbl:  NOTRUN -> [DMESG-WARN][5] ([i915#3002]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-kbl6/igt@gem_cre...@create-massive.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-tglb5/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-tglb3/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-iclb3/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-iclb6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  NOTRUN -> [FAIL][10] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-kbl6/igt@gem_exec_f...@basic-deadline.html
- shard-skl:  NOTRUN -> [FAIL][11] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-skl6/igt@gem_exec_f...@basic-deadline.html

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

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-kbl6/igt@gem_exec_fair@basic-none-...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-tglb6/igt@gem_exec_fair@basic-p...@bcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-tglb8/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-iclb4/igt@gem_exec_fair@basic-p...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-iclb4/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_pxp@regular-baseline-src-copy-readible:
- shard-tglb: NOTRUN -> [SKIP][19] ([i915#4270]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-tglb1/igt@gem_...@regular-baseline-src-copy-readible.html

  * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#768])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/shard-iclb7/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#3323])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21545/

[Intel-gfx] ✓ Fi.CI.IGT: success for Some fixes in HDMI2.1 PCON FRL configuration (rev2)

[Patchwork]

== Series Details ==

Series: Some fixes in HDMI2.1 PCON FRL configuration (rev2)
URL   : https://patchwork.freedesktop.org/series/96411/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10853_full -> Patchwork_21531_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-apl:  ([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], [FAIL][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], [PASS][50]) ([i915#4386])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl8/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl8/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl8/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl4/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl4/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10853/shard-apl1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl6/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl6/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl1/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl1/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl1/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl1/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl2/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl2/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl2/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl3/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl7/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl3/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl3/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl3/boot.html
   [43]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/shard-apl4/boot.html
   [44]: 
https://intel-gfx-ci.01.org/t

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Some fixes in HDMI2.1 PCON FRL configuration (rev2)

[Vudum, Lakshminarayana]

Filed this issue and re-reported.
https://gitlab.freedesktop.org/drm/intel/-/issues/4477
igt@gem_exec_endless@dispatch@vcs1 - incomplete - Per-test timeout exceeded. 
Killing the current test with SIGQUIT. RIP: 0010:cpuidle_enter_state

Thanks,
Lakshmi.

From: Nautiyal, Ankit K 
Sent: Tuesday, November 9, 2021 4:57 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 

Subject: RE: ✗ Fi.CI.IGT: failure for Some fixes in HDMI2.1 PCON FRL 
configuration (rev2)

Hi Lakshmi,

Seems like the below issue:

  *   igt@gem_exec_endless@dispatch@vcs1:
 *   shard-tglb: 
PASS
 -> 
INCOMPLETE
is a known issue https://gitlab.freedesktop.org/drm/intel/-/issues/3778
Recently seen : 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10854/shard-tglb8/igt@gem_exec_endless@dispa...@vecs0.html

Regards,
Ankit

From: Patchwork 
mailto:patchw...@emeril.freedesktop.org>>
Sent: Monday, November 8, 2021 2:26 PM
To: Nautiyal, Ankit K 
mailto:ankit.k.nauti...@intel.com>>
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for Some fixes in HDMI2.1 PCON FRL configuration 
(rev2)

Patch Details
Series:

Some fixes in HDMI2.1 PCON FRL configuration (rev2)

URL:

https://patchwork.freedesktop.org/series/96411/

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21531/index.html

CI Bug Log - changes from CI_DRM_10853_full -> Patchwork_21531_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_21531_full absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21531_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Participating hosts (11 -> 11)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_exec_endless@dispatch@vcs1:
 *   shard-tglb: 
PASS
 -> 
INCOMPLETE

Suppressed

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

  *   igt@kms_mmap_write_crc@main:
 *   {shard-rkl}: NOTRUN -> 
SKIP

Known issues

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

CI changes
Issues hit

  *   boot:
 *   shard-apl: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use per device iommu check

[Patchwork]

== Series Details ==

Series: drm/i915: Use per device iommu check
URL   : https://patchwork.freedesktop.org/series/96715/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10857_full -> Patchwork_21546_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-snb:  ([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], [FAIL][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], [PASS][50]) ([i915#4338])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb7/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb7/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb7/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb6/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb6/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb4/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb2/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10857/shard-snb2/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb7/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb7/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb6/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb5/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb5/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb5/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb5/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb5/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb4/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb4/boot.html
   [43]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21546/shard-snb4/boot.html
   [44]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Pat

Re: [Intel-gfx] [PATCH] drm/i915: Use per device iommu check

[Lucas De Marchi]

On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
and probe presence of iommu domain per device to accurately reflect its
status.


nice, I was just starting to look into thus but for another reason: we
are adding support for other archs, like aarch64, and the global from here
was a problem

should we change drivers/gpu/drm/i915/Kconfig.debug to stop selecting
CONFIG_INTEL_IOMMU and CONFIG_INTEL_IOMMU_DEFAULT_ON?


thanks
Lucas De Marchi

Re: [Intel-gfx] [PATCH] drm/i915: Use per device iommu check

[Tvrtko Ursulin]

On 09/11/2021 17:19, Lucas De Marchi wrote:

On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
and probe presence of iommu domain per device to accurately reflect its
status.


nice, I was just starting to look into thus but for another reason: we
are adding support for other archs, like aarch64, and the global from here
was a problem


Yes I realized the other iommu angle as well. To do this properly we 
need to sort the intel_vtd_active call sites into at least two buckets - 
which are truly about VT-d and which are just IOMMU.


For instance the THP decision in i915_gemfs.co would be "are we behind 
any iommu". Some other call sites are possibly only about the bugs in 
the igfx iommu. Not sure if there is a third bucket for any potential 
differences between igfx iommu and other Intel iommu in case of dgfx.


I'd like to hear from Baolu as well to confirm if intel_iommu driver is 
handling igfx + dgfx correctly in respect to the two global variables I 
mention in the commit message.



should we change drivers/gpu/drm/i915/Kconfig.debug to stop selecting
CONFIG_INTEL_IOMMU and CONFIG_INTEL_IOMMU_DEFAULT_ON?


Don't know. For debug it is useful since it can catch more issues but 
whether or not kconfig can be improved to select the right one for the 
platform? I guess select X if X86, select Y if Z?


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH] drm/i915/psr: Fix PSR2 handling of multiplanar format

[Souza, Jose]

On Tue, 2021-11-09 at 10:31 +, Hogander, Jouni wrote:
> On Mon, 2021-11-08 at 13:38 -0800, José Roberto de Souza wrote:
> > When a plane with a multiplanar format is added to the state by
> > drm_atomic_add_affected_planes(), only the UV plane is
> > added, so a intel_atomic_get_new_plane_state() call to get the Y
> > plane state can return a null pointer.
> 
> I don't understand how this could happen only sometimes? Were you able
> to reproduce this somehow?

here a example:
plane 0 - primary plane with nv12 format
plane 1 - overlay with any format
plane 2 - primary slave

userspace does a flip to overlay, so state do not have the primary plane
but the primary and overlay planes overlap, so the primary is added by 
drm_atomic_add_affected_planes()...

> 
> Generally: checking linked_new_plane_state being valid pointer makes
> sense. I'm just wondering how and when this could happen and how that
> should be handled.
> 
> > To fix this, intel_atomic_get_plane_state() should be called and
> > the return needs to be checked for errors, as it could return a
> > EAGAIN
> > as other atomic state could be holding the lock for the Y plane.
> > 
> > Other issue with the patch being fixed is that the Y plane is not
> > being committed to hardware because the corresponded plane bit is not
> > set in update_planes when UV and Y planes are added to the state by
> > drm_atomic_add_affected_planes().
> 
> To my understanding this one is already set in
> intel_display.c:icl_check_nv12_planes.

primary plane will be added after this was executed.

> 
> > 
> > Cc: Jouni Högander 
> > Cc: Mika Kahola 
> > Fixes: 3809991ff5f4 ("drm/i915/display: Add initial selective fetch
> > support for biplanar formats")
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 9d589d471e335..a1a663f362e7d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1732,13 +1732,17 @@ int intel_psr2_sel_fetch_update(struct
> > intel_atomic_state *state,
> >* same area for Y plane as well.
> >*/
> >   if (linked) {
> > - struct intel_plane_state
> > *linked_new_plane_state =
> > -   intel_atomic_get_new_plane_state(state,
> > linked);
> > - struct drm_rect *linked_sel_fetch_area =
> > -   &linked_new_plane_state->psr2_sel_fetch_area;
> > + struct intel_plane_state
> > *linked_new_plane_state;
> > + struct drm_rect *linked_sel_fetch_area;
> > 
> > + linked_new_plane_state =
> > intel_atomic_get_plane_state(state, linked);
> > + if (IS_ERR(linked_new_plane_state))
> > + return PTR_ERR(linked_new_plane_state);
> > +
> > + linked_sel_fetch_area =
> > &linked_new_plane_state->psr2_sel_fetch_area;
> >   linked_sel_fetch_area->y1 = sel_fetch_area->y1;
> >   linked_sel_fetch_area->y2 = sel_fetch_area->y2;
> > + crtc_state->update_planes |= BIT(linked->id);
> >   }
> >   }
> > 
> 

Re: [Intel-gfx] [PATCH v3] drm/i915/display: Exit PSR when doing async flips

[Souza, Jose]

On Fri, 2021-11-05 at 19:55 +0200, Ville Syrjälä wrote:
> On Fri, Nov 05, 2021 at 05:44:21PM +, Souza, Jose wrote:
> > On Fri, 2021-11-05 at 15:46 +0200, Ville Syrjälä wrote:
> > > On Thu, Nov 04, 2021 at 05:56:52PM +, Souza, Jose wrote:
> > > > On Thu, 2021-11-04 at 16:10 +0200, Ville Syrjälä wrote:
> > > > > On Tue, Nov 02, 2021 at 12:32:14PM -0700, José Roberto de Souza wrote:
> > > > > > Changing the buffer in the middle of the scanout then entering an
> > > > > > period of flip idleness will cause part of the previous buffer being
> > > > > > diplayed to user when PSR is enabled.
> > > > > > 
> > > > > > So here disabling PSR and scheduling activation during the next
> > > > > > sync flip.
> > > > > > 
> > > > > > The async flip check that we had in PSR compute is not executed at
> > > > > > every flip so it was not doing anything useful and is also being
> > > > > > dropped here.
> > > > > > 
> > > > > > v2:
> > > > > > - scheduling the PSR work in _intel_psr_post_plane_update()
> > > > > > 
> > > > > > v3:
> > > > > > - only re enabling PSR when doing a sync flip
> > > > > > 
> > > > > > Cc: Karthik B S 
> > > > > > Cc: Vandita Kulkarni 
> > > > > > Cc: Ville Syrjälä 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Signed-off-by: José Roberto de Souza 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/display/intel_psr.c | 37 
> > > > > > ++--
> > > > > >  1 file changed, 21 insertions(+), 16 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > > > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > index 9d589d471e335..b8fac53d57df1 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > @@ -731,12 +731,6 @@ static bool 
> > > > > > intel_psr2_sel_fetch_config_valid(struct intel_dp *intel_dp,
> > > > > > return false;
> > > > > > }
> > > > > >  
> > > > > > -   if (crtc_state->uapi.async_flip) {
> > > > > > -   drm_dbg_kms(&dev_priv->drm,
> > > > > > -   "PSR2 sel fetch not enabled, async flip 
> > > > > > enabled\n");
> > > > > > -   return false;
> > > > > > -   }
> > > > > > -
> > > > > > /* Wa_14010254185 Wa_14010103792 */
> > > > > > if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
> > > > > > drm_dbg_kms(&dev_priv->drm,
> > > > > > @@ -1780,36 +1774,47 @@ void intel_psr_pre_plane_update(struct 
> > > > > > intel_atomic_state *state,
> > > > > > if (psr->enabled && needs_to_disable)
> > > > > > intel_psr_disable_locked(intel_dp);
> > > > > >  
> > > > > > +   if (psr->enabled && crtc_state->uapi.async_flip)
> > > > > > +   intel_psr_exit(intel_dp);
> > > > > > +
> > > > > > mutex_unlock(&psr->lock);
> > > > > > }
> > > > > >  }
> > > > > >  
> > > > > >  static void _intel_psr_post_plane_update(const struct 
> > > > > > intel_atomic_state *state,
> > > > > > -const struct intel_crtc_state 
> > > > > > *crtc_state)
> > > > > > +const struct intel_crtc_state 
> > > > > > *old_crtc_state,
> > > > > > +const struct intel_crtc_state 
> > > > > > *new_crtc_state)
> > > > > 
> > > > > Might make sense to change this to match how psr_pre_plane_update()
> > > > > works these days.
> > > > 
> > > > Will do as follow up.
> > > > 
> > > > > 
> > > > > >  {
> > > > > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > > > > struct intel_encoder *encoder;
> > > > > >  
> > > > > > -   if (!crtc_state->has_psr)
> > > > > > +   if (!new_crtc_state->has_psr)
> > > > > > return;
> > > > > >  
> > > > > > for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> > > > > > -
> > > > > > crtc_state->uapi.encoder_mask) {
> > > > > > +
> > > > > > new_crtc_state->uapi.encoder_mask) {
> > > > > > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > > > struct intel_psr *psr = &intel_dp->psr;
> > > > > >  
> > > > > > mutex_lock(&psr->lock);
> > > > > >  
> > > > > > -   drm_WARN_ON(&dev_priv->drm, psr->enabled && 
> > > > > > !crtc_state->active_planes);
> > > > > > +   drm_WARN_ON(&dev_priv->drm, psr->enabled &&
> > > > > > +   !new_crtc_state->active_planes);
> > > > > >  
> > > > > > /* Only enable if there is active planes */
> > > > > > -   if (!psr->enabled && crtc_state->active_planes)
> > > > > > -   intel_psr_enable_locked(intel_dp, crtc_state);
> > > > > > +   if (!psr->enabled && new_crtc_state->active_planes)
> > > > > > +   intel_psr_enable_locked(intel_dp, 
> > > > > > new_crtc_state);
> > > > > 
> > > > > What prevents this guy from 

Re: [Intel-gfx] [PATCH V2] drm/i915/gt: Hold RPM wakelock during PXP suspend

[Daniele Ceraolo Spurio]

On 11/8/2021 10:32 PM, Jani Nikula wrote:

On Tue, 09 Nov 2021, "Surendrakumar Upadhyay, TejaskumarX"
 wrote:

-Original Message-
From: Jani Nikula 
Sent: 09 November 2021 00:37
To: Surendrakumar Upadhyay, TejaskumarX
; intel-
g...@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH V2] drm/i915/gt: Hold RPM wakelock during
PXP suspend

On Mon, 08 Nov 2021, Tejas Upadhyay
 wrote:

selftest --r live shows failure in suspend tests when RPM wakelock is
not acquired during suspend.

This changes addresses below error :
<4> [154.177535] RPM wakelock ref not held during HW access <4>
[154.177575] WARNING: CPU: 4 PID: 5772 at
drivers/gpu/drm/i915/intel_runtime_pm.h:113
fwtable_write32+0x240/0x320 [i915]
<4> [154.177974] Modules linked in: i915(+) vgem drm_shmem_helper fuse
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
ledtrig_audio mei_hdcp mei_pxp x86_pkg_temp_thermal coretemp
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_intel_dspcfg
snd_hda_codec snd_hwdep igc snd_hda_core ttm mei_me ptp snd_pcm
prime_numbers mei i2c_i801 pps_core i2c_smbus intel_lpss_pci btusb
btrtl btbcm btintel bluetooth ecdh_generic ecc [last unloaded: i915]
<4> [154.178143] CPU: 4 PID: 5772 Comm: i915_selftest Tainted: G
U5.15.0-rc6-CI-Patchwork_21432+ #1
<4> [154.178154] Hardware name: ASUS System Product Name/TUF

GAMING

Z590-PLUS WIFI, BIOS 0811 04/06/2021 <4> [154.178160] RIP:
0010:fwtable_write32+0x240/0x320 [i915] <4> [154.178604] Code: 15 7b
e1 0f 0b e9 34 fe ff ff 80 3d a9 89 31
00 00 0f 85 31 fe ff ff 48 c7 c7 88 9e 4f a0 c6 05 95 89 31 00 01 e8
c0 15 7b e1 <0f> 0b e9 17 fe ff ff 8b 05 0f 83 58 e2 85 c0 0f 85 8d
00 00 00 48
<4> [154.178614] RSP: 0018:c900016279f0 EFLAGS: 00010286 <4>
[154.178626] RAX:  RBX: 888204fe0ee0
RCX: 0001
<4> [154.178634] RDX: 8001 RSI: 823142b5
RDI: 
<4> [154.178641] RBP: 000320f0 R08: 
R09: c000cd5a
<4> [154.178647] R10: 000f8c90 R11: c90001627808
R12: 
<4> [154.178654] R13: 4000 R14: a04d12e0
R15: 
<4> [154.178660] FS:  7f7390aa4c00() GS:88844f00()
knlGS:
<4> [154.178669] CS:  0010 DS:  ES:  CR0: 80050033 <4>
[154.178675] CR2: 55bc40595028 CR3: 000204474005
CR4: 00770ee0
<4> [154.178682] PKRU: 5554
<4> [154.178687] Call Trace:
<4> [154.178706]  intel_pxp_fini_hw+0x23/0x30 [i915] <4> [154.179284]
intel_pxp_suspend+0x1f/0x30 [i915] <4> [154.179807]
live_gt_resume+0x5b/0x90 [i915]

Changes since V1 :
- split the HW access parts in gt_suspend_late - Daniele
- Remove default PXP configs

Signed-off-by: Tejas Upadhyay

---
  drivers/gpu/drm/i915/gt/intel_gt_pm.c   |  7 ---
  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 15 ---
drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 18 --
  3 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index b4a8594bc46c..d4029de1c80d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -303,7 +303,7 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
user_forcewake(gt, true);
wait_for_suspend(gt);

-   intel_pxp_suspend(>->pxp, false);
+   intel_pxp_suspend_prepare(>->pxp, false);
  }

  static suspend_state_t pm_suspend_target(void) @@ -328,6 +328,7 @@
void intel_gt_suspend_late(struct intel_gt *gt)
GEM_BUG_ON(gt->awake);

intel_uc_suspend(>->uc);
+   intel_pxp_suspend(>->pxp);

/*
 * On disabling the device, we want to turn off HW access to memory
@@ -355,7 +356,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)

  void intel_gt_runtime_suspend(struct intel_gt *gt)  {
-   intel_pxp_suspend(>->pxp, true);
+   intel_pxp_runtime_suspend(>->pxp);
intel_uc_runtime_suspend(>->uc);

GT_TRACE(gt, "\n");
@@ -373,7 +374,7 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
if (ret)
return ret;

-   intel_pxp_resume(>->pxp);
+   intel_pxp_runtime_resume(>->pxp);

return 0;
  }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 23fd86de5a24..3f91996dc6be 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -7,8 +7,9 @@
  #include "intel_pxp_irq.h"
  #include "intel_pxp_pm.h"
  #include "intel_pxp_session.h"
+#include "i915_drv.h"

-void intel_pxp_suspend(struct intel_pxp *pxp, bool runtime)
+void intel_pxp_suspend_prepare(struct intel_pxp *pxp, bool runtime)
  {
if (!intel_pxp_is_enabled(pxp))
return;
@@ -23,10 +24,18 @@ void intel_pxp_suspend(struct intel_pxp *pxp, bool

runtime)

 */
if (!runtime)
intel_pxp_invalidate(pxp);
+}

-   intel_pxp_f

Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

[Ville Syrjälä]

On Tue, Nov 09, 2021 at 03:19:47PM -0500, Harry Wentland wrote:
> On 2021-11-05 08:59, Ville Syrjälä wrote:
> > On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
> >>
> >>
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> >>> planes have different capabilities, implemented respective
> >>> structure for the HDR planes.
> >>>
> >>> Signed-off-by: Uma Shankar 
> >>> ---
> >>>  drivers/gpu/drm/i915/display/intel_color.c | 52 ++
> >>>  1 file changed, 52 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> >>> b/drivers/gpu/drm/i915/display/intel_color.c
> >>> index afcb4bf3826c..6403bd74324b 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state 
> >>> *crtc_state)
> >>>   }
> >>>  }
> >>>  
> >>> + /* FIXME input bpc? */
> >>> +__maybe_unused
> >>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> >>> + /* segment 1 */
> >>> + {
> >>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>> +   DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>> +   DRM_MODE_LUT_INTERPOLATE |
> >>> +   DRM_MODE_LUT_NON_DECREASING),
> >>> + .count = 128,
> >>
> >> Is the distribution of the 128 entries uniform?
> > 
> > I guess this is the plane gamma thing despite being in intel_color.c,
> > so yeah I think that's correct.
> > 
> >> If so, is a
> >> uniform distribution of 128 points across most of the LUT
> >> good enough for HDR with 128 entries?
> > 
> > No idea how good this actually is. It is .24 so at least
> > it does have a fair bit of precision.
> > 
> 
> Precision is good but you also need enough samples. Though that's
> probably less my concern and more your concern and should become
> apparent once its used.

Yeah, for pipe gamma we have a few different variants with
non-uniform spacing of the samples. But not here AFAICS for 
whatever reason.

> 
> >>
> >>> + .input_bpc = 24, .output_bpc = 16,
> >>> + .start = 0, .end = (1 << 24) - 1,
> >>> + .min = 0, .max = (1 << 24) - 1,
> >>> + },
> >>> + /* segment 2 */
> >>> + {
> >>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>> +   DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>> +   DRM_MODE_LUT_INTERPOLATE |
> >>> +   DRM_MODE_LUT_REUSE_LAST |
> >>> +   DRM_MODE_LUT_NON_DECREASING),
> >>> + .count = 1,
> >>> + .input_bpc = 24, .output_bpc = 16,
> >>> + .start = (1 << 24) - 1, .end = 1 << 24,
> >>
> >> .start and .end are only a single entry apart. Is this correct?
> > 
> > One think I wanted to do is simplify this stuff by getting rid of
> > .end entirely. So I think this should just be '.start=1<<24' (or
> > whatever way we decide to specify the input precision, which is
> > I think another slightly open question).
> > 
> > So for this thing we could just have:
> > { .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0   },
> > { .count = 1,   .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
> > { .count = 1,   .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
> > { .count = 1,   .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
> > 
> > + flags/etc. which I left out for brevity.
> > 
> 
> Makes sense. I like this.
> 
> > So that is trying to indicate that the first 129 entries are equally
> > spaced, and would be used to interpolate for input values [0.0,1.0).
> > Input values [1.0,3.0) would interpolate between entry 128 and 129,
> > and [3.0,7.0) would interpolate between entry 129 and 130.
> > 
> 
> What in the segment definition defines the 1.0 mark? In your example
> it seems to be at (1 << 24) but then we would have values that go
> beyond the input_bpc for the last three segments.

Yes, input_bpc would define the precision of the input values (.start).
so 1.0 would be at 1< 
> How about output_bpc? Would output_bpc somehow limit the U32.32 (or
> S31.32) entries, and if so, how?

output_bpc would define the actual precision of the output values,
so again 1.0 would be 1< 
> Or should we treat input_/output_bpc only as capability reporting, so
> userspace can calculate the possible error when programming the LUT?
> Again, this leaves us with the question what the input_/output_bpc
> means for our PWL entries.

Yeah, I mostly thought they might be interesting if userspace wants
to know the exact precision. But not strictly necessary if you want
just to go generate a "close enough" curve. 

What's PWL?

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes

[Ville Syrjälä]

On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> On 2021-11-08 04:54, Pekka Paalanen wrote:
> > On Thu, 4 Nov 2021 12:27:56 -0400
> > Harry Wentland  wrote:
> > 
> >> On 2021-11-04 04:38, Pekka Paalanen wrote:
> >>> On Wed, 3 Nov 2021 11:08:13 -0400
> >>> Harry Wentland  wrote:
> >>>   
>  On 2021-09-06 17:38, Uma Shankar wrote:  
> > Existing LUT precision structure is having only 16 bit
> > precision. This is not enough for upcoming enhanced hardwares
> > and advance usecases like HDR processing. Hence added a new
> > structure with 32 bit precision values.
> >
> > This also defines a new structure to define color lut ranges,
> > along with related macro definitions and enums. This will help
> > describe multi segmented lut ranges in the hardware.
> >
> > Signed-off-by: Uma Shankar 
> > ---
> >  include/uapi/drm/drm_mode.h | 58 +
> >  1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 90c55383f1ee..1079794c86c3 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> > };
> >  };
> >  
> > +/*
> > + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> > + * can be used for either purpose, but not simultaneously. To expose
> > + * modes that support gamma and degamma simultaneously the gamma mode
> > + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> > + * ranges.
> > + */
> > +/* LUT is for gamma (after CTM) */
> > +#define DRM_MODE_LUT_GAMMA BIT(0)
> > +/* LUT is for degamma (before CTM) */
> > +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> > +/* linearly interpolate between the points */
> > +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> > +/*
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> > +/* the curve must be non-decreasing */
> > +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> > +/* the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> > +/* the same curve (red) is used for blue and green channels as well */
> > +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> > +
> > +struct drm_color_lut_range {
> > +   /* DRM_MODE_LUT_* */
> > +   __u32 flags;
> > +   /* number of points on the curve */
> > +   __u16 count;
> > +   /* input/output bits per component */
> > +   __u8 input_bpc, output_bpc;
> > +   /* input start/end values */
> > +   __s32 start, end;
> > +   /* output min/max values */
> > +   __s32 min, max;
> > +};
> > +
> > +enum lut_type {
> > +   LUT_TYPE_DEGAMMA = 0,
> > +   LUT_TYPE_GAMMA = 1,
> > +};
> > +
> > +/*
> > + * Creating 64 bit palette entries for better data
> > + * precision. This will be required for HDR and
> > + * similar color processing usecases.
> > + */
> > +struct drm_color_lut_ext {
> > +   /*
> > +* Data is U32.32 fixed point format.
> > +*/
> > +   __u64 red;
> > +   __u64 green;
> > +   __u64 blue;
> > +   __u64 reserved;
> > +};
> 
>  I've been drawing out examples of drm_color_lut_range defined PWLs
>  and understand a bit better what you and Ville are trying to accomplish
>  with it. It actually makes a lot of sense and would allow for a generic
>  way to populate different PWL definitions with a generic function.
> 
>  But I still have some key questions that either are not answered in these
>  patch sets or that I somehow overlooked.
> 
>  Can you explain how the U32.32 fixed point format relates to the 
>  input_bpc
>  and output_bpc in drm_color_lut_range, as we as to the pixel coming in 
>  from
>  the framebuffer.
> 
>  E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming 
>  alpha
>  is non-multiplied)?
> 
>  If the drm_color_lut_range segments are defined with input_bpc of 24 bpc 
>  will
>  0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would 
>  our 3xff
>  be interpreted as 0x3ff << (24-10)? 
> 
>  Assuming the output_bpc is 16 bpc and the programmed LUT makes this 
>  1-to-1 would
>  the output value be 0x3ff << (16-10)?
> 
>  On AMD HW the pipe-internal format is a custom floating point format. We 
>  could
>  probably express that in terms of input/output_bpc and do the 
>  translation in our
>  driver between that and the internal floating point format, depending on 
>  the
>  fra

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Use unlocked register accesses for LUT loads

[Ville Syrjälä]

On Mon, Nov 08, 2021 at 08:59:31PM +, Shankar, Uma wrote:
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of 
> > Ville Syrjala
> > Sent: Thursday, October 21, 2021 4:04 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Use unlocked register accesses 
> > for LUT
> > loads
> > 
> > From: Ville Syrjälä 
> > 
> > We have to bash in a lot of registers to load the higher precision LUT 
> > modes. The
> > locking overhead is significant, especially as we have to get this done as 
> > quickly as
> > possible during vblank.
> > So let's switch to unlocked accesses for these. Fortunately the LUT 
> > registers are
> > mostly spread around such that two pipes do not have any registers on the 
> > same
> > cacheline. So as long as commits on the same pipe are serialized (which 
> > they are) we
> > should get away with this without angering the hardware.
> > 
> > The only exceptions are the PREC_PIPEGCMAX registers on ilk/snb which we 
> > don't
> > use atm as they are only used in the 12bit gamma mode. If/when we add 
> > support for
> > that we may need to remember to still serialize those registers, though I'm 
> > not sure
> > ilk/snb are actually affected by the same cacheline issue. I think ivb/hsw 
> > at least
> > were, but they use a different set of registers for the precision LUT.
> > 
> > I have a test case which is updating the LUTs on two pipes from a single 
> > atomic
> > commit. Running that in a loop for a minute I get the following worst case 
> > with the
> > locks in place:
> >  intel_crtc_vblank_work_start: pipe B, frame=10037, scanline=1081
> >  intel_crtc_vblank_work_start: pipe A, frame=12274, scanline=769
> >  intel_crtc_vblank_work_end: pipe A, frame=12274, scanline=58
> >  intel_crtc_vblank_work_end: pipe B, frame=10037, scanline=74
> > 
> > And here's the worst case with the locks removed:
> >  intel_crtc_vblank_work_start: pipe B, frame=5869, scanline=1081
> >  intel_crtc_vblank_work_start: pipe A, frame=7616, scanline=769
> >  intel_crtc_vblank_work_end: pipe B, frame=5869, scanline=1096
> >  intel_crtc_vblank_work_end: pipe A, frame=7616, scanline=777
> > 
> > The test was done on a snb using the 10bit 1024 entry LUT mode.
> > The vtotals for the two displays are 793 and 1125. So we can see that with 
> > the locks
> > ripped out the LUT updates are pretty nicely confined within the vblank, 
> > whereas
> > with the locks in place we're routinely blasting past the vblank end which 
> > causes
> > visual artifacts near the top of the screen.
> 
> Unprotected writes should be ok to use in lut updates. Looks good to me.
> Reviewed-by: Uma Shankar 
> 
> One side query though, what happens when we go for higher refresh rates like 
> 300+,
> Some cases where vblank period is shrunk to as low as 8us (480Hz RR panels).

If the vblank is short enough then we're pretty much screwed and will
have to accept tearing. Maybe there's a little of bit of micro 
optimization left we could do to the .load_lut(). But I wouldn't expect
miracles from that since we still have to do the actual mmio, and that
we can't speed up.

Long ago I did have some numbers on how long each mmio access will
take on specific platforms but I don't recall the details anymore.
I guess it might be interesting to measure it again just to have
some idea on the lower bound, and then compare that to what we
currently achieve in .load_lut(). Would at least tell us if there's
any juice left in the tank.

And of course DSB might save us on new platforms since it should
be faster than mmio, but I've not done any measurements on it.
Should be interesting to find out how it performs.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj()

[Rodrigo Vivi]

On Tue, Nov 09, 2021 at 02:48:50PM +0300, Dan Carpenter wrote:
> The "ret" variable is checked on the previous line so we know it's
> zero.  No need to check again.
> 
> Signed-off-by: Dan Carpenter 

Reviewed-by: Rodrigo Vivi 

and pushed.
thanks for the patch

> ---
>  drivers/gpu/drm/i915/display/intel_fb_pin.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c 
> b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> index 3f77f3013584..3b20f69e0240 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> @@ -142,13 +142,11 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
>   if (ret)
>   goto err;
>  
> - if (!ret) {
> - vma = i915_gem_object_pin_to_display_plane(obj, &ww, alignment,
> -view, pinctl);
> - if (IS_ERR(vma)) {
> - ret = PTR_ERR(vma);
> - goto err_unpin;
> - }
> + vma = i915_gem_object_pin_to_display_plane(obj, &ww, alignment,
> +view, pinctl);
> + if (IS_ERR(vma)) {
> + ret = PTR_ERR(vma);
> + goto err_unpin;
>   }
>  
>   if (uses_fence && i915_vma_is_map_and_fenceable(vma)) {
> -- 
> 2.20.1
> 

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

[Rodrigo Vivi]

Hi Dave and Daniel,

Here goes drm-intel-next-fixes-2021-11-09:

Couple Reverts, build fix, couple virtualization fixes,
blank screen and other display rates fixes, and more.

Four patches targeting stable in here.

Display Fixes:
- DP rates related fixes (Imre, Jani)
- A Revert on disaling dual eDP that was causing state readout problems (Jani)
- put the cdclk vtables in const data (Jani)
- Fix DVO port type for moder platforms (Ville)
- Fix blankscreen by turning DP++ TMDS output buffers on encoder->shutdown 
(Ville)
- CCS FBs related fixes (Imre)

GT fixes:
- Fix recursive lock in GuC submission (Matt Brost)
- Revert guc_id from i915_request tracepoint (Joonas)
- Build fix around dmabuf (Matt Auld)

Thanks,
Rodrigo.

The following changes since commit 367fe8dc299c968eabdae890536d55d80ea55e01:

  Merge tag 'amd-drm-next-5.16-2021-10-22' of 
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-10-27 10:38:41 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2021-11-09

for you to fetch changes up to ade4a1fc5741a36b559dfbd4557dc3da1a4394af:

  drm/i915/adlp/fb: Prevent the mapping of redundant trailing padding NULL 
pages (2021-11-09 10:02:48 -0500)


Couple Reverts, build fix, couple virtualization fixes,
blank screen and other display rates fixes, and more.

Four patches targeting stable in here.

Display Fixes:
- DP rates related fixes (Imre, Jani)
- A Revert on disaling dual eDP that was causing state readout problems (Jani)
- put the cdclk vtables in const data (Jani)
- Fix DVO port type for moder platforms (Ville)
- Fix blankscreen by turning DP++ TMDS output buffers on encoder->shutdown 
(Ville)
- CCS FBs related fixes (Imre)

GT fixes:
- Fix recursive lock in GuC submission (Matt Brost)
- Revert guc_id from i915_request tracepoint (Joonas)
- Build fix around dmabuf (Matt Auld)


Imre Deak (4):
  drm/i915/dp: Ensure sink rate values are always valid
  drm/i915/dp: Ensure max link params are always valid
  drm/i915/fb: Fix rounding error in subsampled plane size calculation
  drm/i915/adlp/fb: Prevent the mapping of redundant trailing padding NULL 
pages

Jani Nikula (3):
  Revert "drm/i915/bios: gracefully disable dual eDP for now"
  drm/i915/cdclk: put the cdclk vtables in const data
  drm/i915/dp: fix integer overflow in 128b/132b data rate calculation

Joonas Lahtinen (1):
  drm/i915: Revert 'guc_id' from i915_request tracepoint

Matthew Auld (1):
  drm/i915/dmabuf: fix broken build

Matthew Brost (1):
  drm/i915/guc: Fix recursive lock in GuC submission

Ville Syrjälä (3):
  drm/i915: Extend the async flip VT-d w/a to skl/bxt
  drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern 
platforms
  drm/i915/hdmi: Turn DP++ TMDS output buffers back on in 
encoder->shutdown()

Zhi A Wang (1):
  drm/i915/gvt: fix the usage of ww lock in gvt scheduler.

 drivers/gpu/drm/i915/display/g4x_hdmi.c   |   1 +
 drivers/gpu/drm/i915/display/intel_bios.c | 132 +++---
 drivers/gpu/drm/i915/display/intel_cdclk.c|  44 
 drivers/gpu/drm/i915/display/intel_ddi.c  |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |   9 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  31 +++--
 drivers/gpu/drm/i915/display/intel_fb.c   |   4 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  16 ++-
 drivers/gpu/drm/i915/display/intel_hdmi.h |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|   7 ++
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |   3 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |   3 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |   4 +-
 drivers/gpu/drm/i915/i915_trace.h |   7 +-
 drivers/gpu/drm/i915/intel_pm.c   |  12 ++
 15 files changed, 162 insertions(+), 113 deletions(-)

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: transmit brightness command in HS state

[Tseng, William]

Thanks, Jani.  That does not restore the mode flags perfectly.  I will revise 
the patch.

Regards
William

-Original Message-
From: Jani Nikula  
Sent: Tuesday, November 9, 2021 6:41 PM
To: Tseng, William ; intel-gfx@lists.freedesktop.org
Cc: Tseng, William ; Ville Syrjala 
; Kulkarni, Vandita 
; Lee, Shawn C ; Chiou, 
Cooper 
Subject: Re: [PATCH v2] drm/i915/dsi: transmit brightness command in HS state

On Tue, 09 Nov 2021, William Tseng  wrote:
> In Video Mode, if DSI transcoder is set to transmit packets in LP 
> Escape mode, screen flickering would be obseved when brightness 
> commands are continuously and quickly transmitted to a panel.
>
> The problem may be resolved by changing the mode to transmit packets 
> from Low Power to HS.
>
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Lee Shawn C 
> Cc: Cooper Chiou 
> Signed-off-by: William Tseng 
> ---
>  drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> index f61ed82e8867..2f788cb0f597 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> @@ -81,8 +81,10 @@ static void dcs_set_backlight(const struct 
> drm_connector_state *conn_state, u32
>  
>   for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
>   dsi_device = intel_dsi->dsi_hosts[port]->device;
> + dsi_device->mode_flags &= ~MIPI_DSI_MODE_LPM;
>   mipi_dsi_dcs_write(dsi_device, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
>  &data, len);
> + dsi_device->mode_flags |= MIPI_DSI_MODE_LPM;

Ah, but this doesn't *restore* the flags, it forces MIPI_DSI_MODE_LPM!

BR,
Jani.

>   }
>  }

--
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH v3] drm/i915/dsi: transmit brightness command in HS state

[William Tseng]

In Video Mode, if DSI transcoder is set to transmit packets
in LP Escape mode, screen flickering would be obseved when
brightness commands are continuously and quickly transmitted
to a panel.

The problem may be resolved by changing the mode to transmit
packets from Low Power to HS.

Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Vandita Kulkarni 
Cc: Lee Shawn C 
Cc: Cooper Chiou 
Signed-off-by: William Tseng 
---
 drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
index f61ed82e8867..7d234429e71e 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
@@ -71,6 +71,7 @@ static void dcs_set_backlight(const struct 
drm_connector_state *conn_state, u32
u8 data[2] = {};
enum port port;
size_t len = panel->backlight.max > U8_MAX ? 2 : 1;
+   unsigned long mode_flags;
 
if (len == 1) {
data[0] = level;
@@ -81,8 +82,11 @@ static void dcs_set_backlight(const struct 
drm_connector_state *conn_state, u32
 
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
dsi_device = intel_dsi->dsi_hosts[port]->device;
+   mode_flags = dsi_device->mode_flags;
+   dsi_device->mode_flags &= ~MIPI_DSI_MODE_LPM;
mipi_dsi_dcs_write(dsi_device, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
   &data, len);
+   dsi_device->mode_flags = mode_flags;
}
 }
 
-- 
2.17.1

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: transmit brightness command in HS state (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dsi: transmit brightness command in HS state (rev3)
URL   : https://patchwork.freedesktop.org/series/96702/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10859 -> Patchwork_21549


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_21549 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_21549, 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_21549/index.html

Participating hosts (37 -> 33)
--

  Additional (1): fi-tgl-1115g4 
  Missing(5): bat-dg1-6 fi-bsw-cyan fi-icl-u2 bat-adlp-4 fi-ctg-p8600 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-cfl-8109u/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([i915#1155])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#4103]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([fdo#109285])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][10] -> [DMESG-WARN][11] ([i915#4269])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#1072]) +3 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#3301])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][15] ([i915#3303]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21549/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.

[Intel-gfx] [PATCH 0/1] drm/i915/rpm: Enable runtime pm autosuspend by default

[Tilak Tangudu]

Enable runtime pm autosuspend by default for all Gen12
and Gen12+ platforms

Tilak Tangudu (1):
  drm/i915/rpm: Enable runtime pm autosuspend by default

 drivers/gpu/drm/i915/intel_runtime_pm.c | 4 
 1 file changed, 4 insertions(+)

-- 
2.25.1

[Intel-gfx] [PATCH 1/1] drm/i915/rpm: Enable runtime pm autosuspend by default

[Tilak Tangudu]

Enable runtime pm autosuspend by default for gen12 and
later versions.

Signed-off-by: Tilak Tangudu 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index eaf7688f517d..ef75f24288ef 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -600,6 +600,10 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm)
pm_runtime_use_autosuspend(kdev);
}
 
+   /* XXX: Enable by default only for newer platforms for now */
+   if (GRAPHICS_VER(i915) >= 12)
+   pm_runtime_allow(kdev);
+
/*
 * The core calls the driver load handler with an RPM reference held.
 * We drop that here and will reacquire it during unloading in
-- 
2.25.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/rpm: Enable runtime pm autosuspend by default

[Patchwork]

== Series Details ==

Series: drm/i915/rpm: Enable runtime pm autosuspend by default
URL   : https://patchwork.freedesktop.org/series/96741/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10859 -> Patchwork_21550


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 30)
--

  Additional (1): fi-tgl-1115g4 
  Missing(8): fi-kbl-soraka fi-rkl-11600 fi-rkl-guc bat-dg1-6 fi-tgl-u2 
fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-skl-6700k2:  [PASS][1] -> [FAIL][2] ([i915#4467])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/fi-skl-6700k2/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-skl-6700k2/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [PASS][5] -> [INCOMPLETE][6] ([i915#146])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#1155])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#4103]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([fdo#109285])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][14] -> [DMESG-WARN][15] ([i915#4269])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][16] ([i915#1072]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][17] ([i915#3301])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][18] ([i915#3303]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][20] ([fdo#109271]) -> [FAIL][21] ([i915#3049])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/fi-kbl-guc/igt@i915_pm_...@basic-rte.html

  
  {name}: This element is suppressed. This means it

Re: [Intel-gfx] [PATCH] drm/i915: Use per device iommu check

[Lu Baolu]

Hi Tvrtko,

On 2021/11/9 20:17, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin

On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
and probe presence of iommu domain per device to accurately reflect its
status.

Signed-off-by: Tvrtko Ursulin
Cc: Lu Baolu
---
Baolu, is my understanding here correct? Maybe I am confused by both
intel_iommu_gfx_mapped and dmar_map_gfx being globals in the intel_iommu
driver. But it certainly appears the setup can assign some iommu ops (and
assign the discrete i915 to iommu group) when those two are set to off.


diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index e967cd08f23e..9fb38a54f1fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1763,26 +1763,27 @@ static inline bool run_as_guest(void)
 #define HAS_D12_PLANE_MINIMIZATION(dev_priv) (IS_ROCKETLAKE(dev_priv) || \
  IS_ALDERLAKE_S(dev_priv))

-static inline bool intel_vtd_active(void)
+static inline bool intel_vtd_active(struct drm_i915_private *i915)
 {
-#ifdef CONFIG_INTEL_IOMMU
-   if (intel_iommu_gfx_mapped)
+   if (iommu_get_domain_for_dev(i915->drm.dev))
return true;
-#endif

/* Running as a guest, we assume the host is enforcing VT'd */
return run_as_guest();
 }

Have you verified this change? I am afraid that
iommu_get_domain_for_dev() always gets a valid iommu domain even
intel_iommu_gfx_mapped == 0.

A possible way could look like this:

static bool intel_vtd_active(struct drm_i915_private *i915)
{
struct iommu_domain *domain;

domain = iommu_get_domain_for_dev(i915->drm.dev);

if (domain && (domain->type & __IOMMU_DOMAIN_PAGING))
return true;

... ...
}

Actually I don't like this either since it checks the domain->type out
of the iommu subsystem. We could refactor this later by export an iommu
interface for this check.

Best regards,
baolu

Re: [Intel-gfx] [PATCH] drm/i915: Use per device iommu check

[Lu Baolu]

On 2021/11/10 1:35, Tvrtko Ursulin wrote:


On 09/11/2021 17:19, Lucas De Marchi wrote:

On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
and probe presence of iommu domain per device to accurately reflect its
status.


nice, I was just starting to look into thus but for another reason: we
are adding support for other archs, like aarch64, and the global from 
here

was a problem


Yes I realized the other iommu angle as well. To do this properly we 
need to sort the intel_vtd_active call sites into at least two buckets - 
which are truly about VT-d and which are just IOMMU.


For instance the THP decision in i915_gemfs.co would be "are we behind 
any iommu". Some other call sites are possibly only about the bugs in 
the igfx iommu. Not sure if there is a third bucket for any potential 
differences between igfx iommu and other Intel iommu in case of dgfx.


I'd like to hear from Baolu as well to confirm if intel_iommu driver is 
handling igfx + dgfx correctly in respect to the two global variables I 
mention in the commit message.


I strongly agree that the drivers should call the IOMMU interface
directly for portability. For Intel graphic driver, we have two issues:

#1) driver asks vt-d driver for identity map with intel_iommu=igfx_off.
#2) driver query the status with a global intel_iommu_gfx_mapped.

We need to solve these two problems step by step. This patch is
definitely a good start point.

Best regards,
baolu

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/rpm: Enable runtime pm autosuspend by default

[Patchwork]

== Series Details ==

Series: drm/i915/rpm: Enable runtime pm autosuspend by default
URL   : https://patchwork.freedesktop.org/series/96741/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10859_full -> Patchwork_21550_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([i915#456]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/shard-tglb5/igt@gem_ctx_isolation@preservation...@bcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-tglb7/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][3] -> [FAIL][4] ([i915#2842])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-apl:  [PASS][5] -> [SKIP][6] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/shard-apl7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-glk9/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/shard-kbl3/igt@gem_exec_fair@basic-n...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-kbl4/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_params@no-vebox:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271]) +61 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-skl3/igt@gem_exec_par...@no-vebox.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/shard-tglb5/igt@gem_huc_c...@huc-copy.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-tglb7/igt@gem_huc_c...@huc-copy.html
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-skl6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][17] ([i915#2658])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-skl6/igt@gem_pr...@exhaustion.html

  * igt@gem_pxp@regular-baseline-src-copy-readible:
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#4270]) +3 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-tglb2/igt@gem_...@regular-baseline-src-copy-readible.html

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

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

  * igt@gen7_exec_parse@cmd-crossing-page:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109289])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21550/shard-tglb3/igt@gen7_exec_pa...@cmd-crossing-page.html

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

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][23] -> [DMESG-WARN][24] ([i915#1436] / 
[i915#716])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10859/shard-skl10/igt@gen9_exec_

[Intel-gfx] [PATCH v3 0/2] Some fixes in HDMI2.1 PCON FRL configuration

[Ankit Nautiyal]

Some optimizations in HDMI2.1 PCON configuration and avoiding
resetting the config DPCD.
v2: Addressed comments from Uma.
v3: Rebased.

Ankit Nautiyal (2):
  drm/i915/dp: Optimize the FRL configuration for HDMI2.1 PCON
  drm/i915/dp: For PCON TMDS mode set only the relavant bits in config
DPCD

 drivers/gpu/drm/i915/display/intel_dp.c | 61 +++--
 1 file changed, 46 insertions(+), 15 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v3 1/2] drm/i915/dp: Optimize the FRL configuration for HDMI2.1 PCON

[Ankit Nautiyal]

Currently the HDMI2.1 PCON's frl link config DPCD registers are
reset and configured even if they are already configured.
Also the HDMI Link Mode does not settle to FRL MODE immediately after
HDMI Link Status is active.

This patch:
-Checks if the PCON is already configured for FRL.
-Include HDMI Link Mode in wait for loop along with HDMI Link status DPCD.

v2: Rebase

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 37 +++--
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 45373c213d9e..020c357348b2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2198,6 +2198,18 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp 
*intel_dp)
return max_frl_rate;
 }
 
+static bool
+intel_dp_pcon_is_frl_trained(struct intel_dp *intel_dp,
+u8 max_frl_bw_mask, u8 *frl_trained_mask)
+{
+   if (drm_dp_pcon_hdmi_link_active(&intel_dp->aux) &&
+   drm_dp_pcon_hdmi_link_mode(&intel_dp->aux, frl_trained_mask) == 
DP_PCON_HDMI_MODE_FRL &&
+   *frl_trained_mask >= max_frl_bw_mask)
+   return true;
+
+   return false;
+}
+
 static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
 {
 #define TIMEOUT_FRL_READY_MS 500
@@ -2208,10 +2220,6 @@ static int intel_dp_pcon_start_frl_training(struct 
intel_dp *intel_dp)
u8 max_frl_bw_mask = 0, frl_trained_mask;
bool is_active;
 
-   ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
-   if (ret < 0)
-   return ret;
-
max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
drm_dbg(&i915->drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
 
@@ -2223,6 +2231,12 @@ static int intel_dp_pcon_start_frl_training(struct 
intel_dp *intel_dp)
if (max_frl_bw <= 0)
return -EINVAL;
 
+   max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
+   drm_dbg(&i915->drm, "MAX_FRL_BW_MASK = %u\n", max_frl_bw_mask);
+
+   if (intel_dp_pcon_is_frl_trained(intel_dp, max_frl_bw_mask, 
&frl_trained_mask))
+   goto frl_trained;
+
ret = drm_dp_pcon_frl_prepare(&intel_dp->aux, false);
if (ret < 0)
return ret;
@@ -2232,7 +2246,6 @@ static int intel_dp_pcon_start_frl_training(struct 
intel_dp *intel_dp)
if (!is_active)
return -ETIMEDOUT;
 
-   max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
  DP_PCON_ENABLE_SEQUENTIAL_LINK);
if (ret < 0)
@@ -2248,19 +2261,15 @@ static int intel_dp_pcon_start_frl_training(struct 
intel_dp *intel_dp)
 * Wait for FRL to be completed
 * Check if the HDMI Link is up and active.
 */
-   wait_for(is_active = drm_dp_pcon_hdmi_link_active(&intel_dp->aux) == 
true, TIMEOUT_HDMI_LINK_ACTIVE_MS);
+   wait_for(is_active =
+intel_dp_pcon_is_frl_trained(intel_dp, max_frl_bw_mask, 
&frl_trained_mask),
+TIMEOUT_HDMI_LINK_ACTIVE_MS);
 
if (!is_active)
return -ETIMEDOUT;
 
-   /* Verify HDMI Link configuration shows FRL Mode */
-   if (drm_dp_pcon_hdmi_link_mode(&intel_dp->aux, &frl_trained_mask) !=
-   DP_PCON_HDMI_MODE_FRL) {
-   drm_dbg(&i915->drm, "HDMI couldn't be trained in FRL Mode\n");
-   return -EINVAL;
-   }
-   drm_dbg(&i915->drm, "MAX_FRL_MASK = %u, FRL_TRAINED_MASK = %u\n", 
max_frl_bw_mask, frl_trained_mask);
-
+frl_trained:
+   drm_dbg(&i915->drm, "FRL_TRAINED_MASK = %u\n", frl_trained_mask);
intel_dp->frl.trained_rate_gbps = 
intel_dp_pcon_get_frl_mask(frl_trained_mask);
intel_dp->frl.is_trained = true;
drm_dbg(&i915->drm, "FRL trained with : %d Gbps\n", 
intel_dp->frl.trained_rate_gbps);
-- 
2.25.1

[Intel-gfx] [PATCH v3 2/2] drm/i915/dp: For PCON TMDS mode set only the relavant bits in config DPCD

[Ankit Nautiyal]

Currently we reset the whole PCON linkConfig DPCD to set the TMDS mode.
This also resets the Source control bit and HDMI link enable bit and
goes to autonomous mode of operation, which is seen to spoil the PCONs
internal state.

This patch avoids resetting the PCON link config register and sets only
the source control bit, with FRL Enable bit set to 0 (TMDS mode) in the
configuration DPCD. It then enables the HDMI Link Enable bit.

v2: Removed the redundant resetting of the bits as the buffer is already
initialized to 0. (Uma)
Updated comments and commit message.

v3: Rebase

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 020c357348b2..0a424bf69396 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2287,6 +2287,28 @@ static bool intel_dp_is_hdmi_2_1_sink(struct intel_dp 
*intel_dp)
return false;
 }
 
+static
+int intel_dp_pcon_set_tmds_mode(struct intel_dp *intel_dp)
+{
+   int ret;
+   u8 buf = 0;
+
+   /* Set PCON source control mode */
+   buf |= DP_PCON_ENABLE_SOURCE_CTL_MODE;
+
+   ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_PCON_HDMI_LINK_CONFIG_1, 
buf);
+   if (ret < 0)
+   return ret;
+
+   /* Set HDMI LINK ENABLE */
+   buf |= DP_PCON_ENABLE_HDMI_LINK;
+   ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_PCON_HDMI_LINK_CONFIG_1, 
buf);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
 void intel_dp_check_frl_training(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -2305,7 +2327,7 @@ void intel_dp_check_frl_training(struct intel_dp 
*intel_dp)
int ret, mode;
 
drm_dbg(&dev_priv->drm, "Couldn't set FRL mode, continuing with 
TMDS mode\n");
-   ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
+   ret = intel_dp_pcon_set_tmds_mode(intel_dp);
mode = drm_dp_pcon_hdmi_link_mode(&intel_dp->aux, NULL);
 
if (ret < 0 || mode != DP_PCON_HDMI_MODE_TMDS)
-- 
2.25.1