lkml.org 
[lkml]   [2024]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 0/4] spi: cadence-qspi: Fix runtime PM and system-wide suspend
Hi,

On Feb 26, 2024 at 13:40:00 +0000, Mark Brown wrote:
> On Mon, Feb 26, 2024 at 01:27:57PM +0000, Mark Brown wrote:
> > On Mon, Feb 26, 2024 at 05:48:03PM +0530, Dhruva Gole wrote:
> > > On Feb 22, 2024 at 19:13:29 +0000, Mark Brown wrote:
>
> > [ 1.709414] Call trace:
> > [ 1.711852] __mutex_lock.constprop.0+0x84/0x540
> > [ 1.716460] __mutex_lock_slowpath+0x14/0x20
> > [ 1.720719] mutex_lock+0x48/0x54
> > [ 1.724026] spi_controller_suspend+0x30/0x7c
> > [ 1.728377] cqspi_suspend+0x1c/0x6c
> > [ 1.731944] pm_generic_runtime_suspend+0x2c/0x44
> > [ 1.736640] genpd_runtime_suspend+0xa8/0x254
>
> > (it's generally helpful to provide the most relevant section directly.)
>
> > The issue here appears to be that we've registered for runtime suspend
> > prior to registering the controller...
>
> Actually, no - after this series cqspi_suspend() is the system not
> runtime PM operation and should not be called from runtime suspend. How
> is that happening?

I tried dropping this entire series, it doesn't really solve the kernel
boot issues. Also this particular stack dump isn't easily reproducible
either. Perhaps this series may not be the rootcause, I will need some
more time to see what's breaking boot for us.

But for now this series seems to be in the clear. Will keep you posted
if I find anything funny here.

FYI- We're just using the arm64 defconfig and respective device DTs


--
Best regards,
Dhruva Gole <d-gole@ti.com>

\
 
 \ /
  Last update: 2024-05-27 15:24    [W:0.071 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site