On Wed, Apr 27, 2022 at 08:12:56AM -0500, Adam Ford wrote:
On Tue, Apr 26, 2022 at 12:41 PM Charles Keepax ckeepax@opensource.cirrus.com wrote:
On Tue, Apr 26, 2022 at 11:36:26AM -0500, Adam Ford wrote:
I have an imx8m Mini with a wm8962 codec. If I run a speaker test and suspend the board while the speaker test is running, I get the following upon wake:
wm8962 3-001a: ASoC: error at soc_component_read_no_lock on wm8962.3-001a: -16
This message repeats itself over and over again. If I attempt to use any audio, it fails until I reboot the board.
If I run the audio test, then exit and suspend, the audio works upon resume, so it appears to be related to suspending while running.
I am hoping someone might have a suggestion as to what I might be able to do or try to allow this to successfully suspend and resume if the device is playing sound.
Hmm... EBUSY is what regmap returns when a volatile register is read whilst the chip is still in cache only. The driver does appear to be missing the usually fairly important work around to avoid the IRQ and the PM runtime deadlocking on resume. Although not sure that would actually lead to the error message you are seeing.
Would be really handy to see a little more of the log leading up to the failure if that is possible? And would be really awesome if you had any idea which read was returning the error? You could shove a dump_stack in _soc_component_ret next to the error message.
Because NXP had a downstream kernel, and it didn't appear to happen when using their downstream kernel, I wanted to see the difference. I found this:
static const struct dev_pm_ops wm8962_pm = {
- SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(wm8962_runtime_suspend, wm8962_runtime_resume, NULL) };
I applied this, and it appears to make the issue go away on a 5.15 kernel. I haven't tried it on a 5.18 yet. If this fixes the issue, would that be an acceptable solution to push upstream?
Feels like those operations should be runtime PM, like there is no reason to keep the CODEC in a high power state than necessary.
Let me add the necessary stuff to at least avoid the race with the IRQ and lets see if that has any effect, although I am not totally convinced your symptoms sound like that is the issue. But it is fixing an issue regardless so might as well start there. Any of the debug I requested previously would also be handy though.
Thanks, Charles