[PATCH 00/11] video: Keep EDID modes and DP lane counts within what is reserved

[PATCH 00/11] video: Keep EDID modes and DP lane counts within what is reserved

[Ana Bobillo]

Much of what U-Boot's video drivers set up comes from the display: the
mode from its EDID and, on DisplayPort, the lane count from its DPCD.
Several drivers take these as they come, while the memory they use is
sized in advance: the frame buffer is reserved for a maximum resolution
when the device is bound, and the DP link training code keeps its
per-lane state in four-entry arrays. A monitor or panel announcing a
larger mode, or more than four lanes, makes U-Boot write past them.

Patch 2 makes video_post_probe() refuse a frame buffer larger than the
memory reserved for it, for every video driver. Patch 1 first fixes the
two STM32MP2 defconfigs whose panel is larger than the maximum they ask
for, which only work thanks to the 2MB alignment of the reservation.

Patches 3 to 9 have the drivers which take the mode from the EDID skip
the modes which do not fit, so that a smaller one is used rather than
no display: edid_get_timing_validate() no longer hands back a timing it
rejected (patch 3), the display uclass learns the size of the source's
frame buffer (patch 4), which rk_vop, sunxi DE2 and Tegra124 pass to it
(patches 5 to 7), and the sunxi DE1 and Tegra HDMI drivers, which read
the EDID themselves, check their own limits (patches 8 and 9).

Patches 10 and 11 limit the DPCD lane count to four in the Rockchip eDP
and Tegra124 DP drivers.

Tested on sandbox: the two new tests, dm_test_video_fb_size and
edid_test_timing_validate, fail without the fixes (the first one
crashes sandbox) and pass with them, and ut dm and ut common otherwise
give the same results as on main. Built for chromebook_jerry,
nyan-big, transformer_t30, Cubietruck and orangepi_pc with no new
warnings.

CI: the series passes all 91 jobs of U-Boot's Azure pipeline, in build
13732 of my CI-only pull request, on main d1d45c926a5.
PR:    https://github.com/u-boot/u-boot/pull/1064
Build: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=13732

Ana Bobillo (11):
  configs: stm32mp23/stm32mp25: Size the frame buffer for the LVDS panel
  video: Check that the mode fits in the reserved frame buffer
  edid: Leave the timing alone when no mode is valid
  video: display: Skip modes which do not fit in the source frame buffer
  video: rockchip: vop: Tell the display the frame buffer size
  video: sunxi: de2: Tell the display the frame buffer size
  video: tegra124: Tell the display the frame buffer size
  sunxi: display: Skip EDID modes larger than the frame buffer
  video: tegra: hdmi: Skip modes larger than the DC frame buffer
  video: rockchip: edp: Limit the lane count to four
  video: tegra124: dp: Limit the lane count to four

 common/edid.c                          | 10 ++-
 configs/stm32mp23_defconfig            |  2 +
 configs/stm32mp25_defconfig            |  2 +
 drivers/video/display-uclass.c         | 10 +++
 drivers/video/rockchip/rk_edp.c        |  4 ++
 drivers/video/rockchip/rk_vop.c        | 35 ++++++-----
 drivers/video/sunxi/sunxi_de2.c        |  3 +
 drivers/video/sunxi/sunxi_display.c    |  5 +-
 drivers/video/tegra/dc.c               |  4 +-
 drivers/video/tegra/dc.h               |  4 ++
 drivers/video/tegra/hdmi.c             |  5 ++
 drivers/video/tegra/tegra124/display.c |  3 +
 drivers/video/tegra/tegra124/dp.c      |  3 +
 drivers/video/video-uclass.c           | 12 ++++
 include/display.h                      |  6 ++
 include/edid.h                         |  3 +-
 test/common/Makefile                   |  1 +
 test/common/edid.c                     | 87 ++++++++++++++++++++++++++
 test/dm/video.c                        | 29 +++++++++
 19 files changed, 204 insertions(+), 24 deletions(-)
 create mode 100644 test/common/edid.c


base-commit: d1d45c926a571fb6c1e6d7105c280833646915ea

[PATCH 01/11] configs: stm32mp23/stm32mp25: Size the frame buffer for the LVDS panel

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

The boards built from these defconfigs drive a 1024x600 LVDS panel at
16bpp, but CONFIG_VIDEO_STM32_MAX_XRES and CONFIG_VIDEO_STM32_MAX_YRES
keep their 640x480 defaults, so stm32_ltdc_bind() asks for half of the
1228800 bytes the frame buffer needs. The display only works because
the frame buffer is aligned to 2MB, which leaves room past the size
asked for.

Set the maximum resolution to the panel's, so that the frame buffer
fits in the size asked for. The video uclass is about to check that.

Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 configs/stm32mp23_defconfig | 2 ++
 configs/stm32mp25_defconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/stm32mp23_defconfig b/configs/stm32mp23_defconfig
index 04aaa0f6b26..8d960a51e02 100644
--- a/configs/stm32mp23_defconfig
+++ b/configs/stm32mp23_defconfig
@@ -97,6 +97,8 @@ CONFIG_STM32_OSPI=y
 CONFIG_VIDEO=y
 CONFIG_VIDEO_STM32=y
 CONFIG_VIDEO_STM32_LVDS=y
+CONFIG_VIDEO_STM32_MAX_XRES=1024
+CONFIG_VIDEO_STM32_MAX_YRES=600
 CONFIG_WDT=y
 CONFIG_WDT_STM32MP=y
 CONFIG_WDT_ARM_SMC=y
diff --git a/configs/stm32mp25_defconfig b/configs/stm32mp25_defconfig
index e55ca2e3f0f..ac9f562c8ed 100644
--- a/configs/stm32mp25_defconfig
+++ b/configs/stm32mp25_defconfig
@@ -97,6 +97,8 @@ CONFIG_STM32_OSPI=y
 CONFIG_VIDEO=y
 CONFIG_VIDEO_STM32=y
 CONFIG_VIDEO_STM32_LVDS=y
+CONFIG_VIDEO_STM32_MAX_XRES=1024
+CONFIG_VIDEO_STM32_MAX_YRES=600
 CONFIG_WDT=y
 CONFIG_WDT_STM32MP=y
 CONFIG_WDT_ARM_SMC=y

Re: [PATCH 01/11] configs: stm32mp23/stm32mp25: Size the frame buffer for the LVDS panel

[Patrice CHOTARD]

