[PATCH RFC 0/5] drm: add DRM HDMI Codec framework

[Dmitry Baryshkov]

While porting lt9611 DSI-to-HDMI bridge driver to use HDMI Connector
framework, I stumbled upon an issue while handling the Audio InfoFrames.
The HDMI codec callbacks weren't receiving the drm_atomic_state, so
there was no simple way to get the drm_connector that stayed at the end
of the bridge chain. At the same point the drm_hdmi_connector functions
expected to get drm_connector instance.

While looking for a way to solve the issue, I stumbled upon several
deficiencies in existing hdmi_codec_ops implementations. Only few of the
implementations were able to handle codec's 'plugged' callback. One
third of the drivers didn't implement the get_eld() callback.

Most of the issues can be solved if drm_connector handles
hdmi-audio-codec on its own, delegating functionality to the actual
implementation, be it a driver that implements drm_connector or
drm_bridge.

Implement such high-level framework, adding proper support for Audio
InfoFrame generation to the LT9611 driver.

Several design decisions to be kept in mind:

- drm_connector_hdmi_codec is kept as simple as possible. It implements
  generic functionality (ELD, hotplug, registration).

- drm_hdmi_connector allocates drm_connector_hdmi_codec if the connector
  is setup correspondingly (either I2S or S/PDIF is marked as
  supported).

- drm_bridge_connector provides a way to link HDMI audio codec
  funcionality in the drm_bridge with the drm_connector_hdmi_codec
  framework.

- The drm_bridge didn't implemnent support for no_capture_mute flag. Nor
  there is support for no_i2s_playback/_capture and no_spdif_playback /
  _capture flags. I think it's worth moving no_capture_mute to the
  hdmi_codec_pdata, together with the rest of the codec data. This will
  allow us to keep single implementation of ops in the
  drm_bridge_connector.
  At the same time it might be worth reverting the
  no_i2s_capture / no_spdif_capture bits. Only TDA889x driver sets them,
  while it's safe to assume that most of HDMI / DP devices do not
  support ARC / capture. I think the drivers should opt-in capture
  support rather than having to opt-out of it.

- The bridge's driver has the unbalanced call to
  drmm_connector_hdmi_codec_free(). This is because of the difference in
  lifetime cycles. The drm_connector is tied to the lifetime of the DRM
  device, by using the drmm_ calls. However the bridge can be removed,
  while the DRM device is still lingering on its path to destruction.

This series is in the RFC stage, so some bits are underdocumented.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
---
Dmitry Baryshkov (5):
      drm/bridge: lt9611: use HDMI Connector helper to set InfoFrames
      ASoC: hdmi-codec: pass data to get_dai_id too
      drm/connector: implement generic HDMI codec helpers
      drm/bridge: connector: add support for HDMI codec framework
      drm/bridge: lt9611: switch to using the DRM HDMI codec framework

 drivers/gpu/drm/Makefile                           |   1 +
 drivers/gpu/drm/bridge/Kconfig                     |   2 +
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c     |   3 +-
 drivers/gpu/drm/bridge/analogix/anx7625.c          |   3 +-
 drivers/gpu/drm/bridge/lontium-lt9611.c            | 347 ++++++++++++---------
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c         |   3 +-
 drivers/gpu/drm/bridge/sii902x.c                   |   3 +-
 .../gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c    |   3 +-
 drivers/gpu/drm/drm_bridge_connector.c             | 130 +++++++-
 drivers/gpu/drm/drm_connector.c                    |   8 +
 drivers/gpu/drm/drm_connector_hdmi_codec.c         | 157 ++++++++++
 include/drm/drm_bridge.h                           |  46 +++
 include/drm/drm_connector.h                        |  33 ++
 include/sound/hdmi-codec.h                         |   3 +-
 sound/soc/codecs/hdmi-codec.c                      |   2 +-
 15 files changed, 594 insertions(+), 150 deletions(-)
---
base-commit: f83b272021ad706ff952bc53b707a3a8657eef71
change-id: 20240530-drm-bridge-hdmi-connector-9b0f6725973e

Best regards,
-- 
Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>