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.
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.