02-10-2021, 02:56 AM
My apologies for the delayed response.
Actually, I've been thinking about using an oscilloscope to have a look at the audio output signal, which should clearly show if there's DC bias, but I haven't managed to do that (yet). Maybe I'll get around to that one day, but your explanation shows that checking that actually shouldn't be needed. Thank you very much for pointing out the pull-up configuration, and I'll reiterate below, with further insights.
Indeed, according to the DTS file for PineBook Pro, an internal pull-up resistor is configured on the GPIO line that's used for the headphones detection. Also, the audio codec configuration uses the logical high level of the GPIO line to indicate the presence of headphones, which additionally confirms the use of the pull-up configuration.
Software support for the debouncing of GPIO lines already exists, and it is already in use for the headphones detection. It might be worth playing with the debouncing configuration, but the actual "debounce_time" value is hardcoded to 150 in the Linux kernel driver, which means that improvements to the driver source code would be required to make the value configurable in the DTS file. Doable, if helpful, but not exactly a one-liner.
The pull-up configuration clearly covers the case when the headphones are plugged in, in which case the HP_DET_H GPIO line isn't connected to anything but the 100 nF capacitor on the daughterboard, which is connected to the ground, but that makes no difference in this case. For the plugged-in headphones, there's a clear logical high level. However, the issue of debouncing remains, as already decribed above,
With no headphones connected, the HP_DET_H GPIO line gets connected to the HPO_L audio output, in addition to the above-mentioned connection to the ground through the 100 nF capacitor. In this case, the capacitor might "smooth out" a bit what gets to the GPIO line, but may also adversely affect the audio quality of the left channel. However, the GPIO line gets pretty much the same "junk" (from the standpoint of the logic level) that goes to the left audio channel.
However, the "junk" coming from the HPO_L audio output should be low enough, more precisely below 0.8 V, to cause a logical low level on the GPIO line when there are no headphones plugged in. Which it actually does, but the issue of spurious interrupts remains. As described in the original post, I see spurious headphones detection interrupts generated with no headphones plugged in, and with no actual insertion or removal of the headphones. No amount of debouncing can help there, and it clearly shows that the audio "junk" or something else present on the audio channel isn't stable or clear enough to be fed to the GPIO line,
I know, in the end it kinda works most of the time, but why compromising on something that could be rectified by a slightly different headhones socket? I highly doubt that using a different socket would add more than $0.10 to the BOM, which would be negligible.
By the way, why would we want a built-in RS232-to-USB bridge chip to use it as the console serial port? It's much better to use the RK3399's already existing native serial port as the system console, as it doesn't mandate the initialization of the USB subsystem for the console to become operational, requires no additional active components on the PCB, doesn't waste what's already existing, etc. Quite frankly, the best option would be to have the native serial port made available through an additional jack, instead of having it sharing the headphones jack.
Actually, I've been thinking about using an oscilloscope to have a look at the audio output signal, which should clearly show if there's DC bias, but I haven't managed to do that (yet). Maybe I'll get around to that one day, but your explanation shows that checking that actually shouldn't be needed. Thank you very much for pointing out the pull-up configuration, and I'll reiterate below, with further insights.
Indeed, according to the DTS file for PineBook Pro, an internal pull-up resistor is configured on the GPIO line that's used for the headphones detection. Also, the audio codec configuration uses the logical high level of the GPIO line to indicate the presence of headphones, which additionally confirms the use of the pull-up configuration.
Software support for the debouncing of GPIO lines already exists, and it is already in use for the headphones detection. It might be worth playing with the debouncing configuration, but the actual "debounce_time" value is hardcoded to 150 in the Linux kernel driver, which means that improvements to the driver source code would be required to make the value configurable in the DTS file. Doable, if helpful, but not exactly a one-liner.
The pull-up configuration clearly covers the case when the headphones are plugged in, in which case the HP_DET_H GPIO line isn't connected to anything but the 100 nF capacitor on the daughterboard, which is connected to the ground, but that makes no difference in this case. For the plugged-in headphones, there's a clear logical high level. However, the issue of debouncing remains, as already decribed above,
With no headphones connected, the HP_DET_H GPIO line gets connected to the HPO_L audio output, in addition to the above-mentioned connection to the ground through the 100 nF capacitor. In this case, the capacitor might "smooth out" a bit what gets to the GPIO line, but may also adversely affect the audio quality of the left channel. However, the GPIO line gets pretty much the same "junk" (from the standpoint of the logic level) that goes to the left audio channel.
However, the "junk" coming from the HPO_L audio output should be low enough, more precisely below 0.8 V, to cause a logical low level on the GPIO line when there are no headphones plugged in. Which it actually does, but the issue of spurious interrupts remains. As described in the original post, I see spurious headphones detection interrupts generated with no headphones plugged in, and with no actual insertion or removal of the headphones. No amount of debouncing can help there, and it clearly shows that the audio "junk" or something else present on the audio channel isn't stable or clear enough to be fed to the GPIO line,
I know, in the end it kinda works most of the time, but why compromising on something that could be rectified by a slightly different headhones socket? I highly doubt that using a different socket would add more than $0.10 to the BOM, which would be negligible.
By the way, why would we want a built-in RS232-to-USB bridge chip to use it as the console serial port? It's much better to use the RK3399's already existing native serial port as the system console, as it doesn't mandate the initialization of the USB subsystem for the console to become operational, requires no additional active components on the PCB, doesn't waste what's already existing, etc. Quite frankly, the best option would be to have the native serial port made available through an additional jack, instead of having it sharing the headphones jack.