06-29-2020, 10:21 PM
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...
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...