Hi
Am 16.03.26 um 12:38 schrieb Jani Nikula:
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.
We only fix up the checksum to address the fact that we cannot read the
extensions.
I guess the kernel could be fixed to work correctly with the extensions
missing, but what about user space? Exporting an EDID without the
extensions blocks could cause problems with user-space programs.
Best regards
Thomas
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,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
