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
signature.asc
Description: PGP signature
