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. BR, Jani. > > Best regards > Thomas > > [1] > https://elixir.bootlin.com/linux/v6.19.8/source/drivers/gpu/drm/ast/ast_dp.c#L157 > >> >> /* >> >> --- >> base-commit: 5ee8dbf54602dc340d6235b1d6aa17c0f283f48c >> change-id: 20260313-upstream_ast_dp_edid-5fe6adf7ad36 >> >> Best regards, -- Jani Nikula, Intel
