[alsa-devel] RT5640 jack detection

[Mark Brown]

On Thu, Sep 24, 2015 at 10:34:14PM +0200, Carlo Caione wrote:
> 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"?

Detection is the act of detecting if a jack is physically present in the
socket.  This will normally happen all the time the system is running,
some userspaces rely on uevents to get notifications so the kernel can't
tell if anything is listening.

> > 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?

No, that doesn't appear to have any interlock with DAPM and is just
basic GPIO stuff.

> 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.

To repeat:

| What I'd expect the driver to be doing here is enabling whatever it
| needs to do detection enabled while detection is enabled.  There's quite
| a few examples of this in mainline - look for jack code that has DAPM
| calls in it.

If you need to force things on during detection you should add code to
do that, for example enabling relevant DAPM widgets with _force_enable().

> 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

Enabling things only when needed is of course optimal but you need
detection to work whenever detection is enabled.  It sounds like this is
not the case for your system.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150924/9754b725/attachment.sig>