From: Jani Nikula <jani.nikula@intel.com>
To: "B, Jeevan" <jeevan.b@intel.com>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
"Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
Subject: RE: [PATCH i-g-t v2] tests/kms_setmode: Add HDMI 2.0 clock limit for mode selection
Date: Tue, 31 Mar 2026 16:48:26 +0300 [thread overview]
Message-ID: <934b8aea90466bb00982720c1960286b96ca5602@intel.com> (raw)
In-Reply-To: <DM4PR11MB6312922FD2D9B65F985EDE579053A@DM4PR11MB6312.namprd11.prod.outlook.com>
On Tue, 31 Mar 2026, "B, Jeevan" <jeevan.b@intel.com> wrote:
>> -----Original Message-----
>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Sent: Tuesday, March 31, 2026 6:36 PM
>> To: B, Jeevan <jeevan.b@intel.com>
>> Cc: igt-dev@lists.freedesktop.org; Nautiyal, Ankit K
>> <ankit.k.nautiyal@intel.com>
>> Subject: Re: [PATCH i-g-t v2] tests/kms_setmode: Add HDMI 2.0 clock limit for
>> mode selection
>>
>> On Tue, Mar 31, 2026 at 04:11:00PM +0530, Jeevan B wrote:
>> > eDP modes with high clock rates were being forced on HDMI 2.0
>> > displays, causing kernel to reject with EINVAL. Add clock validation
>> > to skip incompatible eDP modes and fall back to supported modes.
>> >
>> > v2: Add HDMI 2.0 clock limit helper, drop crtc_supports_mode(),
>> > and ensure per-connector compatibility to avoid invalid modes.
>> >
>> > Signed-off-by: Jeevan B <jeevan.b@intel.com>
>> > ---
>> > tests/kms_setmode.c | 44
>> ++++++++++++++++++++++++++++++++++++++++++--
>> > 1 file changed, 42 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c index
>> > 1f2849bc2..f1c1afe45 100644
>> > --- a/tests/kms_setmode.c
>> > +++ b/tests/kms_setmode.c
>> > @@ -79,6 +79,9 @@
>> > /* restricted pipe count */
>> > #define CRTC_RESTRICT_CNT 2
>> >
>> > +/* Clock limit for HDMI 2.0 */
>> > +#define HDMI_2_0_MAX_CLOCK_KHZ 600000
>> > +
>> > static int drm_fd;
>> > static drmModeRes *drm_resources;
>> > static int filter_test_id;
>> > @@ -165,6 +168,16 @@ static bool
>> connector_supports_mode(drmModeConnector *connector,
>> > return false;
>> > }
>> >
>> > +static bool
>> hdmi_connector_mode_exceeds_hdmi20_limit(drmModeConnector
>> *connector,
>> > + drmModeModeInfo
>> *mode)
>> > +{
>> > + if (connector->connector_type != DRM_MODE_CONNECTOR_HDMIA
>> &&
>> > + connector->connector_type != DRM_MODE_CONNECTOR_HDMIB)
>> > + return false;
>> > +
>> > + return mode->clock > HDMI_2_0_MAX_CLOCK_KHZ;
>>
>> Starting to test all kinds of random thing here does not seem maintainable.
>>
>> I think the one sensible option is to make the test skip rather than fail if it
>> couldn't find a common mode between the connectors and the modeset
>> subsequently failed.
>>
>> As for the external vs. internal connector situation, the test should probably
>> try to find a mode on the external connector(s) that has the same refresh rate
>> as one of the modes on the internal connector, and has the same resolution
>> (or less) than the internal panel. That way we can use pfit to upscale content
>> on the internal panel instead of attempting to force the external connectors to
>> use the internal panel's native mode.
>>
> Thanks, that makes sense.
>
> This test iterates through a large set of valid and invalid
> crtc/connector combinations, so trying to enforce strict compatibility
> in mode selection is making the logic complex and hard to maintain.
>
> It's also becoming harder with newer internal panels supporting high
> refresh rates, which often don't have matching modes on external
> connectors.
>
> I agree it's better to keep the selection simple and skip when no common
> mode is found or the modeset fails, instead of adding more heuristics.
>
> Longer term, it might be worth rethinking the mode selection strategy,
> but for now I'll keep this change minimal.
I think long term the test would be easier to maintain if it were
converted to igt_display_require() and igt_crtc_t and friends instead of
hand-rolling everything.
BR,
Jani.
>
> Thanks
> Jeevan B
>> > +}
>> > +
>> > static bool crtc_supports_mode(struct crtc_config *crtc,
>> > drmModeModeInfo *mode) {
>> > int i;
>> > @@ -270,8 +283,35 @@ static void get_mode_for_crtc(struct crtc_config
>> *crtc,
>> > if (conn->modes[j].clock < mode->clock)
>> > mode = &conn->modes[j];
>> > }
>> > - *mode_ret = *mode;
>> > - return;
>> > +
>> > + /* Check HDMI 2.0 clock + per-connector compatibility
>> */
>> > + {
>> > + int k;
>> > + bool compatible = true;
>> > +
>> > + for (k = 0; k < crtc->connector_count; k++) {
>> > + drmModeConnector *other_conn =
>> > + crtc->cconfs[k].connector;
>> > +
>> > + /* HDMI 2.0 clock constraint */
>> > + if
>> (hdmi_connector_mode_exceeds_hdmi20_limit(other_conn,
>> > +
>> mode)) {
>> > + compatible = false;
>> > + break;
>> > + }
>> > +
>> > + /* Ensure connector supports the
>> mode */
>> > + if
>> (!connector_supports_mode(other_conn, mode)) {
>> > + compatible = false;
>> > + break;
>> > + }
>> > + }
>> > +
>> > + if (compatible) {
>> > + *mode_ret = *mode;
>> > + return;
>> > + }
>> > + }
>> > }
>> > }
>> >
>> > --
>> > 2.43.0
>>
>> --
>> Ville Syrjälä
>> Intel
--
Jani Nikula, Intel
prev parent reply other threads:[~2026-03-31 13:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 10:41 [PATCH i-g-t v2] tests/kms_setmode: Add HDMI 2.0 clock limit for mode selection Jeevan B
2026-03-31 11:42 ` Jani Nikula
2026-03-31 13:06 ` Ville Syrjälä
2026-03-31 13:37 ` B, Jeevan
2026-03-31 13:48 ` Jani Nikula [this message]
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=934b8aea90466bb00982720c1960286b96ca5602@intel.com \
--to=jani.nikula@intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=jeevan.b@intel.com \
--cc=ville.syrjala@linux.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