[Letux-kernel] twl gpios / headset detect on gta04a5

H. Nikolaus Schaller hns at goldelico.com
Sun Sep 23 21:23:50 CEST 2018


> Am 23.09.2018 um 20:28 schrieb Andreas Kemnade <andreas at kemnade.info <mailto:andreas at kemnade.info>>:
> On Sun, 23 Sep 2018 19:59:39 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com <mailto:hns at goldelico.com>> wrote:
>>> Am 23.09.2018 um 19:41 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> On Sun, 23 Sep 2018 19:32:34 +0200
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>>> Hi,
>>>>> Am 23.09.2018 um 18:51 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>>>> Hi,
>>>>> I am looking at the headset stuff.
>>>>> The detection is at gpio492 on gta04a5 if I
>>>>> understand everything right.
>>>>> I exported that and no reaction there on plugging
>>>>> And then I am wondering:
>>>>> root at gta04:/sys/class/gpio/gpio492# twl-i2c.sh GPIO r 0x13
>>>>> 0x00
>>>>> # twl-i2c.sh GPIO r 0x14
>>>>> 0x00
>>>>> No pullups/downs enabled?!
>>>>> Hmm, floating inputs there?!
>>>>> twl-i2c.sh GPIO w 0x13 0x20
>>>>> does the trick. the exported gpio shows values.  
>>>> Good finding!
>>>>> But are the pullup/down
>>>>> values correct there?  
>>>> According to schematics:
>>>> 	http://projects.goldelico.com/p/gta04-main/downloads/48/
>>>> there is a 10k from the gpio to the switch and a 10k pull-down.
>>>> So there should be a pull-up for the gpio to provide energy.  
>>> Well, that is one thing. I enabled the pullup using:
>>> twl-i2c.sh GPIO w 0x13 0x20
>>> More interesting are the *other* twl gpio pins. Floating stuff
>>> might be there. And therefore unecessary suspend currents.
>>>> Then,
>>>> - if the headset is connected, the switch is open and the gpio should read "1"
>>>> - while a disconnected headset should connect the gpio to gnd through 20k which should be (note, this circuit has never been tested!) read as "0".
>>> That is wrong. It is tested be my now.  
>> Wrong or not working?
> It it wrong that it hase never been tested. Value is 0 when headset is
> disconnected, 1 when it is connected,

Yes, as I described above.

> and when there is loud sound and headset is enabled but not connected,
> there are sometimes 1 in between.

That should not be the case, but is unavoidable. Well, it should not be
possible to have that situation. If jack detection works, it should shut
down the audio driver if headset is disconnected...

> So the contact seems to an opener.

Yes, that is correct.

Switch is closed with nothing connected. This should pull down the gpio2 to 0 through R716+R717.

Unless audio driver sends signals into the LEFT (white) pin. This goes through R716 to the gpio
and then R716 protects the gpio from being damaged.

Switch opens if a headset is plugged in. And the then disconnected end of the switch is connected
through R716 only to gpio2. So it should also be electrically disconnected from any audio signals.

So far the theory behind this circuit :)

> we are failing here:
> sound/soc/soc-jack.c:
>                ret = request_any_context_irq(gpiod_to_irq(gpios[i].desc),
>                                              gpio_handler,
>                                              IRQF_TRIGGER_RISING |
>                                              IRQF_TRIGGER_FALLING,
>                                              gpios[i].name,
>                                              &gpios[i]);
> Maybe irq does not work for twl gpio.

It should...
AFAIR, there are card-detect gpios (which we do not use in GTA04) but other OMAP3 devices use them.
But I don't know if they are edge triggered?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180923/09866537/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 145088 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180923/09866537/attachment-0001.tiff>

More information about the Letux-kernel mailing list