public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
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

      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