Having the es8316-sound node enabled causes bad serial output from kernel. Disabling fixes issue.
I could not, myself, figure out why this was happening, but someone in the armbian forums had also discovered this and the fix. Speaker output was fine, even with the serial switch thrown and the cable inserted, but I never reached the login-prompt without getting "gobbledygook" on the serial console.
Activity
No, of course not. I wasn't trying to suggest that the node gets permanently disabled. But people were told not to expect sound when using the uart.
From the Pine64 WIKI: "With the UART switch in the ON position, console is relayed via the audiojack and the laptop's sound is turned OFF."
With the Manjaro build, even with the cable plugged in, I still was getting sound through the speakers. I did not try with headphones. Turning output volume down to 0 does not solve the "gobblediegook" problem, only disabling the node in the dts does, for me. It seems that if there is a way programmatically to know the uart switch position, one could enable or disable the node. I'm sorry, I don't know enough to make a suggestion. The schematics are available on the wiki , if that helps.
I am happy to test any possible solutions.
Yes. Sorry if I was not clear. If the physical switch on the bottom of the device was set to the "enable uart" position, I was was getting garbage when the kernel was running..normally before login prompt. I was still getting sound from the speakers. Disabling the sound device in the dts fixed the garbage problem. I,m wondering if there is a better way to handle this. I think there must be some kind of leakage with the circuit that causes interference. I was wondering whether using a dynamic device tree overlay might make it easier to enable/disable or whether there is some better way to handle this.
as the guy who disabled es83xx first for this DT.. There must be a solution for that, armbian images based on ayufans 4.4 rockchip bsp kernel don't bloat UART when the switch is on UART output but I didn't had time yet to dive into this. We currently have issues to get the display working on mainline and I don't really understand why so sound and how to deal with it is of minor priority than having a working display. @tsys from the mailing list I saw that your DT will likely make it into mainline soon, do you plan to send a u-boot DT also upstream once the kernel DT has landed?
I just found this in ayufan's repo
// disable stdout-path as it causes instability due // to sound card power leak //stdout-path = "serial2:1500000n8";Does this help?
Well, disabling the serial will break the serial and disabling the sound will break the sound. The only option that might be acceptable here is to disable the serial by default and provide a device tree overlay to enable it.
I don't like that solution though. Do you really have issues with serial reliability? I do get strange results when I leave RX floating. But as soon as I connect a low impedance connections to any serial device the issues are gone. Since most serial outputs are by now CMOS that will only happen when using very long wires, series resistors or dodgy grounds.
Would you mind checking that again?
Edited by Tobias SchrammI just checked again (I have all of the latest updates installed). I i use the dtb that comes with the installation, I still have the problem. On the other hand, if I use a dtb that I generated a while ago, playing with the sound stuff a little, I don't have the problem. This is a diff showing my changes--(and of course your more recent sleep change). I picked them up from either Ayufan or Mrfixit dtb... Easrlier on, the mic wasn't working, but it now is fine with your dtb and I don't know what could have changed (sound, power, who nows, so that it now works). So it seems like perhaps the system clock specification is what "fixed" the problem? I wonder if this is hardware dependent in that there seems to be a bit of slippage in the quality control of the build on some of these, so that one has a greater or lesser chance of interference. Let me know if there is anything I can test for you.
--- 5.5.rk3399-pinebook-pro.dts 2020-02-05 11:06:24.354098350 -0500 +++ my.v5.5-rc7-panfrost-fixes.rk3399-pinebook-pro.dts 2020-02-05 10:58:51.545953609 -0500 @@ -39,7 +39,7 @@ }; chosen { - bootargs = "earlycon=uart8250,mmio32,0xff1a0000 mem_sleep_default=s2idle"; + bootargs = "earlycon=uart8250,mmio32,0xff1a0000"; stdout-path = "serial2:1500000n8"; }; @@ -197,10 +197,12 @@ simple-audio-card,cpu { sound-dai = <&i2s1>; + system-clock-frequency = <12288000>; }; simple-audio-card,codec { sound-dai = <&es8316>; + system-clock-frequency = <12288000>; }; }; @@ -838,7 +840,7 @@ status = "okay"; bt656-supply = <&vcc1v8_dvp>; - audio-supply = <&vcca1v8_codec>; + audio-supply = <&vcca3v0_codec>; sdmmc-supply = <&vcc_sdio>; gpio1830-supply = <&vcc_3v0>; };Edited by Tobias SchrammHm, I've tested again yesterday and it seems that data transmitted from the PB does indeed get corrupted even with a proper setup. I'not convinced it is interference though. Enabling the i2s peripheral seems to mess with a clock domain in the rk3399. From time to time the serial has a baudrate of 1389000 instead of 1500000 when enabling sound. I'll do some debugging with logic analyzer + scope to figure out what exactly we are dealing with here.
Looks like corruption during playback is actually a signal integrity issue. It is a very weird one though. Somehow the effective signal rise time goes up to three times its nominal value during playback. Almost like the drive strength of the corresponding pins is turned down to next to nothing.
Without audio playback
With audio playback
Edited by Tobias Schrammsound card specs I linked the sound card specs from the vendor , in case that helps you. I can't exactly tell what the default system clock being used for the card is, but it seems that changing the frequency helped--I just can't tell if I was lowering the frequency or raising the frequency from the default
Default from specs: 256/384Fs and USB 12/24 MHz system clock.
Sorry I can't be of more help--I am not much of an electronics/hardware person.
I've checked and upping the drive strength from 3 mA to 12 mA resolves the issue. I'll probably add that to the device tree.
3 mA drive strength
12 mA drive strength
Edited by Tobias SchrammNVM, the fix is much more simple. The io domain power supplies were not correct. Fixed through 74616c1b. Please close if this fixes the issue for you.
mentioned in commit 5a067711
