From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4897447D931; Thu, 24 Sep 2026 12:11:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790251894; cv=pass; b=FU2BP/kAV8BmkeI8mgopZ8jUMAxySTeN0N8jVwX++sp7PDcAzKHnSS7UC8UZKBMnARVJjtoxwRJHXaEPCLGcBVkILCfOU60QZ5b5W/w+E7p56l6H33f0toAwax2SJLqNOtOBMXgWN/ekFuCbXG1BtbGU3hQ0slgDC8zuwdGWhPU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790251894; c=relaxed/simple; bh=ReI0FowMPAJxfhTyPcGJsdbTeKiZ+B00JeEgQ5Wb8QQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FxcFfYeLRin2rNxp69RngMdf64vVNrAsnJA2M1EewlQvJit/nHWQfnMc6Zhnnfz4/N4rgl46xWE9ElanM5KomPrpKsrS2adovSVnvuTE1g6PjysQm4JH7+TleHkLw5pH1tJ57CtoYhBsDPb8WYR0EO7uZ/KO15nmTV9jqPZwbeo= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b=Xu+gcUfb; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b="Xu+gcUfb" ARC-Seal: i=1; a=rsa-sha256; t=1790251823; cv=none; d=zohomail.com; s=zohoarc; b=SMMG8NlP4fqBNXx529QZu5Zdtb4p9tbuMOQ91soQIHcDnn4ZYV2Qq6DwCOwr678Uo7p8enklMkZmlGtEeJGziTS1PKR38Ch/HKt4o33k5EJ7Vn5Q4viwpc3HWxbVLfSZ2E0v1befX4gf1zmvugKkk/KyrSeBPBpn9VFZmOokLPs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1790251823; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; bh=j/JN7+ozPHQKLl/xICwnFADe4iQfIt+/rqVhH5CZrYA=; b=JA02mZ1JM5S0BN3yBf3uyS3rHRpQxWB4DFfmHKkMiPasUG1Oj8qL1w/U6XepZzR2eFpxM5PIYcUrWJusagOO9ZEQ+jQPQMSc0WlC2bLpOSUi2Z23Yxe4/RwXxRq0p4pDbMr3OfPvJzEp1NzpH95dhfCqZ97kDljvcaqPxuUeohg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1790251823; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To; bh=j/JN7+ozPHQKLl/xICwnFADe4iQfIt+/rqVhH5CZrYA=; b=Xu+gcUfbDupdDGdO0xZeIAWmvh740ouAqQ7g8/OfYe3MpyVK0wF1tXyDTwBDYT7Y xzFD/uVYj2XViaDeb0kVdScnlodkBeibyV7UnNF63LSAYs+THvk3+ng2ALMvv9/0UXO CFkcvJQVJ5wXPkjrdhI7uNuS90bR8L/xns/jDyGA= Received: by smtp.zohomail.com with SMTPS id 1790251821166727.927772036528; Thu, 24 Sep 2026 05:10:21 -0700 (PDT) From: Nicolas Frattaroli To: Vidith Madhu Cc: "Borah, Chaitanya Kumar" , Leo Li , Daniel Stone , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Helge Deller , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Sandy Huang , Heiko =?UTF-8?B?U3TDvGJuZXI=?= , Andy Yan , Michel =?UTF-8?B?RMOkbnplcg==?= , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, kernel@collabora.com, Derek Foreman , wayland-devel@lists.freedesktop.org Subject: Re: [PATCH RFC 13/25] drm: Add VRR target frame rate properties Date: Thu, 24 Sep 2026 14:10:13 +0200 Message-ID: In-Reply-To: <6fb8aaed-5abc-db9c-b09b-3390d8b87686@nvidia.com> References: <20260921-vrr-limiter-uapi-v1-0-2fcd7d011646@collabora.com> <6fb8aaed-5abc-db9c-b09b-3390d8b87686@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday, 24 September 2026 09:01:05 Central European Summer Time Vidith= Madhu wrote: >=20 > On Wed, 23 Sep 2026, Nicolas Frattaroli wrote: >=20 > > On Wednesday, 23 September 2026 11:51:45 Central European Summer Time M= ichel D=C3=A4nzer wrote: > > > On 9/21/26 17:51, Nicolas Frattaroli wrote: > > > >=20 > > > > + * .. _VRR-MIN-NUMERATOR: > > > > + * > > > > + * "VRR_MIN_NUMERATOR": > > > > + * Default &drm_crtc integer property forming the numerator of a > > > > + * numerator/denominator pair of a frame rate to set as the minimu= m VRR > > > > + * target rate. Set to 0 to disable. > > > > + * > > > > + * "VRR_MIN_DENOMINATOR": > > > > + * Default &drm_crtc integer property forming the denominator of a > > > > + * numerator/denominator pair of a frame rate to set as the minimu= m VRR > > > > + * target rate. If :ref:`VRR_MIN_NUMERATOR ` is= not > > > > + * zero, it must be non-zero. > > > > + * Otherwise, must also be zero. > > > > + * > > > > + * .. _VRR-MAX-NUMERATOR: > > > > + * > > > > + * "VRR_MAX_NUMERATOR": > > > > + * Default &drm_crtc integer property forming the numerator of a > > > > + * numerator/denominator pair of a frame rate to set as the maximu= m VRR > > > > + * target rate. Set to 0 to disable. > > > > + * > > > > + * "VRR_MAX_DENOMINATOR": > > > > + * Default &drm_crtc integer property forming the denominator of a > > > > + * numerator/denominator pair of a frame rate to set as the maximu= m VRR > > > > + * target rate. If :ref:`VRR_MAX_NUMERATOR ` is= not > > > > + * zero, it must be non-zero. Otherwise, must also be zero. > > > > */ > > >=20 > > > Is there a reason that DENOMINATOR must be 0 when the corresponding N= UMERATOR is? 0 divided by any number is still 0. > >=20 > > No, I think that's an arbitrary convention I settled on and don't enfor= ce. I > > guess it should be "Otherwise, may also be zero", because the only situ= ation > > I'm making userspace avoid is x/0 where x !=3D 0. > >=20 > > > > Either way, should these rules be enforced in drm_atomic_crtc_set_p= roperty? > > >=20 > > > Or rather in atomic_check. > >=20 > > Due to complicating factors like EDID, CinemaVRR, and QMS TFRmin/TFRmax= , checking > > the properties for sensible values is done in the HDMI state helpers at= the moment. > >=20 > > If/when there is a similar mechanism for DP, we can probably factor the= common > > parts out. I really do hope all drivers (including those that don't use= the HDMI > > state helpers) can at least share the hdmi_validate_vrr() logic, but I = haven't > > factored this out into an exported function yet because I don't know ho= w similar > > the DisplayPort-equivalent mechanisms requirements are, or how much of = the state > > derivation non-state-helper drivers (i.e. i915 and amdgpu) need. > >=20 > > Kind regards, > > Nicolas Frattaroli >=20 > Thanks for bringing up support for VRR features on DP. Concerning the=20 > frame rate limits themselves, as I mentioned in patch [02/25] I don't=20 > think there's a reason to limit the validation to HDMI. Agreed. I think factoring most of the stuff out into the CRTC atomic check phase is what I'll do, and then keep the HDMI-specific validation and derivation within the HDMI state helpers. That should somewhat simplify the code as well I think. > There is in fact an analog of QMS for DP, called DP-FAVT mode - this is > quite a bit more streamlined than QMS and the validation should be > simpler. Would be nice to see these properties support that as well Yep, the intent is that the properties are display protocol agnostic, it just so happens that the only implementation I wrote so far is specific to HDMI. Also, good to hear the DP QMS-equivalent is more streamlined. :) > (this was briefly discussed at DisplayNext HackFest, if I understood > access to the DP spec is the main blocker here?). It certainly is a blocker. We also don't have any fancy testing/validation equipment, so validating implementations for protocols before they reach consumer devices is difficult for us (Collabora) at this time. That's also why it's a good idea for anyone who has access to the expensive specialised protocol test equipment to validate that the HDMI VTEM EMP packets we're constructing are actually within spec and not just a "happens to work" kind of deal. Kind regards Nicolas Frattaroli