From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
Jammy Huang <jammy_huang@aspeedtech.com>,
Dave Airlie <airlied@redhat.com>,
Jocelyn Falempe <jfalempe@redhat.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/ast: DisplayPort edid supports 256 bytes
Date: Tue, 17 Mar 2026 09:09:27 +0200 [thread overview]
Message-ID: <abj-J1yYsFymXmn5@intel.com> (raw)
In-Reply-To: <ad40e82fc2e6501f1b6e1073c70a6f1c308c89a8@intel.com>
On Mon, Mar 16, 2026 at 01:38:22PM +0200, Jani Nikula wrote:
> On Mon, 16 Mar 2026, Thomas Zimmermann <tzimmermann@suse.de> 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@aspeedtech.com>
> >> ---
> >> 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.
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.
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-03-17 7:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 10:04 [PATCH] drm/ast: DisplayPort edid supports 256 bytes Jammy Huang
2026-03-16 10:04 ` Thomas Zimmermann
2026-03-16 11:38 ` Jani Nikula
2026-03-16 12:06 ` Thomas Zimmermann
2026-03-17 2:44 ` Jammy Huang
2026-03-17 7:44 ` Thomas Zimmermann
2026-03-17 7:09 ` Ville Syrjälä [this message]
2026-03-17 7:41 ` Thomas Zimmermann
2026-03-17 8:12 ` Ville Syrjälä
2026-03-17 8:17 ` Thomas Zimmermann
2026-03-17 8:28 ` Jani Nikula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abj-J1yYsFymXmn5@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jammy_huang@aspeedtech.com \
--cc=jani.nikula@linux.intel.com \
--cc=jfalempe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.