[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPSr9jE6Qfu4NpmDfUrS+hVad2OP+xr00yoJ3k5=e=f7ZKwY+g@mail.gmail.com>
Date: Wed, 3 Jul 2019 08:56:22 +0800
From: Muchun Song <smuchun@...il.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux PM <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] PM: Move disabling/enabling runtime PM to
suspend/resume noirq
Rafael J. Wysocki <rafael@...nel.org> 于2019年7月3日周三 上午1:54写道:
>
> On Tue, Jul 2, 2019 at 6:37 PM Muchun Song <smuchun@...il.com> wrote:
> >
> > Currently, the PM core disables runtime PM for all devices right after
> > executing subsystem/driver .suspend_late() callbacks for them and
> > re-enables it right before executing subsystem/driver .resume_early()
> > callbacks for them. This may lead to problems when there are two devices
> > such that the irq handler thread function executed for one of them
> > depends on runtime PM working for the other. E.g. There are two devices,
> > one is i2c slave device depends on another device which can be the i2c
> > adapter device. The slave device can generate system wakeup signals and
> > is enabled to wake up the system(via call enable_irq_wake()). So, the irq
> > of slave device is enabled. If a wakeup signal generate after executing
> > subsystem/driver .suspend_late() callbacks. Then, the irq handler thread
> > function will be called(The irq is requested via request_threaded_irq())
> > and the slave device reads data via i2c adapter device(via i2c_transfer()).
> > In that case, it may be failed to read data because of the runtime PM
> > disabled.
> >
> > It is also analogously for resume. If a wakeup signal generate when the
> > system is in the sleep state. The irq handler thread function may be
> > called before executing subsystem/driver .resume_early(). In that case,
> > it also may be failed to read data because of the runtime PM disabled.
> >
>
> This has been discussed for a number of times, documented and no, I'm
> not going to apply this patch.
Thanks for your reply. I want to know why we can't do that, so where
can I find the discussion?
> PM-runtime cannot be relied on during the "noirq" stages of suspend
> and resume, which is why it is disabled by the core in the "late" and
> "early" stages, respectively.
>
What better solution do we have for the example I am talking about
which is described in the commit message? Thanks.
Yours,
Muchun
Powered by blists - more mailing lists