On 11/9/26 18:28, Ana Bobillo wrote:
> From: Ana Bobillo <anabobillo3@gmail.com>
> 
> The boards built from these defconfigs drive a 1024x600 LVDS panel at
> 16bpp, but CONFIG_VIDEO_STM32_MAX_XRES and CONFIG_VIDEO_STM32_MAX_YRES
> keep their 640x480 defaults, so stm32_ltdc_bind() asks for half of the
> 1228800 bytes the frame buffer needs. The display only works because
> the frame buffer is aligned to 2MB, which leaves room past the size
> asked for.
> 
> Set the maximum resolution to the panel's, so that the frame buffer
> fits in the size asked for. The video uclass is about to check that.
> 
> Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
> ---
>  configs/stm32mp23_defconfig | 2 ++
>  configs/stm32mp25_defconfig | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/configs/stm32mp23_defconfig b/configs/stm32mp23_defconfig
> index 04aaa0f6b26..8d960a51e02 100644
> --- a/configs/stm32mp23_defconfig
> +++ b/configs/stm32mp23_defconfig
> @@ -97,6 +97,8 @@ CONFIG_STM32_OSPI=y
>  CONFIG_VIDEO=y
>  CONFIG_VIDEO_STM32=y
>  CONFIG_VIDEO_STM32_LVDS=y
> +CONFIG_VIDEO_STM32_MAX_XRES=1024
> +CONFIG_VIDEO_STM32_MAX_YRES=600
>  CONFIG_WDT=y
>  CONFIG_WDT_STM32MP=y
>  CONFIG_WDT_ARM_SMC=y
> diff --git a/configs/stm32mp25_defconfig b/configs/stm32mp25_defconfig
> index e55ca2e3f0f..ac9f562c8ed 100644
> --- a/configs/stm32mp25_defconfig
> +++ b/configs/stm32mp25_defconfig
> @@ -97,6 +97,8 @@ CONFIG_STM32_OSPI=y
>  CONFIG_VIDEO=y
>  CONFIG_VIDEO_STM32=y
>  CONFIG_VIDEO_STM32_LVDS=y
> +CONFIG_VIDEO_STM32_MAX_XRES=1024
> +CONFIG_VIDEO_STM32_MAX_YRES=600
>  CONFIG_WDT=y
>  CONFIG_WDT_STM32MP=y
>  CONFIG_WDT_ARM_SMC=y

Hi Ana

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

Thanks
Patrice

[PATCH 02/11] video: Check that the mode fits in the reserved frame buffer

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

The video uclass reserves plat->size bytes for the frame buffer of each
video device when it is bound, but many drivers only learn the mode
when the device is probed, some of them from the display's EDID
(rk_vop, sunxi DE2 and the Tegra drivers). video_post_probe() works out
the frame buffer size from that mode and clears the frame buffer, and
the console then draws on it, without checking it against the
reservation. A display announcing a larger mode than the driver allows
for makes U-Boot write past the reserved memory, into the memory
reserved above it, which on ARM holds the MMU page tables.

Refuse to probe a video device whose frame buffer is larger than the
memory reserved for it. The following patches have the drivers skip
such modes, so that a smaller one is used instead.

Add a test which grows the sandbox display after its frame buffer has
been reserved.

Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/video-uclass.c | 12 ++++++++++++
 test/dm/video.c              | 29 +++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 22183d00d97..68712f6f039 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -640,6 +640,18 @@ static int video_post_probe(struct udevice *dev)
 
 	priv->fb_size = priv->line_length * priv->ysize;
 
