[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdUiaNrQo3zWiR45VBANhUdkHMNhXLb9pPBLQ7tCtx1JDg@mail.gmail.com>
Date: Tue, 22 Jan 2019 10:36:50 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Jon Hunter <jonathanh@...dia.com>
Cc: Martin Sperl <kernel@...tin.sperl.org>,
Mark Brown <broonie@...nel.org>,
linux-tegra <linux-tegra@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-spi <linux-spi@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: Re: Regression: spi: core: avoid waking pump thread from spi_sync
instead run teardown delayed
On Mon, Jan 14, 2019 at 4:36 PM Jon Hunter <jonathanh@...dia.com> wrote:
> I have noticed that system suspend has started failing consistently on a
> couple Tegra boards over the last few days with the linux-next branch.
> The following error is seen on on entering suspend ...
>
> [ 58.222033] spi_master spi1: could not stop message queue
> [ 58.222038] spi_master spi1: queue stop failed
> [ 58.222048] dpm_run_callback(): platform_pm_suspend+0x0/0x54 returns -16
> [ 58.222052] PM: Device 7000da00.spi failed to suspend: error -16
> [ 58.222057] PM: Some devices failed to suspend, or early wake event detected
>
> Bisecting today's -next points to commit 412e60373245 ("spi: core: avoid
> waking pump thread from spi_sync instead run teardown delayed") and
> reverting this on top of -next fixes the problem. I have not had chance
> to dig any further but wanted to report this issue to see if you have
> any thoughts.
I can confirm this on r8a7791/koelsch:
PM: suspend entry (deep)
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.010 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
spi_master spi0: could not stop message queue
spi_master spi0: queue stop failed
dpm_run_callback(): rspi_suspend+0x0/0xc returns -16
PM: Device e6b10000.spi failed to suspend: error -16
PM: Some devices failed to suspend, or early wake event detected
In addition, after boot, when the QSPI device is idle (the only activity
was the initial probe), the device is no longer runtime-suspended, as
witnessed by the following change to
/sys/kernel/debug/pm_genpd/pm_genpd_summary:
- /devices/platform/soc/e6b10000.spi suspended
+ /devices/platform/soc/e6b10000.spi active
and by the following change to /sys/kernel/debug/clk/clk_summary:
- qspi 0 1 0
97500000 0 0 50000
- qspi_mod 0 1 0
97500000 0 0 50000
+ qspi 1 1 0
97500000 0 0 50000
+ qspi_mod 1 1 0
97500000 0 0 50000
Reverting 412e60373245 also fixes that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists