From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 41E9A54A7E2; Tue, 22 Sep 2026 13:22:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790083334; cv=none; b=XiW4lEXycMrmpAX0KbYgmObKUydQ5V+15GLLcdbPS2FqDt27dPWuUg7wnhrNV4xqcfx1qQfE03ppZ/KVY+x94ZEnw+EvPk7k7iPjlet+yJzsuqivaJk//WCjzSvoR9gMO9yfmlSlkBoB2WRTcBd9+f8L7B1Ik+npnDBT+zQLetk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790083334; c=relaxed/simple; bh=u4ijRMeEX5UV9FuKjGJW/fsZOMEVjU34gJ0OC6BUeu8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=U/RNsfmGxUfPovTxwp9aXs9uL6LAG+0o7MLz1jvc/mx1HZkuIZJWX2XWwKJNk7SfHa9wtkI50K2FELEHpfE4Bz34VjxxJ7/ghgLRVxQLbrBN1C5TqloFBiA0YrJM6Jvuqmd0ZV0L2pIVLaPevJRN3BBzgGlcoFcSv/XSNAcY3wQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RqS0wZ6M; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RqS0wZ6M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 543431F000FF; Tue, 22 Sep 2026 13:22:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790083332; bh=izoFKgiwl1CtFCyEIjGCaDfq4nQekOb5nh2FLPhllwE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=RqS0wZ6MEt5bZk9R+eKNjlRNCmWaNssWnIKblwHEVt1yhxX+ze4qRQgSdijlnk+u9 x0uj7BswFEX76KgX7c17GHgRy4Qckx0Sx/PiiC1Eb0ER625jj/erLNU2xNNe6T/ltx V2RiRRALLcVkKzNnXsV3FaSSjjAT03Tf6Ho6/htzaKLwBoA7DXu/HOLeogcfu1cYal /IaGMln+Avhf92NI250562x/Cv22XLM8bnqAYK28Am/fhb5I4fg6WoukQ8LWNad5Ef TG8T8MTKfFhq+I45jEqJxtY1TVTGkcKwY3zEkKGZ3sZNnz99fz/nBT+HBhc8F/WX9L sj2D32JDkes8Q== Date: Tue, 22 Sep 2026 15:22:09 +0200 From: Maxime Ripard To: Nicolas Frattaroli Cc: "Borah, Chaitanya Kumar" , Daniel Stone , Maarten Lankhorst , 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?Q?St=C3=BCbner?= , Andy Yan , Leo Li , 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 03/25] drm/atomic-helper: Set mode_changed on vrr_enabled change Message-ID: References: <20260921-vrr-limiter-uapi-v1-0-2fcd7d011646@collabora.com> <20260921-vrr-limiter-uapi-v1-3-2fcd7d011646@collabora.com> <75b82a61-fe82-4597-bfb5-3c717fbb0dda@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="uykltmdeqp3cwq6a" Content-Disposition: inline In-Reply-To: --uykltmdeqp3cwq6a Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH RFC 03/25] drm/atomic-helper: Set mode_changed on vrr_enabled change MIME-Version: 1.0 On Tue, Sep 22, 2026 at 02:53:36PM +0200, Nicolas Frattaroli wrote: > On Monday, 21 September 2026 23:59:11 Central European Summer Time Leo Li= wrote: > > Hi Nicholas, > >=20 > > Thanks for sending this out. I'm looking into an amdgpu implementation > > and had some comments along the way. Will reply inline on respective > > patches. > >=20 > > On 2026-09-21 11:51, Nicolas Frattaroli wrote: > > > A change in whether VRR is enabled or not on a CRTC will be of intere= st > > > to any VRR implementation, as they may need to recalculate certain > > > internal state in response. So far, this was handled ad-hoc in the > > > drivers that implement VRR. > > >=20 > > > Handle this in the common DRM atomic core by setting the mode_changed > > > flag when this occurs. The rationale for using mode_changed is that V= RR > > > is deeply intertwined with the current mode with regards to its timin= g. > > > Consequently, any component that cares about a mode change is likely > > > also going to care about VRR being enabled/disabled. > > >=20 > > > Signed-off-by: Nicolas Frattaroli > > > --- > > > drivers/gpu/drm/drm_atomic_helper.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > >=20 > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/dr= m_atomic_helper.c > > > index 9d006f98413a..0664d5779282 100644 > > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > > @@ -694,6 +694,12 @@ drm_atomic_helper_check_modeset(struct drm_devic= e *dev, > > > new_crtc_state->active_changed =3D true; > > > } > > > =20 > > > + if (old_crtc_state->vrr_enabled !=3D new_crtc_state->vrr_enabled) { > > > + drm_dbg_atomic(dev, "[CRTC:%d:%s] VRR changed\n", > > > + crtc->base.id, crtc->name); > > > + new_crtc_state->mode_changed =3D true; > > > + } > > > + > >=20 > > I don't think this is the case for all hardware, at least not for amdgp= u. > > The parts in HW that adjust vtotal can be programmed without requiring > > bandwidth recalculations or reprogramming of pipes. >=20 > Thanks for pointing this out. I was already unsure of this patch before, > and I don't think Rockchip requires these recalculations either. Original= ly > I added this when I looked at the i915 code iirc and saw them setting it. >=20 > I think in the commit message I also conflate needing to know about VRR > being changed with needing to do a full modeset (which is what mode_chang= ed > basically means). >=20 > I'll drop this patch on the next revision. Alternatively, and since we only have a single driver enabling it (for now), I don't think having some driver specific code for now to handle all this is that bad. Helpers only really make sense when we start sharing code between drivers. Maxime --uykltmdeqp3cwq6a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCarKBAQAKCRAnX84Zoj2+ dr15AYDf1hNAd+Ezbcn8fIQsts+wOtJnh9OA7o3i3CrBbW3rDk1DvSW+ygwNh/8m JmlcHmIBgNLrS0a12gMnSBzONESp+jiggI5QHHajSk3lv1hURiQQRSX119tAwssZ 27Cpd/5zRw== =xdA0 -----END PGP SIGNATURE----- --uykltmdeqp3cwq6a--