From: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Jaroslav Kysela <perex@perex.cz>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.com>,
alsa-devel@alsa-project.org,
Cezary Rojewski <cezary.rojewski@intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: [PATCH 08/20] ASoC: soc-pcm.c: cleanup soc_get_playback_capture()
Date: Wed, 24 May 2023 13:21:09 +0200 [thread overview]
Message-ID: <ab3f0c0a-62fd-a468-b3cf-0e4b59bac6ae@linux.intel.com> (raw)
In-Reply-To: <87wn10ncyi.wl-kuninori.morimoto.gx@renesas.com>
On 5/23/2023 1:49 AM, Kuninori Morimoto wrote:
>
> Hi Amadeusz
>
>>> static int soc_get_playback_capture(...)
>>> {
>>> ...
>>> (A) if (dai_link->dynamic || dai_link->no_pcm) {
>>> ...
>>> if (dai_link->dpcm_playback) {
>>> ...
>>> (B) for_each_rtd_cpu_dais(rtd, i, cpu_dai) {
>>> ...
>>> }
>>> ...
>>> }
>>> if (dai_link->dpcm_capture) {
>>> ...
>>> (B) for_each_rtd_cpu_dais(rtd, i, cpu_dai) {
>>> ...
>>> }
>>> }
>>> ...
>>> }
>>> }
>>>
>>> It checks CPU (B) when no_pcm (A) on original.
>>> But I think "no_pcm - CPU" is dummy DAI -> above check is no meaning.
>>> After the patch, it checks both CPU/Codec.
> (snip)
>>> I wonder is your Codec which is connected to no_pcm DAI valid ?
>>
>> I'm not sure what do you mean, if it is valid? It works fine before this
>> patch ;)
>
> Ah, sorry, let me explain detail.
>
> static int soc_get_playback_capture(...)
> {
> ...
> (A) if (dai_link->dynamic || dai_link->no_pcm) {
> int stream;
>
> if (dai_link->dpcm_playback) {
> stream = SNDRV_PCM_STREAM_PLAYBACK;
>
> (B) for_each_rtd_cpu_dais(rtd, i, cpu_dai) {
> (C) if (snd_soc_dai_stream_valid(cpu_dai, stream)) {
> has_playback = 1;
> break;
> }
> }
> ...
> }
>
> Before appling the patch, in DPCM case (A), it checks CPU valid only (B)/(C).
> In many case, DPCM is like this
>
> dynamic no_pcm
> [CPU/dummy-Codec] - [dummy-CPU/Codec]
>
> I noticed that before the patch, it checks dummy DAI only for no_pcm case.
> But after appling the patch, it will check both CPU and Codec
> valid (X)/(Y)/(Z).
>
> I think this was changed after patch.
> So, my question was what happen for snd_soc_dai_stream_valid() on your Codec.
>
> # I notcied that avs_create_dai_links() is not using dummy CPU on no_pcm case...
>
>
> static int soc_get_playback_capture(...)
> {
> ...
> (X) for_each_rtd_cpu_dais(rtd, i, cpu_dai) {
> (Y) codec_dai = asoc_rtd_to_codec(rtd, i); /* get paired codec */
>
> (Z) if (snd_soc_dai_stream_valid(codec_dai, SNDRV_PCM_STREAM_PLAYBACK) &&
> (Z) snd_soc_dai_stream_valid(cpu_dai, cpu_playback))
> has_playback = 1;
> (Z) if (snd_soc_dai_stream_valid(codec_dai, SNDRV_PCM_STREAM_CAPTURE) &&
> (Z) snd_soc_dai_stream_valid(cpu_dai, cpu_capture))
> has_capture = 1;
> }
> ...
> }
>
> Thank you for your help !!
>
Hi,
sorry for small delay, I've debugged the issue. Seems like one less
critical problem is in ASoC HDA codec, which blocks HDA and HDMI probing
altogether in our driver, something like this should fix this:
commit ed93e4fbc045b8da7906484a9c88e6b53864949b (HEAD)
Author: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Date: Wed May 24 20:54:44 2023 +0200
ASoC: codecs: hda: Fix probe codec definition
In order to properly bind snd_soc_dai_driver its snd_soc_pcm_stream
need
to provide channels_min value, otherwise ASoC framework may think that
stream is improper.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
diff --git a/sound/soc/codecs/hda.c b/sound/soc/codecs/hda.c
index d57b043d6bfe..62fd99f530bf 100644
--- a/sound/soc/codecs/hda.c
+++ b/sound/soc/codecs/hda.c
@@ -341,6 +341,8 @@ static const struct snd_soc_dapm_widget
hda_dapm_widgets[] = {
static struct snd_soc_dai_driver card_binder_dai = {
.id = -1,
.name = "codec-probing-DAI",
+ .capture.channels_min = 1,
+ .playback.channels_min = 1,
};
static int hda_hdev_attach(struct hdac_device *hdev)
With the above fixed, there is issue with how HDMI is being initialized
and I consider it a blocker. So it needs to be fixed first before this
patchset can be merged. I did simple patch like:
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 64a944016c78..e84c3e46557e 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2317,6 +2317,7 @@ static int generic_hdmi_build_pcms(struct
hda_codec *codec)
if (spec->pcm_used >= ARRAY_SIZE(spec->pcm_rec))
break;
/* other pstr fields are set in open */
+ pstr->channels_min = 1;
}
return 0;
and it works for testing purposes, but as commented in code, those
fields are initialized later (in hdmi_pcm_open()), which apparently in
case of ASoC binding is too late. Likely those assignments need to be
moved earlier.
Another thing that should probably be done is some kind of look through
ASoC codec files to make sure that they all define channels_min
properly, otherwise there may be more unexpected failures.
Thanks,
Amadeusz
next prev parent reply other threads:[~2023-05-24 11:23 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 5:46 [PATCH 00/20] ASoC: replace dpcm_playback/capture to playback/capture_only Kuninori Morimoto
2023-05-18 5:46 ` [PATCH 01/20] ASoC: soc-pcm.c: indicate error if stream has no playback no capture Kuninori Morimoto
2023-05-18 10:37 ` Amadeusz Sławiński
2023-05-18 5:46 ` [PATCH 02/20] ASoC: soc-pcm.c: use dai_link on soc_get_playback_capture() Kuninori Morimoto
2023-05-18 10:37 ` Amadeusz Sławiński
2023-05-18 5:46 ` [PATCH 03/20] ASoC: soc-pcm.c: cleanup soc_get_playback_capture() error Kuninori Morimoto
2023-05-18 10:38 ` Amadeusz Sławiński
2023-05-18 5:47 ` [PATCH 04/20] ASoC: soc-pcm.c: use temporary variable at soc_get_playback_capture() Kuninori Morimoto
2023-05-18 10:38 ` Amadeusz Sławiński
2023-05-18 23:12 ` Kuninori Morimoto
2023-05-18 5:47 ` [PATCH 05/20] ASoC: soc-pcm.c: tidyup playback/capture_only " Kuninori Morimoto
2023-05-18 10:38 ` Amadeusz Sławiński
2023-05-18 5:47 ` [PATCH 06/20] ASoC: soc-pcm.c: cleanup normal connection loop at soc_get_playback_capture() part1 Kuninori Morimoto
2023-05-18 10:38 ` Amadeusz Sławiński
2023-05-18 5:47 ` [PATCH 07/20] ASoC: soc-pcm.c: cleanup normal connection loop at soc_get_playback_capture() part2 Kuninori Morimoto
2023-05-18 10:38 ` Amadeusz Sławiński
2023-05-18 5:47 ` [PATCH 08/20] ASoC: soc-pcm.c: cleanup soc_get_playback_capture() Kuninori Morimoto
2023-05-18 10:38 ` Amadeusz Sławiński
2023-05-19 9:57 ` Amadeusz Sławiński
2023-05-22 4:35 ` Kuninori Morimoto
2023-05-22 9:14 ` Amadeusz Sławiński
2023-05-22 23:49 ` Kuninori Morimoto
2023-05-24 11:21 ` Amadeusz Sławiński [this message]
2023-05-24 23:48 ` Kuninori Morimoto
2023-05-18 5:47 ` [PATCH 09/20] ASoC: amd: replace dpcm_playback/capture to playback/capture_only Kuninori Morimoto
2023-05-18 5:48 ` [PATCH 10/20] ASoC: fsl: " Kuninori Morimoto
2023-05-18 5:48 ` [PATCH 11/20] ASoC: sof: " Kuninori Morimoto
2023-05-18 5:48 ` [PATCH 12/20] ASoC: meson: " Kuninori Morimoto
2023-05-18 5:48 ` [PATCH 13/20] ASoC: Intel: " Kuninori Morimoto
2023-05-18 10:39 ` Amadeusz Sławiński
2023-05-18 23:15 ` Kuninori Morimoto
2023-05-18 5:49 ` [PATCH 14/20] ASoC: samsung: " Kuninori Morimoto
2023-05-18 5:49 ` [PATCH 15/20] ASoC: mediatek: " Kuninori Morimoto
2023-05-18 5:49 ` [PATCH 16/20] ASoC: soc-dai.c: " Kuninori Morimoto
2023-05-18 10:39 ` Amadeusz Sławiński
2023-05-18 23:18 ` Kuninori Morimoto
2023-05-18 5:49 ` [PATCH 17/20] ASoC: soc-core.c: " Kuninori Morimoto
2023-05-18 10:39 ` Amadeusz Sławiński
2023-05-18 5:49 ` [PATCH 18/20] ASoC: soc-topology.c: " Kuninori Morimoto
2023-05-18 10:40 ` Amadeusz Sławiński
2023-05-18 5:49 ` [PATCH 19/20] ASoC: soc-compress.c: " Kuninori Morimoto
2023-05-18 10:40 ` Amadeusz Sławiński
2023-05-18 5:49 ` [PATCH 20/20] ASoC: soc-pcm.c: remove dpcm_playback/capture Kuninori Morimoto
2023-05-18 10:40 ` Amadeusz Sławiński
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=ab3f0c0a-62fd-a468-b3cf-0e4b59bac6ae@linux.intel.com \
--to=amadeuszx.slawinski@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.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