We use many global variables in asoc now, except defining two/multi
groups of global variables to fulfill two/multi codecs work at the
same time in one system, is there any other way?
On Tue, Oct 6, 2009 at 6:20 PM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Oct 05, 2009 at 08:18:03PM -0400, Mike Frysinger wrote:
>> am i doing something wrong or are the dev_* output functions kind of
>> useless with ASoC codecs ? it seems like the error output is prefixed
>> by the generic "soc-audio" but no info related to the exact codec is
>> included.
>
> You're missing something here.
>
>> as an example, the typical behavior is for the machine driver to call
>> platform_device_alloc("soc-audio", -1). this struct device is then
>
> This is the device for the ASoC card, not for the CODEC. The ASoC card
> is built up from several different devices, the main ones being the
> devices for the CPU and for the CODEC.
>
>> passed down to the relevant subsystem driver register/probe
>> (i2c/spi/etc...) to the codec driver. these functions typically then
>> set the snd_soc_codec's dev member to the allocated platform device.
>
> No, nothing should ever be setting codec->dev to the soc-audio device.
> If anything is that's a bug and should be fixed. That should be set to
> whatever the device model struct device is for the CODEC, normally an
> I2C or SPI device.
>
>> if there are multiple codecs, things obviously fall apart quickly.
>> the question is how to address this. werent there snd_* output funcs
>> before ? or are those now deprecated/dead ? or perhaps we should
>
> Those have never really been used within ASoC.
>
>> encourage people to stop doing platform_device_alloc("soc-audio") and
>> start doing platform_device_alloc(snd_soc_card.name) ?
>
> At some point, probably before the end of the year, it should be
> possible to have any device registered as the card. However, this is a
> separate issue to the device used for the CODEC itself.
>
>> also, there seems to be a semi-common bug in the codec/machine drivers
>> where they dont actually initialize the dev member. perhaps it's time
>> to upgrade the snd_soc_register_codec() check from a KERN_WARNING to a
>> BUG_ON() ? clearly the current warning isnt getting its message
>> through ...
>
> That would make all the existing drivers instabuggy which isn't a
> helpful way of dealing with things. At some point where this becomes a
> blocker to doing further core work someone will have to go through and
> convert all the remaining CODEC drivers over to use the device model.
> The main problem here is that most of the affected CODEC drivers are
> essentially unmaintained.
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
