From: Mark Brown <broonie@kernel.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>,
agross@kernel.org, lgirdwood@gmail.com, robh+dt@kernel.org,
nishakumari@codeaurora.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
kgunda@codeaurora.org, rnayak@codeaurora.org
Subject: Re: [PATCH v3 1/5] regulator: Allow regulators to verify enabled during enable()
Date: Fri, 29 May 2020 11:50:37 +0100 [thread overview]
Message-ID: <20200529105037.GD4610@sirena.org.uk> (raw)
In-Reply-To: <20200529013743.GL279327@builder.lan>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-05-29 10:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 15:46 [PATCH v3 0/5] Qualcomm labibb regulator driver Sumit Semwal
2020-05-28 15:46 ` [PATCH v3 1/5] regulator: Allow regulators to verify enabled during enable() Sumit Semwal
2020-05-29 1:37 ` Bjorn Andersson
2020-05-29 10:50 ` Mark Brown [this message]
2020-05-29 10:54 ` Mark Brown
2020-05-28 15:46 ` [PATCH v3 2/5] dt-bindings: regulator: Add labibb regulator Sumit Semwal
2020-05-29 3:01 ` Rob Herring
2020-05-28 15:46 ` [PATCH v3 3/5] arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators Sumit Semwal
2020-05-29 1:43 ` Bjorn Andersson
2020-05-28 15:46 ` [PATCH v3 4/5] regulator: qcom: Add labibb driver Sumit Semwal
2020-05-29 2:04 ` Bjorn Andersson
2020-05-28 15:46 ` [PATCH v3 5/5] regulator: qcom: labibb: Add SC interrupt handling Sumit Semwal
2020-05-29 2:28 ` Bjorn Andersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200529105037.GD4610@sirena.org.uk \
--to=broonie@kernel.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=kgunda@codeaurora.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nishakumari@codeaurora.org \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.