On Wed, Sep 23, 2015 at 6:37 PM, Mark Brown broonie@kernel.org wrote:
That can upset userspaces - it means you get things like trying to play a notification tone, starting, realising that a headphone is there and trying to switch on the headphone in the middle of the notification being played back which doesn't tend to work out so well.
What I'd expect the driver to be doing here is enabling whatever it needs to do detection enabled while detection is enabled.
What I don't get here is what do you mean with "detection". Can we simply consider PA listening for jack change events a "detection"?
There's quite a few examples of this in mainline - look for jack code that has DAPM calls in it.
Do you thing the rt5670.c could be a good example for that?
In that case a GPIO is used to trigger the jack type detection. The jack change interrupt is notified also when the codec is off/inactive and in the codec the status of the jack (jack_inserted) is detected directly reading from some codec registers. The DAPM calls are used in the code path to determine the type of the jack.
In my case the setup is different though. The GPIO is driven by the codec itself and it doesn't work when the codec BIAS is off. So the problem is that I cannot use the DAPM code since before that I need to find a way to detect the change in the GPIO status when I'm not actively using the codec.
I see two possible solutions for this problem: 1) as said before I can just avoid to turn the BIAS totally off, leaving the I2S clock active that allows the codec to drive the GPIO or 2) keep polling on the status of the GPIO enabling and then disabling the BIAS (or using the DAPM code) just for the time needed to read the GPIO status
Thanks,