On Wed, Jun 12, 2024 at 05:12:43AM -0700, Breno Leitao wrote: > On Tue, Jun 11, 2024 at 03:49:02PM +0300, Andy Shevchenko wrote: > > On Thu, Jun 06, 2024 at 06:27:07AM -0700, Breno Leitao wrote: > > > > The problem arises because during __pm_runtime_resume(), the spinlock > > > &dev->power.lock is acquired before rpm_resume() is called. Later, > > > rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on > > > mutexes, triggering the error. > > > > > > To address this issue, devices on ACPI are now marked as not IRQ-safe, > > > considering the dependency of acpi_subsys_runtime_resume() on mutexes. > > > > ... > > > > While it's a move in the right direction, the real fix is to get rid of > > the IRQ safe PM hack completely. > > Look at how OMAP code was modified for > > the last few years and now it's pm_runtime_irq_safe()-free. The main > > (ab)users are SH code followed by Tegra drivers. > > Thanks. > > I think these are two different goals here. This near term goal is just > fix the driver so it can use the pm_runtime_irq_safe() in a saner > way, avoiding calling mutexes inside spinlocks. > > Getting rid of the IRQ safe PM seems to me to be more a long term > desirable goal, and unfortunately I cannot afford doing it now. > > Laxman, what is your view on this topic? Yes, please, comment on this. We would like to get rid of the hack named "IRQ safe PM runtime". -- With Best Regards, Andy Shevchenko
