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@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?
>
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
