Re: [PATCH v3 00/11] drm/connector: hdmi: limit infoframes per driver capabilities

[Maxime Ripard <mripard@kernel.org>]

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

On Sat, Dec 06, 2025 at 01:28:14PM +0200, Dmitry Baryshkov wrote:
> On Mon, Dec 01, 2025 at 06:01:56PM +0100, Maxime Ripard wrote:
> > On Fri, Nov 21, 2025 at 07:09:01PM +0200, Dmitry Baryshkov wrote:
> > > > So it's not really impossible, you just need some hardware and a day's
> > > > worth of work.
> > > > 
> > > > There's no reason these should get a pass, it's breaking the spec for no
> > > > reason.
> > > > 
> > > > > > For SPD, It's really not clear to me why atomic_check should do that in
> > > > > > the first place. Your initial concern was about exposing infoframes in
> > > > > > debugfs that wouldn't be used by the driver.
> > > > > > 
> > > > > > If the driver doesn't register a debugfs file for SPD, and ignores
> > > > > > whatever is in the atomic state, what's should we force drivers to do
> > > > > > that?
> > > > > 
> > > > > I really don't think that drivers should mess up with debugfs on their
> > > > > own. Making atomic_check() disable the unsupported InfoFrames makes the
> > > > > picture perfect: the DRM no longer tries to program them to the
> > > > > hardware, DebugFS files stay empty, so the whole state becomes
> > > > > consistent.
> > > > 
> > > > In the "bridge has no access to infoframes" case, there's really no
> > > > infoframe. An empty file is "the infoframe can be there but isn't used",
> > > > not "we don't have access to it and can't report them". Only drivers
> > > > have those infos.
> > > > 
> > > > If we do split up write_infoframe into multiple functions though, I
> > > > guess we could create the debugfs file only if the function pointer is
> > > > set, which removes drivers' involvement if you don't like that.
> > > 
> > > I'm fine with not using HDMI connector framework for lt9611uxc.
> > > Likewise, I think, it's fine to have empty files for the infoframes
> > > which are not being sent over the wire for any reason (hw not supporting
> > > it is one of the reasons).
> > 
> > I can't think of any other example in the kernel where an empty file
> > means that the driver doesn't support something.
> 
> Okay. So we need to sort out implementing the split write_infoframes in
> drm_bridge_connector. Any suggestions there? I'm asking, because I don't
> want to end up exploding it.

I guess it's only really a problem if we want to make it const, but we
don't have to? We could just as well allocate the structure directly at
probe with a drmm helper and fill it as we need to.

Maxime

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