From: Srinivas Kandagatla <[email protected]>
This patchset adds support for.
1. parse Display Port module tokens from ASoC topology
2. add support to DP/HDMI Jack events.
3. fixes a typo in function name in sm8250
Verified these patches on X13s along with changes to tplg in
https://git.codelinaro.org/linaro/qcomlt/audioreach-topology/-/tree/topic/x13s-dp?ref_type=heads
and ucm changes from https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/tree/topic/x13s-dp
Thanks,
Srini
Changes since v1:
- Fixed unused variable warning.
- fixed warning 'break;' to avoid fall-through
Srinivas Kandagatla (4):
ASoC: qcom: q6dsp: parse Display port tokens
ASoC: qcom: common: add Display port Jack function
ASoC: qcom: sc8280xp: add Display port Jack
ASoC: qcom: sm8250: fix a typo in function name
sound/soc/qcom/common.c | 29 +++++++++++++++++++++++++++++
sound/soc/qcom/common.h | 3 +++
sound/soc/qcom/qdsp6/topology.c | 26 ++++++++++++++++++++++++++
sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
sound/soc/qcom/sm8250.c | 4 ++--
5 files changed, 74 insertions(+), 2 deletions(-)
--
2.25.1
From: Srinivas Kandagatla <[email protected]>
DP Module needs to know the data format type which is specified in the
tplg file, parse that info before setting up the module.
Signed-off-by: Srinivas Kandagatla <[email protected]>
---
sound/soc/qcom/qdsp6/topology.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/sound/soc/qcom/qdsp6/topology.c b/sound/soc/qcom/qdsp6/topology.c
index 70572c83e101..27a5adb201c3 100644
--- a/sound/soc/qcom/qdsp6/topology.c
+++ b/sound/soc/qcom/qdsp6/topology.c
@@ -730,6 +730,29 @@ static int audioreach_widget_i2s_module_load(struct audioreach_module *mod,
return 0;
}
+static int audioreach_widget_dp_module_load(struct audioreach_module *mod,
+ struct snd_soc_tplg_vendor_array *mod_array)
+{
+ struct snd_soc_tplg_vendor_value_elem *mod_elem;
+ int tkn_count = 0;
+
+ mod_elem = mod_array->value;
+
+ while (tkn_count <= (le32_to_cpu(mod_array->num_elems) - 1)) {
+ switch (le32_to_cpu(mod_elem->token)) {
+ case AR_TKN_U32_MODULE_FMT_DATA:
+ mod->data_format = le32_to_cpu(mod_elem->value);
+ break;
+ default:
+ break;
+ }
+ tkn_count++;
+ mod_elem++;
+ }
+
+ return 0;
+}
+
static int audioreach_widget_load_buffer(struct snd_soc_component *component,
int index, struct snd_soc_dapm_widget *w,
struct snd_soc_tplg_dapm_widget *tplg_w)
@@ -760,6 +783,9 @@ static int audioreach_widget_load_buffer(struct snd_soc_component *component,
case MODULE_ID_I2S_SOURCE:
audioreach_widget_i2s_module_load(mod, mod_array);
break;
+ case MODULE_ID_DISPLAY_PORT_SINK:
+ audioreach_widget_dp_module_load(mod, mod_array);
+ break;
default:
return -EINVAL;
}
--
2.25.1
From: Srinivas Kandagatla <[email protected]>
Add a common function to add Display port jack, this can be used by
multiple board files and avoid any code duplication.
Signed-off-by: Srinivas Kandagatla <[email protected]>
---
sound/soc/qcom/common.c | 29 +++++++++++++++++++++++++++++
sound/soc/qcom/common.h | 3 +++
2 files changed, 32 insertions(+)
diff --git a/sound/soc/qcom/common.c b/sound/soc/qcom/common.c
index 747041fa7866..3bfe618e7bd7 100644
--- a/sound/soc/qcom/common.c
+++ b/sound/soc/qcom/common.c
@@ -7,10 +7,14 @@
#include <sound/jack.h>
#include <linux/input-event-codes.h>
#include "common.h"
+#define NAME_SIZE 32
static const struct snd_soc_dapm_widget qcom_jack_snd_widgets[] = {
SND_SOC_DAPM_HP("Headphone Jack", NULL),
SND_SOC_DAPM_MIC("Mic Jack", NULL),
+ SND_SOC_DAPM_SPK("HDMI/DP0 Jack", NULL),
+ SND_SOC_DAPM_SPK("HDMI/DP1 Jack", NULL),
+ SND_SOC_DAPM_SPK("HDMI/DP2 Jack", NULL),
};
int qcom_snd_parse_of(struct snd_soc_card *card)
@@ -239,4 +243,29 @@ int qcom_snd_wcd_jack_setup(struct snd_soc_pcm_runtime *rtd,
return 0;
}
EXPORT_SYMBOL_GPL(qcom_snd_wcd_jack_setup);
+
+int qcom_snd_dp_jack_setup(struct snd_soc_pcm_runtime *rtd,
+ struct snd_soc_jack *hdmi_jack, int hdmi_pcm_id)
+{
+ struct snd_soc_dai *codec_dai = snd_soc_rtd_to_codec(rtd, 0);
+ struct snd_soc_card *card = rtd->card;
+ char jack_name[NAME_SIZE];
+ int rval, i;
+
+ snprintf(jack_name, sizeof(jack_name), "HDMI/DP%d Jack", hdmi_pcm_id);
+ rval = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, hdmi_jack);
+ if (rval)
+ return rval;
+
+ for_each_rtd_codec_dais(rtd, i, codec_dai) {
+ rval = snd_soc_component_set_jack(codec_dai->component, hdmi_jack, NULL);
+ if (rval != 0 && rval != -ENOTSUPP) {
+ dev_warn(card->dev, "Failed to set jack: %d\n", rval);
+ return rval;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_snd_dp_jack_setup);
MODULE_LICENSE("GPL");
diff --git a/sound/soc/qcom/common.h b/sound/soc/qcom/common.h
index d7f80ee5ae26..3675d72c5285 100644
--- a/sound/soc/qcom/common.h
+++ b/sound/soc/qcom/common.h
@@ -9,5 +9,8 @@
int qcom_snd_parse_of(struct snd_soc_card *card);
int qcom_snd_wcd_jack_setup(struct snd_soc_pcm_runtime *rtd,
struct snd_soc_jack *jack, bool *jack_setup);
+int qcom_snd_dp_jack_setup(struct snd_soc_pcm_runtime *rtd,
+ struct snd_soc_jack *jack, int id);
+
#endif
--
2.25.1
From: Srinivas Kandagatla <[email protected]>
Add support to Display Port Jack events, by making use of common helper
function.
Signed-off-by: Srinivas Kandagatla <[email protected]>
---
sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
index 878bd50ad4a7..38f97f19add9 100644
--- a/sound/soc/qcom/sc8280xp.c
+++ b/sound/soc/qcom/sc8280xp.c
@@ -19,6 +19,7 @@ struct sc8280xp_snd_data {
struct snd_soc_card *card;
struct sdw_stream_runtime *sruntime[AFE_PORT_MAX];
struct snd_soc_jack jack;
+ struct snd_soc_jack hdmi_jack[8];
bool jack_setup;
};
@@ -27,6 +28,8 @@ static int sc8280xp_snd_init(struct snd_soc_pcm_runtime *rtd)
struct sc8280xp_snd_data *data = snd_soc_card_get_drvdata(rtd->card);
struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
struct snd_soc_card *card = rtd->card;
+ struct snd_soc_jack *hdmi_jack = NULL;
+ int hdmi_pcm_id = 0;
switch (cpu_dai->id) {
case WSA_CODEC_DMA_RX_0:
@@ -41,10 +44,21 @@ static int sc8280xp_snd_init(struct snd_soc_pcm_runtime *rtd)
snd_soc_limit_volume(card, "SpkrLeft PA Volume", 17);
snd_soc_limit_volume(card, "SpkrRight PA Volume", 17);
break;
+ case DISPLAY_PORT_RX_0:
+ hdmi_pcm_id = 0;
+ hdmi_jack = &data->hdmi_jack[hdmi_pcm_id];
+ break;
+ case DISPLAY_PORT_RX_1 ... DISPLAY_PORT_RX_7:
+ hdmi_pcm_id = cpu_dai->id - DISPLAY_PORT_RX_1 + 1;
+ hdmi_jack = &data->hdmi_jack[hdmi_pcm_id];
+ break;
default:
break;
}
+ if (hdmi_jack)
+ return qcom_snd_dp_jack_setup(rtd, hdmi_jack, hdmi_pcm_id);
+
return qcom_snd_wcd_jack_setup(rtd, &data->jack, &data->jack_setup);
}
--
2.25.1
From: Srinivas Kandagatla <[email protected]>
Fix a small type in the function name as its confusing to see a SoC name
that does not exist.
Signed-off-by: Srinivas Kandagatla <[email protected]>
---
sound/soc/qcom/sm8250.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/qcom/sm8250.c b/sound/soc/qcom/sm8250.c
index d70df72c0160..9bd159b81d69 100644
--- a/sound/soc/qcom/sm8250.c
+++ b/sound/soc/qcom/sm8250.c
@@ -70,7 +70,7 @@ static int sm8250_snd_startup(struct snd_pcm_substream *substream)
return qcom_snd_sdw_startup(substream);
}
-static void sm2450_snd_shutdown(struct snd_pcm_substream *substream)
+static void sm8250_snd_shutdown(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
@@ -115,7 +115,7 @@ static int sm8250_snd_hw_free(struct snd_pcm_substream *substream)
static const struct snd_soc_ops sm8250_be_ops = {
.startup = sm8250_snd_startup,
- .shutdown = sm2450_snd_shutdown,
+ .shutdown = sm8250_snd_shutdown,
.hw_params = sm8250_snd_hw_params,
.hw_free = sm8250_snd_hw_free,
.prepare = sm8250_snd_prepare,
--
2.25.1
On Mon, Apr 22, 2024 at 02:43:53PM +0100, Srinivas Kandagatla wrote:
> From: Srinivas Kandagatla <[email protected]>
>
> Add support to Display Port Jack events, by making use of common helper
s/to/for/
drop comma
> function.
>
> Signed-off-by: Srinivas Kandagatla <[email protected]>
> ---
> sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
> index 878bd50ad4a7..38f97f19add9 100644
> --- a/sound/soc/qcom/sc8280xp.c
> +++ b/sound/soc/qcom/sc8280xp.c
> @@ -19,6 +19,7 @@ struct sc8280xp_snd_data {
> struct snd_soc_card *card;
> struct sdw_stream_runtime *sruntime[AFE_PORT_MAX];
> struct snd_soc_jack jack;
> + struct snd_soc_jack hdmi_jack[8];
dp_jack
> bool jack_setup;
> };
>
> @@ -27,6 +28,8 @@ static int sc8280xp_snd_init(struct snd_soc_pcm_runtime *rtd)
> struct sc8280xp_snd_data *data = snd_soc_card_get_drvdata(rtd->card);
> struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
> struct snd_soc_card *card = rtd->card;
> + struct snd_soc_jack *hdmi_jack = NULL;
dp_jack
stray whitespace before =
> + int hdmi_pcm_id = 0;
dp_pcm_id
no need to init
> switch (cpu_dai->id) {
> case WSA_CODEC_DMA_RX_0:
> @@ -41,10 +44,21 @@ static int sc8280xp_snd_init(struct snd_soc_pcm_runtime *rtd)
> snd_soc_limit_volume(card, "SpkrLeft PA Volume", 17);
> snd_soc_limit_volume(card, "SpkrRight PA Volume", 17);
> break;
> + case DISPLAY_PORT_RX_0:
> + hdmi_pcm_id = 0;
> + hdmi_jack = &data->hdmi_jack[hdmi_pcm_id];
> + break;
> + case DISPLAY_PORT_RX_1 ... DISPLAY_PORT_RX_7:
> + hdmi_pcm_id = cpu_dai->id - DISPLAY_PORT_RX_1 + 1;
> + hdmi_jack = &data->hdmi_jack[hdmi_pcm_id];
> + break;
> default:
> break;
> }
>
> + if (hdmi_jack)
> + return qcom_snd_dp_jack_setup(rtd, hdmi_jack, hdmi_pcm_id);
> +
> return qcom_snd_wcd_jack_setup(rtd, &data->jack, &data->jack_setup);
> }
Johan
On Mon, Apr 22, 2024 at 02:43:50PM +0100, Srinivas Kandagatla wrote:
> From: Srinivas Kandagatla <[email protected]>
>
> This patchset adds support for.
> 1. parse Display Port module tokens from ASoC topology
> 2. add support to DP/HDMI Jack events.
> 3. fixes a typo in function name in sm8250
>
> Verified these patches on X13s along with changes to tplg in
> https://git.codelinaro.org/linaro/qcomlt/audioreach-topology/-/tree/topic/x13s-dp?ref_type=heads
> and ucm changes from https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/tree/topic/x13s-dp
It looks like your UCM changes are still muxing the speaker and *each*
displayport output so that you can only use one device at a time (i.e.
only Speaker or DP1 or DP2 can be used).
As we discussed off list last week, this seems unnecessarily limited and
as far as I understood is mostly needed to work around some
implementation details (not sure why DP1 and DP2 can't be used in
parallel either).
Can you please describe the problem here so that we can discuss this
before merging an unnecessarily restricted solution which may later be
harder to change (e.g. as kernel, topology and ucm may again need to be
updated in lock step).
From what I could tell after a quick look, this series does not
necessarily depend on muxing things this way, but please confirm that
too.
Johan
On Mon, Apr 22, 2024 at 02:43:52PM +0100, Srinivas Kandagatla wrote:
> static const struct snd_soc_dapm_widget qcom_jack_snd_widgets[] = {
> SND_SOC_DAPM_HP("Headphone Jack", NULL),
> SND_SOC_DAPM_MIC("Mic Jack", NULL),
> + SND_SOC_DAPM_SPK("HDMI/DP0 Jack", NULL),
> + SND_SOC_DAPM_SPK("HDMI/DP1 Jack", NULL),
> + SND_SOC_DAPM_SPK("HDMI/DP2 Jack", NULL),
Shouldn't these be split in dedicated HDMI and DP jacks too? What if you
have a machine with HDMI and DP jacks which would otherwise both claim
"HDMI/DP0"?
Johan
On Mon, Apr 22, 2024 at 02:43:52PM +0100, Srinivas Kandagatla wrote:
> From: Srinivas Kandagatla <[email protected]>
>
> Add a common function to add Display port jack, this can be used by
> multiple board files and avoid any code duplication.
>
> Signed-off-by: Srinivas Kandagatla <[email protected]>
> ---
> sound/soc/qcom/common.c | 29 +++++++++++++++++++++++++++++
> sound/soc/qcom/common.h | 3 +++
> 2 files changed, 32 insertions(+)
>
> diff --git a/sound/soc/qcom/common.c b/sound/soc/qcom/common.c
> index 747041fa7866..3bfe618e7bd7 100644
> --- a/sound/soc/qcom/common.c
> +++ b/sound/soc/qcom/common.c
> @@ -7,10 +7,14 @@
> #include <sound/jack.h>
> #include <linux/input-event-codes.h>
> #include "common.h"
Missing newline.
> +#define NAME_SIZE 32
>
> static const struct snd_soc_dapm_widget qcom_jack_snd_widgets[] = {
> SND_SOC_DAPM_HP("Headphone Jack", NULL),
> SND_SOC_DAPM_MIC("Mic Jack", NULL),
> + SND_SOC_DAPM_SPK("HDMI/DP0 Jack", NULL),
> + SND_SOC_DAPM_SPK("HDMI/DP1 Jack", NULL),
> + SND_SOC_DAPM_SPK("HDMI/DP2 Jack", NULL),
> };
>
> int qcom_snd_parse_of(struct snd_soc_card *card)
> @@ -239,4 +243,29 @@ int qcom_snd_wcd_jack_setup(struct snd_soc_pcm_runtime *rtd,
> return 0;
> }
> EXPORT_SYMBOL_GPL(qcom_snd_wcd_jack_setup);
> +
> +int qcom_snd_dp_jack_setup(struct snd_soc_pcm_runtime *rtd,
> + struct snd_soc_jack *hdmi_jack, int hdmi_pcm_id)
The function is called dp_jack_setup() so shouldn't the parameters
reflect that and be called dp_jack etc. for consistency (i.e. even if
you plan on using this interface also for hdmi)?
Johan
On 23/04/2024 12:59, Johan Hovold wrote:
> On Mon, Apr 22, 2024 at 02:43:50PM +0100, Srinivas Kandagatla wrote:
>> From: Srinivas Kandagatla <[email protected]>
>>
>> This patchset adds support for.
>> 1. parse Display Port module tokens from ASoC topology
>> 2. add support to DP/HDMI Jack events.
>> 3. fixes a typo in function name in sm8250
>>
>> Verified these patches on X13s along with changes to tplg in
>> https://git.codelinaro.org/linaro/qcomlt/audioreach-topology/-/tree/topic/x13s-dp?ref_type=heads
>> and ucm changes from https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/tree/topic/x13s-dp
>
> It looks like your UCM changes are still muxing the speaker and *each*
> displayport output so that you can only use one device at a time (i.e.
> only Speaker or DP1 or DP2 can be used).
that is true.
What is the use-case to use more than one audio sink devices at the same
time for a laptops?
How do you test it? I never tested anything like that on a full desktop
setup.
May be some manual setup in Wireplumber, but not 100% sure about
multiple stream handling.
>
> As we discussed off list last week, this seems unnecessarily limited and
> as far as I understood is mostly needed to work around some
> implementation details (not sure why DP1 and DP2 can't be used in
> parallel either).
It is absolutely possible to run all the streams in parallel from the
Audio hardware and DSP point of view.
One thing to note is, On Qualcomm DP IP, we can not read/write registers
if the DP port is not connected, which means that we can not send data
in such cases.
This makes it challenging to work with sound-servers like pipewire or
pulseaudio as they tend to send silence data at very early stages in the
full system boot up, ignoring state of the Jack events.
>
> Can you please describe the problem here so that we can discuss this
> before merging an unnecessarily restricted solution which may later be
> harder to change (e.g. as kernel, topology and ucm may again need to be
> updated in lock step).
>
> From what I could tell after a quick look, this series does not
> necessarily depend on muxing things this way, but please confirm that
> too.
These patches have nothing to do with how we model the muxing in UCM or
in tplg.
so these can go as it is irrespective of how we want to model the DP
sinks in the UCM or tplg.
--srini
>
> Johan
On Tue, Apr 23, 2024 at 01:38:18PM +0100, Srinivas Kandagatla wrote:
> On 23/04/2024 12:59, Johan Hovold wrote:
> > It looks like your UCM changes are still muxing the speaker and *each*
> > displayport output so that you can only use one device at a time (i.e.
> > only Speaker or DP1 or DP2 can be used).
> that is true.
>
> What is the use-case to use more than one audio sink devices at the same
> time for a laptops?
I can imagine streaming audio and video to a TV (or audio to a soundbar)
over DP while playing systems sounds and doing video conferencing using
the internal speakers (or the other DP port).
> How do you test it? I never tested anything like that on a full desktop
> setup.
You can select the sink per application in pavucontrol. Just verified
that playing audio over the 3.5 mm jack while playing system sounds
using the internal speakers works just fine.
> > As we discussed off list last week, this seems unnecessarily limited and
> > as far as I understood is mostly needed to work around some
> > implementation details (not sure why DP1 and DP2 can't be used in
> > parallel either).
>
> It is absolutely possible to run all the streams in parallel from the
> Audio hardware and DSP point of view.
>
> One thing to note is, On Qualcomm DP IP, we can not read/write registers
> if the DP port is not connected, which means that we can not send data
> in such cases.
>
> This makes it challenging to work with sound-servers like pipewire or
> pulseaudio as they tend to send silence data at very early stages in the
> full system boot up, ignoring state of the Jack events.
This bit sounds like it can and should be worked around by the driver to
avoid hard-coding policy which would prevent use cases such as the ones
mentioned above.
> > Can you please describe the problem here so that we can discuss this
> > before merging an unnecessarily restricted solution which may later be
> > harder to change (e.g. as kernel, topology and ucm may again need to be
> > updated in lock step).
> >
> > From what I could tell after a quick look, this series does not
> > necessarily depend on muxing things this way, but please confirm that
> > too.
>
> These patches have nothing to do with how we model the muxing in UCM or
> in tplg.
>
> so these can go as it is irrespective of how we want to model the DP
> sinks in the UCM or tplg.
Thanks for confirming.
Johan
On 23/04/2024 13:02, Johan Hovold wrote:
> On Mon, Apr 22, 2024 at 02:43:52PM +0100, Srinivas Kandagatla wrote:
>
>> static const struct snd_soc_dapm_widget qcom_jack_snd_widgets[] = {
>> SND_SOC_DAPM_HP("Headphone Jack", NULL),
>> SND_SOC_DAPM_MIC("Mic Jack", NULL),
>> + SND_SOC_DAPM_SPK("HDMI/DP0 Jack", NULL),
>> + SND_SOC_DAPM_SPK("HDMI/DP1 Jack", NULL),
>> + SND_SOC_DAPM_SPK("HDMI/DP2 Jack", NULL),
>
> Shouldn't these be split in dedicated HDMI and DP jacks too? What if you
> have a machine with HDMI and DP jacks which would otherwise both claim
> "HDMI/DP0"?
These map to the Jack's added as part of qcom_snd_dp_jack_setup and
belong to DISPLAY_PORT_RX_0, DISPLAY_PORT_RX_1, DISPLAY_PORT_RX_2.
If its going via USB-C DP controller it will be either DP or an HDMI ?
This is the most common naming for the USB-C DP/HDMI jack events.
Qualcomm LPASS in some older SoCs had a dedicated HDMI interface which
is different to this one.
Usual Other ways to connect HDMI is via external HDMI Bridge using I2S
interface which totally different to this DP interface.
So none of these will conflict.
hope this clarifies.
thanks,
Srini
>
> Johan
On 23/04/2024 15:58, Johan Hovold wrote:
>> It is absolutely possible to run all the streams in parallel from the
>> Audio hardware and DSP point of view.
>>
>> One thing to note is, On Qualcomm DP IP, we can not read/write registers
>> if the DP port is not connected, which means that we can not send data
>> in such cases.
>>
>> This makes it challenging to work with sound-servers like pipewire or
>> pulseaudio as they tend to send silence data at very early stages in the
>> full system boot up, ignoring state of the Jack events.
> This bit sounds like it can and should be worked around by the driver to
> avoid hard-coding policy which would prevent use cases such as the ones
> mentioned above.
This is not simple as you say. We have to fit these into a proper DPCM.
Either we have a dummy Backend connected for each of these pcm
sub-devices when DP port is not connected and then switch back to DP
when its connected.
Or somehow find a way to not let the pipewire talk to devices which are
not connected.
thanks,
srini
On Tue, Apr 23, 2024 at 04:55:32PM +0100, Srinivas Kandagatla wrote:
> On 23/04/2024 13:02, Johan Hovold wrote:
> > On Mon, Apr 22, 2024 at 02:43:52PM +0100, Srinivas Kandagatla wrote:
> >
> >> static const struct snd_soc_dapm_widget qcom_jack_snd_widgets[] = {
> >> SND_SOC_DAPM_HP("Headphone Jack", NULL),
> >> SND_SOC_DAPM_MIC("Mic Jack", NULL),
> >> + SND_SOC_DAPM_SPK("HDMI/DP0 Jack", NULL),
> >> + SND_SOC_DAPM_SPK("HDMI/DP1 Jack", NULL),
> >> + SND_SOC_DAPM_SPK("HDMI/DP2 Jack", NULL),
> >
> > Shouldn't these be split in dedicated HDMI and DP jacks too? What if you
> > have a machine with HDMI and DP jacks which would otherwise both claim
> > "HDMI/DP0"?
>
> These map to the Jack's added as part of qcom_snd_dp_jack_setup and
> belong to DISPLAY_PORT_RX_0, DISPLAY_PORT_RX_1, DISPLAY_PORT_RX_2.
>
> If its going via USB-C DP controller it will be either DP or an HDMI ?
It will always be DP out of the machine even if an adapter can convert
to HDMI internally.
The DRM ports are called "DP-1" and "DP-2" so it seems we should match
that.
> This is the most common naming for the USB-C DP/HDMI jack events.
It looks like some Intel machines use names like "HDMI/DP, pcm=%d Jack"
(with a pcm device number), but we also have "DP Jack". Not sure which
are are used with USB-C, though. (Or if the former actually support HDMI
altmode.)
> Qualcomm LPASS in some older SoCs had a dedicated HDMI interface which
> is different to this one.
>
> Usual Other ways to connect HDMI is via external HDMI Bridge using I2S
> interface which totally different to this DP interface.
Sure, but if there's ever a design with such a port then it will be
called "HDMI Jack" and then the "HDMI in "HDMI/DP0 Jack" is unnecessary
and confusing when it is always DP out.
Johan
On Tue, Apr 23, 2024 at 04:59:56PM +0100, Srinivas Kandagatla wrote:
> On 23/04/2024 15:58, Johan Hovold wrote:
> >> It is absolutely possible to run all the streams in parallel from the
> >> Audio hardware and DSP point of view.
> >>
> >> One thing to note is, On Qualcomm DP IP, we can not read/write registers
> >> if the DP port is not connected, which means that we can not send data
> >> in such cases.
> >>
> >> This makes it challenging to work with sound-servers like pipewire or
> >> pulseaudio as they tend to send silence data at very early stages in the
> >> full system boot up, ignoring state of the Jack events.
> > This bit sounds like it can and should be worked around by the driver to
> > avoid hard-coding policy which would prevent use cases such as the ones
> > mentioned above.
> This is not simple as you say. We have to fit these into a proper DPCM.
> Either we have a dummy Backend connected for each of these pcm
> sub-devices when DP port is not connected and then switch back to DP
> when its connected.
I don't know how best to implement it, but we shouldn't necessarily let
that determine the user experience.
> Or somehow find a way to not let the pipewire talk to devices which are
> not connected.
Yes, perhaps it requires a change in user space.
But it seems the kernel should be able to fake whatever probing user
space currently does to determine if the there is a DP jack (even when
there is nothing connected).
Johan
On 29/04/2024 15:54, Johan Hovold wrote:
> On Tue, Apr 23, 2024 at 04:55:32PM +0100, Srinivas Kandagatla wrote:
>> On 23/04/2024 13:02, Johan Hovold wrote:
>>> On Mon, Apr 22, 2024 at 02:43:52PM +0100, Srinivas Kandagatla wrote:
>>>
>>>> static const struct snd_soc_dapm_widget qcom_jack_snd_widgets[] = {
>>>> SND_SOC_DAPM_HP("Headphone Jack", NULL),
>>>> SND_SOC_DAPM_MIC("Mic Jack", NULL),
>>>> + SND_SOC_DAPM_SPK("HDMI/DP0 Jack", NULL),
>>>> + SND_SOC_DAPM_SPK("HDMI/DP1 Jack", NULL),
>>>> + SND_SOC_DAPM_SPK("HDMI/DP2 Jack", NULL),
>>>
>>> Shouldn't these be split in dedicated HDMI and DP jacks too? What if you
>>> have a machine with HDMI and DP jacks which would otherwise both claim
>>> "HDMI/DP0"?
>>
>> These map to the Jack's added as part of qcom_snd_dp_jack_setup and
>> belong to DISPLAY_PORT_RX_0, DISPLAY_PORT_RX_1, DISPLAY_PORT_RX_2.
>>
>> If its going via USB-C DP controller it will be either DP or an HDMI ?
>
> It will always be DP out of the machine even if an adapter can convert
> to HDMI internally.
>
> The DRM ports are called "DP-1" and "DP-2" so it seems we should match
> that.
>
>> This is the most common naming for the USB-C DP/HDMI jack events.
>
> It looks like some Intel machines use names like "HDMI/DP, pcm=%d Jack"
> (with a pcm device number), but we also have "DP Jack". Not sure which
> are are used with USB-C, though. (Or if the former actually support HDMI
> altmode.)
I checked this on my machine which has usb-c and I can confirm using
HDMI/DP naming for these jack.
Either way I don't mind having any names, but my point here is to be
more consistent across.
--srini
>
>> Qualcomm LPASS in some older SoCs had a dedicated HDMI interface which
>> is different to this one.
>>
>> Usual Other ways to connect HDMI is via external HDMI Bridge using I2S
>> interface which totally different to this DP interface.
>
> Sure, but if there's ever a design with such a port then it will be
> called "HDMI Jack" and then the "HDMI in "HDMI/DP0 Jack" is unnecessary
> and confusing when it is always DP out.
>
> Johan
On 2024/4/22 21:43, [email protected] wrote:
> From: Srinivas Kandagatla <[email protected]>
>
> This patchset adds support for.
> 1. parse Display Port module tokens from ASoC topology
> 2. add support to DP/HDMI Jack events.
> 3. fixes a typo in function name in sm8250
>
> Verified these patches on X13s along with changes to tplg in
> https://git.codelinaro.org/linaro/qcomlt/audioreach-topology/-/tree/topic/x13s-dp?ref_type=heads
> and ucm changes from https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/tree/topic/x13s-dp
>
> Thanks,
> Srini
>
> Changes since v1:
> - Fixed unused variable warning.
> - fixed warning 'break;' to avoid fall-through
>
> Srinivas Kandagatla (4):
> ASoC: qcom: q6dsp: parse Display port tokens
> ASoC: qcom: common: add Display port Jack function
> ASoC: qcom: sc8280xp: add Display port Jack
> ASoC: qcom: sm8250: fix a typo in function name
>
> sound/soc/qcom/common.c | 29 +++++++++++++++++++++++++++++
> sound/soc/qcom/common.h | 3 +++
> sound/soc/qcom/qdsp6/topology.c | 26 ++++++++++++++++++++++++++
> sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
> sound/soc/qcom/sm8250.c | 4 ++--
> 5 files changed, 74 insertions(+), 2 deletions(-)
>
Hi Srini,
I tested this series on SM8550 with tplg in [1] and ucm in [2]. But the
kernel output errors attached below. Headphone does work properly
without DisplayPort in the ucm.
What could be the possible cause of this? Is there any significant
change from sc8280xp to sm8550?
--
Thanks,
Xilin Wu
[1]
https://github.com/edk2-porting/audioreach-topology/blob/sakuramist/QCS8550-AYN-ODIN2.m4
[2]
https://github.com/strongtz/alsa-ucm-conf/blob/odin2/ucm2/Qualcomm/sm8550/HiFi.conf
[ 1552.313713] qcom-apm gprsvc:service:2:1: Error (1) Processing
0x01001000 cmd
[ 1552.313730] qcom-apm gprsvc:service:2:1: DSP returned error[1001000] 1
[ 1552.314455] qcom-apm gprsvc:service:2:1: Error (1) Processing
0x01001006 cmd
[ 1552.314463] qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
[ 1552.315496] qcom-apm gprsvc:service:2:1: Error (1) Processing
0x01001006 cmd
[ 1552.315506] qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
[ 1552.316033] qcom-apm gprsvc:service:2:1: Error (1) Processing
0x01001001 cmd
[ 1552.316042] qcom-apm gprsvc:service:2:1: DSP returned error[1001001] 1
[ 1552.316045] q6apm-lpass-dais
30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to prepare
Graph -22
[ 1552.316047] q6apm-lpass-dais
30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at
snd_soc_pcm_dai_prepare on DISPLAY_PORT_RX_0: -22
Hi Xilin,
On 23/05/2024 05:09, Xilin Wu wrote:
>>
>> Srinivas Kandagatla (4):
>> ASoC: qcom: q6dsp: parse Display port tokens
>> ASoC: qcom: common: add Display port Jack function
>> ASoC: qcom: sc8280xp: add Display port Jack
>> ASoC: qcom: sm8250: fix a typo in function name
>>
>> sound/soc/qcom/common.c | 29 +++++++++++++++++++++++++++++
>> sound/soc/qcom/common.h | 3 +++
>> sound/soc/qcom/qdsp6/topology.c | 26 ++++++++++++++++++++++++++
>> sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
>> sound/soc/qcom/sm8250.c | 4 ++--
>> 5 files changed, 74 insertions(+), 2 deletions(-)
>>
>
> Hi Srini,
>
> I tested this series on SM8550 with tplg in [1] and ucm in [2]. But the
> kernel output errors attached below. Headphone does work properly
> without DisplayPort in the ucm.
>
> What could be the possible cause of this? Is there any significant
> change from sc8280xp to sm8550?
>
> --
> Thanks,
> Xilin Wu
>
> [1]
> https://github.com/edk2-porting/audioreach-topology/blob/sakuramist/QCS8550-AYN-ODIN2.m4
> [2]
> https://github.com/strongtz/alsa-ucm-conf/blob/odin2/ucm2/Qualcomm/sm8550/HiFi.conf
>
> [ 1552.313713] qcom-apm gprsvc:service:2:1: Error (1) Processing
> 0x01001000 cmd
> [ 1552.313730] qcom-apm gprsvc:service:2:1: DSP returned error[1001000] 1
> [ 1552.314455] qcom-apm gprsvc:service:2:1: Error (1) Processing
Is the DP cable connected?
if its not connected the dsp will throw this error.
due to this issue I did workaround this issue by modeling it as
conflicting device to Speaker in x13s ucm.
I see in your ucm setup its not the case.
which is why you might be hitting this issue.
Can you try
amixer -c 0 cset iface=MIXER,name='DISPLAY_PORT_RX_0 Audio Mixer
MultiMedia2' 1
aplay -D plughw:0,1 some-wav-file.wav
both with and without display connected.
--srini
> 0x01001006 cmd
> [ 1552.314463] qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
> [ 1552.315496] qcom-apm gprsvc:service:2:1: Error (1) Processing
> 0x01001006 cmd
> [ 1552.315506] qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
> [ 1552.316033] qcom-apm gprsvc:service:2:1: Error (1) Processing
> 0x01001001 cmd
> [ 1552.316042] qcom-apm gprsvc:service:2:1: DSP returned error[1001001] 1
> [ 1552.316045] q6apm-lpass-dais
> 30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to prepare
> Graph -22
> [ 1552.316047] q6apm-lpass-dais
> 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at
> snd_soc_pcm_dai_prepare on DISPLAY_PORT_RX_0: -22
Hi Srini,
On 2024/5/24 20:50, Srinivas Kandagatla wrote:
> Hi Xilin,
>
> On 23/05/2024 05:09, Xilin Wu wrote:
>>>
>>> Srinivas Kandagatla (4):
>>> ASoC: qcom: q6dsp: parse Display port tokens
>>> ASoC: qcom: common: add Display port Jack function
>>> ASoC: qcom: sc8280xp: add Display port Jack
>>> ASoC: qcom: sm8250: fix a typo in function name
>>>
>>> sound/soc/qcom/common.c | 29 +++++++++++++++++++++++++++++
>>> sound/soc/qcom/common.h | 3 +++
>>> sound/soc/qcom/qdsp6/topology.c | 26 ++++++++++++++++++++++++++
>>> sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
>>> sound/soc/qcom/sm8250.c | 4 ++--
>>> 5 files changed, 74 insertions(+), 2 deletions(-)
>>>
>>
>> Hi Srini,
>>
>> I tested this series on SM8550 with tplg in [1] and ucm in [2]. But
>> the kernel output errors attached below. Headphone does work properly
>> without DisplayPort in the ucm.
>>
>> What could be the possible cause of this? Is there any significant
>> change from sc8280xp to sm8550?
>>
>> --
>> Thanks,
>> Xilin Wu
>>
>> [1]
>> https://github.com/edk2-porting/audioreach-topology/blob/sakuramist/QCS8550-AYN-ODIN2.m4
>> [2]
>> https://github.com/strongtz/alsa-ucm-conf/blob/odin2/ucm2/Qualcomm/sm8550/HiFi.conf
>>
>> [ 1552.313713] qcom-apm gprsvc:service:2:1: Error (1) Processing
>> 0x01001000 cmd
>> [ 1552.313730] qcom-apm gprsvc:service:2:1: DSP returned error[1001000] 1
>> [ 1552.314455] qcom-apm gprsvc:service:2:1: Error (1) Processing
>
> Is the DP cable connected?
I'm sure that the cable is connected and I have desktop on external display.
If it's not connected, kernel gives the following error when using aplay:
hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at
snd_soc_dai_hw_params on i2s-hifi: -22
>
> if its not connected the dsp will throw this error.
>
> due to this issue I did workaround this issue by modeling it as
> conflicting device to Speaker in x13s ucm.
>
> I see in your ucm setup its not the case.
> which is why you might be hitting this issue.
>
> Can you try
> amixer -c 0 cset iface=MIXER,name='DISPLAY_PORT_RX_0 Audio Mixer
> MultiMedia2' 1
> aplay -D plughw:0,1 some-wav-file.wav
>
> both with and without display connected.
>
aplay always gives the following error:
Playing WAVE 'Summer.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
aplay: set_params:1456: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (42666 42667)
PERIOD_SIZE: (1881 1882)
PERIOD_BYTES: (7524 7528)
PERIODS: (3 5)
BUFFER_TIME: (170657 170658)
BUFFER_SIZE: 7526
BUFFER_BYTES: 30104
TICK_TIME: 0
and kernel gives the following when display is connected:
[drm:dp_catalog_audio_config_sdp] sdp_cfg = 0x100066
[drm:dp_catalog_audio_config_sdp] sdp_cfg2 = 0x1b800004
[drm:dp_audio_hw_params] Header Byte 1: value = 0xce020000, parity_byte
= 0xce
[drm:dp_audio_hw_params] Header Byte 2: value = 0x67010000, parity_byte
= 0x0
[drm:dp_audio_hw_params] Header Byte 3: value = 0x67010000, parity_byte
= 0x67
[drm:dp_audio_hw_params] Header Byte 1: value = 0x67010000, parity_byte
= 0x67
[drm:dp_audio_hw_params] Header Byte 2: value = 0x33443517, parity_byte
= 0x35
[drm:dp_audio_hw_params] Header Byte 3: value = 0x33443517, parity_byte
= 0x33
[drm:dp_audio_hw_params] Header Byte 1: value = 0x84840000, parity_byte
= 0x84
[drm:dp_audio_hw_params] Header Byte 2: value = 0x3344d71b, parity_byte
= 0xd7
[drm:dp_audio_hw_params] Header Byte 3: value = 0x44, parity_byte = 0x33
[drm:dp_audio_hw_params] Header Byte 1: value = 0xd8050000, parity_byte
= 0xd8
[drm:dp_audio_hw_params] Header Byte 2: value = 0x4b0f, parity_byte = 0x4b
[drm:dp_audio_hw_params] Header Byte 3: value = 0x4b0f, parity_byte = 0x0
[drm:dp_audio_hw_params] Header Byte 1: value = 0x71060000, parity_byte
= 0x71
[drm:dp_audio_hw_params] Header Byte 2: value = 0x4b0f, parity_byte = 0x4b
[drm:dp_catalog_audio_config_acr] select: 0x3, acr_ctrl: 0x80004130
[drm:dp_catalog_audio_sfe_level] mainlink_level = 0xa08,
safe_to_exit_level = 0x8
[drm:dp_catalog_audio_enable] dp_audio_cfg = 0xc1
qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001006 cmd
qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001006 cmd
qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001001 cmd
qcom-apm gprsvc:service:2:1: DSP returned error[1001001] 1
q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais:
Failed to prepare Graph -22
q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais:
ASoC: error at snd_soc_pcm_dai_prepare on DISPLAY_PORT_RX_0: -22
[drm:dp_catalog_audio_enable] dp_audio_cfg = 0xc0
>
> --srini
>
>
>
>> 0x01001006 cmd
>> [ 1552.314463] qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
>> [ 1552.315496] qcom-apm gprsvc:service:2:1: Error (1) Processing
>> 0x01001006 cmd
>> [ 1552.315506] qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
>> [ 1552.316033] qcom-apm gprsvc:service:2:1: Error (1) Processing
>> 0x01001001 cmd
>> [ 1552.316042] qcom-apm gprsvc:service:2:1: DSP returned error[1001001] 1
>> [ 1552.316045] q6apm-lpass-dais
>> 30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to prepare
>> Graph -22
>> [ 1552.316047] q6apm-lpass-dais
>> 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at
>> snd_soc_pcm_dai_prepare on DISPLAY_PORT_RX_0: -22
--
Thanks,
Xilin Wu
On Thu, May 09, 2024 at 09:59:40AM +0100, Srinivas Kandagatla wrote:
>
>
> On 29/04/2024 15:54, Johan Hovold wrote:
> > On Tue, Apr 23, 2024 at 04:55:32PM +0100, Srinivas Kandagatla wrote:
> > > On 23/04/2024 13:02, Johan Hovold wrote:
> > > > On Mon, Apr 22, 2024 at 02:43:52PM +0100, Srinivas Kandagatla wrote:
> > > > > static const struct snd_soc_dapm_widget qcom_jack_snd_widgets[] = {
> > > > > SND_SOC_DAPM_HP("Headphone Jack", NULL),
> > > > > SND_SOC_DAPM_MIC("Mic Jack", NULL),
> > > > > + SND_SOC_DAPM_SPK("HDMI/DP0 Jack", NULL),
> > > > > + SND_SOC_DAPM_SPK("HDMI/DP1 Jack", NULL),
> > > > > + SND_SOC_DAPM_SPK("HDMI/DP2 Jack", NULL),
> > > >
> > > > Shouldn't these be split in dedicated HDMI and DP jacks too? What if you
> > > > have a machine with HDMI and DP jacks which would otherwise both claim
> > > > "HDMI/DP0"?
> > >
> > > These map to the Jack's added as part of qcom_snd_dp_jack_setup and
> > > belong to DISPLAY_PORT_RX_0, DISPLAY_PORT_RX_1, DISPLAY_PORT_RX_2.
> > >
> > > If its going via USB-C DP controller it will be either DP or an HDMI ?
> >
> > It will always be DP out of the machine even if an adapter can convert
> > to HDMI internally.
> >
> > The DRM ports are called "DP-1" and "DP-2" so it seems we should match
> > that.
> >
> > > This is the most common naming for the USB-C DP/HDMI jack events.
> >
> > It looks like some Intel machines use names like "HDMI/DP, pcm=%d Jack"
> > (with a pcm device number), but we also have "DP Jack". Not sure which
> > are are used with USB-C, though. (Or if the former actually support HDMI
> > altmode.)
>
> I checked this on my machine which has usb-c and I can confirm using HDMI/DP
> naming for these jack.
>
> Either way I don't mind having any names, but my point here is to be more
> consistent across.
I fear it is till not consistent. On the Intel laptop I see following
jacks:
numid=18,iface=CARD,name='HDMI/DP,pcm=3 Jack'
numid=24,iface=CARD,name='HDMI/DP,pcm=7 Jack'
numid=30,iface=CARD,name='HDMI/DP,pcm=8 Jack'
On the other hand Mediatek and RockChip use just 'DP Jack'.
I'd suggest settling on the latter option. We are closer to MTK and
RockChip rather than Intel.
BTW: a platform can easily have 4 (x1e8100) or even 8 (sc8280xp) DP
outputs. Could you please point out why there are just 3 jacks?
> --srini
> >
> > > Qualcomm LPASS in some older SoCs had a dedicated HDMI interface which
> > > is different to this one.
> > >
> > > Usual Other ways to connect HDMI is via external HDMI Bridge using I2S
> > > interface which totally different to this DP interface.
> >
> > Sure, but if there's ever a design with such a port then it will be
> > called "HDMI Jack" and then the "HDMI in "HDMI/DP0 Jack" is unnecessary
> > and confusing when it is always DP out.
> >
> > Johan
--
With best wishes
Dmitry
On Mon, Apr 22, 2024 at 02:43:53PM +0100, [email protected] wrote:
> From: Srinivas Kandagatla <[email protected]>
>
> Add support to Display Port Jack events, by making use of common helper
> function.
>
> Signed-off-by: Srinivas Kandagatla <[email protected]>
> ---
> sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
> index 878bd50ad4a7..38f97f19add9 100644
> --- a/sound/soc/qcom/sc8280xp.c
> +++ b/sound/soc/qcom/sc8280xp.c
> @@ -19,6 +19,7 @@ struct sc8280xp_snd_data {
> struct snd_soc_card *card;
> struct sdw_stream_runtime *sruntime[AFE_PORT_MAX];
> struct snd_soc_jack jack;
> + struct snd_soc_jack hdmi_jack[8];
> bool jack_setup;
> };
>
> @@ -27,6 +28,8 @@ static int sc8280xp_snd_init(struct snd_soc_pcm_runtime *rtd)
> struct sc8280xp_snd_data *data = snd_soc_card_get_drvdata(rtd->card);
> struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
> struct snd_soc_card *card = rtd->card;
> + struct snd_soc_jack *hdmi_jack = NULL;
> + int hdmi_pcm_id = 0;
Using hdmi_ prefix for DP jacks is counterintuitive at best.
>
> switch (cpu_dai->id) {
> case WSA_CODEC_DMA_RX_0:
> @@ -41,10 +44,21 @@ static int sc8280xp_snd_init(struct snd_soc_pcm_runtime *rtd)
> snd_soc_limit_volume(card, "SpkrLeft PA Volume", 17);
> snd_soc_limit_volume(card, "SpkrRight PA Volume", 17);
> break;
I'd suggest either using DISPLAY_PORT_RX here or adding a comment to
point out that DP RX ids are not sequential.
> + case DISPLAY_PORT_RX_0:
> + hdmi_pcm_id = 0;
> + hdmi_jack = &data->hdmi_jack[hdmi_pcm_id];
> + break;
> + case DISPLAY_PORT_RX_1 ... DISPLAY_PORT_RX_7:
> + hdmi_pcm_id = cpu_dai->id - DISPLAY_PORT_RX_1 + 1;
> + hdmi_jack = &data->hdmi_jack[hdmi_pcm_id];
> + break;
> default:
> break;
> }
>
> + if (hdmi_jack)
> + return qcom_snd_dp_jack_setup(rtd, hdmi_jack, hdmi_pcm_id);
> +
> return qcom_snd_wcd_jack_setup(rtd, &data->jack, &data->jack_setup);
> }
>
> --
> 2.25.1
>
--
With best wishes
Dmitry
On Tue, Apr 23, 2024 at 01:38:18PM +0100, Srinivas Kandagatla wrote:
>
>
> On 23/04/2024 12:59, Johan Hovold wrote:
> > On Mon, Apr 22, 2024 at 02:43:50PM +0100, Srinivas Kandagatla wrote:
> > > From: Srinivas Kandagatla <[email protected]>
> > >
> > > This patchset adds support for.
> > > 1. parse Display Port module tokens from ASoC topology
> > > 2. add support to DP/HDMI Jack events.
> > > 3. fixes a typo in function name in sm8250
> > >
> > > Verified these patches on X13s along with changes to tplg in
> > > https://git.codelinaro.org/linaro/qcomlt/audioreach-topology/-/tree/topic/x13s-dp?ref_type=heads
> > > and ucm changes from https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/tree/topic/x13s-dp
> >
> > It looks like your UCM changes are still muxing the speaker and *each*
> > displayport output so that you can only use one device at a time (i.e.
> > only Speaker or DP1 or DP2 can be used).
> that is true.
>
> What is the use-case to use more than one audio sink devices at the same
> time for a laptops?
Consider multi-seat setup, with each monitor having its own set of
keyboard, mouse, headphone and user behind it.
>
> How do you test it? I never tested anything like that on a full desktop
> setup.
>
> May be some manual setup in Wireplumber, but not 100% sure about multiple
> stream handling.
>
> >
> > As we discussed off list last week, this seems unnecessarily limited and
> > as far as I understood is mostly needed to work around some
> > implementation details (not sure why DP1 and DP2 can't be used in
> > parallel either).
>
> It is absolutely possible to run all the streams in parallel from the Audio
> hardware and DSP point of view.
>
> One thing to note is, On Qualcomm DP IP, we can not read/write registers if
> the DP port is not connected, which means that we can not send data in such
> cases.
How is this handled for the native HDMI playback on platforms like
Dragonboard 820c? As far as I was able to test, playback fails with -EIO
if HDMI output is not enabled or if the DVI monitor is connected.
>
> This makes it challenging to work with sound-servers like pipewire or
> pulseaudio as they tend to send silence data at very early stages in the
> full system boot up, ignoring state of the Jack events.
>
> >
> > Can you please describe the problem here so that we can discuss this
> > before merging an unnecessarily restricted solution which may later be
> > harder to change (e.g. as kernel, topology and ucm may again need to be
> > updated in lock step).
> >
> > From what I could tell after a quick look, this series does not
> > necessarily depend on muxing things this way, but please confirm that
> > too.
>
> These patches have nothing to do with how we model the muxing in UCM or in
> tplg.
>
> so these can go as it is irrespective of how we want to model the DP sinks
> in the UCM or tplg.
>
>
> --srini
> >
> > Johan
--
With best wishes
Dmitry
On 30/05/2024 23:38, Dmitry Baryshkov wrote:
>>> It will always be DP out of the machine even if an adapter can convert
>>> to HDMI internally.
>>>
>>> The DRM ports are called "DP-1" and "DP-2" so it seems we should match
>>> that.
>>>
>>>> This is the most common naming for the USB-C DP/HDMI jack events.
>>> It looks like some Intel machines use names like "HDMI/DP, pcm=%d Jack"
>>> (with a pcm device number), but we also have "DP Jack". Not sure which
>>> are are used with USB-C, though. (Or if the former actually support HDMI
>>> altmode.)
>> I checked this on my machine which has usb-c and I can confirm using HDMI/DP
>> naming for these jack.
>>
>> Either way I don't mind having any names, but my point here is to be more
>> consistent across.
> I fear it is till not consistent. On the Intel laptop I see following
> jacks:
>
> numid=18,iface=CARD,name='HDMI/DP,pcm=3 Jack'
> numid=24,iface=CARD,name='HDMI/DP,pcm=7 Jack'
> numid=30,iface=CARD,name='HDMI/DP,pcm=8 Jack'
>
> On the other hand Mediatek and RockChip use just 'DP Jack'.
>
> I'd suggest settling on the latter option. We are closer to MTK and
> RockChip rather than Intel.
that is fine with me.
>
> BTW: a platform can easily have 4 (x1e8100) or even 8 (sc8280xp) DP
> outputs. Could you please point out why there are just 3 jacks?
The CRD platform that I have access to has 3 ports which is why I
started with 3 ports, but we can add more ports as and when we can
really test them.
--srini
Hi Xilin
On 25/05/2024 08:12, Xilin Wu wrote:
> Hi Srini,
>
> On 2024/5/24 20:50, Srinivas Kandagatla wrote:
>> Hi Xilin,
>>
>> On 23/05/2024 05:09, Xilin Wu wrote:
>>>>
>>>> Srinivas Kandagatla (4):
>>>> ASoC: qcom: q6dsp: parse Display port tokens
>>>> ASoC: qcom: common: add Display port Jack function
>>>> ASoC: qcom: sc8280xp: add Display port Jack
>>>> ASoC: qcom: sm8250: fix a typo in function name
>>>>
>>>> sound/soc/qcom/common.c | 29 +++++++++++++++++++++++++++++
>>>> sound/soc/qcom/common.h | 3 +++
>>>> sound/soc/qcom/qdsp6/topology.c | 26 ++++++++++++++++++++++++++
>>>> sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
>>>> sound/soc/qcom/sm8250.c | 4 ++--
>>>> 5 files changed, 74 insertions(+), 2 deletions(-)
>>>>
>>>
>>> Hi Srini,
>>>
>>> I tested this series on SM8550 with tplg in [1] and ucm in [2]. But
>>> the kernel output errors attached below. Headphone does work properly
>>> without DisplayPort in the ucm.
>>>
>>> What could be the possible cause of this? Is there any significant
>>> change from sc8280xp to sm8550?
>>>
>>> --
>>> Thanks,
>>> Xilin Wu
>>>
>>> [1]
>>> https://github.com/edk2-porting/audioreach-topology/blob/sakuramist/QCS8550-AYN-ODIN2.m4
>>> [2]
For sm8550 you would need this patch for tplg
https://git.codelinaro.org/krzysztof.kozlowski/audioreach-topology/-/commit/d8ef47bc85700a7cdfabee5e06808d9f359b0a26
can you try this as the Container CAP Id changed for platforms from sm8550.
Kryzstof verified Display port tplg and these patches on x1e80100.
thanks,
srini
>>> https://github.com/strongtz/alsa-ucm-conf/blob/odin2/ucm2/Qualcomm/sm8550/HiFi.conf
>>>
>>> [ 1552.313713] qcom-apm gprsvc:service:2:1: Error (1) Processing
>>> 0x01001000 cmd
>>> [ 1552.313730] qcom-apm gprsvc:service:2:1: DSP returned
>>> error[1001000] 1
>>> [ 1552.314455] qcom-apm gprsvc:service:2:1: Error (1) Processing
>>
>> Is the DP cable connected?
>
> I'm sure that the cable is connected and I have desktop on external
> display.
> If it's not connected, kernel gives the following error when using aplay:
>
> hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at
> snd_soc_dai_hw_params on i2s-hifi: -22
>
>>
>> if its not connected the dsp will throw this error.
>>
>> due to this issue I did workaround this issue by modeling it as
>> conflicting device to Speaker in x13s ucm.
>>
>> I see in your ucm setup its not the case.
>> which is why you might be hitting this issue.
>>
>> Can you try
>> amixer -c 0 cset iface=MIXER,name='DISPLAY_PORT_RX_0 Audio Mixer
>> MultiMedia2' 1
>> aplay -D plughw:0,1 some-wav-file.wav
>>
>> both with and without display connected.
>>
>
> aplay always gives the following error:
>
> Playing WAVE 'Summer.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
> Stereo
> aplay: set_params:1456: Unable to install hw params:
> ACCESS: RW_INTERLEAVED
> FORMAT: S16_LE
> SUBFORMAT: STD
> SAMPLE_BITS: 16
> FRAME_BITS: 32
> CHANNELS: 2
> RATE: 44100
> PERIOD_TIME: (42666 42667)
> PERIOD_SIZE: (1881 1882)
> PERIOD_BYTES: (7524 7528)
> PERIODS: (3 5)
> BUFFER_TIME: (170657 170658)
> BUFFER_SIZE: 7526
> BUFFER_BYTES: 30104
> TICK_TIME: 0
>
> and kernel gives the following when display is connected:
>
> [drm:dp_catalog_audio_config_sdp] sdp_cfg = 0x100066
> [drm:dp_catalog_audio_config_sdp] sdp_cfg2 = 0x1b800004
> [drm:dp_audio_hw_params] Header Byte 1: value = 0xce020000, parity_byte
> = 0xce
> [drm:dp_audio_hw_params] Header Byte 2: value = 0x67010000, parity_byte
> = 0x0
> [drm:dp_audio_hw_params] Header Byte 3: value = 0x67010000, parity_byte
> = 0x67
> [drm:dp_audio_hw_params] Header Byte 1: value = 0x67010000, parity_byte
> = 0x67
> [drm:dp_audio_hw_params] Header Byte 2: value = 0x33443517, parity_byte
> = 0x35
> [drm:dp_audio_hw_params] Header Byte 3: value = 0x33443517, parity_byte
> = 0x33
> [drm:dp_audio_hw_params] Header Byte 1: value = 0x84840000, parity_byte
> = 0x84
> [drm:dp_audio_hw_params] Header Byte 2: value = 0x3344d71b, parity_byte
> = 0xd7
> [drm:dp_audio_hw_params] Header Byte 3: value = 0x44, parity_byte = 0x33
> [drm:dp_audio_hw_params] Header Byte 1: value = 0xd8050000, parity_byte
> = 0xd8
> [drm:dp_audio_hw_params] Header Byte 2: value = 0x4b0f, parity_byte = 0x4b
> [drm:dp_audio_hw_params] Header Byte 3: value = 0x4b0f, parity_byte = 0x0
> [drm:dp_audio_hw_params] Header Byte 1: value = 0x71060000, parity_byte
> = 0x71
> [drm:dp_audio_hw_params] Header Byte 2: value = 0x4b0f, parity_byte = 0x4b
> [drm:dp_catalog_audio_config_acr] select: 0x3, acr_ctrl: 0x80004130
> [drm:dp_catalog_audio_sfe_level] mainlink_level = 0xa08,
> safe_to_exit_level = 0x8
> [drm:dp_catalog_audio_enable] dp_audio_cfg = 0xc1
> qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001006 cmd
> qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
> qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001006 cmd
> qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
> qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001001 cmd
> qcom-apm gprsvc:service:2:1: DSP returned error[1001001] 1
> q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais:
> Failed to prepare Graph -22
> q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais:
> ASoC: error at snd_soc_pcm_dai_prepare on DISPLAY_PORT_RX_0: -22
> [drm:dp_catalog_audio_enable] dp_audio_cfg = 0xc0
>
>>
>> --srini
>>
>>
>>
>>> 0x01001006 cmd
>>> [ 1552.314463] qcom-apm gprsvc:service:2:1: DSP returned
>>> error[1001006] 1
>>> [ 1552.315496] qcom-apm gprsvc:service:2:1: Error (1) Processing
>>> 0x01001006 cmd
>>> [ 1552.315506] qcom-apm gprsvc:service:2:1: DSP returned
>>> error[1001006] 1
>>> [ 1552.316033] qcom-apm gprsvc:service:2:1: Error (1) Processing
>>> 0x01001001 cmd
>>> [ 1552.316042] qcom-apm gprsvc:service:2:1: DSP returned
>>> error[1001001] 1
>>> [ 1552.316045] q6apm-lpass-dais
>>> 30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to
>>> prepare Graph -22
>>> [ 1552.316047] q6apm-lpass-dais
>>> 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at
>>> snd_soc_pcm_dai_prepare on DISPLAY_PORT_RX_0: -22
>
On 2024/6/6 17:18, Srinivas Kandagatla wrote:
> Hi Xilin
>
> On 25/05/2024 08:12, Xilin Wu wrote:
>> Hi Srini,
>>
>> On 2024/5/24 20:50, Srinivas Kandagatla wrote:
>>> Hi Xilin,
>>>
>>> On 23/05/2024 05:09, Xilin Wu wrote:
>>>>>
>>>>> Srinivas Kandagatla (4):
>>>>> ASoC: qcom: q6dsp: parse Display port tokens
>>>>> ASoC: qcom: common: add Display port Jack function
>>>>> ASoC: qcom: sc8280xp: add Display port Jack
>>>>> ASoC: qcom: sm8250: fix a typo in function name
>>>>>
>>>>> sound/soc/qcom/common.c | 29 +++++++++++++++++++++++++++++
>>>>> sound/soc/qcom/common.h | 3 +++
>>>>> sound/soc/qcom/qdsp6/topology.c | 26 ++++++++++++++++++++++++++
>>>>> sound/soc/qcom/sc8280xp.c | 14 ++++++++++++++
>>>>> sound/soc/qcom/sm8250.c | 4 ++--
>>>>> 5 files changed, 74 insertions(+), 2 deletions(-)
>>>>>
>>>>
>>>> Hi Srini,
>>>>
>>>> I tested this series on SM8550 with tplg in [1] and ucm in [2]. But
>>>> the kernel output errors attached below. Headphone does work
>>>> properly without DisplayPort in the ucm.
>>>>
>>>> What could be the possible cause of this? Is there any significant
>>>> change from sc8280xp to sm8550?
>>>>
>>>> --
>>>> Thanks,
>>>> Xilin Wu
>>>>
>>>> [1]
>>>> https://github.com/edk2-porting/audioreach-topology/blob/sakuramist/QCS8550-AYN-ODIN2.m4
>>>> [2]
>
> For sm8550 you would need this patch for tplg
>
> https://git.codelinaro.org/krzysztof.kozlowski/audioreach-topology/-/commit/d8ef47bc85700a7cdfabee5e06808d9f359b0a26
>
> can you try this as the Container CAP Id changed for platforms from sm8550.
>
> Kryzstof verified Display port tplg and these patches on x1e80100.
>
That exactly solved the previous problem, thanks!
Hot-unplugging type-c caused `fail to close APM port` error, and DP
audio will no longer work after that. But I guess that would be another
issue anyway :)
--
Thanks,
Xilin Wu
>
> thanks,
> srini
>
>>>> https://github.com/strongtz/alsa-ucm-conf/blob/odin2/ucm2/Qualcomm/sm8550/HiFi.conf
>>>>
>>>> [ 1552.313713] qcom-apm gprsvc:service:2:1: Error (1) Processing
>>>> 0x01001000 cmd
>>>> [ 1552.313730] qcom-apm gprsvc:service:2:1: DSP returned
>>>> error[1001000] 1
>>>> [ 1552.314455] qcom-apm gprsvc:service:2:1: Error (1) Processing
>>>
>>> Is the DP cable connected?
>>
>> I'm sure that the cable is connected and I have desktop on external
>> display.
>> If it's not connected, kernel gives the following error when using aplay:
>>
>> hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at
>> snd_soc_dai_hw_params on i2s-hifi: -22
>>
>>>
>>> if its not connected the dsp will throw this error.
>>>
>>> due to this issue I did workaround this issue by modeling it as
>>> conflicting device to Speaker in x13s ucm.
>>>
>>> I see in your ucm setup its not the case.
>>> which is why you might be hitting this issue.
>>>
>>> Can you try
>>> amixer -c 0 cset iface=MIXER,name='DISPLAY_PORT_RX_0 Audio Mixer
>>> MultiMedia2' 1
>>> aplay -D plughw:0,1 some-wav-file.wav
>>>
>>> both with and without display connected.
>>>
>>
>> aplay always gives the following error:
>>
>> Playing WAVE 'Summer.wav' : Signed 16 bit Little Endian, Rate 44100
>> Hz, Stereo
>> aplay: set_params:1456: Unable to install hw params:
>> ACCESS: RW_INTERLEAVED
>> FORMAT: S16_LE
>> SUBFORMAT: STD
>> SAMPLE_BITS: 16
>> FRAME_BITS: 32
>> CHANNELS: 2
>> RATE: 44100
>> PERIOD_TIME: (42666 42667)
>> PERIOD_SIZE: (1881 1882)
>> PERIOD_BYTES: (7524 7528)
>> PERIODS: (3 5)
>> BUFFER_TIME: (170657 170658)
>> BUFFER_SIZE: 7526
>> BUFFER_BYTES: 30104
>> TICK_TIME: 0
>>
>> and kernel gives the following when display is connected:
>>
>> [drm:dp_catalog_audio_config_sdp] sdp_cfg = 0x100066
>> [drm:dp_catalog_audio_config_sdp] sdp_cfg2 = 0x1b800004
>> [drm:dp_audio_hw_params] Header Byte 1: value = 0xce020000,
>> parity_byte = 0xce
>> [drm:dp_audio_hw_params] Header Byte 2: value = 0x67010000,
>> parity_byte = 0x0
>> [drm:dp_audio_hw_params] Header Byte 3: value = 0x67010000,
>> parity_byte = 0x67
>> [drm:dp_audio_hw_params] Header Byte 1: value = 0x67010000,
>> parity_byte = 0x67
>> [drm:dp_audio_hw_params] Header Byte 2: value = 0x33443517,
>> parity_byte = 0x35
>> [drm:dp_audio_hw_params] Header Byte 3: value = 0x33443517,
>> parity_byte = 0x33
>> [drm:dp_audio_hw_params] Header Byte 1: value = 0x84840000,
>> parity_byte = 0x84
>> [drm:dp_audio_hw_params] Header Byte 2: value = 0x3344d71b,
>> parity_byte = 0xd7
>> [drm:dp_audio_hw_params] Header Byte 3: value = 0x44, parity_byte = 0x33
>> [drm:dp_audio_hw_params] Header Byte 1: value = 0xd8050000,
>> parity_byte = 0xd8
>> [drm:dp_audio_hw_params] Header Byte 2: value = 0x4b0f, parity_byte =
>> 0x4b
>> [drm:dp_audio_hw_params] Header Byte 3: value = 0x4b0f, parity_byte = 0x0
>> [drm:dp_audio_hw_params] Header Byte 1: value = 0x71060000,
>> parity_byte = 0x71
>> [drm:dp_audio_hw_params] Header Byte 2: value = 0x4b0f, parity_byte =
>> 0x4b
>> [drm:dp_catalog_audio_config_acr] select: 0x3, acr_ctrl: 0x80004130
>> [drm:dp_catalog_audio_sfe_level] mainlink_level = 0xa08,
>> safe_to_exit_level = 0x8
>> [drm:dp_catalog_audio_enable] dp_audio_cfg = 0xc1
>> qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001006 cmd
>> qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
>> qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001006 cmd
>> qcom-apm gprsvc:service:2:1: DSP returned error[1001006] 1
>> qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001001 cmd
>> qcom-apm gprsvc:service:2:1: DSP returned error[1001001] 1
>> q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais:
>> Failed to prepare Graph -22
>> q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais:
>> ASoC: error at snd_soc_pcm_dai_prepare on DISPLAY_PORT_RX_0: -22
>> [drm:dp_catalog_audio_enable] dp_audio_cfg = 0xc0
>>
>>>
>>> --srini
>>>
>>>
>>>
>>>> 0x01001006 cmd
>>>> [ 1552.314463] qcom-apm gprsvc:service:2:1: DSP returned
>>>> error[1001006] 1
>>>> [ 1552.315496] qcom-apm gprsvc:service:2:1: Error (1) Processing
>>>> 0x01001006 cmd
>>>> [ 1552.315506] qcom-apm gprsvc:service:2:1: DSP returned
>>>> error[1001006] 1
>>>> [ 1552.316033] qcom-apm gprsvc:service:2:1: Error (1) Processing
>>>> 0x01001001 cmd
>>>> [ 1552.316042] qcom-apm gprsvc:service:2:1: DSP returned
>>>> error[1001001] 1
>>>> [ 1552.316045] q6apm-lpass-dais
>>>> 30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to
>>>> prepare Graph -22
>>>> [ 1552.316047] q6apm-lpass-dais
>>>> 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at
>>>> snd_soc_pcm_dai_prepare on DISPLAY_PORT_RX_0: -22
>>