[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZbbgUcj149aE=N-RX4BLjVNsiOqvRDzWFDELyaKr_Z4Q@mail.gmail.com>
Date: Fri, 30 Jun 2017 00:25:27 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Stephen Warren <swarren@...dia.com>,
Al Cooper <alcooperx@...il.com>,
"open list:PIN CONTROL SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume
On Thu, Jun 29, 2017 at 9:38 PM, Florian Fainelli <f.fainelli@...il.com> wrote:
> On 06/29/2017 02:17 AM, Linus Walleij wrote:
>> So if it is not desireable to have every driver know which exact
>> state it came from like S3 this or S2 that and on this laptop
>> we have S2' which is slightly different and such mess (that you
>> predict IIUC) what we really need to know is pretty simple:
>> did the hardware loose its state or not?
>
> That information is inherently platform specific though, so on platforms
> where pinctrl-single is used, you won't necessarily know whether the
> state should be restored (conversely saved) so maybe that means we
> should have the possibility for a platform to define a wrapper around
> pinctrl-single whose purpose is to implement platform specific
> suspend/r/resume functions and just that really? Is there such a driver
> already that uses pinctrl-single more as a "library" than anything else?
pinctrl-single maye not be the easiest in cases like this, but Tony
et al have bolted in a few OMAP specifics to pinctrl-single in the
past so I don't see why this would be a problem.
commit 02e483f66deb6bd8df6af450726574614eb53be3
"pinctrl: single: Prepare for supporting SoC specific features"
etc.
Yours,
Linus Walleij
Powered by blists - more mailing lists