From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 286D82F1FDE for ; Tue, 17 Mar 2026 10:03:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773741809; cv=none; b=N0Gjb4zzrJsO+oO82zBvlr+UqvpwFCfdNraAo0WJgM4PMuYEtniceSLop6EZvyUOrqslzFz49RrDw/EC+6bDxELXIZv8d38VpRGRL1aF4m79ZzFVW61O5FhghdPlKOQoHX/4j/i9NQm6uynnY80Hx4xe19CAAhLjO/Vv0yAx80Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773741809; c=relaxed/simple; bh=Gv1VNxaSJmz+M7tg3PACPuaBOp/pEOxPdA+9c6bbU5A=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=I3WoZzYXtN5E/AgsfBMdy8540llDOt+eY1bCdv+PElfucOSIhPRFeWJJ37qjdlhHs03w0gsx2EerZkgtE/F5AhNU7P4zb4TJTfBoERPalvxwEIHVhcm/BTcZYtsgfiWLalO24Ycv+GpH9oPDnO2CAO8dsrCgFSe1TSYzwAFXkHs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=kHAPCKjn; arc=none smtp.client-ip=209.85.208.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kHAPCKjn" Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-660c4337d41so737052a12.2 for ; Tue, 17 Mar 2026 03:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773741806; x=1774346606; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding :disposition-notification-to:references:in-reply-to:date:cc:to:from :subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=LXDnZwc0UQAioOB74HdZQyDfdGqfb34J+A9oDeiAkgU=; b=kHAPCKjneWJyXWJBwm19ypAZ5Ki6pCKmpLDgN6CNjKl6Kc88oGeyj9VSV8vYS+HG3B N1iykREur/kUpazV4e5r/bqwAwWw+IIBdXEa1RHx5rHniXOXhAE5DzoAqcGjdHnPj/bt duVK6ItCjzItHNfszRsz+i5W6bmZILzO5WBa65+0zyqPLm7M87dXiRomRMo9d5YQrPMd qrHWKtrb33GaKtdjvmnSkOrr3zcDVq1681dE3LPA/qCQ76MaEq02IUS4eOKdEiHem6A5 Bia4aebkWHD2df3yoNxRLG9cSAZIxfXO7RkxK84oMym0wz0nd8KRGHRktZ2q3z4y52cM f/6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773741806; x=1774346606; h=mime-version:user-agent:content-transfer-encoding :disposition-notification-to:references:in-reply-to:date:cc:to:from :subject:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=LXDnZwc0UQAioOB74HdZQyDfdGqfb34J+A9oDeiAkgU=; b=Xl4nWXFTk+7ZPIPw16BP2QWE4YnTqRAciAm2kkiCiRdfwajQBCzRAy6WBjVKcGeZ/+ YhDr1qBST/pxgME7DvT+L09D9ECjCGqKIskmiYjf7QGjhnSHbQxWdFLMaWwm4lCiteXv IxbajZLEAlEHWXpFjy7efixxoOL43VcvN0DBhzIB6MfFI7tYP2D+lm3gJcSCI0nJQOYd MP+OJLKxL3llZO0RvWFZ026R4UvOe/jeMe0xHHLlBfdeCj/mY/CEw7yg1OGNzT+hWj/l 3KsShUygQ/7iaX+qyzCC/bDcN7TWKWGfb9+G6O3bl8+r/gM7R3IulyaXyDsuKHqoTMF4 Sx0Q== X-Forwarded-Encrypted: i=1; AJvYcCXzqr/uWwm1U5aHndUCbi3CXiEA0aD2EhpTNmAnDWs2LrasjGR2dw06gK7pS1QaD67BoXdZ0wDuy19lF9Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yxc+xfNxoixs+wPSYLu9dksGxvxkimhYbN1lqIlKufbM18GN2q5 CVKALplKBO+LiOvXp9dIVqndM96Rb3RER4Hfnb2LQ9R8MhL+mn+ueSzj X-Gm-Gg: ATEYQzyfVlJYovtLqHoYuQUW6BmoRgzxTQrNkPQESagGuIg7T1OCV7IsPi73Gz/ALf1 tD7uFeybudFGplq9ZJNq6obNF+4ZTMt8QMYuZCvptOHBb20Y/FIxZfWdT+JWOoxkFG+DcP36Vve llbiMbhP4P/WqpukgQwoeaG4Oc8o5RVSMFy/4MgI5TR5IY3MS+auJjVMkzCMiWv0ji5Tqiy7OO3 Cwtt3yA77MxuGOS2lL6/JyQu6Ruc5soVV10uKEv4hJnPlz+zElkUX8SzppG65fIw5D6Uninijft hSCILbGS7mGR5UHGDwU3HIRIXsFr+d9DQCLXDOPUhK8nB6CmrnBeVXYgwQNYLi63ZtDIfo9iYQN dDhtWaGsnblk4JaQtgW0YciZvwBSlUlWKa6xYztC0UIAS9niHVT60REw6ep508toHLDEdh7+kAO pCgWnyv/R1Nrj9vTb71AtVY5mPrkqtNmc8qFweSVF8Z8Tws6LXPYhtGd3WvDMUik3gX07nsTAfT /BQpduhdA== X-Received: by 2002:a05:6402:3548:b0:663:4965:6bac with SMTP id 4fb4d7f45d1cf-663babc294dmr4693237a12.3.1773741806180; Tue, 17 Mar 2026 03:03:26 -0700 (PDT) Received: from [192.168.1.239] (87-205-5-123.static.ip.netia.com.pl. [87.205.5.123]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6635088fa23sm6336330a12.16.2026.03.17.03.03.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 03:03:25 -0700 (PDT) Message-ID: <5649c232fa0243c2c3ca7be91529409921604d69.camel@gmail.com> Subject: Re: [PATCH v4 07/27] drm/amd/display: Use bigger VRR range if found in AMD vsdb From: Tomasz =?UTF-8?Q?Paku=C5=82a?= To: Jani Nikula , alexander.deucher@amd.com, harry.wentland@amd.com, sunpeng.li@amd.com Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, siqueira@igalia.com, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, bernhard.berger@gmail.com, michel.daenzer@mailbox.org, daniel@fooishbar.org Date: Tue, 17 Mar 2026 11:03:22 +0100 In-Reply-To: <7da80c4be3e20c126017646f783b80136bb0700e@intel.com> References: <20260216164516.36803-1-tomasz.pakula.oficjalny@gmail.com> <20260216164516.36803-8-tomasz.pakula.oficjalny@gmail.com> <7da80c4be3e20c126017646f783b80136bb0700e@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Thu, 2026-02-26 at 14:36 +0200, Jani Nikula wrote: > On Mon, 16 Feb 2026, Tomasz Paku=C5=82a wrote: > > [Why] > > Some monitors only expose their full VRR range in AMD vsdb for some > > reason. > >=20 > > [How] > > Compare exposed ranges and use the bigger one. > > Only adjust lower limit if it doesn't support LFC > >=20 > > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4177 > > Signed-off-by: Tomasz Paku=C5=82a > > --- > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 31 +++++++++++++++++++ > > 1 file changed, 31 insertions(+) > >=20 > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/driver= s/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > index b3bf5e0c19a5..f36059bb0324 100644 > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > @@ -13269,6 +13269,34 @@ static bool copy_range_to_amdgpu_connector(str= uct drm_connector *conn) > > return is_freesync_capable(range); > > } > > =20 > > +static void extend_range_from_vsdb(struct drm_display_info *display, > > + const struct amdgpu_hdmi_vsdb_info *vsdb) > > +{ > > + u16 vrr_min =3D display->monitor_range.min_vfreq; > > + u16 vrr_max =3D display->monitor_range.max_vfreq; > > + > > + /* Always extend upper limit */ > > + if (vsdb->max_refresh_rate_hz > vrr_max) > > + vrr_max =3D vsdb->max_refresh_rate_hz; > > + > > + /* > > + * Only extend lower limit if current one disables LFC. > > + > > + * During widespread testing, we found that some manufacturers probab= ly > > + * had issues with their monitors' lower VRR boundaries and adjusted > > + * them up (Gigabyte X34GS with official range 48 - 180, AMD vsdb 48 = - > > + * 180 yet Monitor Ranges 55 - 180). After setting the lower boundary > > + * from AMD vsdb, such monitors start having blanking issues. > > + * > > + * Work around that by not touching VRR min if it still supports LFC. > > + */ > > + if (vsdb->min_refresh_rate_hz < vrr_min && (vrr_min * 2 >=3D vrr_max)= ) > > + vrr_min =3D vsdb->min_refresh_rate_hz; > > + > > + display->monitor_range.min_vfreq =3D vrr_min; > > + display->monitor_range.max_vfreq =3D vrr_max; >=20 > Random driver code should *not* modify struct drm_display_info, > especially the fields that drm_edid.c parses. Drivers should cease to > parse EDID and DisplayID altogether. >=20 > I'm on the verge of NAKing, to the extent that I have control over this, > any further improvements on driver EDID/DisplayID parsing, with the > expectation that everything's moved to shared EDID parser in drm_edid.c > first, and improved there. >=20 > BR, > Jani. Hi! So I prepared a version which completely removes the drm_display_info modifications from this part of the driver, but I think I know why it was there in there in the first place. Without changing these fields, the dri debug information, reports wrong vrr range vs what the driver decided to do. Basically, with monitor that have different vrr range in 'monitor ranges' and AMD vsdb, it only reports the range from monitor ranges, worse, for monitors that report GTF range (all HDMI TV, even some DP monitors) the vrr_range for the connector in dri debug is reported to be 0 - 0 even though the correct range was picked up from other places like DisplayID, AMD vsdb, HDMI Forum vsdb or nvidia specific vsdb. Moving all this into generic edid handling could be quite a problem as well since different manufacturers might want to handle VRR differenty. For example, Intel could decide to support FreeSync sinnalling or just getting the range from there, or not. HDMI VRR is another issue where one brand could decide to prioritize their own solution over the generic one (FreeSync over HDMI vs HDMI VRR). The vrr_range in debug ony exposes display_info.monitor_range but it's name suggests that it does something different. Maybe it needs a dedicated place for drivers to show what they ended up deciding upon? monitr_range alrady is only used to expose the range if it has 'range limits only' flag so only for VRR. My concern is that we would have bad debug info in there now. I'm working on adding a drp connector property that would expose the vrr range so compositors could easily parse it instead of relying on edid parsing, that will be impossible to match. And again, I'm just a guy providing fixes, I think bigger changes should be taken with AMD. The functionality is already in the driver and my patches do not change what it does with it. I'm not even changing how it parses anything when it comes to edid, just using what's already there to decide how to handle VRR. Tomasz