+	/*
+	 * The mode can come from the display itself (e.g. its EDID), so check
+	 * that the frame buffer fits in the memory reserved for it before
+	 * anything is drawn
+	 */
+	if (plat->size && priv->fb_size > plat->size) {
+		log_err("Video device '%s': %dx%d needs %#x bytes but only %#x are reserved\n",
+			dev->name, priv->xsize, priv->ysize, priv->fb_size,
+			plat->size);
+		return -ENOSPC;
+	}
+
 	/*
 	 * Set up video handoff fields for passing video blob to next stage
 	 * NOTE:
diff --git a/test/dm/video.c b/test/dm/video.c
index cc854d0e042..8b62ac77657 100644
--- a/test/dm/video.c
+++ b/test/dm/video.c
@@ -15,6 +15,7 @@
 #include <video_console.h>
 #include <asm/test.h>
 #include <asm/sdl.h>
+#include <dm/device-internal.h>
 #include <dm/test.h>
 #include <dm/uclass-internal.h>
 #include <test/lib.h>
@@ -46,6 +47,34 @@ static int dm_test_video_base(struct unit_test_state *uts)
 }
 DM_TEST(dm_test_video_base, UTF_SCAN_PDATA | UTF_SCAN_FDT);
 
+/* Test that a mode larger than the reserved frame buffer is refused */
+static int dm_test_video_fb_size(struct unit_test_state *uts)
+{
+	struct video_uc_plat *uc_plat;
+	struct sandbox_sdl_plat *plat;
+	struct udevice *dev;
+	int line_length;
+
+	ut_assertok(uclass_find_first_device(UCLASS_VIDEO, &dev));
+	ut_assertnonnull(dev);
+	ut_assert(!device_active(dev));
+	uc_plat = dev_get_uclass_plat(dev);
+
+	/*
+	 * Change the mode after the frame buffer has been reserved, as drivers
+	 * do with a mode read from the display, so that it needs one line more
+	 * than the reserved memory holds
+	 */
+	plat = dev_get_plat(dev);
+	line_length = plat->xres * VNBYTES(plat->bpix);
+	plat->yres = uc_plat->size / line_length + 1;
+	ut_asserteq(-ENOSPC, device_probe(dev));
+	ut_assert(!device_active(dev));
+
+	return 0;
+}
+DM_TEST(dm_test_video_fb_size, UTF_SCAN_PDATA | UTF_SCAN_FDT);
+
 int video_compress_fb(struct unit_test_state *uts, struct udevice *dev,
 		      bool use_copy)
 {

[PATCH 03/11] edid: Leave the timing alone when no mode is valid

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

edid_find_valid_detailed_timing() decodes each detailed timing into the
caller's struct before asking mode_valid() about it. When it rejects
them all, edid_get_timing_validate() fails but leaves the last rejected
timing behind. The Tegra124 display driver ignores that failure and
uses the timing it passed in, which it set from the device tree, so it
ends up with the mode that was just rejected.

Decode into a local struct and copy it out only once it is accepted, so
the timing is left as it was on any error, and say so in the header.

Add a test for edid_get_timing_validate() with a mode_valid() callback.
It goes in test/common, as the code is in common/.

Fixes: 1c1ed441b0d1 ("edid: add edid_get_timing_validate() variant to filter out edid modes")
Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 common/edid.c        | 10 +++--
 include/edid.h       |  3 +-
 test/common/Makefile |  1 +
 test/common/edid.c   | 87 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 97 insertions(+), 4 deletions(-)
 create mode 100644 test/common/edid.c

diff --git a/common/edid.c b/common/edid.c
index e5aa4ca494f..1d934edf843 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -373,12 +373,16 @@ static bool edid_find_valid_detailed_timing(void *buf, int count,
 
 	for (i = 0; i < count && !found; i++, t++)
 		if (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) != 0) {
-			decode_timing((u8 *)t, timing);
+			struct display_timing dtd;
+
+			/* Leave the caller's timing alone if no mode is valid */
+			decode_timing((u8 *)t, &dtd);
 			if (mode_valid)
-				found = mode_valid(mode_valid_priv,
-						   timing);
+				found = mode_valid(mode_valid_priv, &dtd);
 			else
 				found = true;
+			if (found)
+				*timing = dtd;
 		}
 
 	return found;
diff --git a/include/edid.h b/include/edid.h
index 77a5d258311..fe0d88a859c 100644
--- a/include/edid.h
+++ b/include/edid.h
@@ -315,7 +315,8 @@ struct display_timing;
  *
  * @param buf		Buffer containing EDID data
  * @param buf_size	Size of buffer in bytes
- * @param timing	Place to put preferring timing information
+ * @param timing	Place to put preferring timing information, left
+ *			unchanged on error
  * @param panel_bits_per_colourp	Place to put the number of bits per
  *			colour supported by the panel. This will be set to
  *			-1 if not available
diff --git a/test/common/Makefile b/test/common/Makefile
index baefc7b3622..658f30b3652 100644
--- a/test/common/Makefile
+++ b/test/common/Makefile
@@ -8,6 +8,7 @@ endif
 endif
 
 obj-$(CONFIG_CYCLIC) += cyclic.o
+obj-$(CONFIG_I2C_EDID) += edid.o
 obj-$(CONFIG_EVENT_DYNAMIC) += event.o
 obj-y += cread.o
 obj-$(CONFIG_$(PHASE_)CMDLINE) += print.o
diff --git a/test/common/edid.c b/test/common/edid.c
new file mode 100644
index 00000000000..15f5eb81501
--- /dev/null
+++ b/test/common/edid.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Tests for the EDID timing selection
+ *
+ * Copyright 2026 Ana Bobillo <anabobillo3@gmail.com>
+ */
+
+#include <edid.h>
+#include <fdtdec.h>
+#include <linux/string.h>
+#include <test/common.h>
+#include <test/test.h>
+#include <test/ut.h>
+
+/* Detailed timings for 3840x2160 and 1920x1080 at 60Hz */
+static const u8 dtd_3840x2160[18] = {
+	0x08, 0xe8, 0x00, 0x30, 0xf2, 0x70, 0x5a, 0x80,
+	0xb0, 0x58, 0x8a, 0x00, 0x00, 0x00, 0x00, 0x00,
+	0x00, 0x1e,
+};
+
+static const u8 dtd_1920x1080[18] = {
+	0x02, 0x3a, 0x80, 0x18, 0x71, 0x38, 0x2d, 0x40,
+	0x58, 0x2c, 0x45, 0x00, 0x00, 0x00, 0x00, 0x00,
+	0x00, 0x1e,
+};
+
+static void edid_test_fill(u8 *buf)
+{
+	struct edid1_info *edid = (struct edid1_info *)buf;
+
+	memset(buf, '\0', EDID_SIZE);
+	memcpy(edid->header, "\x0\xff\xff\xff\xff\xff\xff\x0", 8);
+	edid->version = 1;
+	edid->revision = 4;
+	edid->video_input_definition = 0xa5;	/* digital, 8 bits/colour */
+	edid->feature_support = 0x02;		/* preferred timing mode */
+	memset(edid->standard_timings, 0x01, sizeof(edid->standard_timings));
+	memcpy(&edid->monitor_details.timing[0], dtd_3840x2160,
+	       sizeof(dtd_3840x2160));
+	memcpy(&edid->monitor_details.timing[sizeof(dtd_3840x2160)],
+	       dtd_1920x1080, sizeof(dtd_1920x1080));
+}
+
+static bool edid_test_max_1920(void *priv, const struct display_timing *timing)
+{
+	return timing->hactive.typ <= 1920;
+}
+
+static bool edid_test_none(void *priv, const struct display_timing *timing)
+{
+	return false;
+}
+
+/* Test that a timing rejected by mode_valid is skipped, and never returned */
+static int edid_test_timing_validate(struct unit_test_state *uts)
+{
+	struct display_timing timing;
+	u8 buf[EDID_SIZE];
+	int bpc;
+
+	edid_test_fill(buf);
+
+	ut_assertok(edid_get_timing_validate(buf, sizeof(buf), &timing, &bpc,
+					     NULL, NULL));
+	ut_asserteq(3840, timing.hactive.typ);
+	ut_asserteq(2160, timing.vactive.typ);
+	ut_asserteq(8, bpc);
+
+	ut_assertok(edid_get_timing_validate(buf, sizeof(buf), &timing, &bpc,
+					     edid_test_max_1920, NULL));
+	ut_asserteq(1920, timing.hactive.typ);
+	ut_asserteq(1080, timing.vactive.typ);
+
+	/* With no valid mode, the timing passed in is left as it was */
+	memset(&timing, '\0', sizeof(timing));
+	timing.hactive.typ = 640;
+	timing.vactive.typ = 480;
+	ut_asserteq(-EINVAL, edid_get_timing_validate(buf, sizeof(buf), &timing,
+						      &bpc, edid_test_none,
+						      NULL));
+	ut_asserteq(640, timing.hactive.typ);
+	ut_asserteq(480, timing.vactive.typ);
+
+	return 0;
+}
+COMMON_TEST(edid_test_timing_validate, 0);

Re: [PATCH 03/11] edid: Leave the timing alone when no mode is valid

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Mon, Nov 09, 2026 at 05:29:11PM +0000, Ana Bobillo wrote:

> From: Ana Bobillo <anabobillo3@gmail.com>
> 
> edid_find_valid_detailed_timing() decodes each detailed timing into the
> caller's struct before asking mode_valid() about it. When it rejects
> them all, edid_get_timing_validate() fails but leaves the last rejected
> timing behind. The Tegra124 display driver ignores that failure and
> uses the timing it passed in, which it set from the device tree, so it
> ends up with the mode that was just rejected.
> 
> Decode into a local struct and copy it out only once it is accepted, so
> the timing is left as it was on any error, and say so in the header.
> 
> Add a test for edid_get_timing_validate() with a mode_valid() callback.
> It goes in test/common, as the code is in common/.
> 
> Fixes: 1c1ed441b0d1 ("edid: add edid_get_timing_validate() variant to filter out edid modes")
> Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>

I'm a little confused, sorry. There's two drivers which use
edid_get_timing_validate. The Tegra124 uses it, and falls back to a
hard-coded 720p on failure, intentionally, and seems reasonable. The
MediaTek driver sees the failure and then turns off clocks for the
driver. So I'm not sure why any of the functional changes here are
necessary or a good idea, can you please elaborate?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 03/11] edid: Leave the timing alone when no mode is valid

[Ana Bobillo]

Hi Tom,

