[Intel-gfx] i915 Updates: DG2 DMC v2.07

[Tolakanahalli Pradeep, Madhumitha]

Kindly add the below changes to linux-firmware:

The following changes since commit 150864a4d73e8c448eb1e2c68e65f07635fe1a66:

  amdgpu partially revert "amdgpu: update beige goby to release 22.20" (2022-07-
25 14:16:04 -0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_2_07

for you to fetch changes up to 3ab394af47ab6b0139a3fa6a7b39564a4d18cb25:

  i915: Add DMC v2.07 for DG2 (2022-07-27 10:52:59 -0700)


Anusha Srivatsa (1):
  i915: Add DMC v2.07 for DG2

 WHENCE   |   3 +++
 i915/dg2_dmc_ver2_07.bin | Bin 0 -> 22488 bytes
 2 files changed, 3 insertions(+)
 create mode 100644 i915/dg2_dmc_ver2_07.bin

--
2.37.1

Thanks!
- Madhumitha

[Intel-gfx] [PATCH 0/2] Context isolation uAPI fixes

[Adrian Larumbe]

This patch series addresses the concerns in
https://gitlab.freedesktop.org/drm/intel/-/issues/4264

Parallel work has be done on IGT to test changes in the kernel driver:
https://lists.freedesktop.org/archives/igt-dev/2022-May/041600.html

Test-with: 20220516205000.2960491-1-adrian.laru...@collabora.com

Adrian Larumbe (2):
  drm/i915: Change semantics of context isolation reporting to UM
  drm/i915: force getparam ioctl return bool for HAS_CONTEXT_ISOLATION

 drivers/gpu/drm/i915/gt/intel_engine_user.c | 14 ++
 drivers/gpu/drm/i915/gt/intel_engine_user.h |  1 +
 drivers/gpu/drm/i915/i915_getparam.c|  2 +-
 include/uapi/drm/i915_drm.h |  4 
 4 files changed, 16 insertions(+), 5 deletions(-)

-- 
2.37.0

[Intel-gfx] [PATCH 2/2] drm/i915: force getparam ioctl return bool for HAS_CONTEXT_ISOLATION

[Adrian Larumbe]

In a previous commit, the uAPI documentation for this param was updated
to reflect the actual usage expected by Iris. Now make sure the driver
does indeed return a boolean value rather than an engine bitmask.

Signed-off-by: Adrian Larumbe 
---
 drivers/gpu/drm/i915/gt/intel_engine_user.c | 14 ++
 drivers/gpu/drm/i915/gt/intel_engine_user.h |  1 +
 drivers/gpu/drm/i915/i915_getparam.c|  2 +-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 46a174f8aa00..7bdee1c9d940 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -306,3 +306,17 @@ unsigned int intel_engines_has_context_isolation(struct 
drm_i915_private *i915)
 
return which;
 }
