[alsa-devel] [RFC PATCH] ALSA: hda - Implement a poll loop for jacks as a module parameter
david.henningsson at canonical.com
Tue Oct 9 16:28:07 CEST 2012
On 10/09/2012 03:32 PM, Takashi Iwai wrote:
> At Tue, 9 Oct 2012 15:19:44 +0200,
> David Henningsson wrote:
>> Now that we have a generic unsol mechanism, we can implement a generic
>> poll loop, which can be used for debugging, or if a codec's unsol
>> mechanism is broken.
Oh, and I was also considering not turning on unsol at all (in
snd_hda_jack_detect_enable) when this is enabled. Then it would help
against "unstable" pins which trigger repeatedly on/off even though
nothing is happening physically.
>> Signed-off-by: David Henningsson <david.henningsson at canonical.com>
> The patch almost looks good, but I postpone as a 3.8 thing.
Ok. I never understood the release timings, but I figured anything
before rc1 would be okay to merge as a feature... (And I couldn't start
a week earlier; because I didn't know if you would accept the generic
That said, it's not very important to me personally which kernel this
>> I'm also considering activating it by default if we go into single_cmd mode
>> due to codec not responding. What do you think?
> Well, I don't buy it. Falling back to single_cmd doesn't mean that we
> are saving the world perfectly.I recently even think it might be
> even better not to do that, otherwise people won't notice the
This is almost philosophical, but if a bug occurs and no user notices,
is it really a bug? :-)
Or, to make it a bit more pragmatic, what other things are broken with
single_cmd? Could you give an example where this change would be harmful?
>> + codec->jackpoll_interval =
>> + msecs_to_jiffies(jackpoll_ms[chip->dev_index]);
> Better to add a sanity check of the interval value.
Ok. Attaching modified patch.
David Henningsson, Canonical Ltd.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7973 bytes
Desc: not available
More information about the Alsa-devel