Let userspace know when snd-hda-intel needs i915

PATCH Superseded Mauro Carvalho Chehab 5 participants 16 messages Apr 29, 2022 – May 4, 2022

Subsystems (2)

Sound Module support

lore

Share & tools

lore

Mauro Carvalho Chehab

author

2022-04-29 06:31 UTC #0 lore raw

cover Let userspace know when snd-hda-intel needs i915

Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific.

In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models:

	https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@[email protected]
	https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@[email protected]

In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs.

With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time.

With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues.

So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver.

This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver.

It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back:

https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099.html

So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind.

Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug.

PS.: This series was generated against next-20220428.

Luis/Takashi/Daniel/David,

If OK for you, I would prefer to have such patches applied via the drm-tip tree once reviewed, in order to make easier to use them by some patches I'm preparing to improve the CI tests that use i915 unbind logic.

Mauro Carvalho Chehab (2):
module: add a function to add module references
ALSA: hda - identify when audio is provided by a video driver

 include/linux/module.h     |  7 +++++++
 kernel/module/main.c       | 31 +++++++++++++++++++++++++++++++
 sound/hda/hdac_component.c |  8 ++++++++
 3 files changed, 46 insertions(+)

Signature · 1 line

2.35.1

Mauro Carvalho Chehab

author

2022-04-29 06:31 UTC #1 lore raw

PATCH 1/2 module: add a function to add module references

Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.

Add a function to allow setting up module references for such cases.

Reviewed-by Dan Williams <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

---

See [PATCH 0/2] at: https://lore.kernel.org/all/[email protected]/

 include/linux/module.h |  7 +++++++
 kernel/module/main.c   | 31 +++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

include/linux/module.h +7 -0

index 46d4d5f2516e..be74f807e41d 100644
@@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr, const struct module *mod)
 /* Search for module by name: must be in a RCU-sched critical section. */
 struct module *find_module(const char *name);
 
+int module_add_named_dependency(const char *name, struct module *this);
+
 /* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
    symnum out of range. */
 int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,

@@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned long addr, unsigned long *
 	return -ERANGE;
 }
 
+static inline int module_add_named_dependency(const char *name, struct module *this)
+{
+	return 0;
+}
+
 static inline int module_get_kallsym(unsigned int symnum, unsigned long *value,
 					char *type, char *name,
 					char *module_name, int *exported)

kernel/module/main.c +31 -0

index 05a42d8fcd7a..dbd577ccc38c 100644
@@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module *b)
 	return 0;
 }
 
+int module_add_named_dependency(const char *name, struct module *this)
+{
+	struct module *mod;
+	int ret;
+
+	if (!name || !this || !this->name) {
+		return -EINVAL;
+	}
+
+	mutex_lock(&module_mutex);
+	mod = find_module(name);
+	if (!mod) {
+		ret = -EINVAL;
+		goto ret;
+	}
+
+	ret = ref_module(this, mod);
+	if (ret)
+		goto ret;
+
+#ifdef CONFIG_MODULE_UNLOAD
+	ret = sysfs_create_link(mod->holders_dir,
+				&this->mkobj.kobj, this->name);
+#endif
+
+ret:
+	mutex_unlock(&module_mutex);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(module_add_named_dependency);
+
 /* Clear the unload stuff of the module. */
 static void module_unload_free(struct module *mod)
 {

Signature · 1 line

2.35.1

Daniel Vetter

2022-04-29 07:54 UTC #2 lore raw

Re: [PATCH 1/2] module: add a function to add module references

Quoted 8 lines · Mauro Carvalho Chehab

Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>

This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.

Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.

Adding Greg for device model questions like this.
-Daniel

Quoted 78 lines

---

See [PATCH 0/2] at: https://lore.kernel.org/all/[email protected]/

 include/linux/module.h |  7 +++++++
 kernel/module/main.c   | 31 +++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

include/linux/module.h +7 -0

index 46d4d5f2516e..be74f807e41d 100644
@@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr, const struct module *mod)
 /* Search for module by name: must be in a RCU-sched critical section. */
 struct module *find_module(const char *name);
 
+int module_add_named_dependency(const char *name, struct module *this);
+
 /* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
    symnum out of range. */
 int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,

@@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned long addr, unsigned long *
 	return -ERANGE;
 }
 
+static inline int module_add_named_dependency(const char *name, struct module *this)
+{
+	return 0;
+}
+
 static inline int module_get_kallsym(unsigned int symnum, unsigned long *value,
 					char *type, char *name,
 					char *module_name, int *exported)

kernel/module/main.c +31 -0

index 05a42d8fcd7a..dbd577ccc38c 100644
@@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module *b)
 	return 0;
 }
 