+
+bool engines_context_isolated(struct drm_i915_private *i915)
+{
+   struct intel_engine_cs *engine;
+
+   if (!DRIVER_CAPS(i915)->has_logical_contexts)
+   return false;
+
+   for_each_uabi_engine(engine, i915)
+   if (!engine->default_state)
+   return false;
+
+   return true;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.h 
b/drivers/gpu/drm/i915/gt/intel_engine_user.h
index 3dc7e8ab9fbc..760167db07d5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.h
@@ -15,6 +15,7 @@ struct intel_engine_cs *
 intel_engine_lookup_user(struct drm_i915_private *i915, u8 class, u8 instance);
 
 unsigned int intel_engines_has_context_isolation(struct drm_i915_private 
*i915);
+bool engines_context_isolated(struct drm_i915_private *i915);
 
 void intel_engine_add_user(struct intel_engine_cs *engine);
 void intel_engines_driver_register(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 6fd15b39570c..dd31cc00c529 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -145,7 +145,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
value = 1;
break;
case I915_PARAM_HAS_CONTEXT_ISOLATION:
-   value = intel_engines_has_context_isolation(i915);
+   value = engines_context_isolated(i915);
break;
case I915_PARAM_SLICE_MASK:
/* Not supported from Xe_HP onward; use topology queries */
-- 
2.37.0

[Intel-gfx] [PATCH 1/2] drm/i915: Change semantics of context isolation reporting to UM

[Adrian Larumbe]

I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by
both Iris and Vulkan , and stood for the guarantee that, when creating a
new context, it would not contain register state from preexisting ones.

However, the actual param ioctl was returning a bitmask for the
engines in which isolation is supported, and IGT gem_ctx_isolation was
exploiting this wrong semantics when making decisions about which
engines support it.

This is a uAPI documentation change that precedes the actual change in
the getparam ioctl.

Signed-off-by: Adrian Larumbe 
---
 include/uapi/drm/i915_drm.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 094f6e377793..09adb7ea01d1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -692,10 +692,6 @@ typedef struct drm_i915_irq_wait {
  * supports) that all state set by this context will not leak to any other
  * context.
  *
- * As not every engine across every gen support contexts, the returned
- * value reports the support of context isolation for individual engines by
- * returning a bitmask of each engine class set to true if that class supports
- * isolation.
  */
 #define I915_PARAM_HAS_CONTEXT_ISOLATION 50
 
-- 
2.37.0

[Intel-gfx] [RESUBMIT][PATCH 2/2] drm/i915/gem: Perform active shrinking from a background thread

[Janusz Krzysztofik]

From: Chris Wilson 

i915 is very greedy and will retain system pages for as long as the user
requires them; once acquired they will be only returned when the object
is freed. In order to respond to system memory pressure, i915 hooks into
the shrinker subsystem, designed to prune the filesystem caches, to
unbind and return system pages. However, we can only do so if the device
is active at that moment, as we cannot resume the device from inside
direct reclaim to unbind pages from the GPU, nor do we want to delay
random processes with unbound waits trying to reclaim active pages. To
workaround that quandary, what we avoided in direct reclaim we
delegated to kswapd, as that is run from process context outside of
direct reclaim and able to sleep and resume the device.

In practice, kswapd also uses fs_reclaim_acquire() around its
shrink_slab calls, prohibiting runtime resume. If we cannot wake the
device from idle, we will retain system memory indefinitely.

As we cannot take advantage of kswapd's decoupled process context to
perform an active reclaim of bound pages, spawn our own kthread to wait
under our wakeref. Similar to kswapd, there is no direct dependency on
the background task to direct reclaim (other than failure to promptly
return pages will implicitly result in oom), as such the task itself does
not inherit the fs-reclaim context. A page reclaimed by i915 will
typically not immediately be available for re-use, as it will require
writeback, and so only a future allocation attempt may benefit.
Concurrent page allocation attempts do not wait for either kswapd or our
own swapper task.

We mark our kthread as a memallocator (allowed to dip into memory
reserves, but not allowed to trigger direct reclaim) and mark up
the call to the shrinker with a fs_reclaim critical section. This
should prevent us from accidentally abusing the background swapper task,
and so the swapper kthread behaves like kswapd with the exception of
being allowed to wake the device up, and being decoupled from the
shrinker_rwsem.

Reported-by: Thomas Hellström 
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/6449
Fixes: 178a30c90ac7 ("drm/i915: Unbind objects in shrinker only if device is 
runtime active")
Signed-off-by: Chris Wilson 
Cc: Thomas Hellström 
Cc: Matthew Auld 
Cc: Tvrtko Ursulin 
Cc: sta...@vger.kernel.org # v4.8+
Signed-off-by: Janusz Krzysztofik 
---
Resubmit reason: drop RFC label.

 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 134 +--
 drivers/gpu/drm/i915/i915_drv.h  |  15 +++
 2 files changed, 135 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 1030053571a2..bc6c1978e64a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -310,6 +310,113 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct 
shrink_control *sc)
return count;
 }
 
+static unsigned long run_swapper(struct drm_i915_private *i915,
+unsigned long target,
+unsigned long *nr_scanned)
+{
+   return i915_gem_shrink(NULL, i915,
+  target, nr_scanned,
+  I915_SHRINK_ACTIVE |
+  I915_SHRINK_BOUND |
+  I915_SHRINK_UNBOUND |
+  I915_SHRINK_WRITEBACK);
+}
+
+static int swapper(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   atomic_long_t *target = >mm.swapper.target;
+   unsigned int noreclaim_state;
+
+   /*
+* For us to be running the swapper implies that the system is under
+* enough memory pressure to be swapping. At that point, we both want
+* to ensure we make forward progress in order to reclaim pages from
+* the device and not contribute further to direct reclaim pressure. We
+* mark ourselves as a memalloc task in order to not trigger direct
+* reclaim ourselves, but dip into the system memory reserves for
+* shrinkers.
+*/
+   noreclaim_state = memalloc_noreclaim_save();
+
+   do {
+   intel_wakeref_t wakeref;
+
+   ___wait_var_event(target,
+ atomic_long_read(target) ||
+ kthread_should_stop(),
+ TASK_IDLE, 0, 0, schedule());
+   if (kthread_should_stop())
+   break;
+
+   with_intel_runtime_pm(>runtime_pm, wakeref) {
+   unsigned long nr_scan = atomic_long_xchg(target, 0);
+
+   /*
+* Now that we have woken up the device hierarchy,
+* act as a normal shrinker. Our shrinker is primarily
+* focussed on supporting direct reclaim (low latency,
+* 

[Intel-gfx] [RESUBMIT][PATCH 1/2] drm/i915/gem: Avoid taking runtime-pm under the shrinker

[Janusz Krzysztofik]

From: Chris Wilson 

Inside the shrinker, we cannot wake the device as that may cause
recursion into fs-reclaim, so instead we only unbind vma if the device
is currently awake. (In order to provide reclaim while asleep, we do
wake the device up during kswapd -- we probably want to limit that wake
up if we have anything to shrink though!)

To avoid the same fs_reclaim recursion potential during
i915_gem_object_unbind, we acquire a wakeref there, see commit
3e817471a34c ("drm/i915/gem: Take runtime-pm wakeref prior to unbinding").
However, we use i915_gem_object_unbind from the shrinker path to make the
object available for shrinking and so we must make the wakeref acquisition
here conditional.

<4> [437.542172] ==
<4> [437.542174] WARNING: possible circular locking dependency detected
<4> [437.542176] 5.19.0-rc6-CI_DRM_11876-g2305e0d00665+ #1 Tainted: G U
<4> [437.542179] --
<4> [437.542181] kswapd0/93 is trying to acquire lock:
<4> [437.542183] 827a7608 (acpi_wakeup_lock){+.+.}-{3:3}, at: 
acpi_device_wakeup_disable+0x12/0x50
<4> [437.542191]
but task is already holding lock:
<4> [437.542194] 8275d360 (fs_reclaim){+.+.}-{0:0}, at: 
balance_pgdat+0x91/0x5c0
<4> [437.542199]
which lock already depends on the new lock.
<4> [437.542202]
the existing dependency chain (in reverse order) is:
<4> [437.542204]
-> #2 (fs_reclaim){+.+.}-{0:0}:
<4> [437.542207]fs_reclaim_acquire+0x9d/0xd0
<4> [437.542211]kmem_cache_alloc_trace+0x2a/0x250
<4> [437.542214]__acpi_device_add+0x263/0x3a0
<4> [437.542217]acpi_add_single_object+0x3ea/0x710
<4> [437.542220]acpi_bus_check_add+0xf7/0x240
<4> [437.54]acpi_bus_scan+0x34/0xf0
<4> [437.542224]acpi_scan_init+0xf5/0x241
<4> [437.542228]acpi_init+0x449/0x4aa
<4> [437.542230]do_one_initcall+0x53/0x2e0
<4> [437.542233]kernel_init_freeable+0x18f/0x1dd
<4> [437.542236]kernel_init+0x11/0x110
<4> [437.542239]ret_from_fork+0x1f/0x30
<4> [437.542241]
-> #1 (acpi_device_lock){+.+.}-{3:3}:
<4> [437.542245]__mutex_lock+0x97/0xf20
<4> [437.542246]acpi_enable_wakeup_device_power+0x30/0xf0
<4> [437.542249]__acpi_device_wakeup_enable+0x31/0x110
<4> [437.542252]acpi_pm_set_device_wakeup+0x55/0x100
<4> [437.542254]__pci_enable_wake+0x5e/0xa0
<4> [437.542257]pci_finish_runtime_suspend+0x32/0x70
<4> [437.542259]pci_pm_runtime_suspend+0xa3/0x160
<4> [437.542262]__rpm_callback+0x3d/0x110
<4> [437.542265]rpm_callback+0x54/0x60
<4> [437.542268]rpm_suspend.part.10+0x105/0x5a0
<4> [437.542270]pm_runtime_work+0x7d/0x1e0
<4> [437.542273]process_one_work+0x272/0x5c0
<4> [437.542276]worker_thread+0x37/0x370
<4> [437.542278]kthread+0xed/0x120
<4> [437.542280]ret_from_fork+0x1f/0x30
<4> [437.542282]
-> #0 (acpi_wakeup_lock){+.+.}-{3:3}:
<4> [437.542285]__lock_acquire+0x15ad/0x2940
<4> [437.542288]lock_acquire+0xd3/0x310
<4> [437.542291]__mutex_lock+0x97/0xf20
<4> [437.542293]acpi_device_wakeup_disable+0x12/0x50
<4> [437.542295]acpi_pm_set_device_wakeup+0x6e/0x100
<4> [437.542297]__pci_enable_wake+0x73/0xa0
<4> [437.542300]pci_pm_runtime_resume+0x45/0x90
<4> [437.542302]__rpm_callback+0x3d/0x110
<4> [437.542304]rpm_callback+0x54/0x60
<4> [437.542307]rpm_resume+0x54f/0x750
<4> [437.542309]__pm_runtime_resume+0x42/0x80
<4> [437.542311]__intel_runtime_pm_get+0x19/0x80 [i915]
<4> [437.542386]i915_gem_object_unbind+0x8f/0x3b0 [i915]
<4> [437.542487]i915_gem_shrink+0x634/0x850 [i915]
<4> [437.542584]i915_gem_shrinker_scan+0x3a/0xc0 [i915]
<4> [437.542679]shrink_slab.constprop.97+0x1a4/0x4f0
<4> [437.542684]shrink_node+0x21e/0x420
<4> [437.542687]balance_pgdat+0x241/0x5c0
<4> [437.542690]kswapd+0x229/0x4f0
<4> [437.542694]kthread+0xed/0x120
<4> [437.542697]ret_from_fork+0x1f/0x30
<4> [437.542701]
other info that might help us debug this:
<4> [437.542705] Chain exists of:
  acpi_wakeup_lock --> acpi_device_lock --> fs_reclaim
<4> [437.542713]  Possible unsafe locking scenario:
<4> [437.542716]CPU0CPU1
<4> [437.542719]
<4> [437.542721]   lock(fs_reclaim);
<4> [437.542725]lock(acpi_device_lock);
<4> [437.542728]lock(fs_reclaim);
<4> [437.542732]   lock(acpi_wakeup_lock);
<4> [437.542736]
 *** DEADLOCK ***

Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/6449
Fixes: 3e817471a34c ("drm/i915/gem: Take runtime-pm wakeref prior to unbinding")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc:  # v5.6+
Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Matthew Auld 
---
Resubmit reason: keep in 

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

[Maxime Ripard]

Hi Dave, Daniel,

Here's this week drm-misc-fixes PR

It's a partial resend from yesterday that only had the simpledrm but the mail 
somehow got lost.

Maxime

drm-misc-fixes-2022-07-29:
One fix to fix simpledrm mode_valid return value, and one for page
migration in nouveau
The following changes since commit 02c87df2480ac855d88ee308ce3fa857d9bd55a8:

  drm/imx/dcss: Add missing of_node_put() in fail path (2022-07-20 10:12:15 
+0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-07-29

for you to fetch changes up to 66cee9097e2b74ff3c8cc040ce5717c521a0c3fa:

  nouveau/svm: Fix to migrate all requested pages (2022-07-28 16:43:31 -0400)


One fix to fix simpledrm mode_valid return value, and one for page
migration in nouveau


Alistair Popple (1):
  nouveau/svm: Fix to migrate all requested pages

Nathan Chancellor (1):
  drm/simpledrm: Fix return type of 
simpledrm_simple_display_pipe_mode_valid()

 drivers/gpu/drm/nouveau/nouveau_dmem.c | 6 +-
 drivers/gpu/drm/tiny/simpledrm.c   | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)


signature.asc
Description: PGP signature

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Avoid taking runtime-pm under the shrinker

[Janusz Krzysztofik]

Hi Matthew,

Thanks for review.

On Tuesday, 26 July 2022 20:14:05 CEST Matthew Auld wrote:
> On 20/07/2022 11:16, Janusz Krzysztofik wrote:
> > From: Chris Wilson 
> > 
> > Inside the shrinker, we cannot wake the device as that may cause
> > recursion into fs-reclaim, so instead we only unbind vma if the device
> > is currently awake. (In order to provide reclaim while asleep, we do
> > wake the device up during kswapd -- we probably want to limit that wake
> > up if we have anything to shrink though!)
> > 
> > To avoid the same fs_reclaim recursion potential during
> > i915_gem_object_unbind, we acquire a wakeref there, see commit
> > 3e817471a34c ("drm/i915/gem: Take runtime-pm wakeref prior to unbinding").
> > However, we use i915_gem_object_unbind from the shrinker path to make the
> > object available for shrinking and so we must make the wakeref acquisition
> > here conditional.
> > 
> > <4> [437.542172] ==
> > <4> [437.542174] WARNING: possible circular locking dependency detected
> > <4> [437.542176] 5.19.0-rc6-CI_DRM_11876-g2305e0d00665+ #1 Tainted: G U
> > <4> [437.542179] --
> > <4> [437.542181] kswapd0/93 is trying to acquire lock:
> > <4> [437.542183] 827a7608 (acpi_wakeup_lock){+.+.}-{3:3}, at: 
> > acpi_device_wakeup_disable+0x12/0x50
> > <4> [437.542191]
> > but task is already holding lock:
> > <4> [437.542194] 8275d360 (fs_reclaim){+.+.}-{0:0}, at: 
> > balance_pgdat+0x91/0x5c0
> > <4> [437.542199]
> > which lock already depends on the new lock.
> > <4> [437.542202]
> > the existing dependency chain (in reverse order) is:
> > <4> [437.542204]
> > -> #2 (fs_reclaim){+.+.}-{0:0}:
> > <4> [437.542207]fs_reclaim_acquire+0x9d/0xd0
> > <4> [437.542211]kmem_cache_alloc_trace+0x2a/0x250
> > <4> [437.542214]__acpi_device_add+0x263/0x3a0
> > <4> [437.542217]acpi_add_single_object+0x3ea/0x710
> > <4> [437.542220]acpi_bus_check_add+0xf7/0x240
> > <4> [437.54]acpi_bus_scan+0x34/0xf0
> > <4> [437.542224]acpi_scan_init+0xf5/0x241
> > <4> [437.542228]acpi_init+0x449/0x4aa
> > <4> [437.542230]do_one_initcall+0x53/0x2e0
> > <4> [437.542233]kernel_init_freeable+0x18f/0x1dd
> > <4> [437.542236]kernel_init+0x11/0x110
> > <4> [437.542239]ret_from_fork+0x1f/0x30
> > <4> [437.542241]
> > -> #1 (acpi_device_lock){+.+.}-{3:3}:
> > <4> [437.542245]__mutex_lock+0x97/0xf20
> > <4> [437.542246]acpi_enable_wakeup_device_power+0x30/0xf0
> > <4> [437.542249]__acpi_device_wakeup_enable+0x31/0x110
> > <4> [437.542252]acpi_pm_set_device_wakeup+0x55/0x100
> > <4> [437.542254]__pci_enable_wake+0x5e/0xa0
> > <4> [437.542257]pci_finish_runtime_suspend+0x32/0x70
> > <4> [437.542259]pci_pm_runtime_suspend+0xa3/0x160
> > <4> [437.542262]__rpm_callback+0x3d/0x110
> > <4> [437.542265]rpm_callback+0x54/0x60
> > <4> [437.542268]rpm_suspend.part.10+0x105/0x5a0
> > <4> [437.542270]pm_runtime_work+0x7d/0x1e0
> > <4> [437.542273]process_one_work+0x272/0x5c0
> > <4> [437.542276]worker_thread+0x37/0x370
> > <4> [437.542278]kthread+0xed/0x120
> > <4> [437.542280]ret_from_fork+0x1f/0x30
> > <4> [437.542282]
> > -> #0 (acpi_wakeup_lock){+.+.}-{3:3}:
> > <4> [437.542285]__lock_acquire+0x15ad/0x2940
> > <4> [437.542288]lock_acquire+0xd3/0x310
> > <4> [437.542291]__mutex_lock+0x97/0xf20
> > <4> [437.542293]acpi_device_wakeup_disable+0x12/0x50
> > <4> [437.542295]acpi_pm_set_device_wakeup+0x6e/0x100
> > <4> [437.542297]__pci_enable_wake+0x73/0xa0
> > <4> [437.542300]pci_pm_runtime_resume+0x45/0x90
> > <4> [437.542302]__rpm_callback+0x3d/0x110
> > <4> [437.542304]rpm_callback+0x54/0x60
> > <4> [437.542307]rpm_resume+0x54f/0x750
> > <4> [437.542309]__pm_runtime_resume+0x42/0x80
> > <4> [437.542311]__intel_runtime_pm_get+0x19/0x80 [i915]
> > <4> [437.542386]i915_gem_object_unbind+0x8f/0x3b0 [i915]
> > <4> [437.542487]i915_gem_shrink+0x634/0x850 [i915]
> > <4> [437.542584]i915_gem_shrinker_scan+0x3a/0xc0 [i915]
> > <4> [437.542679]shrink_slab.constprop.97+0x1a4/0x4f0
> > <4> [437.542684]shrink_node+0x21e/0x420
> > <4> [437.542687]balance_pgdat+0x241/0x5c0
> > <4> [437.542690]kswapd+0x229/0x4f0
> > <4> [437.542694]kthread+0xed/0x120
> > <4> [437.542697]ret_from_fork+0x1f/0x30
> > <4> [437.542701]
> > other info that might help us debug this:
> > <4> [437.542705] Chain exists of:
> >acpi_wakeup_lock --> acpi_device_lock --> fs_reclaim
> > <4> [437.542713]  Possible unsafe locking scenario:
> > <4> [437.542716]CPU0CPU1
> > <4> [437.542719]
> > <4> [437.542721]   lock(fs_reclaim);
> > 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: clear plane color ctl setting when turn full plane off (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: clear plane color ctl setting when turn full plane off (rev4)
URL   : https://patchwork.freedesktop.org/series/106292/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11946 -> Patchwork_106292v4


Summary
---

  **FAILURE**

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

Participating hosts (38 -> 40)
--

  Additional (4): fi-hsw-4770 fi-kbl-8809g bat-jsl-1 bat-adlp-4 
  Missing(2): fi-bdw-samus bat-dg1-5 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions:
- fi-adl-ddr5:[PASS][1] -> [DMESG-WARN][2] +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/fi-adl-ddr5/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/fi-adl-ddr5/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor@atomic-transitions:
- fi-rkl-11600:   [PASS][3] -> [DMESG-WARN][4] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/fi-rkl-11600/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/fi-rkl-11600/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions.html

  * 
igt@kms_cursor_legacy@basic-flip-before-cursor@atomic-transitions-varying-size:
- fi-rkl-guc: [PASS][5] -> [DMESG-WARN][6] +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/fi-rkl-guc/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/fi-rkl-guc/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html

  
 Suppressed 

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

  * igt@i915_selftest@live@gt_heartbeat:
- {bat-rpls-1}:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/bat-rpls-1/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/bat-rpls-1/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor@atomic-transitions:
- {bat-rplp-1}:   [PASS][9] -> [DMESG-WARN][10] +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/bat-rplp-1/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/bat-rplp-1/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions.html

  * 
igt@kms_cursor_legacy@basic-flip-before-cursor@atomic-transitions-varying-size:
- {bat-rpls-2}:   NOTRUN -> [DMESG-WARN][11] +8 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/bat-rpls-2/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
- {fi-jsl-1}: [PASS][12] -> [DMESG-WARN][13] +4 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/fi-jsl-1/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/fi-jsl-1/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
- {bat-rpls-1}:   [PASS][14] -> [DMESG-WARN][15] +5 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/bat-rpls-1/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/bat-rpls-1/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
- {fi-ehl-2}: [PASS][16] -> [DMESG-WARN][17] +4 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/fi-ehl-2/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v4/fi-ehl-2/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html

  * igt@kms_flip@basic-flip-vs-dpms@b-edp1:
- {bat-jsl-3}:[PASS][18] -> 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Move TLB invalidation code for its own file and document it (rev2)

[Patchwork]

== Series Details ==

Series: Move TLB invalidation code for its own file and document it (rev2)
URL   : https://patchwork.freedesktop.org/series/106805/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/106805/revisions/2/mbox/ not 
applied
Applying: drm/i915/gt: Move TLB invalidation to its own file
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gem/i915_gem_pages.c
M   drivers/gpu/drm/i915/gt/intel_gt.c
M   drivers/gpu/drm/i915/gt/intel_gt.h
M   drivers/gpu/drm/i915/i915_vma.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_vma.c
Auto-merging drivers/gpu/drm/i915/gt/intel_gt.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_gt.h
Auto-merging drivers/gpu/drm/i915/gt/intel_gt.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_gt.c
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_pages.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_pages.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/gt: Move TLB invalidation to its own file
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] [PATCH v2 2/2] drm/i915/gt: document TLB cache invalidation functions

[Mauro Carvalho Chehab]

Add a description for the TLB cache invalidation algorithm and for
the related kAPI functions.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v2 0/2] at: 
https://lore.kernel.org/all/cover.1659077372.git.mche...@kernel.org/

 Documentation/gpu/i915.rst  |   7 ++
 drivers/gpu/drm/i915/gt/intel_tlb.c |  25 +++
 drivers/gpu/drm/i915/gt/intel_tlb.h | 101 
 3 files changed, 133 insertions(+)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 4e59db1cfb00..46911fdd79e8 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -58,6 +58,13 @@ Intel GVT-g Host Support(vGPU device model)
 .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
:internal:
 
+TLB cache invalidation
+--
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.h
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.c
+
 Workarounds
 ---
 
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c 
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index af8cae979489..4873b7ecc015 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
 }
 
+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
+ * @seqno: sequence number
+ *
+ * Do a full TLB cache invalidation if the @seqno is bigger than the last
+ * full TLB cache invalidation.
+ *
+ * Note:
+ * The TLB cache invalidation logic depends on GEN-specific registers.
+ * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
+ */
 void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
 {
intel_wakeref_t wakeref;
@@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, 
u32 seqno)
}
 }
 
+/**
+ * intel_gt_init_tlb - initialize TLB-specific vars
+ * @gt: GT structure
+ *
+ * TLB cache invalidation logic internally uses some resources that require
+ * initialization. Should be called before doing any TLB cache invalidation.
+ */
 void intel_gt_init_tlb(struct intel_gt *gt)
 {
mutex_init(>tlb.invalidate_lock);
seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
 }
 
+/**
+ * intel_gt_fini_tlb - initialize TLB-specific vars
+ * @gt: GT structure
+ *
+ * Frees any resources needed by TLB cache invalidation logic.
+ */
 void intel_gt_fini_tlb(struct intel_gt *gt)
 {
mutex_destroy(>tlb.invalidate_lock);
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h 
b/drivers/gpu/drm/i915/gt/intel_tlb.h
index 46ce25bf5afe..dca70c33bd61 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.h
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
@@ -11,16 +11,117 @@
 
 #include "intel_gt_types.h"
 
+/**
+ * DOC: TLB cache invalidation logic
+ *
+ * The way the current algorithm works is that a struct drm_i915_gem_object can
+ * be created on any order. At unbind/evict time, the object is warranted that
+ * it won't be used anymore. So, a sequence number provided by
+ * intel_gt_next_invalidate_tlb_full() is stored on it. This can happen either
+ * at __vma_put_pages() - for VMA sync unbind, or at ppgtt_unbind_vma() - for
+ * VMA async VMA bind.
+ *
+ * At __i915_gem_object_unset_pages(), intel_gt_invalidate_tlb_full() is 
called,
+ * where it checks if the sequence number of the object was already invalidated
+ * or not. If not, it flushes the TLB and increments the sequence number::
+ *
+ *   void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
+ *   {
+ *   ...
+ * with_intel_gt_pm_if_awake(gt, wakeref) {
+ * mutex_lock(>tlb.invalidate_lock);
+ * if (tlb_seqno_passed(gt, seqno))
+ * goto unlock;
+ *
+ * // Some code to do TLB invalidation
+ *   ...
+ *
+ * write_seqcount_invalidate(>tlb.seqno); // increment seqno
+ * mutex_lock(>tlb.invalidate_lock);
+ *  }
+ *
+ * So, let's say the current seqno is 2 and 3 new objects were created,
+ * on this order::
+ *
+ * obj1
+ * obj2
+ * obj3
+ *
+ * They can be unbind/evict on a different order. At unbind/evict time,
+ * the mm.tlb will be stamped with the sequence number, using the number
+ * from the last TLB flush, plus 1.
+ *
+ * Different threads may be used on unbind/evict and/or unset pages.
+ * As the logic at void intel_gt_invalidate_tlb_full() is protected by a mutex,
+ * for simplicity, let's consider just two threads:
+ *
+ * 
+---+-+-+
+ * | sequence number   | Thread 0| Thread 1
+
+ * 
+===+=+=+
+ * | seqno=2   | | 
|
+ * |   

[Intel-gfx] [PATCH v2 0/2] Move TLB invalidation code for its own file and document it

[Mauro Carvalho Chehab]

There are more things to be added to TLB invalidation. Before doing that,
move the code to its own file, and add the relevant documentation.

Patch 1 only moves the code and do some function renames. No functional
change.

Patch 2 adds documentation for the TLB invalidation algorithm and functions.

---

v2: only patch 2 (kernel-doc) was modified:

  - The kernel-doc markups for TLB were added to i915.rst doc;
  - Some minor fixes at the texts;
  - Use a table instead of a literal block while explaining how the algorithm 
works.
That should make easier to understand the logic, both in text form and after
its conversion to HTML/PDF;
  - Remove mention for GuC, as this depends on a series that will be sent later.

Chris Wilson (1):
  drm/i915/gt: Move TLB invalidation to its own file

Mauro Carvalho Chehab (1):
  drm/i915/gt: document TLB cache invalidation functions

 Documentation/gpu/i915.rst|   7 +
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 168 +
 drivers/gpu/drm/i915/gt/intel_gt.h|  12 --
 drivers/gpu/drm/i915/gt/intel_tlb.c   | 208 ++
 drivers/gpu/drm/i915/gt/intel_tlb.h   | 130 ++
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 8 files changed, 352 insertions(+), 179 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h

-- 
2.36.1

[Intel-gfx] [PATCH v2 1/2] drm/i915/gt: Move TLB invalidation to its own file

[Mauro Carvalho Chehab]

From: Chris Wilson 

Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.

Signed-off-by: Chris Wilson 
Cc: Fei Yang 
Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v2 0/2] at: 
https://lore.kernel.org/all/cover.1659077372.git.mche...@kernel.org/

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 168 +---
 drivers/gpu/drm/i915/gt/intel_gt.h|  12 --
 drivers/gpu/drm/i915/gt/intel_tlb.c   | 183 ++
 drivers/gpu/drm/i915/gt/intel_tlb.h   |  29 
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 7 files changed, 219 insertions(+), 179 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..d3df9832d1f7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -126,6 +126,7 @@ gt-y += \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
+   gt/intel_tlb.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 8357dbdcab5c..1cd76cc5d9f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -7,7 +7,7 @@
 #include 
 
 #include "gt/intel_gt.h"
-#include "gt/intel_gt_pm.h"
+#include "gt/intel_tlb.h"
 
 #include "i915_drv.h"
 #include "i915_gem_object.h"
@@ -199,7 +199,7 @@ static void flush_tlb_invalidate(struct drm_i915_gem_object 
*obj)
if (!obj->mm.tlb)
return;
 
-   intel_gt_invalidate_tlb(gt, obj->mm.tlb);
+   intel_gt_invalidate_tlb_full(gt, obj->mm.tlb);
obj->mm.tlb = 0;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f435e06125aa..18d82cd620bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -11,9 +11,7 @@
 #include "pxp/intel_pxp.h"
 
 #include "i915_drv.h"
-#include "i915_perf_oa_regs.h"
 #include "intel_context.h"
-#include "intel_engine_pm.h"
 #include "intel_engine_regs.h"
 #include "intel_ggtt_gmch.h"
 #include "intel_gt.h"
@@ -31,6 +29,7 @@
 #include "intel_renderstate.h"
 #include "intel_rps.h"
 #include "intel_gt_sysfs.h"
+#include "intel_tlb.h"
 #include "intel_uncore.h"
 #include "shmem_utils.h"
 
@@ -48,8 +47,7 @@ static void __intel_gt_init_early(struct intel_gt *gt)
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
intel_gt_init_timelines(gt);
-   mutex_init(>tlb.invalidate_lock);
-   seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
+   intel_gt_init_tlb(gt);
intel_gt_pm_init_early(gt);
 
intel_uc_init_early(>uc);
@@ -770,7 +768,7 @@ void intel_gt_driver_late_release_all(struct 
drm_i915_private *i915)
intel_gt_fini_requests(gt);
intel_gt_fini_reset(gt);
intel_gt_fini_timelines(gt);
-   mutex_destroy(>tlb.invalidate_lock);
+   intel_gt_fini_tlb(gt);
intel_engines_free(gt);
}
 }
@@ -881,163 +879,3 @@ void intel_gt_info_print(const struct intel_gt_info *info,
 
intel_sseu_dump(>sseu, p);
 }
-
-struct reg_and_bit {
-   i915_reg_t reg;
-   u32 bit;
-};
-
-static struct reg_and_bit
-get_reg_and_bit(const struct intel_engine_cs *engine, const bool gen8,
-   const i915_reg_t *regs, const unsigned int num)
-{
-   const unsigned int class = engine->class;
-   struct reg_and_bit rb = { };
-
-   if (drm_WARN_ON_ONCE(>i915->drm,
-class >= num || !regs[class].reg))
-   return rb;
-
-   rb.reg = regs[class];
-   if (gen8 && class == VIDEO_DECODE_CLASS)
-   rb.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
-   else
-   rb.bit = engine->instance;
-
-   rb.bit = BIT(rb.bit);
-
-   return rb;
-}
-
-static void mmio_invalidate_full(struct intel_gt *gt)
-{
-   static const i915_reg_t gen8_regs[] = {
-   [RENDER_CLASS]  = GEN8_RTCR,
-   [VIDEO_DECODE_CLASS]= GEN8_M1TCR, /* , GEN8_M2TCR */
-   [VIDEO_ENHANCEMENT_CLASS]   = GEN8_VTCR,
-   [COPY_ENGINE_CLASS] = GEN8_BTCR,
-   };
-   static const i915_reg_t gen12_regs[] = {
-   [RENDER_CLASS]  = GEN12_GFX_TLB_INV_CR,
-   [VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR,
-   [VIDEO_ENHANCEMENT_CLASS]   = GEN12_VE_TLB_INV_CR,
-   [COPY_ENGINE_CLASS] = 

[Intel-gfx] ✓ Fi.CI.IGT: success for Move DG2 to GuC v70.4.1

[Patchwork]

== Series Details ==

Series: Move DG2 to GuC v70.4.1
URL   : https://patchwork.freedesktop.org/series/106827/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11946_full -> Patchwork_106827v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/shard-iclb2/igt@feature_discov...@psr2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-iclb4/igt@feature_discov...@psr2.html

  * igt@gem_create@create-massive:
- shard-kbl:  NOTRUN -> [DMESG-WARN][3] ([i915#4991])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-kbl1/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-skl:  NOTRUN -> [SKIP][4] ([fdo#109271]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-skl4/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/shard-kbl7/igt@gem_...@in-flight-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-kbl4/igt@gem_...@in-flight-suspend.html

  * igt@gem_eio@unwedge-stress:
- shard-skl:  [PASS][7] -> [TIMEOUT][8] ([i915#3063])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/shard-skl7/igt@gem_...@unwedge-stress.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-skl6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#4525]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/shard-iclb1/igt@gem_exec_balan...@parallel-keep-submit-fence.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-iclb7/igt@gem_exec_balan...@parallel-keep-submit-fence.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  NOTRUN -> [FAIL][11] ([i915#2842]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_lmem_swapping@verify-ccs:
- shard-kbl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-kbl1/igt@gem_lmem_swapp...@verify-ccs.html

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

  * igt@i915_pm_dc@dc9-dpms:
- shard-iclb: [PASS][14] -> [SKIP][15] ([i915#4281])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/shard-iclb4/igt@i915_pm...@dc9-dpms.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-iclb3/igt@i915_pm...@dc9-dpms.html

  * igt@i915_pm_rpm@system-suspend:
- shard-skl:  [PASS][16] -> [INCOMPLETE][17] ([i915#4939])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/shard-skl1/igt@i915_pm_...@system-suspend.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-skl4/igt@i915_pm_...@system-suspend.html

  * igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs:
- shard-kbl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +6 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-kbl7/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-apl3/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html

  * igt@kms_color_chamelium@pipe-a-gamma:
- shard-kbl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) 
+11 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-kbl1/igt@kms_color_chamel...@pipe-a-gamma.html

  * igt@kms_color_chamelium@pipe-b-ctm-limited-range:
- shard-skl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106827v1/shard-skl4/igt@kms_color_chamel...@pipe-b-ctm-limited-range.html

  * igt@kms_color_chamelium@pipe-d-ctm-red-to-blue:
- shard-apl:  NOTRUN 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: clear plane color ctl setting when turn full plane off (rev3)

[Vudum, Lakshminarayana]

I have never done that. Author probably should have access to that. If I 
remember correctly, there should be a re-run button which I not able to see at 
the moment.

Lakshmi.

From: Shankar, Uma 
Sent: Thursday, July 28, 2022 10:50 PM
To: Kurmi, Suresh Kumar ; Vudum, Lakshminarayana 
; Lee, Shawn C ; 
intel-gfx@lists.freedesktop.org; Naramasetti, LaxminarayanaX 

Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915: clear plane color ctl setting 
when turn full plane off (rev3)

Hi Lakshmi,
Can you trigger a re-run just to confirm as recommended by Suresh.

Regards,
Uma Shankar

From: Kurmi, Suresh Kumar 
mailto:suresh.kumar.ku...@intel.com>>
Sent: Friday, July 29, 2022 9:29 AM
To: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>; Lee, 
Shawn C mailto:shawn.c@intel.com>>; 
intel-gfx@lists.freedesktop.org; 
Naramasetti, LaxminarayanaX 
mailto:laxminarayanax.naramase...@intel.com>>
Cc: Shankar, Uma mailto:uma.shan...@intel.com>>
Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915: clear plane color ctl setting 
when turn full plane off (rev3)

IGT_6598 is very old, we should trigger the re-run with the latest CI IGT 
version since ADL-M and RKL has been very stable BAT machine.

-Suresh

From: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Sent: Thursday, July 28, 2022 9:08 PM
To: Lee, Shawn C mailto:shawn.c@intel.com>>; 
intel-gfx@lists.freedesktop.org; Kurmi, 
Suresh Kumar 
mailto:suresh.kumar.ku...@intel.com>>; 
Naramasetti, LaxminarayanaX 
mailto:laxminarayanax.naramase...@intel.com>>
Cc: Shankar, Uma mailto:uma.shan...@intel.com>>
Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915: clear plane color ctl setting 
when turn full plane off (rev3)



From: Vudum, Lakshminarayana
Sent: Thursday, July 28, 2022 8:36 AM
To: 
20220722070343.10654-1-shawn.c@intel.com;
 intel-gfx@lists.freedesktop.org; 
Kurmi, Suresh Kumar 
mailto:suresh.kumar.ku...@intel.com>>; 
Naramasetti, LaxminarayanaX 
mailto:laxminarayanax.naramase...@intel.com>>
Cc: Shankar, Uma mailto:uma.shan...@intel.com>>
Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915: clear plane color ctl setting 
when turn full plane off (rev3)

Shawn,

I see from our CI that we haven’t seen FIFO underruns lately on ADL-M and RKL.

I see your series is using IGT_6598 and CI is using IGT_6603. Not sure, how old 
is the one used in the series and how much it makes difference.



@Kurmi, Suresh Kumar/@Naramasetti, 
LaxminarayanaX How do you see this 
issue? Should I file a new issue and re-report?



Thanks,

Lakshmi.


From: Lee, Shawn C mailto:shawn.c@intel.com>>
Sent: Thursday, July 28, 2022 8:10 AM
To: intel-gfx@lists.freedesktop.org
Cc: Shankar, Uma mailto:uma.shan...@intel.com>>; Vudum, 
Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915: clear plane color ctl setting 
when turn full plane off (rev3)


Hi Lakshmi,

Below issues are not related to the patch. Re-run these test cases with this 
patch and get pass result on my local machine.
Best regards,
Shawn

From: Patchwork 
mailto:patchw...@emeril.freedesktop.org>>
Sent: Wednesday, July 27, 2022 4:54 PM
To: Lee, Shawn C mailto:shawn.c@intel.com>>
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915: clear plane color ctl setting when 
turn full plane off (rev3)

Patch Details
Series:
drm/i915: clear plane color ctl setting when turn full plane off (rev3)
URL:
https://patchwork.freedesktop.org/series/106292/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106292v3/index.html
CI Bug Log - changes from CI_DRM_11946 -> Patchwork_106292v3
Summary

FAILURE

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106292v3, 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_106292v3/index.html

Participating hosts (38 -> 37)

Additional (2): fi-hsw-4770 bat-jsl-1
Missing (3): fi-rkl-11600 fi-bdw-samus bat-dg1-5

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions:

 *   fi-adl-ddr5: 
PASS
 ->