From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (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 028EE41D4EC; Mon, 6 Jul 2026 10:03:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783332212; cv=none; b=EQQbNKrMHXnKzzLj20k6UxBxlm7qtrgMLNWl6fGzk/fghKnSYIEGlF0p2rlumxeUh9ardNOYCCIEZGChLnXX2rws+Slffn8kudJLoqiJVAWwdqez35XZ/+swmVzfH1UBwmyHp82Bwm3EHs+rVnwe/vs2bSU7DrWbu4OifR2u4A4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783332212; c=relaxed/simple; bh=Sb4iMYjbedO64WmPLzaRf05zqar0z8v+EnBWdzETtUg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Hbw2DJGbqz7FyENRjnT8QFUjypl3mnbWUA7A2xEEmNkZi7DHgFPRUlHglMkSpATakyGVwO/WofBNyoP88sAtNjuTafYK2msJmyEgQ2yQWEm5weGt3OX2liJIj1YjSV7pSrG4g0VxFj5/2F8DTiiP2IU5PHLK3e+qGMQGdN4jBR0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=BWFu4YUB; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="BWFu4YUB" Received: from killaraus.ideasonboard.com (2001-14ba-70f3-e800--a06.rev.dnainternet.fi [IPv6:2001:14ba:70f3:e800::a06]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 21E8133D; Mon, 6 Jul 2026 12:02:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1783332160; bh=Sb4iMYjbedO64WmPLzaRf05zqar0z8v+EnBWdzETtUg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BWFu4YUBI/IcrAAjTK1CItkEH1FftGsDP7SOEZp9j02bgYinuypdBO11soxkSjvA8 JUrJ6PgZHVkFxO+iKj0vkdfTPhpMH+TELU8hb9oTM7V4LqPJlqsFhllXBAvv0UE3x3 +f97cTPme7hAI5ubiZRfwQDMmQ5h8WotKuUDjX6M= Date: Mon, 6 Jul 2026 13:03:27 +0300 From: Laurent Pinchart To: Geert Uytterhoeven Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, Thuan Nguyen , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Geert Uytterhoeven , Magnus Damm , Andrzej Hajda , Neil Armstrong , Robert Foss , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH 1/4] dt-bindings: display: vga-connector: Allow hardcoding EDID Message-ID: <20260706100327.GA66892@killaraus.ideasonboard.com> References: <20260705213542.28987-1-laurent.pinchart+renesas@ideasonboard.com> <20260705213542.28987-2-laurent.pinchart+renesas@ideasonboard.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Mon, Jul 06, 2026 at 10:08:57AM +0200, Geert Uytterhoeven wrote: > On Sun, 5 Jul 2026 at 23:35, 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 > > Thanks for your patch! > > > --- a/Documentation/devicetree/bindings/display/connector/vga-connector.yaml > > +++ b/Documentation/devicetree/bindings/display/connector/vga-connector.yaml > > @@ -19,10 +19,25 @@ properties: > > description: phandle link to the I2C controller used for DDC EDID probing > > $ref: /schemas/types.yaml#/definitions/phandle > > > > + edid: > > + $ref: /schemas/types.yaml#/definitions/uint8-array > > + description: > > + When the DDC signals are not wired to the connector, and the connected > > + display is not removable, this property is used to supply a binary EDID > > + blob for the display. > > + > > port: > > $ref: /schemas/graph.yaml#/properties/port > > description: Connection to controller providing VGA signals > > > > +allOf: > > + - if: > > + required: > > + - ddc-i2c-bus > > + then: > > + properties: > > + edid: false > > + > > What if the DDC signals are wired to the connector on the provider side, > but not on the consumer side? > A DT overlay describing the consumer device can add an edid property, > but it cannot delete the ddc-i2c-bus property in the base DTB. As the use case is devices where the VGA display is an integral part of the device, I don't this this is a big issue. I would be quite surprised if a manufacturer wanted to support different SKUs with multiple VGA display overlays, with the DDC signals wired up in the base board on all SKUs, and on the VGA display side in some SKUs only. If that happened, they could set the ddc-i2c-bus property in the overlays that wire the signals, implement /delete-property/ support for overlays (would be an interesting feature in my opinion), or as a very last resort propose relaxing the constraint here. > > required: > > - compatible > > - port -- Regards, Laurent Pinchart