From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A880D3976AF for ; Tue, 17 Mar 2026 08:28:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773736119; cv=none; b=DMgbru5SmFxEAiBxB0QxG7G7f6gKZQpvy8dHtUorcoQSVTzzEUasileznFbf1Vr7c2sw405hp7iM/C+MDH6621D5TUKL9wiVTdFO2YKFtGQgM8uBQve5N7d2QdzWttO+lk1Pg7mEL5+l+7kzh15MSBX01dGY/p2BFXMSC5ocg9k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773736119; c=relaxed/simple; bh=RyEyZWlgRoJR+qedehkyL9nP/wYmPAVc+XgVhfvHdrY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=TjB93y/6vIcR6yR7j4C3IF+kZ4vJvkqi12f2H3GwJ4aCpNA7mX6CPSq4DKS0ld1iedu/M8SIfwIu1MDa4/EDG8WbXWlsrmHgwYDBGX8hyVyP8pRkQiPc1yJPHtVVbQAiEyEP4R65mEr345/mFncKDLbgq96bDwcqQEnhOxskFJQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=dvtS/P1q; arc=none smtp.client-ip=198.175.65.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="dvtS/P1q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773736115; x=1805272115; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=RyEyZWlgRoJR+qedehkyL9nP/wYmPAVc+XgVhfvHdrY=; b=dvtS/P1qbN0Mc5MF8SioxFPpAqgPhKOhUvmSfg4C18YjPO8hTrGrZWcM KAW3iftWlGZD5VpExWuWMf1+XTxH3B3e1+BvZPf6VzH6AjGg0lYoY57R9 bP4XTzF7sCUQiWLZyoocIoojpldKRkrmq7C+IgRig7emimeCJkKxif5Zl oqufHYnQ+99KIcY7qnLgRmjzA2T9Hd2ZGnjoiVW0jpoRly7Pef0DAQlNr Y6WxS78riZlF5juvLCOBFsWlCXYcI3lbXUsXxad6KGNa52EQPgFwA0AZr V8r4rTIKra9mY4aoZs+GhdnkHSp5ZOAHWB0TT1wWcDHQfBv8LPPQNoFIK A==; X-CSE-ConnectionGUID: 9jV6F+6yTUib446U6RVTfA== X-CSE-MsgGUID: FRxacTWJSK+Ruem4Ud/OEg== X-IronPort-AV: E=McAfee;i="6800,10657,11731"; a="74795338" X-IronPort-AV: E=Sophos;i="6.23,124,1770624000"; d="scan'208";a="74795338" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2026 01:28:34 -0700 X-CSE-ConnectionGUID: Nc5HWpsCSjG1czo0fM73Eg== X-CSE-MsgGUID: YLUR8khUTjWWamcEA4RNrA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,124,1770624000"; d="scan'208";a="252689770" Received: from krybak-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.246.32]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2026 01:28:29 -0700 From: Jani Nikula To: Ville =?utf-8?B?U3lyasOkbMOk?= , Thomas Zimmermann Cc: Jammy Huang , Dave Airlie , Jocelyn Falempe , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/ast: DisplayPort edid supports 256 bytes In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland References: <20260313-upstream_ast_dp_edid-v1-1-2a75b7c091b2@aspeedtech.com> <7b91451a-7764-4822-b15b-47437592691f@suse.de> Date: Tue, 17 Mar 2026 10:28:26 +0200 Message-ID: <5c090a1cc9eb75eaacf2932241636bd12016df13@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 17 Mar 2026, Ville Syrj=C3=A4l=C3=A4 wrote: > On Tue, Mar 17, 2026 at 08:41:35AM +0100, Thomas Zimmermann wrote: >> Hi >>=20 >> Am 17.03.26 um 08:09 schrieb Ville Syrj=C3=A4l=C3=A4: >> > On Mon, Mar 16, 2026 at 01:38:22PM +0200, Jani Nikula wrote: >> >> On Mon, 16 Mar 2026, Thomas Zimmermann 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 >> >>>> --- >> >>>> 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 =3D 0; >> >>>> unsigned int i; >> >>>>=20=20=20=20 >> >>>> - 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 short= ened >> >>> EDID work with DRM. If you leave this as-is, it will still clear sup= port >> >>> for any extension in block 1. >> >>> >> >>> See the table 2.4 in the VESA EDID 1.4 standard for the semantics. F= or >> >>> 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.=C2=A0 In 1.4, the block map is optional. That code should cl= ear 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. >> > I think as a short term goal it would be much better if all EDID >> > mangling would be done by drm_edid.c rather than individual drivers. >>=20 >> We don't fix the EDID here, but work around a hardware limitation. I=20 >> guess we could fix this automatically near edid_block_read() [1] if the= =20 >> driver clearly communicates this issue.=C2=A0 The read loop could then f= ix=20 >> the header's checksum by itself. > > edid_filter_invalid_blocks() already has the code to update > the extension block count and fix up the checksum. I've been meaning to nuke edid_filter_invalid_blocks()... It's a real problem that users report issues with EDID, attach the EDID from sysfs, but it's not the actual EDID because the kernel modified it. BR, Jani. > > So seems to me all we'd need is some way for the driver to > indicate it simply cannot read the requested block (based on > which edid_read_block() would return some other value than > EDID_BLOCK_READ_FAIL), and then the fixup happens naturally. > > Hmm. What happens if the driver returns "success" for the > read, but just leaves the entire block zeroed? Looks to me > like we should then end up with status=3D=3DEDID_BLOCK_ZERO > and the block will get treated as invalid and filtered out. > >> Best regards >> Thomas >>=20 >> [1]=20 >> https://elixir.bootlin.com/linux/v6.19.8/source/drivers/gpu/drm/drm_edid= .c#L2424 >>=20 >> > >>=20 >> --=20 >> -- >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Frankenstr. 146, 90461 N=C3=BCrnberg, Germany, www.suse.com >> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG N=C3= =BCrnberg) >>=20 --=20 Jani Nikula, Intel