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@renesas.com
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
- 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.
- 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