Spurious headphone detection interrupts

[KC9UDX]

The more I think about it, the more I think about that jack. I'd be inclined to disconnect it and see if the problem goes away.

[dsimic]

I tend to agree.  As a note, please see the edit I've made to my previous reply a few minutes ago...  I'll try inserting and removing the headphones a few times, as it could really be up to the headphones jack being practically unused on my PineBook Pro.  Who knows what could've happened to the jack during the PCB soldering.

[KC9UDX]

The more I think about it, the more I think about that jack. I'd be inclined to disconnect it and see if the problem goes away.

But then I look at the schematic, and the headphone jack is not of a conventional design with a switch. It uses the plug ring as a switch, at least according to the schematic. The reference voltage comes from a GPIO output on the codec. I don't really understand why, and I don't know what controls the codec. If for some reason the GPIO on the codec turns off, or becomes an input, "insertion" will be detected.

Now that I know how it works, I'm pretty sure the headphone jack can't be at fault unless there is debris or something like tin whiskers in it.

---

My edit didn't work as expected!

---

Here's a strange thought, too. You shouldn't get audio out of the speakers if that count is an odd number. So whilst it's at 33, maybe play something and see if that comes out the speakers.

[dsimic]

My understanding is that the RK3399's GPIO0_B0 line receives the interrupt as generated by the headphones jack, but the schematics doesn't seem to provide the actual details how (what goes beyond CN3, the daughterboard, doesn't seem to be documented).

The same connection to the headphones jack that generates the interrupt to the SoC also goes to the GPIO1 line of the ES8316 audio codec, to inform it too, which seems to be required in the ES8316 datasheet.

Edit: Music playback through the internal speakers works fine, despite having 33 as the current interrupt count, which is weird. Furthermore, after inserting the headphones, the count went to 34, with the headphones working as expected and muted speakers.  After unplugging the headphones, the count went to 36 (not 35), which is even more weird, but the speakers work as expected.

Edit #2: After inserting the headphones again, the interrupt count went to 37.  After unplugging the headphones, it went to 40.   Anyway, the music playback works as expected, which should be up to the Linux kernel driver reconfiguring the audio routing according to the actual RK3399 GPIO line state, instead of according to the related interrupt count.

[KC9UDX]

I thought one of them would have to be an output. Else I don't see where the reference voltage comes from. Since the codec is on the other side of a 10k (pull-up?) resistor, I figure that must be it. You could find out by plugging in a headphone plug and seeing if there's still a logical "high" at the codec.

If the codec GPIO is actually an input, then switching by the SOC interrupt seems redundant at best, a conflict at worst.

The whole thing doesn't make sense to me, I just don't see why the GPIO on the codec is necessary for this function.

---

I'm having a hard time reading the schematic on my phone (only option I have at the moment, and usually). But there is a separate schematic file that shows the jack.

[dsimic]

Please see my second edit above.

Also, I'd say that the GPIO1 line on the audio codec serves solely to inform the codec of the headphones insertion.  Why does the codec need that, I can't say because it isn't documented.

Edit: Thank you for pointing it out, now I see the daughterboard schematic.  Let me check it out.

Edit #2: I could be wrong, but aren't the left and right audio channel switched at the daughterboard schematic?  Shouldn't the tip be the left channel, and shouldn't the first ring be the right channel?  To make matters worse, I've tried playing some left/right channel sample music, which can be heard as expected using the built-in speakers, but when the headphones are connected...  I hear both channels in both earpieces, i.e., there's seems to be no separation between the channels.

Edit #3: I really don't seem to understand how the headphones detection, the jack part, actually works?  When no headphones are connected, HP_DET_H seems to be connected to HPO_L through a single resistor, R16 (1K, the other couple of resistors are 0R or NC), while HP_DET_H is not pulled low by R234, because it's marked as NC.

[KC9UDX]

Are you sure the codec GPIO isn't an output?

It's too late in my day for me to recall which channel is which on a TRRS jack, but you're probably right.

J2 is drawn funny. Are 4&6 and 5&3 shorted?? If so, how can the left channel work at all? If not, something is missing to make insertion detection work.

I *thought* that I verified that mine has discreet left and right channels at that jack. But it's been a while so I may be wrong.

If 4 and 6 are actually a switch, then we're back to a conventional design, the codec GPIO doesn't necessarily have to be an output, and L and R can be separate. But then how can insertion detection be a logic level??

[dsimic]

Please, have a look at my third edit above...

I agree that J2, the audio jack, looks funny.  According to the way J2 is depicted, its pins 3 & 5 and 4 & 6 should be shorted when no headphones are connected.  How should it be possible for the left channel to work as expected, or at all, is beyond my comprehension.

Furthermore, the audio codec actually receives nothing on its GPIO1 line...  The R233 resistor is marked as NC, as well as R234, which somehow slipped by in the earlier analysis.   I'd say that the Pine64 engineers probably originally followed the ES8316 reference design that requires GPIO1 to be the headphones "flag", but the thing refused to work as expected so R233 became NC, which actually makes more sense.

Edit: Corrected the J2 pin numbers above.

[KC9UDX]

If 4&6 and 5&3 do work that way (I agree they should) then
1) the schematic is drawn wrong,
2) your problem might be debris or oxidation preventing good contact between 4&6*
3) I don't see how detection works without imposing DC on the left channel which seems like a bad idea
*Unless there *isn't* DC on the left channel, in which case I'll blame whatever other means they somehow use for detection.

Good thinking on everything in your last paragraph.

[dsimic]

It could be easily that the PineBook Pro schematic we have available actually isn't the latest revision.  For example, the schematic available for RockPro64 is obviously outdated, so it could be the same for the PineBook Pro.

Could it be that the headphones detection works because the RK3399's GPIO line is tolerable when it receives all kinds of weirdness, instead of a clear logic level?  The audio signal shorted from HPO_L to HP_DET_H should be somewhat filtered by the C9 on the daughterboard (but that would also negatively affect the left audio channel), which might help in removing some of the weirdness that the RK3399's GPIO line receives?  But, how would all that "work" when there's no audio playback at all?

Furthermore, the above-presented excuse for the bad design might be confirmed by experiencing more than a single interrupt generated upon unplugging the headphones...  During the disconnection/unplugging, the left channel signal no longer has the path through the left earpiece or the left built-in speaker, so all of it tries to go through the RK3399's GPIO line, and the bumps on the headphone plug recreate or reinforce that scenario a few times during the disconnection of headphones.

However, I'd agree that my above-presented sorry excuse for the bad design is rather absurd and highly debatable.  Though, here's something that might actually support it: if there's no music playback, I see only one headphones detection interrupt upon the unplugging of the headphones.  If there is music playback, the unplugging always generates a few interrupts.  I've checked it and confirmed a few times.  Even if it doesn't support the sorry excuse, this behavior is really strange.