From: Jason-JH Lin <jason-jh.lin@mediatek.com>
To: <igt-dev@lists.freedesktop.org>,
Karthik B S <karthik.b.s@intel.com>,
Swati Sharma <swati2.sharma@intel.com>,
Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>,
Bhanuprakash Modem <bhanuprakash.modem@gmail.com>,
Fei Shao <fshao@chromium.org>
Cc: Jani <jani.nikula@intel.com>,
Jason-JH Lin <jason-jh.lin@mediatek.com>,
Paul-PL Chen <paul-pl.chen@mediatek.com>,
Nancy Lin <nancy.lin@mediatek.com>,
Singo Chang <singo.chang@mediatek.com>,
Gil Dekel <gildekel@google.com>, Yacoub <markyacoub@chromium.org>,
<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: [PATCH i-g-t] tests/kms_invalid_mode: Allow clock-too-high test on non-Intel platforms
Date: Tue, 14 Apr 2026 18:10:54 +0800 [thread overview]
Message-ID: <20260414101108.1920755-1-jason-jh.lin@mediatek.com> (raw)
The clock-too-high subtest was being skipped on non-Intel platforms
because igt_get_max_dotclock() returns 0 when reading from
Intel-specific debugfs fails.
This change allows the test to run on all platforms by:
- Using a clearly invalid clock value (10 GHz) when max_dotclock is
unavailable, which any reasonable driver should reject
- Restricting bigjoiner/ultrajoiner logic to Intel devices only
This prevents the test from being marked as IGNORED/SKIP on non-Intel
platforms while maintaining the original test intent of verifying that
drivers properly reject modes with excessively high clock rates.
Tested on MTK platforms where the test now properly executes and
verifies invalid clock validation.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
---
tests/kms_invalid_mode.c | 38 +++++++++++++++++++++++---------------
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/tests/kms_invalid_mode.c b/tests/kms_invalid_mode.c
index 5edffb649ef4..18d79e59c736 100644
--- a/tests/kms_invalid_mode.c
+++ b/tests/kms_invalid_mode.c
@@ -126,7 +126,13 @@ adjust_mode_clock_too_high(data_t *data, drmModeModeInfoPtr mode)
{
int max_dotclock = data->max_dotclock;
- igt_require(max_dotclock != 0);
+ /*
+ * If max_dotclock is unavailable (e.g., non-Intel platforms),
+ * use an obviously invalid value that any driver should reject.
+ * 10 GHz is well beyond any reasonable hardware capability.
+ */
+ if (max_dotclock == 0)
+ max_dotclock = 10000000; /* 10 GHz in kHz */
/*
* FIXME When we have a fixed mode, the kernel will ignore
@@ -139,21 +145,23 @@ adjust_mode_clock_too_high(data_t *data, drmModeModeInfoPtr mode)
if (has_scaling_mode_prop(data))
return false;
- /*
- * Newer platforms can support modes higher than the maximum dot clock
- * by using pipe joiner, so set the mode clock twice that of maximum
- * dot clock;
- */
- if (can_bigjoiner(data)) {
- igt_info("Platform supports bigjoiner with %s\n",
- data->output->name);
- max_dotclock *= 2;
- }
+ if (is_intel_device(data->drm_fd)) {
+ /*
+ * Newer platforms can support modes higher than the maximum dot clock
+ * by using pipe joiner, so set the mode clock twice that of maximum
+ * dot clock;
+ */
+ if (can_bigjoiner(data)) {
+ igt_info("Platform supports bigjoiner with %s\n",
+ data->output->name);
+ max_dotclock *= 2;
+ }
- if (can_ultrajoiner(data)) {
- igt_info("Platform supports ultrajoiner with %s\n",
- data->output->name);
- max_dotclock *= 4;
+ if (can_ultrajoiner(data)) {
+ igt_info("Platform supports ultrajoiner with %s\n",
+ data->output->name);
+ max_dotclock *= 4;
+ }
}
mode->clock = max_dotclock + 1;
--
2.43.0
next reply other threads:[~2026-04-14 10:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 10:10 Jason-JH Lin [this message]
2026-04-14 10:44 ` [PATCH i-g-t] tests/kms_invalid_mode: Allow clock-too-high test on non-Intel platforms Jani Nikula
2026-04-15 1:26 ` Jason-JH Lin (林睿祥)
2026-04-14 13:11 ` ✓ Xe.CI.BAT: success for " Patchwork
2026-04-14 13:34 ` ✓ i915.CI.BAT: " Patchwork
2026-04-14 14:23 ` ✓ Xe.CI.FULL: " Patchwork
2026-04-14 20:58 ` ✓ i915.CI.Full: " 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=20260414101108.1920755-1-jason-jh.lin@mediatek.com \
--to=jason-jh.lin@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=bhanuprakash.modem@gmail.com \
--cc=fshao@chromium.org \
--cc=gildekel@google.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=juhapekka.heikkila@gmail.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=karthik.b.s@intel.com \
--cc=markyacoub@chromium.org \
--cc=nancy.lin@mediatek.com \
--cc=paul-pl.chen@mediatek.com \
--cc=singo.chang@mediatek.com \
--cc=swati2.sharma@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox