All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To: igt-dev@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Subject: [Intel-gfx] [PATCH i-g-t 4/4] tests/core_hotunplug: Select health checks for initially detected chipset
Date: Tue, 13 Sep 2022 14:04:41 +0200	[thread overview]
Message-ID: <20220913120441.146757-5-janusz.krzysztofik@linux.intel.com> (raw)
In-Reply-To: <20220913120441.146757-1-janusz.krzysztofik@linux.intel.com>

As soon as we first time open a drm device to be exercised, we identify
its chipset, store that information, and perform some basic device
specific checks.  We also store a filter that matches the device bus
address to make sure we will exercise still one and the same device after
each driver unbind-rebind / device unplug-rediscover operation.

However, each time before we select device specific health checks, whether
before or after a driver unbind-rebind / device unplug-rediscover
operation, we identify the device chipset again.  Besides being more
expensive, that approach could also result in using different set of
health checks should device filters not work as expected.

Always use the stored chipset type instead of identifying it now and
again.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 tests/core_hotunplug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
index 29cb26ab12..7c7ed09e63 100644
--- a/tests/core_hotunplug.c
+++ b/tests/core_hotunplug.c
@@ -400,7 +400,7 @@ static void node_healthcheck(struct hotunplug *priv, unsigned flags)
 	if (closed)	/* store fd for cleanup if not dirty */
 		priv->fd.drm_hc = fd_drm;
 
-	if (is_i915_device(fd_drm)) {
+	if (priv->chipset == DRIVER_INTEL) {
 		/* don't report library failed asserts as healthcheck failure */
 		priv->failure = "Unrecoverable test failure";
 		if (local_i915_healthcheck(fd_drm, "") &&
-- 
2.25.1


WARNING: multiple messages have this Message-ID (diff)
From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To: igt-dev@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org, Petri Latvala <petri.latvala@intel.com>
Subject: [igt-dev] [PATCH i-g-t 4/4] tests/core_hotunplug: Select health checks for initially detected chipset
Date: Tue, 13 Sep 2022 14:04:41 +0200	[thread overview]
Message-ID: <20220913120441.146757-5-janusz.krzysztofik@linux.intel.com> (raw)
In-Reply-To: <20220913120441.146757-1-janusz.krzysztofik@linux.intel.com>

As soon as we first time open a drm device to be exercised, we identify
its chipset, store that information, and perform some basic device
specific checks.  We also store a filter that matches the device bus
address to make sure we will exercise still one and the same device after
each driver unbind-rebind / device unplug-rediscover operation.

However, each time before we select device specific health checks, whether
before or after a driver unbind-rebind / device unplug-rediscover
operation, we identify the device chipset again.  Besides being more
expensive, that approach could also result in using different set of
health checks should device filters not work as expected.

Always use the stored chipset type instead of identifying it now and
again.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 tests/core_hotunplug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
index 29cb26ab12..7c7ed09e63 100644
--- a/tests/core_hotunplug.c
+++ b/tests/core_hotunplug.c
@@ -400,7 +400,7 @@ static void node_healthcheck(struct hotunplug *priv, unsigned flags)
 	if (closed)	/* store fd for cleanup if not dirty */
 		priv->fd.drm_hc = fd_drm;
 
-	if (is_i915_device(fd_drm)) {
+	if (priv->chipset == DRIVER_INTEL) {
 		/* don't report library failed asserts as healthcheck failure */
 		priv->failure = "Unrecoverable test failure";
 		if (local_i915_healthcheck(fd_drm, "") &&
-- 
2.25.1

  parent reply	other threads:[~2022-09-13 12:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-13 12:04 [Intel-gfx] [PATCH i-g-t 0/4] tests/core_hotunplug: A couple of fixes and enhancements Janusz Krzysztofik
2022-09-13 12:04 ` [igt-dev] " Janusz Krzysztofik
2022-09-13 12:04 ` [Intel-gfx] [PATCH i-g-t 1/4] tests/core_hotunplug: Free mem allocated by igt_audio_driver_unload Janusz Krzysztofik
2022-09-13 12:04   ` [igt-dev] " Janusz Krzysztofik
2022-09-20  5:04   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-09-20  5:04     ` Mauro Carvalho Chehab
2022-09-13 12:04 ` [Intel-gfx] [PATCH i-g-t 2/4] tests/core_hotunplug: Also unload audio before device unplug Janusz Krzysztofik
2022-09-13 12:04   ` [igt-dev] " Janusz Krzysztofik
2022-09-20  5:06   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-09-20  5:06     ` Mauro Carvalho Chehab
2022-09-13 12:04 ` [Intel-gfx] [PATCH i-g-t 3/4] tests/core_hotunplug: Don't apply i915 workarounds on other platforms Janusz Krzysztofik
2022-09-13 12:04   ` [igt-dev] " Janusz Krzysztofik
2022-09-20  5:23   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-09-20  5:23     ` Mauro Carvalho Chehab
2022-09-13 12:04 ` Janusz Krzysztofik [this message]
2022-09-13 12:04   ` [igt-dev] [PATCH i-g-t 4/4] tests/core_hotunplug: Select health checks for initially detected chipset Janusz Krzysztofik
2022-09-20  5:10   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-09-20  5:10     ` Mauro Carvalho Chehab
2022-09-13 14:41 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/core_hotunplug: A couple of fixes and enhancements Patchwork
2022-09-14  2:17 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2022-09-14 15:25 ` [igt-dev] ✓ Fi.CI.IGT: success " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220913120441.146757-5-janusz.krzysztofik@linux.intel.com \
    --to=janusz.krzysztofik@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mchehab@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.