On 19/12/2025 11:54, Maxime Ripard wrote:
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.


Yes, I wanted to keep it const, as we usually do for all function tables. I will use drmm_alloc for it.


--
With best wishes
Dmitry

Reply via email to