Re: [PATCH 1/4] dt-bindings: display: vga-connector: Allow hardcoding EDID

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Mon, Jul 06, 2026 at 05:40:30PM +0200, Maxime Ripard wrote:
> On Mon, Jul 06, 2026 at 12:45:22PM +0300, Laurent Pinchart wrote:
> > On Mon, Jul 06, 2026 at 10:52:32AM +0200, Maxime Ripard wrote:
> > > On Mon, Jul 06, 2026 at 12:35:39AM +0300, Laurent Pinchart wrote:
> > > > Since DDC version 2, introduced in 1996, VGA monitors have exposed EDID
> > > > data over an I2C bus. The bus is also used to detect the presence of a
> > > > connected monitor by trying to read the EDID data.
> > > > 
> > > > Some devices where the VGA display is integrated in the device and
> > > > always connected do not connect the DDC pins. Some development boards,
> > > > such as the Renesas M3N Salvator-XS, also do not connect the DDC pins.
> > > > 
> > > > To support those, add the ability to provide hardcoded EDID data in the
> > > > device tree. This is mutually exclusive with specifying a DDC bus, and
> > > > can only be done when the VGA display is guaranteed to be always
> > > > connected.
> > > > 
> > > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > 
> > > This feels redundant with the EDID firmware loading mechanism we have in
> > > KMS already. It should at least be mentioned why we would need to set it
> > > in the device tree at all.
> > 
> > Very good question.
> > 
> > I assume you're talking about CONFIG_DRM_LOAD_EDID_FIRMWARE, as the
> > debugfs override_edid feature isn't meant for production. If there are
> > other relevant mechanisms I'm not aware of, please let me know.
> 
> No, that's indeed what I meant.
> 
> > In the use case at hand, the VGA display is an integral part of the
> > device, the same way an LVDS or DSI panel would be. Using
> > CONFIG_DRM_LOAD_EDID_FIRMWARE, the manufacturer would need to set the
> > drm.edid_firmware command line parameter, and provide EDID as a file in
> > /lib/firmware/ (possibly in an initramfs). Beside the complexity, and
> > the fact it won't be very friendly to people who run a different
> > userspace on the device, I think EDID counts in this case as system
> > description, the same way we support specifying panel timings in device
> > tree.
> 
> It's *some* hardware description, but you have no idea whether it's
> actually the hardware you're running from. What would be in that EDID
> anyway?

It would be the EDID corresponding to the connected display :-) I see it
as identical to how a user of the simple panel driver is responsible for
listing the timings corresponding to the hardware in the device tree.

> There's another alternative we've used several times already, in
> simple-bridge for example: just register any VESA mode up to a given
> resolution:
> https://elixir.bootlin.com/linux/v7.1.2/source/drivers/gpu/drm/bridge/simple-bridge.c#L66

I don't see how that would help. The goal is to provide the kernel with
the data corresponding to the display integrated in the device.

> I guess it's what you would do with that EDID anyway?

-- 
Regards,

Laurent Pinchart