[alsa-devel] codec->card removed

[jonsmirl at gmail.com]

On Fri, Sep 26, 2014 at 3:46 PM, Lars-Peter Clausen <lars at metafoo.de> wrote:

> 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.


People are already doing that. There are three known tablets with various
external amp chips that have some GPIO controls. The driver used the be
non-SOC, it was these amps that caused it to covert.

There is also a lot of variation with what jacks are installed. It supports
MIc 1 & 2, Vmic
Line In L/R
FM L/R
Phone Out L/R
Headphone L/R


> 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.
>

The I2S support on the chip needs ASoC. There is also a SPDIF unit that
looks like the on-chip codec. It was too confusing to have some drivers
implemented as ASoC and others not.



>
> 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
>
>


-- 
Jon Smirl
jonsmirl at gmail.com