At Tue, 6 Oct 2009 14:17:40 +0200, Harald Welte wrote: > > Hi all, > > On Tue, Oct 06, 2009 at 08:01:40AM +0200, Takashi Iwai wrote: > > > > As you describe, we implement it with self-reschedule workqueue, acting > > > like a timer. > > > Is there some advice to implement timer-like task, I tested with timer and > > > it will crash the driver. > > > > Right, you can't call it in a softirq. > > > > A few problems, however: > > - present variable should be in struct via_spec, instead of a static > > variable in update_hp_jack_state(). > > I agree > > - This mechanism is unconditionally invoked on VT1708 although, in > > theory, you can have a hardware that doesn't need HP jack detection > > Yes, Logan/Li/Lydia: If we generate this kind of workaround with a timer, > it should only be used on those particular chips that absolutely need it. As far as I see, the code is only for VT1708, so it's already specific to the codec chip. But, even with this chip, you might have a pin configuration that doesn't need the HP jack detection. > > - Waking up each 100ms for the *whole* time is really bad regarding > > the power-saving; can't it be optimized? > > I would personally actually suggest to simply not support headphone plug events > in case you are using such a [buggy?] chipset that does not support them. > > I mean, what do you gain from that event? It's not something super-important. > > waking up unconditionally every 100ms is really a too high burden on the > battery life. > > Another option might be to make it a module load time parameter, so people > can choose if they actually want to pay the high power/batyery price for this > small feature. Yes. Basically, if we can drop the analog-loopback feature, the HP jack probing can be simplified very much. The probing is needed only when the PCM is opened/prepared and running. It can be implemented in a similar way for the volume-update procedure at PCM trigger. And, during PCM running, (relatively) high-frequent polling isn't so critical. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel