[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200529105037.GD4610@sirena.org.uk>
Date: Fri, 29 May 2020 11:50:37 +0100
From: Mark Brown <broonie@...nel.org>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Sumit Semwal <sumit.semwal@...aro.org>, agross@...nel.org,
lgirdwood@...il.com, robh+dt@...nel.org,
nishakumari@...eaurora.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
kgunda@...eaurora.org, rnayak@...eaurora.org
Subject: Re: [PATCH v3 1/5] regulator: Allow regulators to verify enabled
during enable()
On Thu, May 28, 2020 at 06:37:43PM -0700, Bjorn Andersson wrote:
> On Thu 28 May 08:46 PDT 2020, Sumit Semwal wrote:
> > Some regulators might need to verify that they have indeed been enabled
> > after the enable() call is made and enable_time delay has passed.
> > _regulator_enable_delay(delay);
> My interpretation of "enable_time" (i.e. the value of delay) is that it
> denotes the maximum time it will take for the regulator to turn on, and
Right.
> the purpose of this patch is to be able to handle cases where we can
> poll the hardware to see if it completed earlier.
Is that it? From the changelog it sounded like this was a workaround
for broken hardware not an attempt at optimization.
> So I think you should flip the meaning of your two variables around,
> making "delay" the total time to sleep and the newly introduced
> "poll_enabled_time" the interval at which you check if the hardware
> finished early.
Yes.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists