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

[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.

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