From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: [PATCH 1/4] ASoC: rt286: rt286_mic_detect() uses component Date: Wed, 26 Oct 2016 09:20:45 +0530 Message-ID: <20161026035045.GB3000@localhost> References: <87eg3a2v32.wl%kuninori.morimoto.gx@renesas.com> <87d1iu2v1j.wl%kuninori.morimoto.gx@renesas.com> <87insi2obs.wl%kuninori.morimoto.gx@renesas.com> <5a1187a2-521a-0cd7-856a-ffdc69a045ed@metafoo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by alsa0.perex.cz (Postfix) with ESMTP id EF95D266669 for ; Wed, 26 Oct 2016 05:41:45 +0200 (CEST) Content-Disposition: inline In-Reply-To: <5a1187a2-521a-0cd7-856a-ffdc69a045ed@metafoo.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Lars-Peter Clausen Cc: Linux-ALSA , Kuninori Morimoto , Takashi Iwai , Mengdong Lin , Mark Brown , Pierre-Louis Bossart , Jin Yao , Simon List-Id: alsa-devel@alsa-project.org 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 > >>>> > >>>> 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