From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Henningsson <david.henningsson@canonical.com>
Subject: Re: [RFC PATCH] HDA: Generic input jack handling
Date: Tue, 18 Oct 2011 15:13:15 +0200
Message-ID: <4E9D7B6B.9020600@canonical.com>
References: <4E8EE75A.3050809@canonical.com> <s5hfwj50zsq.wl%tiwai@suse.de>
	<4E8EF48F.4000707@canonical.com> <s5hbott0x8n.wl%tiwai@suse.de>
	<4E8F16AA.7000104@canonical.com> <s5hsjn4zut2.wl%tiwai@suse.de>
	<4E8F2315.5070309@canonical.com> <s5hpqi8t0tv.wl%tiwai@suse.de>
	<4E915DA1.5040405@canonical.com> <s5hhb3itpzx.wl%tiwai@suse.de>
	<4E9181F8.9050405@canonical.com> <s5hsjmxz950.wl%tiwai@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
Received: from youngberry.canonical.com (youngberry.canonical.com
	[91.189.89.112])
	by alsa0.perex.cz (Postfix) with ESMTP id DBB3C103900
	for <alsa-devel@alsa-project.org>;
	Tue, 18 Oct 2011 15:13:15 +0200 (CEST)
In-Reply-To: <s5hsjmxz950.wl%tiwai@suse.de>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Sender: alsa-devel-bounces@alsa-project.org
Errors-To: alsa-devel-bounces@alsa-project.org
To: Takashi Iwai <tiwai@suse.de>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>
List-Id: alsa-devel@alsa-project.org

On 10/13/2011 08:40 AM, Takashi Iwai wrote:
>> Thanks for the explanation and for your thoughts about what you think
>> could lie ahead. What would you think about the following instead:
>>
>> struct detectable_jack {
>> 	hda_nid_t nid;
>> 	int jack_type; /* SND_JACK_xxx */
>> };
>>
>> #define MAX_DETECTABLE_JACKS 16
>>
>> struct auto_pin_cfg {
>> 	/* ... */
>> 	struct detectable_jack detectable_jacks[MAX_DETECTABLE_JACKS];
>> };
>>
>> We will let snd_hda_parse_pin_def_config fill this in as well, and the
>> unsol_tag will be index to this array. Tags over MAX_DETECTABLE_JACKS
>> can be used by codec specific stuff, e g sigmatel's power events.
>
> Hmm... This sounds trickier.  Can't it be simply a list of nid,
> event_type and jack_type?  Or just add jack_type to the event struct
> in patch_sigmatel.c.
>
> When we track all unsol events in the table, the hardware
> initialization can be simplified.  Create a function to call
> SET_UNSOL_ENABLE verb for the all entries, and call it from the
> codec_patch init callback.

Just for the record - I think we can to talk about this next week to see 
if we can merge our thoughts and come to a conclusion we're both happy with.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic