On Tue, Oct 6, 2009 at 8:38 PM, Takashi Iwai tiwai@suse.de 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.
- 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?