All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Stephan Gerhold <stephan@gerhold.net>
Cc: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>,
	alsa-devel@alsa-project.org, tiwai@suse.de,
	Daniel Baluta <daniel.baluta@gmail.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Mark Brown <broonie@kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Bard Liao <yung-chuan.liao@linux.intel.com>
Subject: Re: [PATCH 1/4] ASoC: soc-pcm: dpcm: fix playback/capture checks
Date: Tue, 16 Jun 2020 12:05:49 -0500	[thread overview]
Message-ID: <45d43cc9-be22-a7d2-1628-3fb30232bd7c@linux.intel.com> (raw)
In-Reply-To: <7cbc9233-e5f2-03e0-5659-cf22dea75e53@linux.intel.com>




>>> simple-card.c and audio-graph-card do hard-code but that's done with 
>>> C in
>>> the driver:
>>>
>>>     ret = asoc_simple_parse_daifmt(dev, cpu_ep, codec_ep,
>>>                        NULL, &dai_link->dai_fmt);
>>>     if (ret < 0)
>>>         goto out_put_node;
>>>
>>>     dai_link->dpcm_playback        = 1;
>>>     dai_link->dpcm_capture        = 1;
>>>
>>>
>>> that that should be fixed based on the DAI format used in that 
>>> dai_link - in
>>> other words we can make sure the capabilities of the dailink are aligned
>>> with the dais while parsing the DT blobs.
>>
>> But how do you know which capabilities to set? The device tree doesn't
>> tells us that. We could add some code to look up the snd_soc_dai_driver
>> early, based on the references in the device tree (basically something
>> like snd_soc_of_get_dai_name(), see
>>    
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/soc-core.c#n2988) 
>>
>>
>> At least to me that function doesn't exactly look trivial though,
>> and that's just to properly fill in the dpcm_playback/capture
>> parameters. Essentially those parameters only complicate the current
>> device tree use case,  where you want the DAI link to be for both
>> playback/capture, but restricted to the capabilities of the DAI.
>>
>> Just wondering if setting up dpcm_playback/capture properly is worth it
>> at all in this case. This isn't necessary for the non-DPCM case either,
>> there we automatically set it based on the DAI capabilities.
> 
> We can add a simple loop for each direction that relies on
> snd_soc_dai_stream_valid() to identify if each DAI is capable of doing 
> playback/capture.

see below completely untested diff to show what I had in mind: we 
already make use of snd_soc_dai_stream_valid() in other parts of the 
core so we should be able to determine dpcm_playback/capture based on 
the same information already used.

diff --git a/sound/soc/generic/audio-graph-card.c 
b/sound/soc/generic/audio-graph-card.c
index 9ad35d9940fe..4c67f1f65eb4 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -215,7 +215,9 @@ static int graph_dai_link_of_dpcm(struct 
asoc_simple_priv *priv,
         struct asoc_simple_dai *dai;
         struct snd_soc_dai_link_component *cpus = dai_link->cpus;
         struct snd_soc_dai_link_component *codecs = dai_link->codecs;
+       int stream;
         int ret;
+       int i;

         /* Do it all CPU endpoint, and 1st Codec endpoint */
         if (!li->cpu && dup_codec)
@@ -317,8 +319,34 @@ static int graph_dai_link_of_dpcm(struct 
asoc_simple_priv *priv,
         if (ret < 0)
                 goto out_put_node;

-       dai_link->dpcm_playback         = 1;
-       dai_link->dpcm_capture          = 1;
+       for_each_pcm_streams(stream) {
+               struct snd_soc_dai_link_component *cpu;
+               struct snd_soc_dai_link_component *codec;
+               struct snd_soc_dai *d;
+               bool dpcm_direction = true;
+
+               for_each_link_cpus(dai_link, i, cpu) {
+                       d = snd_soc_find_dai(cpu);
+                       if (!d || !snd_soc_dai_stream_valid(d, stream)) {
+                               dpcm_direction = false;
+                               break;
+                       }
+               }
+               for_each_link_codecs(dai_link, i, codec) {
+                       d = snd_soc_find_dai(codec);
+                       if (!d || !snd_soc_dai_stream_valid(d, stream)) {
+                               dpcm_direction = false;
+                               break;
+                       }
+               }
+               if (dpcm_direction) {
+                       if (stream == SNDRV_PCM_STREAM_PLAYBACK)
+                               dai_link->dpcm_playback = 1;
+                       if (stream == SNDRV_PCM_STREAM_CAPTURE)
+                               dai_link->dpcm_capture = 1;
+               }
+       }
+
         dai_link->ops                   = &graph_ops;
         dai_link->init                  = asoc_simple_dai_init;



  reply	other threads:[~2020-06-16 17:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08 19:44 [PATCH 0/4] ASoC: Fix dailink checks for DPCM Pierre-Louis Bossart
2020-06-08 19:44 ` [PATCH 1/4] ASoC: soc-pcm: dpcm: fix playback/capture checks Pierre-Louis Bossart
2020-06-16  8:54   ` Stephan Gerhold
2020-06-16  9:02     ` Stephan Gerhold
2020-06-16 14:23       ` Pierre-Louis Bossart
2020-06-16 14:52         ` Mark Brown
2020-06-16 15:05           ` Pierre-Louis Bossart
2020-06-16 15:55             ` Stephan Gerhold
2020-06-16 16:32               ` Pierre-Louis Bossart
2020-06-16 17:05                 ` Pierre-Louis Bossart [this message]
2020-06-17  9:01                   ` Stephan Gerhold
2020-06-17 14:33                     ` Pierre-Louis Bossart
2020-06-17 17:46                       ` Stephan Gerhold
2020-06-18 15:01                         ` Mark Brown
2020-06-18 15:45                           ` Pierre-Louis Bossart
2020-06-22 17:54                             ` Stephan Gerhold
2020-06-22 17:59                               ` Mark Brown
2020-06-16 16:42             ` Mark Brown
2020-07-17 13:42               ` Jerome Brunet
2020-07-17 17:13                 ` Pierre-Louis Bossart
2020-07-17 18:18                   ` Mark Brown
2020-07-17 18:34                     ` Pierre-Louis Bossart
2020-06-08 19:44 ` [PATCH 2/4] ASoC: core: only convert non DPCM link to DPCM link Pierre-Louis Bossart
2020-06-08 19:44 ` [PATCH 3/4] ASoC: Intel: boards: replace capture_only by dpcm_capture Pierre-Louis Bossart
2020-06-08 19:44 ` [PATCH 4/4] ASoC: SOF: nocodec: conditionally set dpcm_capture/dpcm_playback flags Pierre-Louis Bossart
2020-06-09 15:28 ` [PATCH 0/4] ASoC: Fix dailink checks for DPCM Mark Brown

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=45d43cc9-be22-a7d2-1628-3fb30232bd7c@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=daniel.baluta@gmail.com \
    --cc=guennadi.liakhovetski@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stephan@gerhold.net \
    --cc=tiwai@suse.de \
    --cc=yung-chuan.liao@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.