On Mon, Oct 24, 2016 at 11:19:17AM +0200, Lars-Peter Clausen wrote:
> On 10/24/2016 09:43 AM, Kuninori Morimoto wrote:
> > Hi
> >
> >>>> From: Kuninori Morimoto <kuninori.morimoto.gx@xxxxxxxxxxx>
> >>>>
> >>>> Intel broadwell is using card->codec_dev_list, but it will be
> >>>> replaced to component list soon. Then, it will not be able to use
> >>>> "codec".
> >>>
> >>> Can't it be deduced by a simple container_of()?
> >>
> >> There is the snd_soc_component_to_codec() helper for this.
> >
> > The points are
> > 1) We would like to remove "codec" related functions
>
> The focus at the moment is to remove all special handling of CODECs from the
> ASoC core. And trying to do this without being too invasive and causing too
> many changes all over the place.
>
> > 2) We can get "codec" pointer by above function/macro,
> > but "codec" function/macro is using codec->component inside.
> >
>
> That's not a problem though.
>
> This is slightly unrelated to this series, but these drivers should not be
> poking the internal data structures of snd_soc_card in the first place. The
> best way to get the pointer to the CODEC is by using the DAI link init
> callback. This also means that there is no need to run a lookup each time
> the CODEC is needed. An alternative is to add a helper function in the core
> that allows to lookup a component by name.
>
> Maybe somebody from the Intel side can look into fixing this. The affected
> boards are cht_bsw_rt5672 and broadwell, which both access the cards
> codec_dev_list field.
This also exists in some customer SKL machines.
I agree that this may not be best implementation so I can send a patch for
this.
As Lars suggested we can use DAI link init callback, but then I dont feel it
is right to use rtd->codec to get codec pointer, again we will be looking
into rtd internals. So would make sense to combine two suggestion and add an
API:
struct snd_soc_codec *snd_soc_get_codec(struct snd_soc_pcm_runtime *rtd)
{
return rtd->codec;
}
then we can use this is drivers.
Let me know if all are in agreement, I can test this and send out..
Thanks
--
~Vinod
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