+int module_add_named_dependency(const char *name, struct module *this)
+{
+	struct module *mod;
+	int ret;
+
+	if (!name || !this || !this->name) {
+		return -EINVAL;
+	}
+
+	mutex_lock(&module_mutex);
+	mod = find_module(name);
+	if (!mod) {
+		ret = -EINVAL;
+		goto ret;
+	}
+
+	ret = ref_module(this, mod);
+	if (ret)
+		goto ret;
+
+#ifdef CONFIG_MODULE_UNLOAD
+	ret = sysfs_create_link(mod->holders_dir,
+				&this->mkobj.kobj, this->name);
+#endif
+
+ret:
+	mutex_unlock(&module_mutex);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(module_add_named_dependency);
+
 /* Clear the unload stuff of the module. */
 static void module_unload_free(struct module *mod)
 {

Signature · 1 line

2.35.1

Signature · 3 lines

Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Mauro Carvalho Chehab

author

2022-04-29 08:08 UTC #3 lore raw

Re: [PATCH 1/2] module: add a function to add module references

Hi Daniel,

Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter <[email protected]> escreveu:

Quoted 16 lines · Mauro Carvalho Chehab

Quoted 8 lines
Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.

Quoted 5 lines

Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.

I agree with you that the device link between snd-hda and the DRM driver should properly handle unbinding on both directions. This is something that require further discussions with ALSA and DRM people, and we should keep working on it.

Yet, the binding between those drivers do exist, but, despite other similar inter-driver bindings being properly reported by lsmod, this one is invisible for userspace.

What this series does is to make such binding visible. As simple as that.

Quoted 83 lines

Adding Greg for device model questions like this.
-Daniel

Quoted 78 lines

---

See [PATCH 0/2] at: https://lore.kernel.org/all/[email protected]/

 include/linux/module.h |  7 +++++++
 kernel/module/main.c   | 31 +++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

include/linux/module.h +7 -0

index 46d4d5f2516e..be74f807e41d 100644
@@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr, const struct module *mod)
 /* Search for module by name: must be in a RCU-sched critical section. */
 struct module *find_module(const char *name);
 
+int module_add_named_dependency(const char *name, struct module *this);
+
 /* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
    symnum out of range. */
 int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,

@@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned long addr, unsigned long *
 	return -ERANGE;
 }
 
+static inline int module_add_named_dependency(const char *name, struct module *this)
+{
+	return 0;
+}
+
 static inline int module_get_kallsym(unsigned int symnum, unsigned long *value,
 					char *type, char *name,
 					char *module_name, int *exported)

kernel/module/main.c +31 -0

index 05a42d8fcd7a..dbd577ccc38c 100644
@@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module *b)
 	return 0;
 }
 
