[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180105191837.GI9076@sirena.org.uk>
Date: Fri, 5 Jan 2018 19:18:37 +0000
From: Mark Brown <broonie@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: Chunyan Zhang <zhang.chunyan@...aro.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Ulf Hansson <ulf.hansson@...aro.org>,
Chunyan Zhang <zhang.lyra@...il.com>
Subject: Re: [PATCH V2 1/5] bindings: regulator: added support for suspend
states
On Fri, Jan 05, 2018 at 12:53:28PM -0600, Rob Herring wrote:
> On Thu, Jan 04, 2018 at 03:22:44PM +0800, Chunyan Zhang wrote:
> > + - regulator-suspend-microvolt: the default voltage which regulator
> > + would be set in suspend. The voltage for suspend also can be
> > + adjusted among {regulator-suspend-min-microvolt,
> > + regulator-suspend-max-microvolt} by calling
> > + regulator_set_suspend_voltage(). This property is not deprecated,
> You mean "is deprecated", right?
I suspect "is now" but yeah.
> > + - regulator-changeable-in-suspend: whether the default voltage and
> > + the regulator on/off in suspend can be changed in runtime.
> Is this not implied by having the constraints? Or the driver should know
> this. The simply means you have some 2nd bank of registers for settings
> while in suspend mode, right?
No, it means that the software has permission to use those changes to
those registers - we only want to be changing things if the user has
permission to change them since some systems will have specific
constraints, we don't know if it's safe without being explicitly told.
You're right that we could infer this from a range being provided
though, let's do that.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists