Hi Thomas, Thanks for the comments. I found the code at [1] is now not working. Because i+=4 in the loop iteration.
For the block map, we should handle it depending on the number of blocks: 1. 0 or 1, no edid modification required. 2. >= 2, check block1 offset 0x00 to see if it is 0xF0 which means block map. Set number of extensions to 0 if block1 is block map; Otherwise, set number of extensions to 1. BR Jammy > > 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/a > >> st_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) >
