[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0h97zsjG=xKHz=zjaQiLz-ER5YfsQz=c3k7ZFafG8H8Cg@mail.gmail.com>
Date: Tue, 19 Dec 2017 12:19:20 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alan Stern <stern@...land.harvard.edu>,
Kevin Hilman <khilman@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 3/4] PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
On Tue, Dec 19, 2017 at 12:13 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Tue, Dec 19, 2017 at 8:38 AM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
>> On 10 December 2017 at 01:00, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>>> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>>>
[cut]
>
>> Moreover, what happens when/if a driver that has deployed this
>> solution, starts being used on a new SoC and then additional
>> operations during system suspend becomes required (for example
>> pinctrls that needs to be put in a system sleep state)? Then
>> everything falls apart, doesn't it?
>
> Then you runtime-resume the device in ->suspend() and the remaining
> callbacks will run for you just fine.
BTW, I guess you'll need a middle layer in that case anyway so that
the driver doesn't have to distinguish between platforms it has to
work with which makes the argument somewhat moot.
Thanks,
Rafael
Powered by blists - more mailing lists