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. > 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. > 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. > 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