+int module_add_named_dependency(const char *name, struct module *this)
+{
+	struct module *mod;
+	int ret;
+
+	if (!name || !this || !this->name) {
+		return -EINVAL;
+	}
+
+	mutex_lock(&module_mutex);
+	mod = find_module(name);
+	if (!mod) {
+		ret = -EINVAL;
+		goto ret;
+	}
+
+	ret = ref_module(this, mod);
+	if (ret)
+		goto ret;
+
+#ifdef CONFIG_MODULE_UNLOAD
+	ret = sysfs_create_link(mod->holders_dir,
+				&this->mkobj.kobj, this->name);
+#endif
+
+ret:
+	mutex_unlock(&module_mutex);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(module_add_named_dependency);
+
 /* Clear the unload stuff of the module. */
 static void module_unload_free(struct module *mod)
 {

Signature · 1 line

2.35.1

Greg KH

2022-04-29 08:30 UTC #4 lore raw

Re: [PATCH 1/2] module: add a function to add module references

Quoted 32 lines · Mauro Carvalho Chehab

Hi Daniel,
Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter <[email protected]> escreveu:
Quoted 16 lines · Mauro Carvalho Chehab
Quoted 8 lines
Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.
Quoted 5 lines
Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.
I agree with you that the device link between snd-hda and the DRM driver should properly handle unbinding on both directions. This is something that require further discussions with ALSA and DRM people, and we should keep working on it.

Quoted 5 lines

Yet, the binding between those drivers do exist, but, despite other similar inter-driver bindings being properly reported by lsmod, this one is invisible for userspace.
What this series does is to make such binding visible. As simple as that.

It also increases the reference count, and creates a user/kernel api with the symlinks, right? Will the reference count increase prevent the modules from now being unloadable?

This feels like a very "weak" link between modules that should not be needed if reference counting is implemented properly (so that things are cleaned up in the correct order.)

Please don't paper over the real issue with this hack.

thanks,

greg k-h

Mauro Carvalho Chehab

author

2022-04-29 09:15 UTC #5 lore raw

Re: [PATCH 1/2] module: add a function to add module references

HI Greg,

Em Fri, 29 Apr 2022 10:30:33 +0200
Greg KH <[email protected]> escreveu:

Quoted 39 lines · Mauro Carvalho Chehab

Quoted 32 lines
Hi Daniel,
Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter <[email protected]> escreveu:
Quoted 16 lines · Mauro Carvalho Chehab
Quoted 8 lines
Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.
Quoted 5 lines
Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.
I agree with you that the device link between snd-hda and the DRM driver should properly handle unbinding on both directions. This is something that require further discussions with ALSA and DRM people, and we should keep working on it.
Quoted 5 lines
Yet, the binding between those drivers do exist, but, despite other similar inter-driver bindings being properly reported by lsmod, this one is invisible for userspace.
What this series does is to make such binding visible. As simple as that.

Quoted 7 lines

It also increases the reference count, and creates a user/kernel api with the symlinks, right? Will the reference count increase prevent the modules from now being unloadable?
This feels like a very "weak" link between modules that should not be needed if reference counting is implemented properly (so that things are cleaned up in the correct order.)

The refcount increment exists even without this patch, as hda_component_master_bind() at sound/hda/hdac_component.c uses try_module_get() when it creates the device link.

This series won't change anything with that regards. The only difference is that it will now properly report userspace that snd-hda will be using something inside the DRM driver (basically, it uses the DRM driver to power-control the HDA hardware on modern CPU/GPUs).

Btw, this is not the only case where userspace invisible bindings between two driver happen within the Kernel. On media, DVB drivers attach the frontend/tuner drivers using I2C bus on a way where lsmod doesn't current report any dependencies. See, for instance, PCTV 290e driver (partial) dependency chain:

	$ lsmod
	Module                  Size  Used by
	rc_pinnacle_pctv_hd    16384  0
	em28xx_rc              20480  0
	tda18271               53248  1
	cxd2820r               45056  1
	em28xx_dvb             36864  0
	dvb_core              155648  2 cxd2820r,em28xx_dvb
	em28xx                106496  2 em28xx_rc,em28xx_dvb
	tveeprom               28672  1 em28xx
	videobuf2_vmalloc      20480  1 uvcvideo
	videobuf2_memops       20480  1 videobuf2_vmalloc
	videobuf2_common       69632  4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops
	videodev              266240  4 videobuf2_v4l2,uvcvideo,videobuf2_common,em28xx
	mc                     65536  6 videodev,videobuf2_v4l2,uvcvideo,dvb_core,videobuf2_common,em28xx

In the above example, tda18271 is an I2C tuner driver which talks to the hardware via the I2C bus registered by the em28xx driver. It is loaded during em28xx probing time.

Again, lsmod doesn't show such dependencies. One can't remove the tuner driver without first removing the em28xx driver, which is the one that increments its refcount.

Back to the snd-hda issue, the problem is not with refcount. It is, instead, to provide a way for userspace to know what's the correct order to remove/unbind modules.

Regards,
Mauro

Greg KH

2022-04-29 10:10 UTC #6 lore raw

Re: [PATCH 1/2] module: add a function to add module references

Quoted 48 lines · Mauro Carvalho Chehab

HI Greg,
Em Fri, 29 Apr 2022 10:30:33 +0200
Greg KH <[email protected]> escreveu:
Quoted 43 lines · Mauro Carvalho Chehab
Quoted 32 lines
Hi Daniel,
Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter <[email protected]> escreveu:
Quoted 16 lines · Mauro Carvalho Chehab
Quoted 8 lines
Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.
Quoted 5 lines
Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.
I agree with you that the device link between snd-hda and the DRM driver should properly handle unbinding on both directions. This is something that require further discussions with ALSA and DRM people, and we should keep working on it.
Quoted 5 lines
Yet, the binding between those drivers do exist, but, despite other similar inter-driver bindings being properly reported by lsmod, this one is invisible for userspace.
What this series does is to make such binding visible. As simple as that.
It also increases the reference count, and creates a user/kernel api with the symlinks, right? Will the reference count increase prevent the modules from now being unloadable?

Quoted 7 lines

Quoted 3 lines
This feels like a very "weak" link between modules that should not be needed if reference counting is implemented properly (so that things are cleaned up in the correct order.)
The refcount increment exists even without this patch, as hda_component_master_bind() at sound/hda/hdac_component.c uses try_module_get() when it creates the device link.

Ok, then why shouldn't try_module_get() be creating this link instead of having to manually do it this way again? You don't want to have to go around and add this call to all users of that function, right?

thanks,

greg k-h

Mauro Carvalho Chehab

author

2022-04-29 10:24 UTC #7 lore raw

Re: [PATCH 1/2] module: add a function to add module references

Em Fri, 29 Apr 2022 12:10:07 +0200
Greg KH <[email protected]> escreveu:

Quoted 53 lines · Mauro Carvalho Chehab

Quoted 52 lines
HI Greg,
Em Fri, 29 Apr 2022 10:30:33 +0200
Greg KH <[email protected]> escreveu:
Quoted 46 lines · Mauro Carvalho Chehab
Quoted 32 lines
Hi Daniel,
Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter <[email protected]> escreveu:
Quoted 16 lines · Mauro Carvalho Chehab
Quoted 8 lines
Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.
Quoted 5 lines
Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.
I agree with you that the device link between snd-hda and the DRM driver should properly handle unbinding on both directions. This is something that require further discussions with ALSA and DRM people, and we should keep working on it.
Quoted 5 lines
Yet, the binding between those drivers do exist, but, despite other similar inter-driver bindings being properly reported by lsmod, this one is invisible for userspace.
What this series does is to make such binding visible. As simple as that.
It also increases the reference count, and creates a user/kernel api with the symlinks, right? Will the reference count increase prevent the modules from now being unloadable?
This feels like a very "weak" link between modules that should not be needed if reference counting is implemented properly (so that things are cleaned up in the correct order.)

Quoted 7 lines

Quoted 3 lines
The refcount increment exists even without this patch, as hda_component_master_bind() at sound/hda/hdac_component.c uses try_module_get() when it creates the device link.
Ok, then why shouldn't try_module_get() be creating this link instead of having to manually do it this way again? You don't want to have to go around and add this call to all users of that function, right?

Works for me, but this is not a too trivial change, as the new try_module_get() function will require two parameters, instead of one:

- the module to be referenced;
- the module which will reference it.

On trivial cases, one will be THIS_MODULE, but, in the specific case of snd_hda, the binding is done via an ancillary routine under snd_hda_core, but the actual binding happens at snd_hda_intel.

Ok, we could add a __try_module_get() (or whatever other name that would properly express what it does) with two parameters, and then define try_module_get() as:

	#define try_module_get(mod) __try_module_get(mod, THIS_MODULE)

Would that work for you?

Regards,
Mauro

Greg KH

2022-04-29 10:36 UTC #8 lore raw

Re: [PATCH 1/2] module: add a function to add module references

Quoted 67 lines · Mauro Carvalho Chehab

Em Fri, 29 Apr 2022 12:10:07 +0200
Greg KH <[email protected]> escreveu:
Quoted 53 lines · Mauro Carvalho Chehab
Quoted 52 lines
HI Greg,
Em Fri, 29 Apr 2022 10:30:33 +0200
Greg KH <[email protected]> escreveu:
Quoted 46 lines · Mauro Carvalho Chehab
Quoted 32 lines
Hi Daniel,
Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter <[email protected]> escreveu:
Quoted 16 lines · Mauro Carvalho Chehab
Quoted 8 lines
Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.
Quoted 5 lines
Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.
I agree with you that the device link between snd-hda and the DRM driver should properly handle unbinding on both directions. This is something that require further discussions with ALSA and DRM people, and we should keep working on it.
Quoted 5 lines
Yet, the binding between those drivers do exist, but, despite other similar inter-driver bindings being properly reported by lsmod, this one is invisible for userspace.
What this series does is to make such binding visible. As simple as that.
It also increases the reference count, and creates a user/kernel api with the symlinks, right? Will the reference count increase prevent the modules from now being unloadable?
This feels like a very "weak" link between modules that should not be needed if reference counting is implemented properly (so that things are cleaned up in the correct order.)
Quoted 7 lines
Quoted 3 lines
The refcount increment exists even without this patch, as hda_component_master_bind() at sound/hda/hdac_component.c uses try_module_get() when it creates the device link.
Ok, then why shouldn't try_module_get() be creating this link instead of having to manually do it this way again? You don't want to have to go around and add this call to all users of that function, right?
Works for me, but this is not a too trivial change, as the new try_module_get() function will require two parameters, instead of one:

Quoted 6 lines

- the module to be referenced;
- the module which will reference it.
On trivial cases, one will be THIS_MODULE, but, in the specific case of snd_hda, the binding is done via an ancillary routine under snd_hda_core, but the actual binding happens at snd_hda_intel.

For calls that want to increment a module reference on behalf of a different code segment than is calling it, create a new function so we can audit-the-heck out of those code paths as odds are, they are unsafe.

For the normal code path, just turn try_module_get() into a macro that includes THIS_MODULE as part of it like we do for the driver register functions (see usb_register_driver() in include/linux/usb.h as an example of how to do that.)

Quoted 5 lines

Ok, we could add a __try_module_get() (or whatever other name that would properly express what it does) with two parameters, and then define try_module_get() as:
	#define try_module_get(mod) __try_module_get(mod, THIS_MODULE)

Yes, that's the way forward.

thanks,

greg k-h

Daniel Vetter

2022-05-04 08:50 UTC #9 lore raw

Re: [PATCH 1/2] module: add a function to add module references

Quoted 84 lines · Greg KH

Quoted 67 lines · Mauro Carvalho Chehab
Em Fri, 29 Apr 2022 12:10:07 +0200
Greg KH <[email protected]> escreveu:
Quoted 53 lines · Mauro Carvalho Chehab
Quoted 52 lines
HI Greg,
Em Fri, 29 Apr 2022 10:30:33 +0200
Greg KH <[email protected]> escreveu:
Quoted 46 lines · Mauro Carvalho Chehab
Quoted 32 lines
Hi Daniel,
Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter <[email protected]> escreveu:
Quoted 16 lines · Mauro Carvalho Chehab
Quoted 8 lines
Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.
Quoted 5 lines
Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.
I agree with you that the device link between snd-hda and the DRM driver should properly handle unbinding on both directions. This is something that require further discussions with ALSA and DRM people, and we should keep working on it.
Quoted 5 lines
Yet, the binding between those drivers do exist, but, despite other similar inter-driver bindings being properly reported by lsmod, this one is invisible for userspace.
What this series does is to make such binding visible. As simple as that.
It also increases the reference count, and creates a user/kernel api with the symlinks, right? Will the reference count increase prevent the modules from now being unloadable?
This feels like a very "weak" link between modules that should not be needed if reference counting is implemented properly (so that things are cleaned up in the correct order.)
Quoted 7 lines
Quoted 3 lines
The refcount increment exists even without this patch, as hda_component_master_bind() at sound/hda/hdac_component.c uses try_module_get() when it creates the device link.
Ok, then why shouldn't try_module_get() be creating this link instead of having to manually do it this way again? You don't want to have to go around and add this call to all users of that function, right?
Works for me, but this is not a too trivial change, as the new try_module_get() function will require two parameters, instead of one:
Quoted 6 lines
- the module to be referenced;
- the module which will reference it.
On trivial cases, one will be THIS_MODULE, but, in the specific case of snd_hda, the binding is done via an ancillary routine under snd_hda_core, but the actual binding happens at snd_hda_intel.
For calls that want to increment a module reference on behalf of a different code segment than is calling it, create a new function so we can audit-the-heck out of those code paths as odds are, they are unsafe.
For the normal code path, just turn try_module_get() into a macro that includes THIS_MODULE as part of it like we do for the driver register functions (see usb_register_driver() in include/linux/usb.h as an example of how to do that.)

Quoted 7 lines

Quoted 5 lines
Ok, we could add a __try_module_get() (or whatever other name that would properly express what it does) with two parameters, and then define try_module_get() as:
	#define try_module_get(mod) __try_module_get(mod, THIS_MODULE)
Yes, that's the way forward.

This might result in some complaints because it can create module refcount loops. Well, seemingly module refcount loops, you can break them by first unloading the driver, and then unloading the module. Currently a lot of folks rely on just unload the module to tear down the drivers (and all in right order through device links and component and all that). So maybe we want to make this some kind of weak reference, i.e. it shows up in lsmod, but the magic teardown still works and the module isn't actually pinnned.

Either way I agree that something like this sounds like the right approach.
-Daniel

Quoted 4 lines

thanks,
greg k-h

Signature · 3 lines

Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Lucas De Marchi

2022-04-29 15:53 UTC #10 lore raw

Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references

In reply to Mauro Carvalho Chehab

Quoted 74 lines · Mauro Carvalho Chehab

Em Fri, 29 Apr 2022 12:10:07 +0200
Greg KH <[email protected]> escreveu:
Quoted 53 lines · Mauro Carvalho Chehab
Quoted 52 lines
HI Greg,
Em Fri, 29 Apr 2022 10:30:33 +0200
Greg KH <[email protected]> escreveu:
Quoted 46 lines · Mauro Carvalho Chehab
Quoted 32 lines
Hi Daniel,
Em Fri, 29 Apr 2022 09:54:10 +0200
Daniel Vetter <[email protected]> escreveu:
Quoted 16 lines · Mauro Carvalho Chehab
Quoted 8 lines
Sometimes, device drivers are bound using indirect references, which is not visible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such cases.
Reviewed-by Dan Williams <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
This sounds like duct tape at the wrong level. We should have a device_link connecting these devices, and maybe device_link internally needs to make sure the respective driver modules stay around for long enough too. But open-coding this all over the place into every driver that has some kind of cross-driver dependency sounds terrible.
Quoted 5 lines
Or maybe the bug is that the snd driver keeps accessing the hw/component side when that is just plain gone. Iirc there's still fundamental issues there on the sound side of things, which have been attempted to paper over by timeouts and stuff like that in the past instead of enforcing a hard link between the snd and i915 side.
I agree with you that the device link between snd-hda and the DRM driver should properly handle unbinding on both directions. This is something that require further discussions with ALSA and DRM people, and we should keep working on it.
Quoted 5 lines
Yet, the binding between those drivers do exist, but, despite other similar inter-driver bindings being properly reported by lsmod, this one is invisible for userspace.
What this series does is to make such binding visible. As simple as that.
It also increases the reference count, and creates a user/kernel api with the symlinks, right? Will the reference count increase prevent the modules from now being unloadable?
This feels like a very "weak" link between modules that should not be needed if reference counting is implemented properly (so that things are cleaned up in the correct order.)
Quoted 7 lines
Quoted 3 lines
The refcount increment exists even without this patch, as hda_component_master_bind() at sound/hda/hdac_component.c uses try_module_get() when it creates the device link.
Ok, then why shouldn't try_module_get() be creating this link instead of having to manually do it this way again? You don't want to have to go around and add this call to all users of that function, right?
Works for me, but this is not a too trivial change, as the new try_module_get() function will require two parameters, instead of one:
- the module to be referenced;
- the module which will reference it.
On trivial cases, one will be THIS_MODULE, but, in the specific case of snd_hda, the binding is done via an ancillary routine under snd_hda_core, but the actual binding happens at snd_hda_intel.

Quoted 5 lines

Ok, we could add a __try_module_get() (or whatever other name that would properly express what it does) with two parameters, and then define try_module_get() as:
	#define try_module_get(mod) __try_module_get(mod, THIS_MODULE)

agree that this should be done at this level rather than open coding it at every driver. Main improvement being fixed here regardless of the snd-hda-intel issue is to properly annotate what is holding a module.

Right now we have 1) symbol module dependencies; 2) kernel references;
3) userspace references. With (2) and (3) being unknown to the user from lsmod pov. Handling this any time try_module_get() is called would make
(2) visible to lsmod.

