Re: WM8962 crashing on suspend

[Adam Ford <aford173@gmail.com>]

On Thu, Apr 28, 2022 at 3:23 AM Charles Keepax
<ckeepax@opensource.cirrus.com> wrote:
>
> On Wed, Apr 27, 2022 at 11:54:40AM -0500, Adam Ford wrote:
> > On Wed, Apr 27, 2022 at 11:48 AM Charles Keepax
> > <ckeepax@opensource.cirrus.com> wrote:
> > > On Wed, Apr 27, 2022 at 04:24:31PM +0100, Mark Brown wrote:
> > > > On Wed, Apr 27, 2022 at 02:57:30PM +0000, Charles Keepax wrote:
> > > > > On Wed, Apr 27, 2022 at 08:12:56AM -0500, Adam Ford wrote:
> > > > > > 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.
> > > >
> > > > The issue Adam reported was suspending during playback - if you suspend
> > > > during playback or capture the device is not idle at the point where we
> > > > start trying to suspend so it shouldn't be in runtime suspend and won't
> > > > by default be runtime suspended by the PM core.
> > >
> > > Yeah in my head snd_soc_suspend would have been called which
> > > would (assuming the DAI doesn't have ignore_suspend set) shut
> > > down the DAPM graph for the audio route, causing the runtime
> > > references to all be released and the CODEC to be suspended
> > > through runtime_pm. Not sure if I missed something there, and
> > > that also allows for systems where the CODEC doesn't suspend
> > > during system suspend. That said guess there probably arn't
> > > any use-cases for that on wm8962 and I am more than happy to
> > > use the force_suspend ops if you are happy with it.
> >
> > I am not familiar with this driver or the force_suspend ops, so I am
> > not sure if there are going to be side-effects.
> > I don't mind collecting more data if it's helpful.  I probably won't
> > be able to add more debug info until this weekend at the earliest.
> >
>
> Nah, its good your ok to upstream your out of tree patch, just
> making sure I fill in the holes in my knowledge with Mark :-)

I'd like to push the patch with a Fixes tag, but I am not sure that we
have a definitive hash to use.  Ideally, it'd get backported, but I am
not sure that I have the means to test it, because the hardware
platform I have doesn't go back that far.  Any thoughts? If not, I'll
just push it without a fixes tag.

adam
>
> Thanks,
> Charles