Hi Dmitry, On Sun, Feb 25, 2024 at 04:50:00PM +0200, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 20:14, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > Here's a series that creates some extra infrastructure specifically > > targeted at HDMI controllers. > > > > The idea behind this series came from a recent discussion on IRC during > > which we discussed infoframes generation of i915 vs everything else. > > > > Infoframes generation code still requires some decent boilerplate, with > > each driver doing some variation of it. > > > > In parallel, while working on vc4, we ended up converting a lot of i915 > > logic (mostly around format / bpc selection, and scrambler setup) to > > apply on top of a driver that relies only on helpers. > > > > While currently sitting in the vc4 driver, none of that logic actually > > relies on any driver or hardware-specific behaviour. > > > > The only missing piece to make it shareable are a bunch of extra > > variables stored in a state (current bpc, format, RGB range selection, > > etc.). > > > > The initial implementation was relying on some generic subclass of > > drm_connector to address HDMI connectors, with a bunch of helpers that > > will take care of all the "HDMI Spec" related code. Scrambler setup is > > missing at the moment but can easily be plugged in. > > > > The feedback was that creating a connector subclass like was done for > > writeback would prevent the adoption of those helpers since it couldn't > > be used in all situations (like when the connector driver can implement > > multiple output) and required more churn to cast between the > > drm_connector and its subclass. The decision was thus to provide a set > > of helper and to store the required variables in drm_connector and > > drm_connector_state. This what has been implemented now. > > > > Hans Verkuil also expressed interest in implementing a mechanism in v4l2 > > to retrieve infoframes from HDMI receiver and implementing a tool to > > decode (and eventually check) infoframes. His current work on > > edid-decode to enable that based on that series can be found here: > > https://git.linuxtv.org/hverkuil/edid-decode.git/log/?h=hverkuil > > > > And some more context here: > > https://lore.kernel.org/dri-devel/50db7366-cd3d-4675-aaad-b857202234de@xxxxxxxxx/ > > > > This series thus leverages the infoframe generation code to expose it > > through debugfs. > > [...] > > > > > Let me know what you think, > > Maxime > > The overall idea looks great. I've started checking how I can use that > for our msm devices family, which makes use of bridges and > drm_bridge_connector. Yeah, I had that in mind for a while too. I think it would be valuable, but it's difficult as it is already so I didn't tackle it at first :) The format negociation especially seems to divert quite a lot from what i915 and vc4 have been doing, and that's user facing to some extent. > My current idea is to extend the drm_bridge_funcs with the new > callback to be called once the drm_connector has been instantiated. > This way all the bridges can influence new connector. > Another possibility is to follow drm_bridge_connector design closely > and let it call into drm_connector_hdmi code if it detects that the > last bridge is the HDMI one. > WDYT? I had the latter in mind, but I haven't really tried to reconcile the connector state output_format with the drm_atomic_helper_bridge_propagate_bus_fmt, and plug in the output_bpc count too. We would have to create the max_bpc properties from the HDMI connector, and then propagate that upstream along the bridges I guess (or we can just ignore it for now). So, yeah, I had the latter in mind but it might turn out that the former is actually easier. Both make sense to me at least. Maxime
Attachment:
signature.asc
Description: PGP signature
