Fixing audio after deep sleep: Work Thread

[Syonyk]

One of my major annoyances with the PBP right now is that sound doesn't work after deep sleep.

I'm using Ubuntu 20.04, the 5.7 kernel from Manjaro/tsys with the hwaccel patches, and the BSP uboot (as the mainline uboot/ATF don't support deep sleep yet, and I consider this an important feature).  If you're following along, you're on your own if you're doing something different.

Coming out of deep sleep, the system simply doesn't have sound.  If you run the proper incantations, and things aren't using the sound devices, you can, with a bit of fiddling, get sound working again.

Experimentally, playing with modules, I traced the issue down to module snd_soc_es8316 - coded up here: https://gitlab.manjaro.org/tsys/linux-pi...s/es8316.c

Compare this with, say, the es8328 file: https://gitlab.manjaro.org/tsys/linux-pi...s/es8328.c

You'll notice, if you look in the ops struct, that there's a suspend and resume function in the 8328 codec - but NOT in the 8316 codec!

My theory is that the reason there's no sound after deep sleep is because the 8316 driver simply doesn't know how to properly reset the codec after sleep.  When the module is re-inserted, the device is re-initialized, which is why sound comes back - but there's no need to do this, if the module can simply perform the proper actions on resume.  Right?

Let's implement that set of functions and try it out!

---

Hm. Copying the probe code into the resume handler doesn't appear to have worked. Time to go deeper.

[Syonyk]

I found the actual guide to registers and such for the es8316 (vs just the datasheet).  Attached.

---

There is also this thread: https://forum.pine64.org/showthread.php?tid=10268

It has the unbind/bind command that seems to re-initialize the driver without re-inserting modules, though it is apparently somewhat at risk of a kernel panic if sound is playing.

Code:

$ sudo tee /sys/bus/i2c/drivers/es8316/{un,}bind <<< 1-0011

This should be useful to trace flow through as well.

[Syonyk]

Well, some progress!

I added a function to dump the config registers out - and after resume, they're (not surprisingly) nonsense compared to what they started as after initialized and working.

I decided to just save all the config registers (0x50 of them) on suspend, and restore them on resume. Calling the _probe function again didn't work - I tried that as well. Even though unbind/rebind calls that, it calls a bunch of other stuff too, and I don't think fully re-initializing the sound system is the right answer.

The unbind/rebind, as noted in the other thread, reliably kernel panics the system if done while sound is playing, so that's not a great option.

Restoring the config registers, I have sound after resume, with the caveat that if sound is playing (say, in a browser tab), it doesn't work after resume - but if I close that tab, or reload it, I then have sound again. It seems like if a process is doing something with sound, that something sticks until it lets go, then things can reset - but I don't have do anything other than close/reload the tab. Chrome is somewhat worse and seems to require the browser to be killed before sound will re-init for some reason - but only if you're actively playing sound. Otherwise, it seems to work halfway sanely.

Given all this, I'm going to contact the authors of the es8316.c file and see if they've got any insights into the proper sequence for restoring the card. I don't think I need to save/restore all the registers, but I'm uncertain as to what else would work. Unless anyone happens to have some insight into this card...