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 > > > <[email protected]> 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'? > > 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'. 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/[email protected]/ -- With best wishes Dmitry
