On Mon, Mar 16, 2026 at 01:38:22PM +0200, Jani Nikula wrote: > On Mon, 16 Mar 2026, Thomas Zimmermann <[email protected]> wrote: > > Hi Jammy > > > > Am 13.03.26 um 11:04 schrieb Jammy Huang: > >> DisplayPort supports edid at most 256 bytes. Thus, allow it to fetch > >> edid block 0 and 1. > >> > >> Signed-off-by: Jammy Huang <[email protected]> > >> --- > >> ASPEED DisplayPort's EDID size can be 256 bytes at most. Thus, EDID > >> blocks fetched can be 0 and 1. > >> --- > >> drivers/gpu/drm/ast/ast_dp.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c > >> index 9d07dad358c..c938e1d6b1d 100644 > >> --- a/drivers/gpu/drm/ast/ast_dp.c > >> +++ b/drivers/gpu/drm/ast/ast_dp.c > >> @@ -88,7 +88,7 @@ static int ast_astdp_read_edid_block(void *data, u8 > >> *buf, unsigned int block, si > >> int ret = 0; > >> unsigned int i; > >> > >> - if (block > 0) > >> + if (block > 1) > >> return -EIO; /* extension headers not supported */ > > > > But see the code at [1]. It clears the number of extensions to zero and > > updates the checksum accordingly. This is required to make the shortened > > EDID work with DRM. If you leave this as-is, it will still clear support > > for any extension in block 1. > > > > See the table 2.4 in the VESA EDID 1.4 standard for the semantics. For > > 1.3, if the number of blocks is >2, the first extensions is a 'block map > > of the extensions'. This is useless, as it's not a data extension in > > itself. In 1.4, the block map is optional. That code should clear the > > EDID's number of extensions to 0 or 1, depending on whether there is a > > block map to be expected. > > I think long-term the goal should be for the kernel to not modify the > EDID, at all.
I think as a short term goal it would be much better if all EDID mangling would be done by drm_edid.c rather than individual drivers. -- Ville Syrjälä Intel
