From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH v4 0/5] ALSA: jack: Refactoring for jack kctls Date: Wed, 08 Apr 2015 11:22:23 +0200 Message-ID: References: <1428062838-14786-1-git-send-email-yang.jie@intel.com> <5524D6D8.60205@canonical.com> <5524E677.2020803@canonical.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 5BDC62651AC for ; Wed, 8 Apr 2015 11:22:24 +0200 (CEST) In-Reply-To: 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: "Jie, Yang" Cc: "alsa-devel@alsa-project.org" , "broonie@kernel.org" , "Girdwood, Liam R" , David Henningsson List-Id: alsa-devel@alsa-project.org At Wed, 8 Apr 2015 09:18:10 +0000, Jie, Yang wrote: > > > >> } > > >> > > >> Now the HDA looks more like the ASoC variant. Yang, what do you think > > >> about that? That would make the API simpler, wouldn't it? > > > > > > Here repeat what I stated in another reply: > > > > > > For jack creating, we use the same API -- snd_jack_new(); > > > > > > For kctl creating, yes, we use different APIs: > > > snd_jack_kctl_new() for input jacks(HDA), > > > snd_jack_add_kctls() for kctl jacks(ASoC). > > > > > > There are 2 reasons that I made them different: > > > 1. a. for HDA phantom jack, in the old/exist logic, > > > __snd_hda_jack_add_kctl() will also call snd_kctl_jack_new() and > > > snd_hda_ctl_add(), it will create kctls and add them to card(also > > > assigning some arrays, they are different with calling > > > snd_ctl_add() only, which is what we will do for ASoC kctl adding); > > > > Actually, now that I look at snd_hda_ctl_add, I don't know why we need to > > call it for HDA jacks. There does not seem to be anything relevant for HDA > > jacks there. I think we can just call snd_ctl_add for HDA jacks too. > > OK, then it may make life easier. Hi Takashi, you agree with this? > Do we need add those kctls to the HDA codec, or to hda_nid_item? It's been added in the local list to manage the kctls belonging to a codec more easily. But if snd_hda_codec_free() and _reset() can remove them gracefully, there is no big reason to keep tracking there. Takashi