Paired with fixes to the (unreleased) kmod 30[1], this allows modprobe -r --remove-holders <module> to also try removing the holders before removing the module itself.

thanks
Lucas De Marchi

[1] https://lore.kernel.org/linux-modules/[email protected]/T/#t

Quoted 5 lines

Would that work for you?
Regards,
Mauro

Mauro Carvalho Chehab

author

2022-04-29 06:31 UTC #11 lore raw

PATCH 2/2 ALSA: hda - identify when audio is provided by a video driver

In reply to Mauro Carvalho Chehab

On some devices, the hda driver needs to hook into a video driver, in order to be able to properly access the audio hardware and/or the power management function.

That's the case of several snd_hda_intel devices that depends on i915 driver.

Currently, this dependency is hidden from /proc/modules and from lsmod, making harder to identify the need to unbind the audio driver before being able to unbind the i915 driver.

Add a reference for it at the module dependency, in order to allow userspace to identify it, and print a message on such cases.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

---

See [PATCH 0/2] at: https://lore.kernel.org/all/[email protected]/

 sound/hda/hdac_component.c | 8 ++++++++
 1 file changed, 8 insertions(+)

sound/hda/hdac_component.c +8 -0

index bb37e7e0bd79..103c6be8be1e 100644
@@ -211,6 +211,14 @@ static int hdac_component_master_bind(struct device *dev)
 	}
 
 	complete_all(&acomp->master_bind_complete);
