[alsa-devel] [PATCH 14/31] HDA patch_via.c: Add Jack detect feature for VT1708.

Takashi Iwai tiwai at suse.de
Tue Oct 6 14:38:12 CEST 2009

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.


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



More information about the Alsa-devel mailing list