Message-ID: <st6wob5hden6ypxt2emzokfhl3ezpbuypv2kdtf5zdrdhlyjfw@l2neflb4uupo>
Date: Tue, 2 Sep 2025 20:06:54 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Daniel Stone <daniel@...ishbar.org>, 
	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>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann <tzimmermann@...e.de>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Sandy Huang <hjc@...k-chips.com>, Heiko Stübner <heiko@...ech.de>, 
	Andy Yan <andy.yan@...k-chips.com>, Chen-Yu Tsai <wens@...e.org>, 
	Samuel Holland <samuel@...lland.org>, Dave Stevenson <dave.stevenson@...pberrypi.com>, 
	Maíra Canal <mcanal@...lia.com>, Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>, 
	Liu Ying <victor.liu@....com>, Rob Clark <robin.clark@....qualcomm.com>, 
	Dmitry Baryshkov <lumag@...nel.org>, Abhinav Kumar <abhinav.kumar@...ux.dev>, 
	Jessica Zhang <jessica.zhang@....qualcomm.com>, Sean Paul <sean@...rly.run>, 
	Marijn Suijten <marijn.suijten@...ainline.org>, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, linux-sunxi@...ts.linux.dev, 
	linux-arm-msm@...r.kernel.org, freedreno@...ts.freedesktop.org
Subject: Re: [PATCH v3 00/11] drm/connector: hdmi: limit infoframes per
 driver capabilities

On Tue, Sep 02, 2025 at 06:45:44AM +0300, Dmitry Baryshkov wrote:
> On Mon, Sep 01, 2025 at 09:07:02AM +0200, Maxime Ripard wrote:
> > On Sun, Aug 31, 2025 at 01:29:13AM +0300, Dmitry Baryshkov wrote:
> > > On Sat, Aug 30, 2025 at 09:30:01AM +0200, Daniel Stone wrote:
> > > > Hi Dmitry,
> > > > 
> > > > On Sat, 30 Aug 2025 at 02:23, Dmitry Baryshkov
> > > > <dmitry.baryshkov@....qualcomm.com> wrote:
> > > > > It's not uncommon for the particular device to support only a subset of
> > > > > HDMI InfoFrames. It's not a big problem for the kernel, since we adopted
> > > > > a model of ignoring the unsupported Infoframes, but it's a bigger
> > > > > problem for the userspace: we end up having files in debugfs which do
> > > > > mot match what is being sent on the wire.
> > > > >
> > > > > Sort that out, making sure that all interfaces are consistent.
> > > > 
> > > > Thanks for the series, it's a really good cleanup.
> > > > 
> > > > I know that dw-hdmi-qp can support _any_ infoframe, by manually
> > > > packing it into the two GHDMI banks. So the supported set there is
> > > > 'all of the currently well-known ones, plus any two others, but only
> > > > two and not more'. I wonder if that has any effect on the interface
> > > > you were thinking about for userspace?
> > > 
> > > I was mostly concerned with the existing debugfs interface (as it is
> > > also used e.g. for edid-decode, etc).
> > > 
> > > It seems "everything + 2 spare" is more or less common (ADV7511, MSM
> > > HDMI also have those. I don't have at hand the proper datasheet for
> > > LT9611 (non-UXC one), but I think its InfoFrames are also more or less
> > > generic).  Maybe we should change debugfs integration to register the
> > > file when the frame is being enabled and removing it when it gets unset.
> > 
> > But, like, for what benefit?
> > 
> > It's a debugfs interface for userspace to consume. The current setup
> > works fine with edid-decode already. Why should we complicate the design
> > that much and create fun races like "I'm running edid-decode in parallel
> > to a modeset that would remove the file I just opened, what is the file
> > now?".
> 
> Aren't we trading that with the 'I'm running edid-decode in paralle with
> to a modeset and the file suddenly becomes empty'?

In that case, you know what the file is going to be: empty. And you went
from a racy, straightforward, design to a racy, complicated, design.

It was my question before, but I still don't really see what benefits it
would have, and why we need to care about it in the core, when it could
be dealt with in the drivers just fine on a case by case basis.

> > > Then in the long run we can add 'slots' and allocate some of the frames
> > > to the slots. E.g. ADV7511 would get 'software AVI', 'software SPD',
> > > 'auto AUDIO' + 2 generic slots (and MPEG InfoFrame which can probably be
> > > salvaged as another generic one)). MSM HDMI would get 'software AVI',
> > > 'software AUDIO' + 2 generic slots (+MPEG + obsucre HDMI which I don't
> > > want to use). Then the framework might be able to prioritize whether to
> > > use generic slots for important data (as DRM HDR, HDMI) or less important
> > > (SPD).
> > 
> > Why is it something for the framework to deal with? If you want to have
> > extra infoframes in there, just go ahead and create additional debugfs
> > files in your driver.
> > 
> > If you want to have the slot mechanism, check in your atomic_check that
> > only $NUM_SLOT at most infoframes are set.
> 
> The driver can only decide that 'we have VSI, SPD and DRM InfoFrames
> which is -ETOOMUCH for 2 generic slots'. The framework should be able to
> decide 'the device has 2 generic slots, we have HDR data, use VSI and
> DRM InfoFrames and disable SPD for now'.

I mean... the spec does? The spec says when a particular feature
requires to send a particular infoframe. If your device cannot support
to have more than two "features" enabled at the same time, so be it. It
something that should be checked in that driver atomic_check.

Or just don't register the SPD debugfs file, ignore it, put a comment
there, and we're done too.

> But... We are not there yet and I don't have clear usecase (we support
> HDR neither on ADV7511 nor on MSM HDMI, after carefully reading the
> guide I realised that ADV7511 has normal audio infoframes). Maybe I
> should drop all the 'auto' features, simplifying this series and land
> [1] for LT9611UXC as I wanted origianlly.
> 
> [1] https://lore.kernel.org/dri-devel/20250803-lt9611uxc-hdmi-v1-2-cb9ce1793acf@oss.qualcomm.com/

Looking back at that series, I think it still has value to rely on the
HDMI infrastructure at the very least for the atomic_check sanitization.

But since you wouldn't use the generated infoframes, just skip the
debugfs files registration. You're not lying to userspace anymore, and
you get the benefits of the HDMI framework.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)

Powered by blists - more mailing lists