From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (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 B402F22A4F8 for ; Thu, 26 Feb 2026 13:42:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772113345; cv=none; b=pcFlWLb5kWqbpAzsyhwoc9OI0dC/0rVLWtEjsOSukedjbObnKzF8KC49xZJAGvgQmdfAEi9LHutqsmJQ0Zmsq2qjaRFzwGGXO2J1PLLLUImIXO6Xi54J3R9f2H/UI777iv6fSSfuH0VfhLbtoy7QWlLHD7X1qSfKNCV8P2rti/I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772113345; c=relaxed/simple; bh=FNgYb/nGnffTYEsmXqYndK7uodAhuh1kRsy54SeaaKg=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=bLsz/n/V9zG2VNiVwOcYgfqRlulZ3GSRHQq3jPbgsD3JXKMw0D4pLmpnvSOKZBQz+0lq6yAajCNemgkiolYr3MvEj9pQIrYO5wP7550UfZlaV6YDCz6x+ZI3hurSlo36qHkd0uxSdTX/l8vf+AjgvlLoEk0hWF6VwFo7EoOKhxM= 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=HdZynKuc; arc=none smtp.client-ip=209.85.218.49 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="HdZynKuc" Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-b90ba3bae60so9373666b.2 for ; Thu, 26 Feb 2026 05:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772113340; x=1772718140; 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=8Yew8OpH5AIziFpFPDFNxtnqOMKVJfhBoAbJ3Hh32Xo=; b=HdZynKuc80ch8bd15CX3AFaOAz+6H2CzRXsvxYqt7aEang+rNwfXxRgGMyy95Fd85r 9umx8kjzaAwyH+E4HluZprfJr/RPFucLoRmo6Mcewow6Bi0dBHyV+ivCyjP8KgzXsDo1 UlpmAZ1KoE57QRdrCJShwMMpsIRM5GBui6hE4jgIrmUKWYztDivcG0fQ4yS8V1D8wweG bK3z7Pn3mPYXWmeWmKbSETvrBA2SLm3JxkxvGcYwZONHtt421dBKlyNEJ00ICuZ9u4ek pY37V2YxCLahmSYDXhULjo25WWU5Fk9ui8HeZJIC6uAuSLWCOwLITKT3q1a7skX/Gil+ 2Aow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772113340; x=1772718140; 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=8Yew8OpH5AIziFpFPDFNxtnqOMKVJfhBoAbJ3Hh32Xo=; b=f62QlQKGxpdWar+kKIzOaFMGVqgl328NGFY5Sji32wLGVzKRo/Z7vIoCbUnw384jaS tujljV/dYCGvGryGZlLmzZTTHV1GAKiQCh7+09ZLG3uboNEvIEQdnyojwWan8+4n7LTu 7gVmHevVOuzygUbSYb5SPLkz87Bb6Y6TCk9VsHinBfefWT96tQBjAOrYVNohT/EVyYw4 K3mkR9ecstTG6hh5STEhtgjfPz4vwsaGKu+EYBI1VTlk089ceDXyxunkSiEbEjhZ9dQe DbWvllYuvi8y5ZU2oB01vTT6TQ/rzGbyIaz6bIFgcTUapcTy0Wpt5449D/RidDTrPSb6 WZnw== X-Forwarded-Encrypted: i=1; AJvYcCWFEUM0y/cfDHgZ7xoXa9t5Scycl1liLyOy8sRk6K85KxvE/4HRXRBmw3TX1p/Y4oqsvniA59WnkkLlqFM=@vger.kernel.org X-Gm-Message-State: AOJu0YwgoijCjjWv9iy+BJt84cvMxrCdaaOwh5EL6xDBC+pQk8e78KrU lrGh4JdiOrPNkb+/PPIEErc4pnrIXClp0yG6+3kKrK1CjSyKc8ppezHe X-Gm-Gg: ATEYQzxyze0APdxhzQqpAfxiaMrM5igEhnK/6kW6ILAm5WMbDd8fNkURfQ4au9edkF+ tgTyDuq1fedSwPhip1qaOAElIxQbZvQJbwG/uFoiXtMsp2VkgUOvVgPco6Fdp5ZCABY5R+nit8I p790FrakcQARLrnZnwv3A8KDh8tEbw0JshJ0rxILkISk4ps8YBLn1Ss4AwFtzBXjLIFyxelouIW 8KYpKdkBEfj517UIUaTL+XB6AnCCzArJYS47DZFtxCJC+BGsqA6T0iQ63L3ZDIcviZ35ZSzdVx6 +DquCP0RrIDRrZxbI+54Fzwxy3pALbBXUxjnRvGL8bAfpzq41e2DEZI0wAbBdt9mQiwRtATkBhD 8zaQ/yRE7zxnn+qjFLgMef4Ohe7hPEdMSNkl1D0Qqcj7gTMl1qPNGjb73XCQ+UhQxYLq6C6dFBR 9/hzyidDJ9zBNzpOUEV6A6rZJ88UJ3OGfI8JWt/+XhP+VejAI4rtJKoJ46+F249YQ5iy4ZY2uU0 /D9EoUDcMY= X-Received: by 2002:a17:907:9494:b0:b73:99f7:8130 with SMTP id a640c23a62f3a-b9081b6dc66mr674893266b.6.1772113339377; Thu, 26 Feb 2026 05:42:19 -0800 (PST) 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 a640c23a62f3a-b935aeee867sm57475266b.66.2026.02.26.05.42.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 05:42:18 -0800 (PST) Message-ID: 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: Thu, 26 Feb 2026 14:42:15 +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. I completely agree with you, and I too am saddened by how selective AMD can be when contributing to open source, BUT I'm just a guy who figured out some fixes neglected by them. Not being an AMD employee, I don't have access to their plans or what has been their idea behind modifying drm_display_info (probably just a lack of understanding, like in my case). If maybe I could get OK from Alex or Harry to completely rip out drm_display_info modifications from amdgpu_dm_update_freesync_caps, then sure, but currently, I'm not in a position to do so. Still, it seems like amdgpu already relies purely on it's internal structs from there on out, so it should be pretty straightforward. Moreover, moving all DisplayID and CTA extension parsing would be amazing, BUT AMD vsdb specification isn't public. Here, amdgpu even uses firmware to parse it, which is bonkers IMO, but they want to keep their secrets (for some reason). There always will be some VRR meddling in the drivers based on hardware features, though I do think AMD should release their whole Freesync vsdb to the public as other drivers could parse this info as well, because we can already see it's needed to properly support all monitors. Hell, even some of my fixes could be moved to general drm code to facilitate proper VRR range detection. Going back to the issue at hand, if I could get OK from AMD to rip out all drm_display_info modifications from amdgpu_dm_update_freesync_caps then it won't be a problem, but until then, I'm dealing with what I've been given, doing as little functional, changes as possible. We already know amdgpu code is... unoptimal, and I wouldn't want to add to that :D Tomasz >=20 >=20 > > +} > > + > > /** > > * amdgpu_dm_update_freesync_caps - Update Freesync capabilities > > * > > @@ -13339,6 +13367,9 @@ void amdgpu_dm_update_freesync_caps(struct drm_= connector *connector, > > if (is_monitor_range_invalid(connector)) > > monitor_range_from_vsdb(&connector->display_info, &vsdb_info); > > =20 > > + /* Try extending range if found in AMD vsdb */ > > + extend_range_from_vsdb(&connector->display_info, &vsdb_info); > > + > > if (dpcd_caps.allow_invalid_MSA_timing_param) > > freesync_capable =3D copy_range_to_amdgpu_connector(connector);