Hi Maxime, On Thu, 22 Feb 2024 at 20:14, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > Hi, > > 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. 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? Some context, older MSM devices have an on-die HDMI encoder, implemented as drm_bridge at drivers/gpu/drm/msm/hdmi. Newer generation of devices has dropped the on-die HDMI implementation in favour of using external DSI-to-HDMI bridges, like Lontium LT9611 or LT9611UXC. I'm looking at enabling new HDMI infrastructure for both cases. -- With best wishes Dmitry
