Message-ID: <3772903.e9J7NaK4W3@workhorse>
Date: Thu, 11 Dec 2025 20:34:22 +0100
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: Harry Wentland <harry.wentland@....com>, Leo Li <sunpeng.li@....com>,
 Rodrigo Siqueira <siqueira@...lia.com>,
 Alex Deucher <alexander.deucher@....com>,
 Christian König <christian.koenig@....com>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Thomas Zimmermann <tzimmermann@...e.de>,
 Andrzej Hajda <andrzej.hajda@...el.com>,
 Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>,
 Sandy Huang <hjc@...k-chips.com>,
 Heiko Stübner <heiko@...ech.de>,
 Andy Yan <andy.yan@...k-chips.com>,
 Jani Nikula <jani.nikula@...ux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>,
 Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
 Tvrtko Ursulin <tursulin@...ulin.net>, Dmitry Baryshkov <lumag@...nel.org>,
 Sascha Hauer <s.hauer@...gutronix.de>, Rob Herring <robh@...nel.org>,
 kernel@...labora.com, amd-gfx@...ts.freedesktop.org,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 intel-gfx@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org
Subject: Re: [PATCH v5 04/17] drm/bridge: Act on the DRM color format property

On Tuesday, 9 December 2025 15:27:28 Central European Standard Time Maxime Ripard wrote:
> Hi,
> 
> On Fri, Nov 28, 2025 at 10:05:40PM +0100, Nicolas Frattaroli wrote:
> > The new DRM color format property allows userspace to request a specific
> > color format on a connector. In turn, this fills the connector state's
> > color_format member to switch color formats.
> > 
> > Make drm_bridges consider the color_format set in the connector state
> > during the atomic bridge check. Specifically, reject any output bus
> > formats that do not correspond to the requested color format.
> > 
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
> > ---
> >  drivers/gpu/drm/drm_bridge.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 45 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 8f355df883d8..8aac9747f35e 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -1052,6 +1052,47 @@ static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
> >  	return ret;
> >  }
> >  
> > +static bool __pure bus_format_is_color_fmt(u32 bus_fmt, enum drm_color_format fmt)
> > +{
> > +	if (fmt == DRM_COLOR_FORMAT_AUTO)
> > +		return true;
> > +
> > +	switch (bus_fmt) {
> > +	case MEDIA_BUS_FMT_FIXED:
> > +		return true;
> > +	case MEDIA_BUS_FMT_RGB888_1X24:
> > +	case MEDIA_BUS_FMT_RGB101010_1X30:
> > +	case MEDIA_BUS_FMT_RGB121212_1X36:
> > +	case MEDIA_BUS_FMT_RGB161616_1X48:
> > +		return fmt == DRM_COLOR_FORMAT_RGB444;
> > +	case MEDIA_BUS_FMT_YUV8_1X24:
> > +	case MEDIA_BUS_FMT_YUV10_1X30:
> > +	case MEDIA_BUS_FMT_YUV12_1X36:
> > +	case MEDIA_BUS_FMT_YUV16_1X48:
> > +		return fmt == DRM_COLOR_FORMAT_YCBCR444;
> > +	case MEDIA_BUS_FMT_UYVY8_1X16:
> > +	case MEDIA_BUS_FMT_VYUY8_1X16:
> > +	case MEDIA_BUS_FMT_YUYV8_1X16:
> > +	case MEDIA_BUS_FMT_YVYU8_1X16:
> > +	case MEDIA_BUS_FMT_UYVY10_1X20:
> > +	case MEDIA_BUS_FMT_YUYV10_1X20:
> > +	case MEDIA_BUS_FMT_VYUY10_1X20:
> > +	case MEDIA_BUS_FMT_YVYU10_1X20:
> > +	case MEDIA_BUS_FMT_UYVY12_1X24:
> > +	case MEDIA_BUS_FMT_VYUY12_1X24:
> > +	case MEDIA_BUS_FMT_YUYV12_1X24:
> > +	case MEDIA_BUS_FMT_YVYU12_1X24:
> > +		return fmt == DRM_COLOR_FORMAT_YCBCR422;
> > +	case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
> > +	case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
> > +	case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
> > +	case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
> > +		return fmt == DRM_COLOR_FORMAT_YCBCR420;
> > +	default:
> > +		return false;
> > +	}
> > +}
> > +
> >  /*
> >   * This function is called by &drm_atomic_bridge_chain_check() just before
> >   * calling &drm_bridge_funcs.atomic_check() on all elements of the chain.
> > @@ -1137,6 +1178,10 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
> >  	}
> >  
> >  	for (i = 0; i < num_out_bus_fmts; i++) {
> > +		if (!bus_format_is_color_fmt(out_bus_fmts[i], conn_state->color_format)) {
> > +			ret = -ENOTSUPP;
> > +			continue;
> > +		}
> 
> Sorry, I'm struggling a bit to understand how this would work if a bridge both supports the bus
> format selection and HDMI state helpers? Can you expand on it?

I have very little idea of whether this makes conceptual sense. The
hope is that by working backwards from the last bridge and only
accepting either fixed formats or something that corresponds to
the target color format, we don't claim that a setup can do a
colour format if the whole bridge chain isn't able to do it.

Of course, format conversions along the bridge chain where one
input format can be converted to a set of output formats by some
bridge will throw a massive wrench into this. And this is all
assuming that the bus format is in any way related to the color
format that will be sent out on the wire.

In practice, I don't have any hardware where whatever counts as
a "bridge" is an actually more involved setup than just the TX
controller. I tried looking into getting a board with one of the
supported DSI-to-HDMI bridge chips so I can at least test how it
would work in such a scenario, and I got one, but I'd need to make
my own flat flex PCB to adapt it to the pinout of my SBC's DSI
port.

So yeah I don't know how it's supposed to work, I just know this
works for the case I'm working with, and any more complex case
is literally unobtanium hardware which I'm not going to bother
blowing days on maybe making a cable for when I'm already touching
three different GPU drivers here and the intel-gfx-ci is screaming
into my inbox about vague failures in unrelated codepaths in its
native language, Klingon.

Which is all to say: is there a virtual drm bridge driver that
exists, where I can set what formats it supports on the input
and on the output, so that I can actually get a feel for how this
is conceptually supposed to work without needing special hardware?

Better yet: do you have a specific setup in mind where you know
this approach does not work?

> 
> Maxime
> 

Powered by blists - more mailing lists