[alsa-devel] RT5640 jack detection
Carlo Caione
carlo at endlessm.com
Thu Sep 24 22:34:14 CEST 2015
On Wed, Sep 23, 2015 at 6:37 PM, Mark Brown <broonie at 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,
--
Carlo Caione | +39.340.80.30.096 | Endless
More information about the Alsa-devel
mailing list