[alsa-devel] [PATCH RFC 0/7] Allow multiple callbacks for hda_jack

[Takashi Iwai]

At Tue, 16 Sep 2014 10:33:30 +0200,
David Henningsson wrote:
> 
> 
> 
> On 2014-09-15 14:11, Takashi Iwai wrote:
> > At Mon, 15 Sep 2014 10:42:21 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Thu, 11 Sep 2014 17:14:00 +0200,
> >> David Henningsson wrote:
> >>>
> >>>
> >>>
> >>> On 2014-09-11 16:19, Takashi Iwai wrote:
> >>>> Hi,
> >>>>
> >>>> this is a series of patches I quickly cooked up after the discussion
> >>>> in this morning: the support of multiple callbacks per jack.
> >>>>
> >>>> The series is applied on top of the previous fix patch (ALSA: hda -
> >>>> Fix invalid pin powermap without jack detection).  It begins with
> >>>> a couple of cleanups, then introduces the new hda_jack_callback
> >>>> struct and the changes along with it, then ends with another
> >>>> couple of cleanup patches based on the new infrastructure.
> >>>>
> >>>> I've tested only with a small set of devices, so far.
> >>>
> >>> In general I like this idea and I remember thinking along the same lines.
> >>>
> >>> I'm pondering whether we could use a more memory efficient layout for
> >>> the callback list. Like allocating a snd_array on codec level and have
> >>> indices to that list instead of pointers. Then the kernel would have
> >>> less memory blocks to worry about. What do you think?
> >>
> >> I don't think the memory usage would be any problem in this case as
> >> it's just a few numbers of small blocks.  The only question is which
> >> is better manageable in the source code level.  Let's see...
> >
> > I tried hacking with snd_array, but this ended up more complexity in
> > the code (either adding an extra stuff into struct hda_codec or
> > obviously more overhead than the simple kmalloc).  So, I decided to
> > keep the code as it was.
> >
> > If you find a better solution, let me know.  In anyway, I'll submit v2
> > patches.
> 
> The attached version is a quick write-up of what I was thinking. 
> (Untested, apply on top of patch 4/7.) Whether its better or worse is a 
> matter of taste I suppose - the iterating over the callbacks is a little 
> less compact, but OTOH the freeing is slightly simpler, and there are 
> also less calls to malloc.

Thanks, it's surprisingly identical with what I've wrote for
comparison ;)  And I didn't like to put a new field to hda_codec.

> Btw, in your version, the current free in snd_hda_jack_tbl_clear is 
> within CONFIG_SND_HDA_INPUT_JACK ifdef. Looks like a memory leak if 
> CONFIG_SND_HDA_INPUT_JACK is not defined.

Good catch.  I'll fix that.


thanks,

Takashi