On 26/09/2025 18:09, Dmitry Baryshkov wrote:
On Fri, Sep 26, 2025 at 11:30:26AM +0100, Srinivas Kandagatla wrote:
On 9/25/25 5:28 AM, Dmitry Baryshkov wrote:
On Thu, Sep 25, 2025 at 12:05:09PM +0800, Jianfeng Liu wrote:
After reusing drm_hdmi_audio_* helpers and drm_bridge_connector
integration in drm/msm/dp, we have dropped msm_dp_audio_hw_params and
use msm_dp_audio_prepare instead. While userspace is still calling
hw_params to do audio initialization, and we get the following errors:
q6apm-lpass-dais 3700000.remoteproc:glink-edge:gpr:service@1:bedais:
q6apm_lpass_dai_prepare() started
q6apm-lpass-dais 3700000.remoteproc:glink-edge:gpr:service@1:bedais:
q6apm_lpass_dai_prepare() started
q6apm-lpass-dais 3700000.remoteproc:glink-edge:gpr:service@1:bedais:
q6apm_lpass_dai_prepare() started
hdmi-audio-codec hdmi-audio-codec.0.auto: hdmi_codec_hw_params() started
q6apm-lpass-dais 3700000.remoteproc:glink-edge:gpr:service@1:bedais:
q6apm_lpass_dai_prepare() started
qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd
qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1
q6apm-lpass-dais 3700000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to
start APM port 104
q6apm-lpass-dais 3700000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error
(-22): at snd_soc_dai_prepare() on DISPLAY_PORT_RX_0
MultiMedia2 Playback: ASoC error (-22): at dpcm_run_update_startup() on
MultiMedia2 Playback
And a call to hdmi_codec_prepare() comes only at this place.
Srini, Mark, when selecting to only implement .prepare for codec ops I
was following the commit 2fef64eec23a ("ASoC: hdmi-codec: Add a prepare
hook"), which documents that IEC958 status bit is set after
.hw_params(), so it's only visible during .prepare(). Is it okay to
implement both callbacks? Or should the audioreach DAI driver be fixed
somehow instead (I suppose it assumes that the port is available after
.hw_params(), not sure if that assumption is correct)?
msm_dp_audio_prepare is not called because hdmi-codec driver only checks
and runs hw_params before q6apm_lpass_dai_prepare(). This commit will
add hw_params callback same as drm_connector_hdmi_audio_prepare, so that
hdmi-codec driver can work with userspace alsa.
Tested with Radxa Dragon Q6A.
Fixes: 98a8920e7b07 ("drm/msm/dp: reuse generic HDMI codec implementation")
Signed-off-by: Jianfeng Liu <[email protected]>
The patch LGTM, but I would wait for response from audio maintainers.
The ordering matters in this case as we need clocks and audio
configuration on DP codec side to be setup before we start configuring
the dsp pipeline. Looks like that DSP is trying to setup DP endpoint
even before it is ready.
q6apm prepare loads the dsp pipeline and starts configuring the
endpoints, if the DP endpoint is not ready dsp would throw an error.
We might be able to pull in some dsp logs to confirm this, but I dont
have a setup that I can reproduce this issue.
What would be your recommendation to proceed? Is it okay for the DAI
driver to depend on the .hw_params enabling the clock? Also I see that
the error regarding the clocks comes from .prepare callback too. What is
the order of .prepare callbacks()? Can we influence it?
Srinivas, any response from your side?
--
With best wishes
Dmitry