On Mon, 9 Nov 2026 at 18:16, Tom Rini <trini@konsulko.com> wrote:
> I'm a little confused, sorry. There's two drivers which use
> edid_get_timing_validate. The Tegra124 uses it, and falls back to a
> hard-coded 720p on failure, intentionally, and seems reasonable. The
> MediaTek driver sees the failure and then turns off clocks for the
> driver. So I'm not sure why any of the functional changes here are
> necessary or a good idea, can you please elaborate?

Sorry, the commit message makes it look like a bug in the current code,
and it isn't one: for those two callers the timing left behind does not
matter, as you say. (The 720p fallback is in tegra/hdmi.c, the
Tegra20/30 HDMI driver.)

The caller I meant is the third one, display_read_timing(), which calls
edid_get_timing_validate() with display_mode_valid(). Tegra124's
display_init() (tegra/tegra124/display.c) first fills its timing from
the device tree, then lets display_read_timing() replace it from the
eDP panel's EDID, and if that fails it carries on with what it has
("Failed to decode EDID, using defaults").

Today that works, because the Tegra124 DP driver has no mode_valid(), so
the first detailed timing is always accepted and the timing is only
overwritten by a mode that is used. Patch 4 makes display_mode_valid()
reject the modes which do not fit in the frame buffer, and patch 7 has
Tegra124 pass its size. Without this patch, a panel whose EDID only has
modes too large for the frame buffer would leave the last of them in
the timing, and display_init() would use it instead of the device tree
one. Patch 2 then refuses it in video_post_probe(), so there would be
no display at all, rather than the panel's device tree mode.

So it is a prerequisite for patches 4 and 7, not a fix. In v2 I will
drop the Fixes: tag and say that in the commit message. If you would
rather leave edid_get_timing_validate() as it is, display_init() could
instead decode the device tree timing again when display_read_timing()
fails; I can do it that way if you prefer.

Thanks,
Ana

[PATCH 04/11] video: display: Skip modes which do not fit in the source frame buffer

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

display_read_timing() picks the first EDID timing which the display
driver accepts, but the display driver does not know how much memory
the video device feeding it has reserved for its frame buffer, so it
can pick a mode which does not fit.

Add the size and depth of the source's frame buffer to struct
display_plat, which the video device sets, as it does src_dev, before
it reads the timing. display_mode_valid() then skips the modes which do
not fit, so that a smaller one is picked. A video device which does not
set them is not affected.

Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/display-uclass.c | 10 ++++++++++
 include/display.h              |  6 ++++++
 2 files changed, 16 insertions(+)

