Re: clk_imx8mp_audiomix_runtime_resume Kernel panic regression on v6.12

[Francesco Dolcini <francesco@dolcini.it>]

Hello Shengjiu,

On Tue, Nov 19, 2024 at 05:35:36PM +0800, Shengjiu Wang wrote:
> On Fri, Nov 15, 2024 at 10:47 PM Francesco Dolcini <francesco@dolcini.it> wrote:
> >
> > On Fri, Nov 15, 2024 at 11:13:58AM +0800, Shengjiu Wang wrote:
> > > On Tue, Nov 12, 2024 at 5:20 PM Francesco Dolcini <francesco@dolcini.it> wrote:
> > > >
> > > > On Tue, Nov 12, 2024 at 08:59:58AM +0100, Francesco Dolcini wrote:
> > > > > On Mon, Oct 07, 2024 at 03:25:55PM +0200, Francesco Dolcini wrote:
> > > > > > it seems that an old regression is back on v6.12, reproduced on -rc2
> > > > > > (not sure about rc1).
> > > > > >
> > > > > > The original report is from https://lore.kernel.org/all/20240424164725.GA18760@francesco-nb/
> > > > > > and it was fixed with https://lore.kernel.org/all/1715396125-3724-1-git-send-email-shengjiu.wang@nxp.com/.
> > > > > >
> > > > > > Is it now back?
> > > > >
> > > > > I was able to reproduce this issue once more, this time with 6.11.7.
> > > > > As I wrote in another email the issue is not systematic as it used to
> > > > > be.
> > > > >
> > > > > Any idea?
> > > >
> > > > Frank, Shengjiu, could it be that the udelay(5) in imx_pgc_power_up() is
> > > > too short and therefore we have such non-systematic failures?
> > > >
> > >
> > > Francesco,  it seems hard to reproduce it on my i.MX8MP-EVK board.
> > >
> > > If it is easy to reproduce on your side, you can try to enlarge the delay
> > > time to see if there is any improvement.
> >
> > It's hard also for me to reproduce, we just have a relatively extensive
> > test farm and 2 times it happened while doing unrelated tests. I was hoping we
> > could have some idea on what's going on, I'll see if I can put together some
> > kind of stress test, being able to reproduce it more systematically would
> > certainly help.
> >
> 
> With my test,  the issue reproduced with delay 5us/6us. but hard reproduced
> with 7us.
> I think we may need to use a delay of 10us for safety.

Great that you were able to narrow this down and confirm the issue.
I wonder if you would have any information on what is the actual delay
that the HW would need, instead of guessing numbers. If not, well, let's
go with 15usec, or 10usec, your call in the end.

Will you send a patch?

Francesco