All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Benoit Cousson <bcousson@baylibre.com>
Cc: Fabien Parent <fparent@baylibre.com>,
	misael.lopez@ti.com, broonie@kernel.org, lgirdwood@gmail.com,
	alsa-devel@alsa-project.org
Subject: Re: [RFT v3 3/3] ASoC: core: Add support for DAI multicodec
Date: Fri, 23 May 2014 14:42:26 +0200	[thread overview]
Message-ID: <537F4232.4090801@metafoo.de> (raw)
In-Reply-To: <537DA0C6.7080502@baylibre.com>

On 05/22/2014 09:01 AM, Benoit Cousson wrote:
> Hi Lars,
>
> On 16/05/2014 12:44, Lars-Peter Clausen wrote:
>> On 05/15/2014 05:01 PM, Benoit Cousson wrote:
>
> [...]
>
>>>>> @@ -1586,16 +1626,21 @@ static int soc_probe_link_dais(struct
>>>>> snd_soc_card *card, int num, int order)
>>>>>                             codec2codec_close_delayed_work);
>>>>>
>>>>>                 /* link the DAI widgets */
>>>>> -            ret = soc_link_dai_widgets(card, dai_link,
>>>>> -                    cpu_dai, codec_dai);
>>>>> -            if (ret)
>>>>> -                return ret;
>>>>> +            for (i = 0; i < rtd->num_codecs; i++) {
>>>>> +                ret = soc_link_dai_widgets(card, dai_link,
>>>>> +                        cpu_dai, rtd->codec_dais[i]);
>>>>
>>>> This will create a DAI link widget for each CODEC DAI. The DAI link
>>>> widget will configure the CPU and the CODEC DAI that are connected to
>>>> it. If there is one DAI link widget per CODEC DAI this means that the
>>>> CPU DAI will be connected to multiple DAI link widgets, which means it
>>>> will be configured once for each CODEC DAI (with possible conflicting
>>>> configurations).
>>>
>>> I've got that point, but now I'm wondering what struct should be per
>>> codec_dai. Should we consider one source and several sinks to
>>> represent the multiple codecs?
>>
>> The soc_link_dai_widgets function should take the rtd as a parameter
>> instead of the CODEC and CPU DAIs. Same goes for snd_soc_dapm_new_pcm()
>> then you create one dai_link widget per stream (i.e. one for capture of
>> there is capture support, one for playback if there is playback
>> support). And then create the paths between the dai_link widgets and the
>> DAI widgets accordingly.
>
> I'm still not 100% sure how it should work so here is a tentative patch to try to handle that part. Please note that in my setup none of that code is ever called :-( I'm not sure why!
>
> Please ignore the extra DEBUG code I added and there is probably some way to factorize some code, but I'd like to be sure that this is the proper way to handle the routes in the multicodec case before re-sending that series.

If we do not want to support CODEC<-->CODEC links with multiple CODECs you 
do not have to care about this for now. But I think the code looks good. The 
result should look something like this:

                     +----------+
                     | Playback | --> [ CODEC 1 DAI ]
         [ CPU ] --> | DAI LINK | --> [ CODEC 2 DAI ]
                     |          | --> [ CODEC 3 DAI ]
                     +----------+

                     +----------+
[ CODEC 1 DAI ]-- > | Capture  |
[ CODEC 2 DAI ] --> | DAI LINK | --> [ CPU DAI ]
[ CODEC 3 DAI ] --> |          |
                     +----------+

Also note that the code in upstream is now using snd_soc_dapm_add_path() 
rather than snd_soc_dapm_add_route()

- Lars

  reply	other threads:[~2014-05-23 12:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-24 12:01 [RFT v3 0/3] ASoC: core: Add support for DAI multicodec Benoit Cousson
2014-04-24 12:01 ` [RFT v3 1/3] ASoC: core: Add helpers for dai link and aux dev init Benoit Cousson
2014-04-24 12:24   ` Mark Brown
2014-04-24 12:01 ` [RFT v3 2/3] ASoC: core: Add one dai_get_widget helper instead of two rtd based ones Benoit Cousson
2014-04-24 12:25   ` Mark Brown
2014-04-24 12:01 ` [RFT v3 3/3] ASoC: core: Add support for DAI multicodec Benoit Cousson
2014-04-26 12:51   ` Lars-Peter Clausen
2014-04-29 17:53     ` Benoit Cousson
2014-05-15 15:01     ` Benoit Cousson
2014-05-16 10:44       ` Lars-Peter Clausen
2014-05-16 11:31         ` Benoit Cousson
2014-05-22  7:01         ` Benoit Cousson
2014-05-23 12:42           ` Lars-Peter Clausen [this message]
2014-05-06 11:24   ` Lars-Peter Clausen
2014-05-16 20:06     ` Sinan Akman
2014-05-17 11:46       ` Mark Brown
2014-06-23 14:26     ` Benoit Cousson

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=537F4232.4090801@metafoo.de \
    --to=lars@metafoo.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=bcousson@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=fparent@baylibre.com \
    --cc=lgirdwood@gmail.com \
    --cc=misael.lopez@ti.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.