[alsa-devel] [PATCH v4 0/5] ALSA: jack: Refactoring for jack kctls

Jie, Yang yang.jie at intel.com
Wed Apr 8 16:14:28 CEST 2015


> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Wednesday, April 08, 2015 5:22 PM
> To: Jie, Yang
> Cc: David Henningsson; alsa-devel at alsa-project.org; broonie at kernel.org;
> Girdwood, Liam R
> Subject: Re: [alsa-devel] [PATCH v4 0/5] ALSA: jack: Refactoring for jack kctls
> 
> 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.
> 
 
I am not sure if snd_hda_codec_free() and _reset() can remove them, with
removing tracking them in HDA codec in my current patch series. To be more
simply and safely, I just keep this old tracking ATM, and we can add patch
to optimize them later if needed, do you agree?

Thanks,
Keyon

> 
> Takashi


More information about the Alsa-devel mailing list