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

David Henningsson david.henningsson at canonical.com
Tue Sep 16 10:33:30 CEST 2014



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.

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.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jack.diff
Type: text/x-patch
Size: 3954 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140916/32e77be0/attachment-0001.bin>


More information about the Alsa-devel mailing list