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@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 unsol event.)
That said, it's not very important to me personally which kernel this goes into.
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 breakage.
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.