diff --git a/drivers/video/display-uclass.c b/drivers/video/display-uclass.c
index 85dac12a197..06888df4112 100644
--- a/drivers/video/display-uclass.c
+++ b/drivers/video/display-uclass.c
@@ -42,6 +42,16 @@ static bool display_mode_valid(void *priv, const struct display_timing *timing)
 {
 	struct udevice *dev = priv;
 	struct dm_display_ops *ops = display_get_ops(dev);
+	struct display_plat *disp_uc_plat = dev_get_uclass_plat(dev);
+	u64 bits;
+
+	/* Skip modes which do not fit in the source's frame buffer */
+	if (disp_uc_plat->fb_size) {
+		bits = (u64)timing->hactive.typ * timing->vactive.typ *
+		       disp_uc_plat->fb_bpp;
+		if (bits > (u64)disp_uc_plat->fb_size * 8)
+			return false;
+	}
 
 	if (ops && ops->mode_valid)
 		return ops->mode_valid(dev, timing);
diff --git a/include/display.h b/include/display.h
index 26b965daba9..f2ff9ffced8 100644
--- a/include/display.h
+++ b/include/display.h
@@ -18,11 +18,17 @@ struct display_timing;
  * controller
  * @src_dev:	Source device providing the video
  * @in_use:	Display is being used
+ * @fb_size:	Size of the source's frame buffer in bytes, or 0 if unknown. Set
+ *		by the source before reading the timing, so that modes which
+ *		do not fit in the frame buffer are skipped
+ * @fb_bpp:	Bits per pixel of the source's frame buffer
  */
 struct display_plat {
 	int source_id;
 	struct udevice *src_dev;
 	bool in_use;
+	uint fb_size;
+	int fb_bpp;
 };
 
 /**

Re: [PATCH 04/11] video: display: Skip modes which do not fit in the source frame buffer

[Svyatoslav Ryhel]

пн, 9 лист. 2026 р. о 19:29 Ana Bobillo <anabobillo3@gmail.com> пише:
>
> From: Ana Bobillo <anabobillo3@gmail.com>
>
> display_read_timing() picks the first EDID timing which the display
> driver accepts, but the display driver does not know how much memory
> the video device feeding it has reserved for its frame buffer, so it
> can pick a mode which does not fit.
>
> Add the size and depth of the source's frame buffer to struct
> display_plat, which the video device sets, as it does src_dev, before
> it reads the timing. display_mode_valid() then skips the modes which do
> not fit, so that a smaller one is picked. A video device which does not
> set them is not affected.
>
> Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
> ---
>  drivers/video/display-uclass.c | 10 ++++++++++
>  include/display.h              |  6 ++++++
>  2 files changed, 16 insertions(+)
>
> diff --git a/drivers/video/display-uclass.c b/drivers/video/display-uclass.c
> index 85dac12a197..06888df4112 100644
> --- a/drivers/video/display-uclass.c
> +++ b/drivers/video/display-uclass.c
> @@ -42,6 +42,16 @@ static bool display_mode_valid(void *priv, const struct display_timing *timing)
>  {
>         struct udevice *dev = priv;
>         struct dm_display_ops *ops = display_get_ops(dev);
> +       struct display_plat *disp_uc_plat = dev_get_uclass_plat(dev);
> +       u64 bits;
> +
> +       /* Skip modes which do not fit in the source's frame buffer */
> +       if (disp_uc_plat->fb_size) {
> +               bits = (u64)timing->hactive.typ * timing->vactive.typ *
> +                      disp_uc_plat->fb_bpp;
> +               if (bits > (u64)disp_uc_plat->fb_size * 8)
> +                       return false;
> +       }
>
>         if (ops && ops->mode_valid)
>                 return ops->mode_valid(dev, timing);
> diff --git a/include/display.h b/include/display.h
> index 26b965daba9..f2ff9ffced8 100644
> --- a/include/display.h
> +++ b/include/display.h
> @@ -18,11 +18,17 @@ struct display_timing;
>   * controller
>   * @src_dev:   Source device providing the video
>   * @in_use:    Display is being used
> + * @fb_size:   Size of the source's frame buffer in bytes, or 0 if unknown. Set
> + *             by the source before reading the timing, so that modes which
> + *             do not fit in the frame buffer are skipped
> + * @fb_bpp:    Bits per pixel of the source's frame buffer
>   */
>  struct display_plat {
>         int source_id;
>         struct udevice *src_dev;
>         bool in_use;
> +       uint fb_size;
> +       int fb_bpp;
>  };
>

Decent idea

Acked-by: Svyatoslav Ryhel <clamor95@gmail.com>

[PATCH 05/11] video: rockchip: vop: Tell the display the frame buffer size

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

The VOP reserves a frame buffer for CONFIG_VIDEO_ROCKCHIP_MAX_XRES x
CONFIG_VIDEO_ROCKCHIP_MAX_YRES at 32bpp, but takes whatever mode the
eDP, HDMI or MIPI encoder reads from the display. A display announcing
a larger mode makes the frame buffer run past the reserved memory.

Work out the depth before reading the timing and pass it, with the
reserved size, to the display, so that only modes which fit are used.

Fixes: 7b7ad5c31c91 ("rockchip: video: Add a video-output driver")
Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/rockchip/rk_vop.c | 35 ++++++++++++++++++---------------
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
index 17dfe62c9da..ff7f7a7fa79 100644
--- a/drivers/video/rockchip/rk_vop.c
+++ b/drivers/video/rockchip/rk_vop.c
@@ -245,6 +245,7 @@ static void rkvop_mode_set(struct udevice *dev,
  */
 static int rk_display_init(struct udevice *dev, ulong fbbase, ofnode ep_node)
 {
+	struct video_uc_plat *plat = dev_get_uclass_plat(dev);
 	struct video_priv *uc_priv = dev_get_uclass_priv(dev);
 	int vop_id, remote_vop_id;
 	struct display_timing timing;
@@ -326,6 +327,22 @@ static int rk_display_init(struct udevice *dev, ulong fbbase, ofnode ep_node)
 	}
 	debug("vop_id=%d\n", vop_id);
 
+	/* Set bitwidth for vop display according to vop mode */
+	switch (vop_id) {
+	case VOP_MODE_EDP:
+#if defined(CONFIG_ROCKCHIP_RK3288)
+	case VOP_MODE_LVDS:
+#endif
+		l2bpp = VIDEO_BPP16;
+		break;
+	case VOP_MODE_HDMI:
+	case VOP_MODE_MIPI:
+		l2bpp = VIDEO_BPP32;
+		break;
+	default:
+		l2bpp = VIDEO_BPP16;
+	}
+
 	disp_uc_plat = dev_get_uclass_plat(disp);
 	debug("Found device '%s', disp_uc_priv=%p\n", disp->name, disp_uc_plat);
 	if (display_in_use(disp)) {
@@ -335,6 +352,8 @@ static int rk_display_init(struct udevice *dev, ulong fbbase, ofnode ep_node)
 
 	disp_uc_plat->source_id = remote_vop_id;
 	disp_uc_plat->src_dev = dev;
+	disp_uc_plat->fb_size = plat->size;
+	disp_uc_plat->fb_bpp = 1 << l2bpp;
 
 	ret = device_probe(disp);
 	if (ret) {
@@ -357,22 +376,6 @@ static int rk_display_init(struct udevice *dev, ulong fbbase, ofnode ep_node)
 		return ret;
 	}
 
-	/* Set bitwidth for vop display according to vop mode */
-	switch (vop_id) {
-	case VOP_MODE_EDP:
-#if defined(CONFIG_ROCKCHIP_RK3288)
-	case VOP_MODE_LVDS:
-#endif
-		l2bpp = VIDEO_BPP16;
-		break;
-	case VOP_MODE_HDMI:
-	case VOP_MODE_MIPI:
-		l2bpp = VIDEO_BPP32;
-		break;
-	default:
-		l2bpp = VIDEO_BPP16;
-	}
-
 	rkvop_mode_set(dev, &timing, vop_id);
 
 	ret = reset_get_by_name(dev, "dclk", &dclk_rst);

Re: [PATCH 05/11] video: rockchip: vop: Tell the display the frame buffer size

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

On Mon, Nov 09, 2026 at 05:29:27PM +0000, Ana Bobillo wrote:

> From: Ana Bobillo <anabobillo3@gmail.com>
> 
> The VOP reserves a frame buffer for CONFIG_VIDEO_ROCKCHIP_MAX_XRES x
> CONFIG_VIDEO_ROCKCHIP_MAX_YRES at 32bpp, but takes whatever mode the
> eDP, HDMI or MIPI encoder reads from the display. A display announcing
> a larger mode makes the frame buffer run past the reserved memory.
> 
> Work out the depth before reading the timing and pass it, with the
> reserved size, to the display, so that only modes which fit are used.
> 
> Fixes: 7b7ad5c31c91 ("rockchip: video: Add a video-output driver")
> Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
[snip]
> @@ -357,22 +376,6 @@ static int rk_display_init(struct udevice *dev, ulong fbbase, ofnode ep_node)
>  		return ret;
>  	}
>  
> -	/* Set bitwidth for vop display according to vop mode */
> -	switch (vop_id) {
> -	case VOP_MODE_EDP:
> -#if defined(CONFIG_ROCKCHIP_RK3288)
> -	case VOP_MODE_LVDS:
> -#endif
> -		l2bpp = VIDEO_BPP16;
> -		break;
> -	case VOP_MODE_HDMI:
> -	case VOP_MODE_MIPI:
> -		l2bpp = VIDEO_BPP32;
> -		break;
> -	default:
> -		l2bpp = VIDEO_BPP16;
> -	}
> -
>  	rkvop_mode_set(dev, &timing, vop_id);
>  
>  	ret = reset_get_by_name(dev, "dclk", &dclk_rst);

Just out of patch context, we then use '1 << l2bpp' and should perhaps
now use our new disp_uc_plat->fb_bpp ?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 05/11] video: rockchip: vop: Tell the display the frame buffer size

[Ana Bobillo]

Hi Tom,

On Mon, 9 Nov 2026 at 18:30, Tom Rini <trini@konsulko.com> wrote:
> Just out of patch context, we then use '1 << l2bpp' and should perhaps
> now use our new disp_uc_plat->fb_bpp ?

Yes, it is the same value, and using it there makes it plain that the
VOP and the encoder are set up with the depth the mode was checked
against. In v2 rkvop_enable() and display_enable() will take
disp_uc_plat->fb_bpp; l2bpp is then only used for uc_priv->bpix.

Thanks,
Ana

[PATCH 06/11] video: sunxi: de2: Tell the display the frame buffer size

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

The DE2 driver reserves a frame buffer for LCD_MAX_WIDTH x
LCD_MAX_HEIGHT at 32bpp, but takes whatever mode the HDMI encoder reads
from the display's EDID, while sunxi_dw_hdmi_mode_valid() only checks
the pixel clock. A display announcing a larger mode makes the frame
buffer run past the reserved memory.

Pass the reserved size and depth to the display before reading the
timing, so that only modes which fit are used.

Fixes: 56009451d843 ("sunxi: video: Add A64/H3/H5 HDMI driver")
Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/sunxi/sunxi_de2.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index ab36ee1595b..383cf47b907 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -181,6 +181,7 @@ static int sunxi_de2_init(struct udevice *dev, ulong fbbase,
 			  enum video_log2_bpp l2bpp,
 			  struct udevice *disp, int mux, bool is_composite)
 {
+	struct video_uc_plat *plat = dev_get_uclass_plat(dev);
 	struct video_priv *uc_priv = dev_get_uclass_priv(dev);
 	struct display_timing timing;
 	struct display_plat *disp_uc_plat;
@@ -194,6 +195,8 @@ static int sunxi_de2_init(struct udevice *dev, ulong fbbase,
 	}
 
 	disp_uc_plat->source_id = mux;
+	disp_uc_plat->fb_size = plat->size;
+	disp_uc_plat->fb_bpp = 1 << l2bpp;
 
 	ret = display_read_timing(disp, &timing);
 	if (ret) {

Re: [PATCH 06/11] video: sunxi: de2: Tell the display the frame buffer size

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On Mon, Nov 09, 2026 at 05:29:35PM +0000, Ana Bobillo wrote:
> From: Ana Bobillo <anabobillo3@gmail.com>
> 
> The DE2 driver reserves a frame buffer for LCD_MAX_WIDTH x
> LCD_MAX_HEIGHT at 32bpp, but takes whatever mode the HDMI encoder reads
> from the display's EDID, while sunxi_dw_hdmi_mode_valid() only checks
> the pixel clock. A display announcing a larger mode makes the frame
> buffer run past the reserved memory.
> 
> Pass the reserved size and depth to the display before reading the
> timing, so that only modes which fit are used.
> 
> Fixes: 56009451d843 ("sunxi: video: Add A64/H3/H5 HDMI driver")
> Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>

Here and elsewhere, fixes isn't appropriate for populating newly added
fields.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 06/11] video: sunxi: de2: Tell the display the frame buffer size

[Ana Bobillo]

Hi Tom,

On Mon, 9 Nov 2026 at 18:21, Tom Rini <trini@konsulko.com> wrote:
> Here and elsewhere, fixes isn't appropriate for populating newly added
> fields.

OK, I will drop the Fixes: tags from 5/11 and 6/11 in v2 (7/11 has
none), and from 3/11 as said there. I would keep them on 8/11 to 11/11,
as those change only the driver itself, with no new field: the sunxi
DE1 and Tegra HDMI drivers check their own frame buffer limits, and the
Rockchip eDP and Tegra124 DP drivers limit the lane count to four. Does
that sound right to you?

I will wait a few days for comments on the rest of the series before
sending v2.

Thanks,
Ana

Re: [PATCH 06/11] video: sunxi: de2: Tell the display the frame buffer size

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On Mon, Nov 09, 2026 at 11:28:48AM -0800, Ana Bobillo wrote:
> Hi Tom,
> 
> On Mon, 9 Nov 2026 at 18:21, Tom Rini <trini@konsulko.com> wrote:
> > Here and elsewhere, fixes isn't appropriate for populating newly added
> > fields.
> 
> OK, I will drop the Fixes: tags from 5/11 and 6/11 in v2 (7/11 has
> none), and from 3/11 as said there. I would keep them on 8/11 to 11/11,
> as those change only the driver itself, with no new field: the sunxi
> DE1 and Tegra HDMI drivers check their own frame buffer limits, and the
> Rockchip eDP and Tegra124 DP drivers limit the lane count to four. Does
> that sound right to you?

I'd have to double check, but yes. And it's some general feedback for
all of your current series too, so please go and check those as well.

> I will wait a few days for comments on the rest of the series before
> sending v2.

Sounds good, thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH 07/11] video: tegra124: Tell the display the frame buffer size

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

The Tegra124 display driver reserves a frame buffer for LCD_MAX_WIDTH x
LCD_MAX_HEIGHT at 16bpp, but takes whatever mode the eDP driver reads
from the panel's EDID. A panel announcing a larger mode makes the frame
buffer run past the reserved memory.

Pass the reserved size and depth to the display before it is probed,
so that only modes which fit are used, and the device tree timing is
kept when none does. The width is rounded up to 16 pixels after the
mode is picked, so a mode which only fits before that rounding is still
refused when the video device is probed.

Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/tegra/tegra124/display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/tegra/tegra124/display.c b/drivers/video/tegra/tegra124/display.c
index abe31e27d84..bae4725f064 100644
--- a/drivers/video/tegra/tegra124/display.c
+++ b/drivers/video/tegra/tegra124/display.c
@@ -331,6 +331,7 @@ static int display_update_config_from_edid(struct udevice *dp_dev,
 static int display_init(struct udevice *dev, void *lcdbase,
 			int fb_bits_per_pixel, struct display_timing *timing)
 {
+	struct video_uc_plat *plat = dev_get_uclass_plat(dev);
 	struct display_plat *disp_uc_plat;
 	struct dc_ctlr *dc_ctlr;
 	struct udevice *dp_dev;
@@ -354,6 +355,8 @@ static int display_init(struct udevice *dev, void *lcdbase,
 	debug("Found device '%s', disp_uc_priv=%p\n", dp_dev->name,
 	      disp_uc_plat);
 	disp_uc_plat->src_dev = dev;
+	disp_uc_plat->fb_size = plat->size;
+	disp_uc_plat->fb_bpp = fb_bits_per_pixel;
 
 	ret = uclass_get_device(UCLASS_DISPLAY, 0, &dp_dev);
 	if (ret) {

[PATCH 08/11] sunxi: display: Skip EDID modes larger than the frame buffer

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

sunxi_hdmi_edid_get_mode() takes the first detailed timing of the EDID
which video_edid_dtd_to_ctfb_res_modes() can convert, of any size, but
sunxi_de_bind() only reserves a frame buffer for LCD_MAX_WIDTH x
LCD_MAX_HEIGHT. A display announcing a larger mode makes the frame
buffer run past the reserved memory.

Skip the detailed timings which are larger than that, so that the next
one is used. If none fits, the display is handled as one whose EDID has
no usable detailed timing.

Fixes: 75481607c741 ("sunxi: video: Add DDC & EDID support")
Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/sunxi/sunxi_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/video/sunxi/sunxi_display.c b/drivers/video/sunxi/sunxi_display.c
index fa492c661db..8783c09031a 100644
--- a/drivers/video/sunxi/sunxi_display.c
+++ b/drivers/video/sunxi/sunxi_display.c
@@ -287,10 +287,11 @@ static int sunxi_hdmi_edid_get_mode(struct sunxi_display_priv *sunxi_display,
 		return -EINVAL;
 	}
 
-	/* Take the first usable detailed timing */
+	/* Take the first usable detailed timing which fits in the fb */
 	for (i = 0; i < 4; i++, t++) {
 		r = video_edid_dtd_to_ctfb_res_modes(t, mode);
-		if (r == 0)
+		if (r == 0 && mode->xres <= LCD_MAX_WIDTH &&
+		    mode->yres <= LCD_MAX_HEIGHT)
 			break;
 	}
 	if (i == 4) {

[PATCH 09/11] video: tegra: hdmi: Skip modes larger than the DC frame buffer

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

tegra_lcd_bind() reserves a frame buffer for LCD_MAX_WIDTH x
LCD_MAX_HEIGHT, and the DC takes the mode its HDMI bridge read from the
display's EDID, but tegra_hdmi_mode_valid() only checks the pixel
clock. A display announcing a larger mode makes the frame buffer run
past the reserved memory.

Move the DC limits to dc.h and have tegra_hdmi_mode_valid() refuse the
modes which exceed them, so that a smaller one, or the default 720p
mode, is used instead.

Fixes: 2dd1092ab887 ("video: tegra20: provide driver support for the HDMI controller")
Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/tegra/dc.c   | 4 ++--
 drivers/video/tegra/dc.h   | 4 ++++
 drivers/video/tegra/hdmi.c | 5 +++++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/video/tegra/dc.c b/drivers/video/tegra/dc.c
index ced49718834..07e26f23970 100644
--- a/drivers/video/tegra/dc.c
+++ b/drivers/video/tegra/dc.c
@@ -49,8 +49,8 @@ struct tegra_lcd_priv {
 
 enum {
 	/* Maximum LCD size we support */
-	LCD_MAX_WIDTH		= 2560,
-	LCD_MAX_HEIGHT		= 1600,
+	LCD_MAX_WIDTH		= TEGRA_DC_MAX_WIDTH,
+	LCD_MAX_HEIGHT		= TEGRA_DC_MAX_HEIGHT,
 	LCD_MAX_LOG2_BPP	= VIDEO_BPP16,
 };
 
diff --git a/drivers/video/tegra/dc.h b/drivers/video/tegra/dc.h
index 2a4013b3355..20b417e7b57 100644
--- a/drivers/video/tegra/dc.h
+++ b/drivers/video/tegra/dc.h
@@ -14,6 +14,10 @@
 /* arch-tegra/dc exists only because T124 uses it */
 #include <asm/arch-tegra/dc.h>
 
+/* Largest mode the frame buffer of a DC is reserved for */
+#define TEGRA_DC_MAX_WIDTH	2560
+#define TEGRA_DC_MAX_HEIGHT	1600
+
 struct tegra_dc_plat {
 	struct udevice *dev;		/* Display controller device */
 	struct dc_ctlr *dc;		/* Display controller regmap */
diff --git a/drivers/video/tegra/hdmi.c b/drivers/video/tegra/hdmi.c
index bfb48b25187..caf2b3f2f34 100644
--- a/drivers/video/tegra/hdmi.c
+++ b/drivers/video/tegra/hdmi.c
@@ -431,6 +431,11 @@ static bool tegra_hdmi_mode_valid(void *hdmi_priv, const struct display_timing *
 	if (timing->pixelclock.typ > priv->config->max_pclk)
 		return false;
 
+	/* The DC frame buffer is only reserved for modes up to this size */
+	if (timing->hactive.typ > TEGRA_DC_MAX_WIDTH ||
+	    timing->vactive.typ > TEGRA_DC_MAX_HEIGHT)
+		return false;
+
 	return true;
 }
 

Re: [PATCH 09/11] video: tegra: hdmi: Skip modes larger than the DC frame buffer

[Svyatoslav Ryhel]

пн, 9 лист. 2026 р. о 19:29 Ana Bobillo <anabobillo3@gmail.com> пише:
>
> From: Ana Bobillo <anabobillo3@gmail.com>
>
> tegra_lcd_bind() reserves a frame buffer for LCD_MAX_WIDTH x
> LCD_MAX_HEIGHT, and the DC takes the mode its HDMI bridge read from the
> display's EDID, but tegra_hdmi_mode_valid() only checks the pixel
> clock. A display announcing a larger mode makes the frame buffer run
> past the reserved memory.
>
> Move the DC limits to dc.h and have tegra_hdmi_mode_valid() refuse the
> modes which exceed them, so that a smaller one, or the default 720p
> mode, is used instead.
>
> Fixes: 2dd1092ab887 ("video: tegra20: provide driver support for the HDMI controller")
> Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
> ---
>  drivers/video/tegra/dc.c   | 4 ++--
>  drivers/video/tegra/dc.h   | 4 ++++
>  drivers/video/tegra/hdmi.c | 5 +++++
>  3 files changed, 11 insertions(+), 2 deletions(-)

Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>

[PATCH 10/11] video: rockchip: edp: Limit the lane count to four

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

rk_edp_init_training() takes the lane count from the sink's
MAX_LANE_COUNT DPCD register, masked to 5 bits, and link training uses
it to index the four ln_link_trn_ctl[] registers, the four-entry
train_set[] and the link status read from the sink. A sink reporting
more than four lanes makes rk_edp_set_link_training() write past those
registers into the ones after them, and the training loops read past
train_set[] and the link status buffer.

Limit the lane count to the four lanes the controller has, as the
analogix_dp driver in Linux does.

Fixes: 5852d539eab0 ("rockchip: video: Add a display driver for rockchip eDP")
Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/rockchip/rk_edp.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/video/rockchip/rk_edp.c b/drivers/video/rockchip/rk_edp.c
index 0ba68dbce3d..85c201e8809 100644
--- a/drivers/video/rockchip/rk_edp.c
+++ b/drivers/video/rockchip/rk_edp.c
@@ -646,6 +646,10 @@ static int rk_edp_init_training(struct rk_edp_priv *edp)
 		return -EPERM;
 	}
 
+	/* The sink may report more lanes than the controller has */
+	if (edp->link_train.lane_count > LANE_CNT4)
+		edp->link_train.lane_count = LANE_CNT4;
+
 	ret = rk_edp_link_power_up(edp);
 	if (ret)
 		return ret;

[PATCH 11/11] video: tegra124: dp: Limit the lane count to four

[Ana Bobillo]

From: Ana Bobillo <anabobillo3@gmail.com>

tegra_dc_dp_init_max_link_cfg() takes the lane count from the sink's
MAX_LANE_COUNT DPCD register, masked to 5 bits, and link training uses
it to fill the four-entry pe[], vs[] and pc[] arrays on the stack. A
sink reporting more than four lanes makes tegra_dp_lt_adjust() write
past them.

Limit the lane count to the four lanes the SOR has.

Fixes: 59dd5aa8fa51 ("tegra: video: Add Embedded DisplayPort driver")
Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
---
 drivers/video/tegra/tegra124/dp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/tegra/tegra124/dp.c b/drivers/video/tegra/tegra124/dp.c
index 611bf2f81a6..22e9a4b15f7 100644
--- a/drivers/video/tegra/tegra124/dp.c
+++ b/drivers/video/tegra/tegra124/dp.c
@@ -664,6 +664,9 @@ static int tegra_dc_dp_init_max_link_cfg(
 	if (ret)
 		return ret;
 	link_cfg->max_lane_count = dpcd_data & DP_MAX_LANE_COUNT_MASK;
+	/* The sink may report more lanes than the SOR has */
+	if (link_cfg->max_lane_count > DP_MAX_LANE_COUNT_LANE_4)
+		link_cfg->max_lane_count = DP_MAX_LANE_COUNT_LANE_4;
 	link_cfg->tps3_supported = (dpcd_data &
 			DP_MAX_LANE_COUNT_TPS3_SUPPORTED_YES) ? 1 : 0;
 

Re: [PATCH 11/11] video: tegra124: dp: Limit the lane count to four

[Svyatoslav Ryhel]

пн, 9 лист. 2026 р. о 19:30 Ana Bobillo <anabobillo3@gmail.com> пише:
>
> From: Ana Bobillo <anabobillo3@gmail.com>
>
> tegra_dc_dp_init_max_link_cfg() takes the lane count from the sink's
> MAX_LANE_COUNT DPCD register, masked to 5 bits, and link training uses
> it to fill the four-entry pe[], vs[] and pc[] arrays on the stack. A
> sink reporting more than four lanes makes tegra_dp_lt_adjust() write
> past them.
>
> Limit the lane count to the four lanes the SOR has.
>
> Fixes: 59dd5aa8fa51 ("tegra: video: Add Embedded DisplayPort driver")
> Signed-off-by: Ana Bobillo <anabobillo3@gmail.com>
> ---
>  drivers/video/tegra/tegra124/dp.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/tegra/tegra124/dp.c b/drivers/video/tegra/tegra124/dp.c
> index 611bf2f81a6..22e9a4b15f7 100644
> --- a/drivers/video/tegra/tegra124/dp.c
> +++ b/drivers/video/tegra/tegra124/dp.c
> @@ -664,6 +664,9 @@ static int tegra_dc_dp_init_max_link_cfg(
>         if (ret)
>                 return ret;
>         link_cfg->max_lane_count = dpcd_data & DP_MAX_LANE_COUNT_MASK;
> +       /* The sink may report more lanes than the SOR has */
> +       if (link_cfg->max_lane_count > DP_MAX_LANE_COUNT_LANE_4)
> +               link_cfg->max_lane_count = DP_MAX_LANE_COUNT_LANE_4;
>         link_cfg->tps3_supported = (dpcd_data &
>                         DP_MAX_LANE_COUNT_TPS3_SUPPORTED_YES) ? 1 : 0;
>

Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>

Re: [PATCH 00/11] video: Keep EDID modes and DP lane counts within what is reserved

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

On Mon, Nov 09, 2026 at 05:28:36PM +0000, Ana Bobillo wrote:

> Much of what U-Boot's video drivers set up comes from the display: the
> mode from its EDID and, on DisplayPort, the lane count from its DPCD.
> Several drivers take these as they come, while the memory they use is
> sized in advance: the frame buffer is reserved for a maximum resolution
> when the device is bound, and the DP link training code keeps its
> per-lane state in four-entry arrays. A monitor or panel announcing a
> larger mode, or more than four lanes, makes U-Boot write past them.
> 
> Patch 2 makes video_post_probe() refuse a frame buffer larger than the
> memory reserved for it, for every video driver. Patch 1 first fixes the
> two STM32MP2 defconfigs whose panel is larger than the maximum they ask
> for, which only work thanks to the 2MB alignment of the reservation.
> 
> Patches 3 to 9 have the drivers which take the mode from the EDID skip
> the modes which do not fit, so that a smaller one is used rather than
> no display: edid_get_timing_validate() no longer hands back a timing it
> rejected (patch 3), the display uclass learns the size of the source's
> frame buffer (patch 4), which rk_vop, sunxi DE2 and Tegra124 pass to it
> (patches 5 to 7), and the sunxi DE1 and Tegra HDMI drivers, which read
> the EDID themselves, check their own limits (patches 8 and 9).
> 
> Patches 10 and 11 limit the DPCD lane count to four in the Rockchip eDP
> and Tegra124 DP drivers.
> 
> Tested on sandbox: the two new tests, dm_test_video_fb_size and
> edid_test_timing_validate, fail without the fixes (the first one
> crashes sandbox) and pass with them, and ut dm and ut common otherwise
> give the same results as on main. Built for chromebook_jerry,
> nyan-big, transformer_t30, Cubietruck and orangepi_pc with no new
> warnings.
> 
> CI: the series passes all 91 jobs of U-Boot's Azure pipeline, in build
> 13732 of my CI-only pull request, on main d1d45c926a5.
> PR:    https://github.com/u-boot/u-boot/pull/1064
> Build: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=13732

I would like to ask, given that the project AI policy is "please,
don't", are you using LLMs for your series, and if so to what extent?
Thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 00/11] video: Keep EDID modes and DP lane counts within what is reserved

[Ana Bobillo]

Hi Tom,

On Tue, 10 Nov 2026 at 18:01, Tom Rini <trini@konsulko.com> wrote:
> I would like to ask, given that the project AI policy is "please,
> don't", are you using LLMs for your series, and if so to what extent?

Yes, to the full extent. All of my series on the list were produced by
an LLM-based coding agent: it found the issues by reading the code and
wrote the patches, the tests, the cover letters and the replies on the
list, this one included. The builds, sandbox tests and CI runs the
cover letters describe were really run and passed as stated, but no
person reviewed the patches by hand before they were sent.

I should have said so when I first posted, and I am sorry I did not.
Given the project's policy I will not send a v2 of this series or any
new series. The ones already on the list are for you and the
custodians to decide on.

Ana

Re: [PATCH 00/11] video: Keep EDID modes and DP lane counts within what is reserved

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On Tue, Nov 10, 2026 at 10:16:03AM -0800, Ana Bobillo wrote:
> Hi Tom,
> 
> On Tue, 10 Nov 2026 at 18:01, Tom Rini <trini@konsulko.com> wrote:
> > I would like to ask, given that the project AI policy is "please,
> > don't", are you using LLMs for your series, and if so to what extent?
> 
> Yes, to the full extent. All of my series on the list were produced by
> an LLM-based coding agent: it found the issues by reading the code and
> wrote the patches, the tests, the cover letters and the replies on the
> list, this one included. The builds, sandbox tests and CI runs the
> cover letters describe were really run and passed as stated, but no
> person reviewed the patches by hand before they were sent.
> 
> I should have said so when I first posted, and I am sorry I did not.
> Given the project's policy I will not send a v2 of this series or any
> new series. The ones already on the list are for you and the
> custodians to decide on.

Thanks for answering honestly, we appreciate it.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]