AMD General
> -----Original Message----- > From: Jani Nikula <[email protected]> > Sent: Friday, September 18, 2026 10:30 > To: Zuo, Jerry <[email protected]>; [email protected]; > Wentland, Harry <[email protected]>; Li, Sun peng (Leo) > <[email protected]>; Deucher, Alexander > <[email protected]> > Cc: Zuo, Jerry <[email protected]>; [email protected]; amd- > [email protected] > Subject: Re: [PATCH v2 2/2] drm/amd/display: Use drm_edid_block_count() > instead of raw extensions > > On Mon, 27 Jul 2026, Fangzhi Zuo <[email protected]> wrote: > > Hi Timo, > > > > Thanks for the patch. Heads-up that this overlaps with a fix already > > in > > amd-staging-drm-next: > > > > 21590e1adc9e ("drm/amd/display: Fix 8K Mode Not Parsed by EDID") > > More precisely commit 11a90eaf5c80 ("drm/amd/display: Fix 8K Mode Not > Parsed by EDID") upstream. > > > That commit addresses the same underlying problem your patch targets > > -- > > edid->extensions (byte 0x7e) not accounting for HF-EEODB blocks, so > > edid->only > > 2 of 4 blocks of an HDMI 2.1 EDID get copied into sink->dc_edid and > > the 8K modes in the DisplayID extension blocks are lost. It takes a > > slightly different approach: instead of drm_edid_block_count(), it > > populates edid_blob_ptr with a full, HF-EEODB-aware blob and copies > > edid_blob_ptr->length. So on current amd-staging the > > dm_helpers_read_local_edid() hunk here no longer applies cleanly. > > That's an awful, ugly hack. Please work to remove it. Drivers are not supposed > to look at or use connector->edid_blob_ptr at all. See the documentation. > > I really did put in a *lot* of effort into abstracting HF-EEODB properly and > neatly for everyone, across the subsystem. The opaque struct drm_edid is the > abstraction. Please embrace it, and you'll get HF-EEODB for free, with no > hacks. > > If you face issues, please talk to me instead of hacking stuff and > intentionally > working around the the abstractions. > > > Could you rebase on the latest amd-staging-drm-next and see what, if > > anything, is still needed on top? There may still be value in the > > helper conversion for readability, but we should avoid re-fixing the > > same HF-EEODB issue two different ways. > > The one and only fix for HF-EEODB is to use struct drm_edid everywhere. Thanks, I totally agree. The fact is the dc_edid to drm_edid transition/refactor is not fully completed yet. That leads to w/a is coming up as a temporary fix. Will remove once the transition is complete. > > > BR, > Jani. > > > -- > Jani Nikula, Intel
