On Tue, Apr 26, 2022 at 12:41 PM Charles Keepax
<ckeepax@xxxxxxxxxxxxxxxxxxxxx> 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?
adam
>
> Thanks,
> Charles
