At Tue, 6 Oct 2009 23:27:35 +0800, Li Bo wrote: > > On Tue, Oct 6, 2009 at 8:38 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > 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. > > > > Yes, it's only for VT1708, and HP exists on most cases, and so HP jack detection > are needed. > And present will put into via_spec. If it's restricted only during the opened (better running) PCM stream, it's not too bad. But, it'd be even better to check the availability of HP jack. > >> > - 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 > > > > I know that jack detect on VT1708 that do not support unsolicited > response is weird, but > it's for customer request (and so are some other patches:), we just > have to do something. > > I think it's good in open/close callback, I'll update. > > About self-reschedule workqueue, maybe there are some other choices, > or should we keep > using it? A delayed workqueue is OK. But, it should check some flag before rescheduling itself. Also, don't forget about suspend/resume. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
