RE: [PATCH] drm/ast: DisplayPort edid supports 256 bytes

[Jammy Huang]

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 <tzimmermann@xxxxxxx>
> 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 <jammy_huang@xxxxxxxxxxxxxx>
> >>> ---
> >>> 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)
>