On 09/26/2014 09:32 PM, jonsmirl@gmail.com wrote:
On Fri, Sep 26, 2014 at 3:25 PM, Lars-Peter Clausen <lars@metafoo.de mailto:lars@metafoo.de> wrote:
On 09/26/2014 09:19 PM, jonsmirl@gmail.com <mailto:jonsmirl@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