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

[Takashi Iwai]

At Wed, 8 Apr 2015 14:14:28 +0000,
Jie, Yang wrote:
> 
> > -----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?

Well, this isn't about optimization, but rather relevant with the
design -- how more deeply two infrastructures can be integrated.


Takashi