[alsa-devel] codec->card removed

[Lars-Peter Clausen]

On 09/26/2014 09:32 PM, jonsmirl at gmail.com wrote:
>
>
> On Fri, Sep 26, 2014 at 3:25 PM, Lars-Peter Clausen <lars at metafoo.de
> <mailto:lars at metafoo.de>> wrote:
>
>     On 09/26/2014 09:19 PM, jonsmirl at gmail.com <mailto:jonsmirl at gmail.com>
>     wrote:
>
>         How should I rewrite this to reflect that codec->card has been removed?
>
>
>         This is codec is on the SOC chip, not an external one.
>
>         static int sunxi_codec_trigger(struct snd_pcm_substream *substream, int
>         cmd, struct snd_soc_dai *dai) {
>         struct snd_soc_pcm_runtime *rtd = substream->private_data;
>         struct snd_soc_dai *codec_dai = rtd->codec_dai;
>         struct snd_soc_codec *codec = codec_dai->codec;
>         struct snd_soc_card *card = codec->card;
>         struct sunxi_priv *priv = snd_soc_card_get_drvdata(card)__;
>
>
>
>     It was moved to the component sub-structure in the CODEC struct. So
>
>     codec->component.card
>
>     But you really shouldn't access the card from the CODEC driver, that is
>     a layering violation.
>
>     Similarly accessing rtd->codec_dai from the CODEC driver is not correct,
>     since codec_dai may not necessarily point to the CODEC DAI of your
>     CODEC. (E.g. for multi-codec links or codec-to-codec links).
>
>
> In this case CPU DAI and CODEC DAI are integrated onto the CPU SOC. You
> can't attach an external codec.
> Check out sunxi_codec_probe()
> Where should 'priv' have been stashed?

The way your driver looks right now you wouldn't need to make it a ASoC 
driver, since the whole audio card is defined in this one driver. But 
generally people still want to be able to for example hook up external 
amplifiers or similar. So even in the case that the SoC side is not 
componetized it still makes sense to have a ASoC driver. But you'd want to 
split the driver for your on-SoC component and the card driver, since the 
card driver will potentially contain other components as well.

Since we now do have support for things like controls and DAPM widgets at 
the component level it makes sense to implement most of the drivers 
functionality as part of your snd_soc_component driver. For the moment 
you'll still need a dummy CODEC driver so ASoC will create a PCM device. But 
this is a requirement that might go away in the future.

- Lars