From: "Tomasz Pakuła" <tomasz.pakula.oficjalny@gmail.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
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
Subject: Re: [PATCH 01/17] drm/amd/display: Return if DisplayID not found in parse_amd_vsdb()
Date: Tue, 20 Jan 2026 13:07:03 +0100 [thread overview]
Message-ID: <222c4c14ee6c20f18381580b249d160d197ce3e4.camel@gmail.com> (raw)
In-Reply-To: <b535614d27e30831628b4a70b7ed825fd03791d4@intel.com>
On Mon, 2026-01-19 at 15:23 +0200, Jani Nikula wrote:
> On Mon, 19 Jan 2026, Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> wrote:
> > [Why]
> > The function would continue to try to parse EDID even if DisplayID
> > extension block wasn't found. Sometimes it got lucky and found AMD vsdb
> > in CEA extension block which made debugging harder.
> >
> > [How]
> > Add a return if DisplayID extension block wasn't found
>
> Maybe don't use homegrown EDID parsing, but use drm_edid.c instead?
>
> BR,
> Jani.
>
I would be all for it but I didn't want to make even more changes. I
cannot refactor the whole amdgpu on my own :)
Plus, the generic drm code doesn't yet parse AMD vsdb. I could certainly
add such functionality, especially since it's already in projects like
edid-decode but amdgpu seems to be doing a lot of home-grown edid
parsing and I'm not really sure why, even sending stuff to firmware.
Especially confusing is the part where AMD vsdb is parsed differently if
it's in CTA extensiton block or DisplayID. They honestly are identical.
At least, here in, setting the freesync caps, getting info from generic
drm should be ok. I'll think about it and probably intoroduce AMD vsdb
parsing to drm in a separate series.
>
Tomasz
next prev parent reply other threads:[~2026-01-20 14:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 1:11 [PATCH 00/17] drm/amd: VRR fixes, HDMI Gaming Features Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 01/17] drm/amd/display: Return if DisplayID not found in parse_amd_vsdb() Tomasz Pakuła
2026-01-19 13:23 ` Jani Nikula
2026-01-20 12:07 ` Tomasz Pakuła [this message]
2026-01-19 1:11 ` [PATCH 02/17] drm/amd/display: Refactor amdgpu_dm_update_freesync_caps() Tomasz Pakuła
2026-01-19 8:23 ` kernel test robot
2026-01-19 1:11 ` [PATCH 03/17] drm/amd/display: Check for VRR range in CEA AMD vsdb Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 04/17] drm/amd/display: Use bigger VRR range if found in " Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 05/17] drm/amd/display: Refactor PCON VRR compatibility check Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 06/17] drm/amd/display: Add PCON VRR ID check override Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 07/17] drm/amd/display: Add CH7218 PCON ID Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 08/17] drm/edid: Parse more info from HDMI Forum vsdb Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 09/17] drm/amd/display: Rename PCON adaptive sync types Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 10/17] drm/amd/display: Enable HDMI VRR over PCON Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 11/17] drm/amd/display: Support HDMI VRRmax=0 Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 12/17] drm/amd/display: Build HDMI vsif in correct slot Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 13/17] drm/amd/display: Save HDMI gaming info to edid caps Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 14/17] drm/amd/display: Restore ALLM support in HDMI vsif Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 15/17] drm/amd/display: Trigger ALLM if it's available Tomasz Pakuła
2026-01-20 10:33 ` Michel Dänzer
2026-01-20 11:23 ` Daniel Stone
2026-01-20 11:45 ` Jani Nikula
2026-01-20 12:47 ` Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 16/17] drm/amd/display: Reintroduce VTEM info frame Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 17/17] drm/amd/display: Enable HDMI VRR Tomasz Pakuła
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=222c4c14ee6c20f18381580b249d160d197ce3e4.camel@gmail.com \
--to=tomasz.pakula.oficjalny@gmail.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bernhard.berger@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=jani.nikula@linux.intel.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 \
/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