| Message ID | 20241217-drm-bridge-hdmi-connector-v7-0-cb9df2b6a515@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: add DRM HDMI Codec framework | expand |
On Tue Dec 17, 2024 at 1:40 AM CET, Dmitry Baryshkov wrote: > This series depends on the ELD mutex series [1] > > [1] https://lore.kernel.org/r/20241201-drm-connector-eld-mutex-v1-0-ba56a6545c03@linaro.org There's a v2 of that patch series here: https://lore.kernel.org/all/20241206-drm-connector-eld-mutex-v2-0-c9bce1ee8bea@linaro.org/ HTH, Diederik
On Tue, Dec 17, 2024 at 01:36:29PM +0100, Diederik de Haas wrote: > On Tue Dec 17, 2024 at 1:40 AM CET, Dmitry Baryshkov wrote: > > This series depends on the ELD mutex series [1] > > > > [1] https://lore.kernel.org/r/20241201-drm-connector-eld-mutex-v1-0-ba56a6545c03@linaro.org > > There's a v2 of that patch series here: > https://lore.kernel.org/all/20241206-drm-connector-eld-mutex-v2-0-c9bce1ee8bea@linaro.org/ ... and it's even merged to drm-misc-next. I dropped it from b4 deps, but I forgot to update the cover letter.
Hi, On Tue, Dec 17, 2024 at 02:40:22AM +0200, Dmitry Baryshkov wrote: > 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 sets up HDMI codec device 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. > > - 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. Sorry if this isn't clear to me and I'm quite late to the party, but did you test this on vc4 with both a pi3 and pi4, or was it just compile tested? Maxime
On Tue, 17 Dec 2024 at 19:21, Maxime Ripard <mripard@kernel.org> wrote: > > Hi, > > On Tue, Dec 17, 2024 at 02:40:22AM +0200, Dmitry Baryshkov wrote: > > 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 sets up HDMI codec device 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. > > > > - 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. > > Sorry if this isn't clear to me and I'm quite late to the party, but did > you test this on vc4 with both a pi3 and pi4, or was it just compile > tested? LT9611 is actually tested, VC4 is only compile-tested. Should I put an RFT tag?
On Wed, Dec 18, 2024 at 07:24:23AM +0200, Dmitry Baryshkov wrote: > On Tue, 17 Dec 2024 at 19:21, Maxime Ripard <mripard@kernel.org> wrote: > > On Tue, Dec 17, 2024 at 02:40:22AM +0200, Dmitry Baryshkov wrote: > > > 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 sets up HDMI codec device 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. > > > > > > - 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. > > > > Sorry if this isn't clear to me and I'm quite late to the party, but did > > you test this on vc4 with both a pi3 and pi4, or was it just compile > > tested? > > LT9611 is actually tested, VC4 is only compile-tested. Should I put an RFT tag? Yeah, we definitely need to test it on the pi3 (polling-based) and the pi4 (irq-based) at least. Dave, Maira, could you give it a try? Maxime
Hi Maxime & Dmitry On Wed, 18 Dec 2024 at 07:59, Maxime Ripard <mripard@kernel.org> wrote: > > On Wed, Dec 18, 2024 at 07:24:23AM +0200, Dmitry Baryshkov wrote: > > On Tue, 17 Dec 2024 at 19:21, Maxime Ripard <mripard@kernel.org> wrote: > > > On Tue, Dec 17, 2024 at 02:40:22AM +0200, Dmitry Baryshkov wrote: > > > > 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 sets up HDMI codec device 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. > > > > > > > > - 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. > > > > > > Sorry if this isn't clear to me and I'm quite late to the party, but did > > > you test this on vc4 with both a pi3 and pi4, or was it just compile > > > tested? > > > > LT9611 is actually tested, VC4 is only compile-tested. Should I put an RFT tag? > > Yeah, we definitely need to test it on the pi3 (polling-based) and the > pi4 (irq-based) at least. > > Dave, Maira, could you give it a try? I'm on it. Dave > Maxime
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 sets up HDMI codec device 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. - 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. This series depends on the ELD mutex series [1] [1] https://lore.kernel.org/r/20241201-drm-connector-eld-mutex-v1-0-ba56a6545c03@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- Changes in v7: - Renamed drm_connector_hdmi_codec_init() to drm_connector_hdmi_audio_init() (Maxime) - Added extra empty line in struct drm_connector_hdmi_codec_funcs (Maxime) - Dropped if/else from drm_bridge_connector_audio_startup() (Maxime) - Added optional .read_edid() callback and reworked drm_atomic_helper_connector_hdmi_hotplug() to use that callback instead of having an internal function which accepts EDID (Maxime) - Made VC4 and drm_bridge_connector use .force() in addition to .detect() and .detect_ctx(). - Moved HDMI codec functions out of struct drm_connector_hdmi_funcs. Assign them from drm_connector_hdmi_audio_init(). - Documented struct drm_connector_hdmi_codec and its fields. - Link to v6: https://lore.kernel.org/r/20241206-drm-bridge-hdmi-connector-v6-0-50dc145a9c06@linaro.org Changes in v6: - Dropped extra checks on the EDID (Jani) - Reworked drmm_connector_hdmi_init(), splitting the codec init to a separate optional function rather than passing arguments through drm_connector (Maxime) - Reworked EDID update functions (Maxime, Jani) - No longer refresh the EDID in vc4_hdmi_connector_get_modes(), it is redundant as vc4_hdmi_connector_detect_cxtx() already does that. - Link to v5: https://lore.kernel.org/r/20241201-drm-bridge-hdmi-connector-v5-0-b5316e82f61a@linaro.org Changes in v5: - Moved prototypes from drm_internal.h to drm_connector_hdmi_codec_internal.h (Jani) - Rebased on top of ELD mutex series, resolving the long-standing FIXME - Converted the VC4 driver (compile-tested only) - Link to v4: https://lore.kernel.org/r/20241122-drm-bridge-hdmi-connector-v4-0-b4d69d6e3bd9@linaro.org Changes in v4: - Added forward declaration of struct drm_edid (LKP) - Fixed kerneldoc for drm_atomic_helper_connector_hdmi_update_edid(). - Link to v3: https://lore.kernel.org/r/20241109-drm-bridge-hdmi-connector-v3-0-c15afdca5884@linaro.org Changes in v3: - Dropped RFC status - Fixed drm_connector_hdmi_codec_init() kerneldoc (LKP) - Dropped double underscore prefix from __drm_atomic_helper_connector_hdmi_update_edid() (Jani) - Moved drm_edid_free() from drm_atomic_helper_connector_hdmi_update_edid() to the caller's side (Jani) - Link to v2: https://lore.kernel.org/r/20241101-drm-bridge-hdmi-connector-v2-0-739ef9addf9e@linaro.org Changes in v2: - Use drm_atomic_get_old_connector_for_encoder in atomic_disable() to prevent it from crashing - Reworked HDMI codec init/exit, removing drmm_ calls (Maxime) - Drafted the helper to be called from .detect_ctx() that performs HDMI Connector maintenance duties (Maxime) - Moved no_capture_mute to struct hdmi_codec_pdata - Link to v1: https://lore.kernel.org/r/20240615-drm-bridge-hdmi-connector-v1-0-d59fc7865ab2@linaro.org --- Dmitry Baryshkov (10): ASoC: hdmi-codec: pass data to get_dai_id too ASoC: hdmi-codec: move no_capture_mute to struct hdmi_codec_pdata 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 drm/display/hdmi: implement hotplug functions drm/bridge_connector: hook drm_atomic_helper_connector_hdmi_hotplug() drm/vc4: hdmi: switch to using generic HDMI Codec infrastructure drm/vc4: hdmi: stop rereading EDID in get_modes() drm/vc4: hdmi: use drm_atomic_helper_connector_hdmi_hotplug_edid() drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 3 +- drivers/gpu/drm/bridge/analogix/anx7625.c | 3 +- drivers/gpu/drm/bridge/ite-it66121.c | 2 +- drivers/gpu/drm/bridge/lontium-lt9611.c | 169 ++++++++---------- drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 +- drivers/gpu/drm/bridge/sii902x.c | 5 +- .../gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 +- drivers/gpu/drm/display/drm_bridge_connector.c | 137 ++++++++++++++- drivers/gpu/drm/display/drm_hdmi_state_helper.c | 56 ++++++ drivers/gpu/drm/drm_connector.c | 5 + drivers/gpu/drm/drm_connector_hdmi_codec.c | 189 +++++++++++++++++++++ drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_dp.c | 2 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +- drivers/gpu/drm/sti/sti_hdmi.c | 2 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 99 +++-------- drivers/gpu/drm/vc4/vc4_hdmi.h | 2 - include/drm/display/drm_hdmi_state_helper.h | 5 + include/drm/drm_bridge.h | 38 +++++ include/drm/drm_connector.h | 141 +++++++++++++++ include/sound/hdmi-codec.h | 7 +- sound/soc/codecs/hdmi-codec.c | 4 +- 25 files changed, 678 insertions(+), 206 deletions(-) --- base-commit: 81a9a93b169a273ccc4a9a1ee56f17e9981d3f98 change-id: 20240530-drm-bridge-hdmi-connector-9b0f6725973e Best regards,