+
+	if (acomp->ops->owner && acomp->ops->owner->name) {
+		dev_info(dev, "audio component provided by %s driver\n",
+			 acomp->ops->owner->name);
+		module_add_named_dependency(acomp->ops->owner->name,
+					    dev->driver->owner);
+	}
+
 	return 0;
 
  module_put:

Signature · 1 line

2.35.1

Patchwork

2022-04-29 06:56 UTC #12 lore raw

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Let userspace know when snd-hda-intel needs i915

In reply to Mauro Carvalho Chehab

== Series Details ==

Series: Let userspace know when snd-hda-intel needs i915
URL : https://patchwork.freedesktop.org/series/103315/
State : warning

== Summary ==

Error: dim checkpatch failed
4f9130351583 module: add a function to add module references -:53: WARNING:BRACES: braces {} are not necessary for single statement blocks #53: FILE: kernel/module.c:838:
+ if (!name || !this || !this->name) {
+ return -EINVAL;
+ }

total: 0 errors, 1 warnings, 0 checks, 56 lines checked 488163eb8175 ALSA: hda - identify when audio is provided by a video driver

Patchwork

2022-04-29 06:56 UTC #13 lore raw

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Let userspace know when snd-hda-intel needs i915

In reply to Mauro Carvalho Chehab

== Series Details ==

Series: Let userspace know when snd-hda-intel needs i915
URL : https://patchwork.freedesktop.org/series/103315/
State : warning

== Summary ==

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

Patchwork

2022-04-29 07:19 UTC #14 lore raw

[Intel-gfx] ✓ Fi.CI.BAT: success for Let userspace know when snd-hda-intel needs i915

In reply to Mauro Carvalho Chehab

