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>
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]