mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yaroslav Bolyukin <iam@lach.pw>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>
Cc: "Harry Wentland" <harry.wentland@amd.com>,
	"Leo Li" <sunpeng.li@amd.com>,
	"Rodrigo Siqueira" <siqueira@igalia.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Wayne Lin" <Wayne.Lin@amd.com>,
	amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	"Yaroslav Bolyukin" <iam@lach.pw>
Subject: [PATCH v5 7/7] drm/amd: use fixed dsc bits-per-pixel from edid
Date: Fri, 17 Oct 2025 18:27:36 +0200	[thread overview]
Message-ID: <20251017162736.45368-8-iam@lach.pw> (raw)
In-Reply-To: <20251017162736.45368-1-iam@lach.pw>

VESA vendor header from DisplayID spec may contain fixed bit per pixel
rate, it should be used by drm driver for the modes that declare
they are only supported with the declared fixed bits per pixel value.

It is however unclear how to deal with the modes created from userspace.
Current implementation assumes that fixed bits per pixel value should
always be used if the preferred display mode has this flag set, which is
the case for all the known hardware.

Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0d03e324d5b9..739d5dabcf41 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6521,6 +6521,11 @@ static void fill_stream_properties_from_drm_display_mode(
 
 	stream->output_color_space = get_output_color_space(timing_out, connector_state);
 	stream->content_type = get_output_content_type(connector_state);
+
+	/* DisplayID Type VII pass-through timings. */
+	if (mode_in->dsc_passthrough_timings_support && info->dp_dsc_bpp_x16 != 0) {
+		stream->timing.dsc_fixed_bits_per_pixel_x16 = info->dp_dsc_bpp_x16;
+	}
 }
 
 static void fill_audio_info(struct audio_info *audio_info,
@@ -7067,6 +7072,13 @@ create_stream_for_sink(struct drm_connector *connector,
 					&mode, preferred_mode, scale);
 
 			preferred_refresh = drm_mode_vrefresh(preferred_mode);
+
+			/*
+			 * HACK: In case of multiple supported modes, we should look at the matching mode to decide this flag.
+			 * But what is matching mode, how should it be decided?
+			 * Assuming that only preferred mode would have this flag.
+			 */
+			mode.dsc_passthrough_timings_support = preferred_mode->dsc_passthrough_timings_support;
 		}
 	}
 
-- 
2.51.0


      parent reply	other threads:[~2025-10-17 16:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-17 16:27 [PATCH v5 0/7] DisplayID DSC passthrough timing support Yaroslav Bolyukin
2025-10-17 16:27 ` [PATCH v5 1/7] drm/edid: rename VESA block parsing functions to more generic name Yaroslav Bolyukin
2025-10-17 16:27 ` [PATCH v5 2/7] drm/edid: prepare for VESA vendor-specific data block extension Yaroslav Bolyukin
2025-10-17 16:27 ` [PATCH v5 3/7] drm/edid: MSO should only be used for non-eDP displays Yaroslav Bolyukin
2025-10-17 16:27 ` [PATCH v5 4/7] drm/edid: parse DSC DPP passthru support flag for mode VII timings Yaroslav Bolyukin
2025-10-17 16:27 ` [PATCH v5 5/7] drm/edid: for consistency, use mask everywhere for block rev parsing Yaroslav Bolyukin
2025-10-17 16:27 ` [PATCH v5 6/7] drm/edid: parse DRM VESA dsc bpp target Yaroslav Bolyukin
2025-10-17 16:27 ` Yaroslav Bolyukin [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=20251017162736.45368-8-iam@lach.pw \
    --to=iam@lach.pw \
    --cc=Wayne.Lin@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=siqueira@igalia.com \
    --cc=sunpeng.li@amd.com \
    --cc=tzimmermann@suse.de \
    --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

all inboxes | Powered by JetHome®