== Series Details ==

Series: Let userspace know when snd-hda-intel needs i915
URL : https://patchwork.freedesktop.org/series/103315/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103315v1
====================================================

Summary
-------

**SUCCESS**

No regressions found.

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

Participating hosts (43 -> 43)
------------------------------

Additional (2): bat-dg1-6 bat-adlp-4
Missing (2): fi-kbl-soraka fi-bsw-cyan

Possible new issues
-------------------

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

### IGT changes ###

#### Suppressed ####

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

* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: [PASS][1] -> [DMESG-WARN][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html

* igt@i915_selftest@live@vma:
- {bat-rpls-1}: [PASS][3] -> [INCOMPLETE][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@[email protected]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-rpls-1/igt@i915_selftest@[email protected]

Known issues
------------

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

### IGT changes ###

#### Issues hit ####

* igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][5] ([i915#5827])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-dg1-6/igt@gem_exec_suspend@[email protected]

* igt@gem_lmem_swapping@basic:
- bat-adlp-4: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@[email protected]

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

* igt@i915_pm_rpm@module-reload:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][8] ([i915#3576]) +3 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@[email protected]

* igt@kms_chamelium@dp-crc-fast:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@[email protected]

* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-4: NOTRUN -> [SKIP][10] ([i915#4103]) +1 similar issue
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@[email protected]

* igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-4: NOTRUN -> [SKIP][11] ([i915#4093]) +3 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@[email protected]

* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [PASS][12] -> [DMESG-WARN][13] ([i915#62]) +11 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-8109u/igt@[email protected]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/fi-cfl-8109u/igt@[email protected]

* igt@kms_setmode@basic-clone-single-crtc:
- bat-adlp-4: NOTRUN -> [SKIP][14] ([i915#3555])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@[email protected]

* igt@prime_vgem@basic-fence-read:
- bat-adlp-4: NOTRUN -> [SKIP][15] ([i915#3291] / [i915#3708]) +2 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@[email protected]

* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][16] ([i915#3301] / [i915#3708])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-4/igt@[email protected]

#### Possible fixes ####

* igt@i915_module_load@reload:
- {bat-rpls-2}: [DMESG-WARN][17] ([i915#5537]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@[email protected]
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-rpls-2/igt@[email protected]

* igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][19] ([i915#5334]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770: [INCOMPLETE][21] ([i915#4785]) -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-hsw-4770/igt@i915_selftest@[email protected]
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/fi-hsw-4770/igt@i915_selftest@[email protected]
- fi-snb-2600: [INCOMPLETE][23] ([i915#3921]) -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-snb-2600/igt@i915_selftest@[email protected]
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/fi-snb-2600/igt@i915_selftest@[email protected]

* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][25] ([i915#3576]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@[email protected]
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/bat-adlp-6/igt@kms_busy@[email protected]

#### Warnings ####

* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: [INCOMPLETE][27] ([i915#5127]) -> [INCOMPLETE][28] ([i915#5127] / [i915#5857])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-rkl-11600/igt@gem_exec_suspend@[email protected]
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/fi-rkl-11600/igt@gem_exec_suspend@[email protected]

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

Build changes
-------------

* Linux: CI_DRM_11550 -> Patchwork_103315v1

CI-20190529: 20190529
CI_DRM_11550: 56b089ae03ef8ea8ab7f474eaa70367898891ef0 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6451: f055bd83bd831a938d639718c2359516224f15f9 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_103315v1: 56b089ae03ef8ea8ab7f474eaa70367898891ef0 @ git://anongit.freedesktop.org/gfx-ci/linux

### Linux commits

1a869a51e1fc ALSA: hda - identify when audio is provided by a video driver 6a8c66c0e09f module: add a function to add module references

== Logs ==

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

Patchwork

2022-04-29 08:40 UTC #15 lore raw

[Intel-gfx] ✓ Fi.CI.IGT: success for Let userspace know when snd-hda-intel needs i915

In reply to Mauro Carvalho Chehab

== Series Details ==

Series: Let userspace know when snd-hda-intel needs i915
URL : https://patchwork.freedesktop.org/series/103315/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103315v1_full
====================================================

Summary
-------

**SUCCESS**

No regressions found.

Participating hosts (10 -> 13)
------------------------------

Additional (3): shard-rkl shard-dg1 shard-tglu

Possible new issues
-------------------

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

### IGT changes ###

#### Suppressed ####

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

* igt@gem_exec_suspend@basic-s0@smem:
- {shard-dg1}: NOTRUN -> [INCOMPLETE][1] +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-dg1-12/igt@gem_exec_suspend@[email protected]

* igt@i915_selftest@mock@hugepages:
- {shard-rkl}: NOTRUN -> [INCOMPLETE][2]
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-rkl-5/igt@i915_selftest@[email protected]

* {igt@kms_concurrent@pipe-d@hdmi-a-3}:
- {shard-dg1}: NOTRUN -> [CRASH][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-dg1-18/igt@kms_concurrent@[email protected]

New tests
---------

New tests have been introduced between CI_DRM_11550_full and Patchwork_103315v1_full:

### New IGT tests (4) ###

* igt@kms_sequence@get-busy@hdmi-a-3-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [2.43] s

* igt@kms_sequence@get-busy@hdmi-a-3-pipe-b:
- Statuses : 1 pass(s)
- Exec time: [2.38] s

* igt@kms_sequence@get-busy@hdmi-a-3-pipe-c:
- Statuses : 1 pass(s)
- Exec time: [2.38] s

* igt@kms_sequence@get-busy@hdmi-a-3-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [2.39] s

Known issues
------------

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

### CI changes ###

#### Possible fixes ####

### IGT changes ###

#### Issues hit ####

* igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl: NOTRUN -> [SKIP][52] ([fdo#109271]) +165 similar issues
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl10/igt@gem_exec_fair@[email protected]

* igt@gem_exec_fair@basic-none@vecs0:
- shard-glk: [PASS][53] -> [FAIL][54] ([i915#2842])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk4/igt@gem_exec_fair@[email protected]
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-glk3/igt@gem_exec_fair@[email protected]

* igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl: [PASS][55] -> [SKIP][56] ([fdo#109271])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-kbl4/igt@gem_exec_fair@[email protected]
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-kbl4/igt@gem_exec_fair@[email protected]

* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][57] ([i915#2842])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-iclb4/igt@gem_exec_fair@[email protected]

* igt@gem_exec_flush@basic-uc-prw-default:
- shard-snb: [PASS][58] -> [SKIP][59] ([fdo#109271]) +1 similar issue
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-snb2/igt@[email protected]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-snb6/igt@[email protected]

* igt@gem_huc_copy@huc-copy:
- shard-skl: NOTRUN -> [SKIP][60] ([fdo#109271] / [i915#2190])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl8/igt@[email protected]

* igt@gem_lmem_swapping@verify-ccs:
- shard-skl: NOTRUN -> [SKIP][61] ([fdo#109271] / [i915#4613]) +2 similar issues
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl9/igt@[email protected]

* igt@gem_lmem_swapping@verify-random-ccs:
- shard-apl: NOTRUN -> [SKIP][62] ([fdo#109271] / [i915#4613])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl8/igt@[email protected]

* igt@gem_softpin@allocator-evict-all-engines:
- shard-glk: [PASS][63] -> [FAIL][64] ([i915#4171])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk5/igt@[email protected]
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-glk1/igt@[email protected]

* igt@gem_userptr_blits@dmabuf-sync:
- shard-apl: NOTRUN -> [SKIP][65] ([fdo#109271] / [i915#3323])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl2/igt@[email protected]

* igt@i915_module_load@reload:
- shard-skl: [PASS][66] -> [DMESG-WARN][67] ([i915#1982])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/igt@[email protected]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl9/igt@[email protected]

* igt@i915_pm_dc@dc6-psr:
- shard-skl: NOTRUN -> [FAIL][68] ([i915#454])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl7/igt@[email protected]

* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp:
- shard-apl: NOTRUN -> [SKIP][69] ([fdo#109271] / [i915#1937])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl7/igt@i915_pm_lpsp@[email protected]

* igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl: [PASS][70] -> [FAIL][71] ([i915#2521])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/igt@[email protected]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl6/igt@[email protected]

* igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][72] ([fdo#109271] / [i915#3886]) +3 similar issues
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl7/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs.html

* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs:
- shard-apl: NOTRUN -> [SKIP][73] ([fdo#109271]) +115 similar issues
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl8/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs.html

* igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-skl: NOTRUN -> [SKIP][74] ([fdo#109271] / [i915#3886]) +6 similar issues
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl9/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_mc_ccs.html

* igt@kms_color_chamelium@pipe-a-ctm-0-5:
- shard-apl: NOTRUN -> [SKIP][75] ([fdo#109271] / [fdo#111827]) +5 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl7/igt@[email protected]

* igt@kms_color_chamelium@pipe-d-ctm-0-25:
- shard-skl: NOTRUN -> [SKIP][76] ([fdo#109271] / [fdo#111827]) +11 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl6/igt@[email protected]

* igt@kms_content_protection@lic:
- shard-apl: NOTRUN -> [TIMEOUT][77] ([i915#1319])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl7/igt@[email protected]

* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][78] -> [INCOMPLETE][79] ([i915#3614])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-kbl4/igt@[email protected]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-kbl3/igt@[email protected]

* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][80] -> [FAIL][81] ([i915#2346])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk9/igt@[email protected]
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-glk9/igt@[email protected]

* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][82] -> [FAIL][83] ([i915#2122])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk3/igt@kms_flip@[email protected]
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-glk6/igt@kms_flip@[email protected]

* igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@a-edp1:
- shard-skl: [PASS][84] -> [FAIL][85] ([i915#2122]) +2 similar issues
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/igt@kms_flip@[email protected]
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl3/igt@kms_flip@[email protected]

* igt@kms_flip@flip-vs-suspend@a-dp1:
- shard-apl: [PASS][86] -> [DMESG-WARN][87] ([i915#180]) +3 similar issues
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl6/igt@kms_flip@[email protected]
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl4/igt@kms_flip@[email protected]

* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling:
- shard-skl: NOTRUN -> [SKIP][88] ([fdo#109271] / [i915#3701])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl8/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html

* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-skl: NOTRUN -> [SKIP][89] ([fdo#109271] / [i915#533])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl9/igt@[email protected]

* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-apl: NOTRUN -> [FAIL][90] ([i915#265])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl7/igt@[email protected]

* igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb:
- shard-skl: NOTRUN -> [FAIL][91] ([i915#265])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl7/igt@[email protected]

* igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-75@pipe-b-edp-1-downscale-with-pixel-format:
- shard-iclb: [PASS][92] -> [INCOMPLETE][93] ([i915#5293])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-iclb4/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-75@pipe-b-edp-1-downscale-with-pixel-format.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-iclb2/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-75@pipe-b-edp-1-downscale-with-pixel-format.html

* igt@kms_psr2_su@page_flip-p010:
- shard-skl: NOTRUN -> [SKIP][94] ([fdo#109271] / [i915#658])
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl9/igt@kms_psr2_su@page_flip-p010.html

* igt@kms_writeback@writeback-check-output:
- shard-skl: NOTRUN -> [SKIP][95] ([fdo#109271] / [i915#2437])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl7/igt@[email protected]

* igt@kms_writeback@writeback-invalid-parameters:
- shard-apl: NOTRUN -> [SKIP][96] ([fdo#109271] / [i915#2437])
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl8/igt@[email protected]

* igt@syncobj_timeline@invalid-transfer-non-existent-point:
- shard-skl: NOTRUN -> [DMESG-WARN][97] ([i915#5098])
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl10/igt@[email protected]

* igt@sysfs_clients@sema-25:
- shard-skl: NOTRUN -> [SKIP][98] ([fdo#109271] / [i915#2994]) +2 similar issues
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl9/igt@[email protected]

#### Possible fixes ####

* igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [TIMEOUT][99] ([i915#3063]) -> [PASS][100]
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb3/igt@[email protected]
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-tglb7/igt@[email protected]

* igt@gem_eio@kms:
- shard-tglb: [FAIL][101] ([i915#232]) -> [PASS][102]
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb3/igt@[email protected]
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-tglb7/igt@[email protected]

* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [FAIL][103] ([i915#2842]) -> [PASS][104]
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb6/igt@gem_exec_fair@[email protected]
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-tglb6/igt@gem_exec_fair@[email protected]

* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [FAIL][105] ([i915#2849]) -> [PASS][106]
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-iclb7/igt@gem_exec_fair@[email protected]
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-iclb8/igt@gem_exec_fair@[email protected]

* igt@gem_exec_flush@basic-uc-rw-default:
- shard-snb: [SKIP][107] ([fdo#109271]) -> [PASS][108] +1 similar issue
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-snb6/igt@[email protected]
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-snb5/igt@[email protected]

* igt@gem_exec_whisper@basic-fds-forked-all:
- shard-skl: [INCOMPLETE][109] ([i915#5843]) -> [PASS][110]
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/igt@[email protected]
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl8/igt@[email protected]

* igt@gem_softpin@softpin:
- shard-skl: [DMESG-WARN][111] ([i915#1982]) -> [PASS][112]
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/igt@[email protected]
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl3/igt@[email protected]

* igt@kms_async_flips@alternate-sync-async-flip:
- shard-glk: [FAIL][113] ([i915#2521]) -> [PASS][114]
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk6/igt@[email protected]
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-glk8/igt@[email protected]
- shard-kbl: [FAIL][115] ([i915#2521]) -> [PASS][116]
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-kbl3/igt@[email protected]
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-kbl6/igt@[email protected]

* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [DMESG-WARN][117] ([i915#180]) -> [PASS][118] +2 similar issues
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl7/igt@[email protected]
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl2/igt@[email protected]

* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: [FAIL][119] ([i915#2346] / [i915#533]) -> [PASS][120]
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk4/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-glk1/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html

* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-skl: [FAIL][121] ([i915#79]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/igt@kms_flip@[email protected]
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl7/igt@kms_flip@[email protected]

* igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
- shard-skl: [FAIL][123] ([i915#2122]) -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/igt@kms_flip@[email protected]
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl7/igt@kms_flip@[email protected]

* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-edp-1-planes-upscale-downscale:
- shard-iclb: [SKIP][125] ([i915#5235]) -> [PASS][126] +2 similar issues
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-edp-1-planes-upscale-downscale.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-iclb1/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-edp-1-planes-upscale-downscale.html

* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [SKIP][127] ([fdo#109441]) -> [PASS][128] +2 similar issues
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-iclb4/igt@kms_psr@psr2_cursor_mmap_cpu.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html

* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][129] ([i915#4939]) -> [PASS][130]
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/igt@[email protected]
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl7/igt@[email protected]

* igt@perf@polling-parameterized:
- shard-skl: [FAIL][131] ([i915#5639]) -> [PASS][132]
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/igt@[email protected]
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl10/igt@[email protected]

#### Warnings ####

* igt@gem_eio@unwedge-stress:
- shard-tglb: [FAIL][133] ([i915#232]) -> [FAIL][134] ([i915#5784])
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb5/igt@[email protected]
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-tglb8/igt@[email protected]

* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-iclb: [SKIP][135] ([i915#588]) -> [SKIP][136] ([i915#658])
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-iclb2/igt@[email protected]
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-iclb6/igt@[email protected]

* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: [SKIP][137] ([fdo#109271] / [i915#3777]) -> [SKIP][138] ([fdo#109271]) +13 similar issues
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-apl2/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-apl6/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html

* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-kbl: [SKIP][139] ([fdo#109271] / [i915#3777]) -> [SKIP][140] ([fdo#109271]) +14 similar issues
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-kbl7/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-kbl7/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
- shard-skl: [SKIP][141] ([fdo#109271] / [i915#3777]) -> [SKIP][142] ([fdo#109271]) +12 similar issues
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-skl1/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html

* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-glk: [SKIP][143] ([fdo#109271] / [i915#3777]) -> [SKIP][144] ([fdo#109271]) +17 similar issues
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk7/igt@[email protected]
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-glk4/igt@[email protected]

* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- shard-snb: [SKIP][145] ([fdo#109271] / [i915#5341]) -> [SKIP][146] ([fdo#109271])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-snb7/igt@[email protected]
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-snb2/igt@[email protected]

* igt@kms_psr2_sf@cursor-plane-move-continuous-sf:
- shard-iclb: [SKIP][147] ([i915#2920]) -> [SKIP][148] ([i915#658])
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-iclb2/igt@[email protected]
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-iclb5/igt@[email protected]

* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-iclb: [SKIP][149] ([i915#2920]) -> [SKIP][150] ([fdo#111068] / [i915#658]) +1 similar issue
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-iclb2/igt@[email protected]
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103315v1/shard-iclb1/igt@[email protected]

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

Build changes
-------------

* Linux: CI_DRM_11550 -> Patchwork_103315v1

== Logs ==

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