alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Benoit Cousson <bcousson@baylibre.com>
To: Lars-Peter Clausen <lars@metafoo.de>
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: Mon, 23 Jun 2014 16:26:17 +0200	[thread overview]
Message-ID: <53A83909.2060002@baylibre.com> (raw)
In-Reply-To: <5368C67D.4080506@metafoo.de>

Hi Lars,

I finally got some BW to address your second email :-)

On 06/05/2014 13:24, Lars-Peter Clausen wrote:
> On 04/24/2014 02:01 PM, Benoit Cousson wrote:
>> DAI link assumes a one to one mapping between CPU DAI and CODEC. In
>> some cases, the same CPU DAI can be connected to several codecs.
>> This is the case for example, if you connect two mono codecs to the
>> same I2S link in order to have a stereo card.
>> The current ASoC implementation does not allow such setup.
>>
>> Add support for DAI links composed of a single CPU DAI and multiple
>> CODECs. Sound cards have to pass the CODECs array in the corresponding
>> DAI link through a new 'snd_soc_dai_link_component' struct. Each CODEC in
>> this array is described in the same manner single CODEC DAIs are
>> (either DT/OF node or codec_name).
>>
>> Fix a trailing space in the header as well.
>>
>> Based on an original code done by Misael.
>>
>> Signed-off-by: Benoit Cousson <bcousson@baylibre.com>
>> Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
>> Signed-off-by: Fabien Parent <fparent@baylibre.com>
>
> Some thoughts on the parameter fixup.
>
>> ---
>>   include/sound/soc-dai.h  |   5 +
>>   include/sound/soc.h      |  13 ++
>>   sound/soc/soc-compress.c |  83 +++++---
>>   sound/soc/soc-core.c     | 364 ++++++++++++++++++++++-----------
>>   sound/soc/soc-dapm.c     |  71 ++++---
>>   sound/soc/soc-pcm.c      | 512
>> ++++++++++++++++++++++++++++++++---------------
>>   6 files changed, 715 insertions(+), 333 deletions(-)
>>
>> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
>> index fad7676..6985851 100644
>> --- a/include/sound/soc-dai.h
>> +++ b/include/sound/soc-dai.h
>> @@ -274,6 +274,11 @@ struct snd_soc_dai {
>>       struct snd_soc_codec *codec;
>>       struct snd_soc_component *component;
>>
>> +    /* CODEC TDM slot masks and params (for fixup) */
>> +    unsigned int tx_mask;
>> +    unsigned int rx_mask;
>> +    struct snd_pcm_hw_params params[2];
>
> snd_pcm_hw_params is rather large, given that for a lot of setups we
> don't need it it might be better to make this a pointer and only
> allocate the params struct when needed.

OK.

>
> [...]
>> @@ -3624,17 +3697,26 @@ static int
>> snd_soc_xlate_tdm_slot_mask(unsigned int slots,
>>   int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai,
>>       unsigned int tx_mask, unsigned int rx_mask, int slots, int
>> slot_width)
>>   {
>> +    int ret = 0;
>> +
>>       if (dai->driver && dai->driver->ops->xlate_tdm_slot_mask)
>>           dai->driver->ops->xlate_tdm_slot_mask(slots,
>>                           &tx_mask, &rx_mask);
>>       else
>>           snd_soc_xlate_tdm_slot_mask(slots, &tx_mask, &rx_mask);
>>
>> +    if (dai->codec) {
>> +        dai->tx_mask = tx_mask;
>> +        dai->rx_mask = rx_mask;
>> +    }
>
> I don't think it makes sense to artificially limit this to just CODECs.
> While we do not support multiple CPU DAIs (yet?) adding the check for
> CODECs just makes the code more complex, but doesn't gain us anything.

OK, makes sense.

>
>
> [...]
>> +    for (i = 0; i < rtd->num_codecs; i++) {
>> +        struct snd_soc_dai *codec_dai = rtd->codec_dais[i];
>> +        struct snd_pcm_hw_params *codec_params;
>> +
>> +        codec_params = &codec_dai->params[substream->stream];
>
> The fixed up params are only ever used in here. Do we really need to
> keep two copies per CODEC DAI around?

Well, we can indeed, create a local copy that will be used for the 
fixup. Moreover, it will avoid allocating the data dynamically.

>> +
>> +        /* copy params for each codec */
>> +        memcpy(codec_params, params, sizeof(struct snd_pcm_hw_params));
>> +
>> +        /* fixup params based on TDM slot masks */
>> +        if (codec_dai->tx_mask)
>> +            soc_pcm_codec_params_fixup(codec_params,
>> +                           codec_dai->tx_mask);
>> +        if (codec_dai->rx_mask)
>> +            soc_pcm_codec_params_fixup(codec_params,
>> +                           codec_dai->rx_mask);
>> +
>
> If we fix-up the number of channels to be always the number of slots
> should we also setup a constraint for userspace that the number of
> channels must match the number of channels specified in the CPU DAI
> mask? Or should we check how many of the channels in the CODEC mask are
> actually active and fix-up the the number of channels according to that?

That's a pretty good question.

I've tried to check the current users of the snd_soc_dai_set_tdm_slot to 
understand how it is used in cpu/codec dais.

There are only ~10 users, and it seems that the definition of the mask 
is dependent of the user. I don't know if we can really enforce anything 
because of that :-(

>> +        if (codec_dai->driver->ops &&
>> +            codec_dai->driver->ops->hw_params) {
>> +            ret = codec_dai->driver->ops->hw_params(substream,
>> +                        codec_params, codec_dai);
>> +            if (ret < 0) {
>> +                dev_err(codec_dai->dev,
>> +                    "ASoC: can't set %s hw params: %d\n",
>> +                    codec_dai->name, ret);
>> +                goto codec_err;
>> +            }
>>           }
>
> I think it makes sense to factor this whole block out into a helper
> function. E.g. soc_dai_hw_params(struct snd_soc_dai* dai, struct
> hw_params *params);. This will make it possible to also use it in other
> places like the dapm_dai_link_event() function.

OK, good point.

Thanks,
Benoit

-- 
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com

      parent reply	other threads:[~2014-06-23 14:26 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
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 [this message]

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=53A83909.2060002@baylibre.com \
    --to=bcousson@baylibre.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=fparent@baylibre.com \
    --cc=lars@metafoo.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).