[alsa-devel] dev_* output functions and ASoC codecs

[Mark Brown]

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.