[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190111123913.GA2804@sirena.org.uk>
Date: Fri, 11 Jan 2019 12:39:13 +0000
From: Mark Brown <broonie@...nel.org>
To: Claudiu.Beznea@...rochip.com
Cc: Nicolas.Ferre@...rochip.com, alexandre.belloni@...tlin.com,
Ludovic.Desroches@...rochip.com, linux@...linux.org.uk,
lgirdwood@...il.com, rjw@...ysocki.net, pavel@....cz,
len.brown@...el.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 2/3] regulator: core: add helper to check if regulator
is disabled in suspend
On Thu, Jan 10, 2019 at 10:24:26AM +0000, Claudiu.Beznea@...rochip.com wrote:
> On 09.01.2019 18:57, Mark Brown wrote:
> > regulator state which feels fragile. But based on the cover letter
> > that's kind of like what the initial proposal about target states was so
> > perhaps this is the way we end up going...
> Are you talking about [1] ?
I can't follow that link right now, I'm working offline.
> I can get rid of this patch, take advantage of [3] and [4] and introduce
> also the regulator standby states. In this case, no matter the mapping b/w
> Linux power saving modes and AT91 SoC's power saving modes, we will be
> covered on misconfiguration (at least on SAMA5D2 Xplained board).
> And in patch 3/3 I could get rid of regulator checks and rely on DT (bad
> thing would be that in case of no input for regulator's state in
> mem/standby the board could not properly suspended/resumed), if any.
> What do you think about this?
Like I say I'm working offline so I can't check the links but it sounds
like you're saying that the existing suspend mode configuration features
are enough for your systems? If so that's great - certainly what you're
saying above sounds sensible to me but it's possible I misunderstood
something based on not having the links.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists