[alsa-devel] [PATCH 1/1] ASoC: add support for multiple cards/codecs in debugfs

Peter Ujfalusi peter.ujfalusi at nokia.com
Thu Oct 1 07:41:07 CEST 2009

On Wednesday 30 September 2009 15:39:38 ext Mark Brown wrote:
> On Wed, Sep 30, 2009 at 02:21:46PM +0300, Peter Ujfalusi wrote:
> > Yes, when I have moved to 2.6.31 it was kind of weird to have the
> > snd_soc_init_card(socdev) called from the codec driver itself, which I
> > still not feel too comfortable with...
> That was always happening anyway, the function just got renamed.

Might be, but in case if you have one sound card with two (or more) codecs (or 
dai_link) on it than all codecs will call the snd_soc_init_card(socdev), right?

For me at least this does not sound right. I have to check the code itself what 
it actually does.

> > I have in my board two codecs, using separate sound cards for each.
> > One card - one codec.
> > So far DAPM and in general ASoC behaved quite well in all possible
> > scenarios.
> I can't remember off-hand what they are but there are some issues you'll
> run into if you look hard enough - I certainly wouldn't say that it's a
> supported configuration.  Device probe/removal is where the issues are
> if I remember correctly, it can work but it's fragile.

At the moment I'm compiling things in (no problems so far), but I'll try them as 
modules and see how they behave.
> > Btw. do you have some information about this upcoming reorganization, to
> > see what is coming?
> Probably from an external point of view it'll have a dev_name added to
> all the strings in the DAPM maps for deduplication when used in the
> board drivers (which are the only things that ought to need to know
> about more than one device).  For the cards the soc-audio device will go
> away and the card device will be used directly, possibly with only the
> DAIs being directly referenced from the machine driver.
> It's much more of an upheaval internally.

I see, thanks.

> > All of that being said, it would be still nice to at least fix the
> > current situation in some way, since the current implementation is
> > clearly not behaving correctly.
> >
> > Does it help, if I use the dev_name() instead of the codec->name for the
> > directory for now?
> I'd use both, the dev_name() is rather illegible by itself.

Is it good if the patch creates a directory hierarchy like this:

Or should I use some intermediate buffer to construct a single level tree:

From the point of what is coming the former is much more future proof, if we 
take into account that we can have more than one codec in one soc device (or 


More information about the Alsa-devel mailing list