On 2025/6/3 22:06:36, Dmitry Baryshkov wrote:
On Thu, May 29, 2025 at 10:40:12AM +0800, Xilin Wu wrote:
On 2025/4/24 01:52:45, Dmitry Baryshkov wrote:
From: Dmitry Baryshkov <lu...@kernel.org>
The MSM DisplayPort driver implements several HDMI codec functions
in the driver, e.g. it manually manages HDMI codec device registration,
returning ELD and plugged_cb support. In order to reduce code
duplication reuse drm_hdmi_audio_* helpers and drm_bridge_connector
integration.
Signed-off-by: Dmitry Baryshkov <dmitry.barysh...@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.barysh...@oss.qualcomm.com>
---
A lot of DisplayPort bridges use HDMI Codec in order to provide audio
support. Present DRM HDMI Audio support has been written with the HDMI
and in particular DRM HDMI Connector framework support, however those
audio helpers can be easily reused for DisplayPort drivers too.
Patches by Hermes Wu that targeted implementing HDMI Audio support in
the iTE IT6506 driver pointed out the necessity of allowing one to use
generic audio helpers for DisplayPort drivers, as otherwise each driver
has to manually (and correctly) implement the get_eld() and plugged_cb
support.
Implement necessary integration in drm_bridge_connector and provide an
example implementation in the msm/dp driver.
---
Changes in v7:
- Dropped applied patches
- Link to v6:
https://lore.kernel.org/r/20250314-dp-hdmi-audio-v6-0-dbd228fa7...@oss.qualcomm.com
Changes in v6:
- Added DRM_BRIDGE_OP_DP_AUDIO and separate set of DisplayPort audio
callbacks to the drm_bridge interface (Maxime)
- Link to v5:
https://lore.kernel.org/r/20250307-dp-hdmi-audio-v5-0-f3be215fd...@linaro.org
Changes in v5:
- Rebased on top of linux-next, also handling HDMI audio piece of the
MSM HDMI driver.
- Link to v4:
https://lore.kernel.org/r/20250301-dp-hdmi-audio-v4-0-82739daf2...@linaro.org
Changes in v4:
- Rebased on linux-next, adding DRM_BRIDGE_OP_HDMI_AUDIO to Synopsys QP
HDMI driver.
- Drop outdated comment regarding subconnector from the commit message.
- Link to v3:
https://lore.kernel.org/r/20250219-dp-hdmi-audio-v3-0-42900f034...@linaro.org
Changes in v3:
- Dropped DRM_BRIDGE_OP_DisplayPort, added DRM_BRIDGE_OP_HDMI_AUDIO
(Laurent, Maxime)
- Dropped the subconnector patch (again)
- Link to v2:
https://lore.kernel.org/r/20250209-dp-hdmi-audio-v2-0-16db6ebf2...@linaro.org
Changes in v2:
- Added drm_connector_attach_dp_subconnector_property() patches
- Link to v1:
https://lore.kernel.org/r/20250206-dp-hdmi-audio-v1-0-8aa14a8c0...@linaro.org
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/dp/dp_audio.c | 131
++++--------------------------------
drivers/gpu/drm/msm/dp/dp_audio.h | 27 ++------
drivers/gpu/drm/msm/dp/dp_display.c | 28 ++------
drivers/gpu/drm/msm/dp/dp_display.h | 6 --
drivers/gpu/drm/msm/dp/dp_drm.c | 8 +++
6 files changed, 31 insertions(+), 170 deletions(-)
This change breaks DP audio on the qcs6490 platform, tested on kernel
next-20250528.
I can not confirm this issue here (though I tested it on a different
hardware). Do you have any patches on top of linux-next?
I have this patch series applied, but I don't think it could be relevant:
[PATCH v4 0/8] Enable audio on qcs6490-RB3Gen2 and qcm6490-idp boards
https://lore.kernel.org/all/20250527111227.2318021-1-quic_pkump...@quicinc.com/
[ 0.368035] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x70020000
[ 0.369359] hdmi-audio-codec hdmi-audio-codec.0.auto: hdmi_codec_probe:
dai_count 0
[ 0.369362] hdmi-audio-codec hdmi-audio-codec.0.auto: hdmi_codec_probe:
Missing hw_params
[ 0.369364] hdmi-audio-codec hdmi-audio-codec.0.auto: hdmi_codec_probe:
Invalid parameters
[ 0.369366] hdmi-audio-codec hdmi-audio-codec.0.auto: probe with driver
hdmi-audio-codec failed with error -22
[ 0.370536] [drm] Initialized msm 1.12.0 for ae01000.display-controller
on minor 0
Manually reverting this change solves the problem.
It is suspicious, since dai_count can not be 0. We set
hdmi_audio_max_i2s_playback_channels to 8, which in turn should set the
hdmi_codec_pdata.i2s to 1.
It suddenly comes to my mind that I'm using a kernel with everything
compiled as builtin. Could that be a possible issue?
--
Best regards,
Xilin Wu <sop...@radxa.com>
