mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
To: Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.com>
Cc: linux-sound <linux-sound@vger.kernel.org>,
	wtaymans@redhat.com, arun@asymptotic.io,
	Jaroslav Kysela <perex@perex.cz>,
	lkml <linux-kernel@vger.kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Subject: DP/HDMI Jack and Pipewire
Date: Fri, 7 Nov 2025 10:15:50 +0000	[thread overview]
Message-ID: <76b8ca1d-040b-472e-9804-5c0c0100b5b5@oss.qualcomm.com> (raw)

Hi Everyone,

On Qualcomm platforms we have an issue enabling Display port on a full
Distro setup with pipewire and wireplumber in place.

The issue is that Display port Audio IP on Qualcomm SoC is powered off
if there is no Display connected. It make sense to keep it in this low
power mode when there is no use. And the DP IP is not expecting any data
in this state and any attempt to configure or send data would result in
error from DSP.

However, we create PCM devices and jacks for all audio sinks and
sources, including DisplayPort DAI links. When PipeWire starts up
without any awareness of jack state it probes all available PCM devices,
including the DisplayPort ones. Since no display is connected, the
prepare callback for DP fails, leading PipeWire to mark the sound card
as unusable. Consequently, it abandons entire sound card, including
other valid audio sinks. I have also started discussing this issue with
pipewire [1]


What is the expected pcm device behavior when DP jack is not connected?

Two possibilities:

1. Consume the data even when the Display is not connected. I see that
in Intel case it sinks the data somewhere and gives the user an
experience that the data is getting consumed.

2. Throw an error to user if they attempt to configure or send the data
to this disconnected pcm.


Also what userspace ABI to for such usecase?

This is blocking end-to-end DP audio enablement on Qualcomm SoCs.

Not sure if this is right approach or will work but somehow we back the
pcm devices with disconnected jack state to use dummy pcm ops instead of
actual pcm ops?
This should at least keep the pipewire happy. Is this the right approach?


[1]: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4938

Thanks,
Srini

             reply	other threads:[~2025-11-07 10:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07 10:15 Srinivas Kandagatla [this message]
2025-11-08  9:21 ` Takashi Iwai
2025-11-09 11:43   ` Jaroslav Kysela

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76b8ca1d-040b-472e-9804-5c0c0100b5b5@oss.qualcomm.com \
    --to=srinivas.kandagatla@oss.qualcomm.com \
    --cc=arun@asymptotic.io \
    --cc=broonie@kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    --cc=wtaymans@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®