All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benoit Cousson <bcousson@baylibre.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, lars@metafoo.de,
	lgirdwood@gmail.com, Misael Lopez Cruz <misael.lopez@ti.com>
Subject: Re: [RFC] ASoC: core: Add support for DAI multicodec
Date: Thu, 13 Mar 2014 12:46:43 +0100	[thread overview]
Message-ID: <53219AA3.2060305@baylibre.com> (raw)
In-Reply-To: <20140312225125.GZ28112@sirena.org.uk>

On 12/03/2014 23:51, Mark Brown wrote:
> On Tue, Mar 11, 2014 at 12:17:24PM +0100, Benoit Cousson wrote:
>
>> +struct snd_soc_dai_link_codec {
>> +	const char *codec_name;
>> +	const struct device_node *codec_of_node;
>> +	const char *codec_dai_name;
>> +
>> +	struct snd_soc_codec *codec;
>> +	struct snd_soc_dai *codec_dai;
>> +
>> +	int (*hw_params_fixup)(struct snd_soc_pcm_runtime *rtd,
>> +			       struct snd_pcm_hw_params *params);
>> +	struct snd_pcm_hw_params hw_params;
>> +};
>
> The implementation looks basically fine, it's possible there's something
> nasty in there but the patch is rather large and not quite repetitive
> enough.

I think some non-regression tests on that series will be good, because, 
so far it was used on Misa platform (dra7-evm AFAIR) and my own BBB + 
audio cape platform and BBB + 2 mono Codecs from NXP (to be upstreamed 
soon :-)).

We need to ensure that it will not break the thousand ASoC 
implementations we have in mainline today.

> Most of the interface seems good - I'm not super thrilled with
> having the separate CODECs list but equally well the idea of updating
> all the machine drivers isn't super awesome either and should be punted
> for a cleanup run later.

Yes, that's as well the point I don't like, but couldn't find an easy 
and smooth transition solution. And I guess Misa had the same concern 
before.

> I would like to see something nicer for the fixup though - I think we
> can avoid doing it if we use the TDM API to specify the slots that are
> in use by a CODEC.  Xiubo has done some nice work there recently which
> is handy.  Instead of having a fixup function if we specified a TDM
> and channel map configuration then the core core could override the
> params so that the channel count was clamped by how many channels are
> actually being sent to the device - so if there's two TDM slots active
> the device would be told to play stereo.  Would that work for your use
> cases?

Yes, I think so. My current setup is pretty basic: 2 mono Class D 
amplifiers connected to the same I2S link to build a stereo card.

OK, so I'll rebase the patch to asoc/next. I'll try to split the huge 
patch at least into a series of 2 or 3 patches, and I'll remove the 
fixup part.

Thanks,
Benoit

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

  reply	other threads:[~2014-03-13 11:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-11 11:17 [RFC] ASoC: core: Add support for DAI multicodec Benoit Cousson
2014-03-12  0:28 ` Mark Brown
2014-03-13 10:42   ` Benoit Cousson
2014-03-12 22:51 ` Mark Brown
2014-03-13 11:46   ` Benoit Cousson [this message]
2014-03-13 19:22     ` 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=53219AA3.2060305@baylibre.com \
    --to=bcousson@baylibre.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --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 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.