From: Lars-Peter Clausen <lars@metafoo.de>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>, Simon <horms@verge.net.au>
Subject: Re: Question about Component and Card
Date: Mon, 03 Aug 2015 13:51:48 +0200 [thread overview]
Message-ID: <55BF55D4.5010007@metafoo.de> (raw)
In-Reply-To: <87wpxcvl5n.wl%kuninori.morimoto.gx@renesas.com>
On 08/03/2015 10:23 AM, Kuninori Morimoto wrote:
>
> Hi Lars
>
>>> I noticed my sound card (which is not upstreamed) can't probe in next branch.
>>> I think it is because this patch
>>> 1b7c12316982f74a5b8e7704c24cf5524d0723a3
>>> (ASoC: Prevent components from being bound to multiple cards)
>>>
>>> In my case, my sound device (= CPU) has some DAIs,
>>> and these are connected to some codecs.
>>> It is shown as below. And I would like to use these as 2 sound cards.
>>> ex) aplay -D hw:0 xxx
>>> aplay -D hw:1 xxx
>>> But, 2nd sound card can't probe because of above patch now.
>>> (component->card indicates 1st card)
>>> It can be probeed if I used DPCM card (= 1 CPU + 2 Codec), but...
>>> But, is my understanding wrong ?
>>
>> ASoC always had the restriction that you can only bind a component to a
>> single card. Otherwise the internal data structures will get corrupted,
>> which may result in undefined behavior at a later point. The patch made this
>> restriction explicit to make sure that issue is caught when it happens and
>> you don't have dig through crashes from random memory corruption.
>
> Hmm...
> Current my CPU driver is probing all channels in 1 driver.
> Then, I can use multi sound card if CPU driver probes limited channels.
> (ex driver0 probes ch0, ch1
> driver1 probes ch2, ch3, or something like this)
>
> This means I need to re-consider / change my CPU driver for it.
> Do you think this is good idea ? or do I have other solution ?
Yeah, it's difficult. I guess this is a case where the control path (e.g.
memory mapped register region, irq, etc.) is shared, but the data paths are
independent. In theory this means you can use each DAI in a different sound
card. But in practice they still share the same DAPM context, even though
there are no connections in the DAPM graph between them. I don't know how to
solve this issue. The easiest way out would be to register a different
component for each DAI. But that might not be possible depending on how the
system is structured.
next prev parent reply other threads:[~2015-08-03 11:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-03 5:33 Question about Component and Card Kuninori Morimoto
2015-08-03 6:27 ` Lars-Peter Clausen
2015-08-03 8:23 ` Kuninori Morimoto
2015-08-03 11:51 ` Lars-Peter Clausen [this message]
2015-08-03 15:58 ` Mark Brown
2015-08-04 0:22 ` Kuninori Morimoto
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=55BF55D4.5010007@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=horms@verge.net.au \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.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.