LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Mark Brown <broonie@kernel.org>
Cc: David Collins <collinsd@codeaurora.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-arm-msm@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Date: Wed, 30 May 2018 09:41:55 -0700	[thread overview]
Message-ID: <CAD=FV=V1gGccKr1mHM0zx_-FFdLU1vrzUChwx6KTUyTGzj39Tw@mail.gmail.com> (raw)
In-Reply-To: <20180530163644.GW6920@sirena.org.uk>

Hi,

On Wed, May 30, 2018 at 9:36 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:31:55AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > If we're just going to use the most recently set voltage then hopefully
>> > the hardware already knew that, and it might not be the lowest available
>> > voltage if the last consumer to get turned off was holding the voltage
>> > higher.
>
>> To circle back to the original point: the problem is that (IMHO) the
>> hardware is doing the wrong thing by still counting Linux's vote for a
>> voltage even though Linux also voted that the regulator should be
>> disabled.  So basically we're working around the hardware by
>> pretending to vote for a dummy lower voltage whenever Linux wants the
>> regulator disabled.  From Linux's point of view everything works as
>> normal--we just tell the hardware a falsehood so it doesn't count our
>> vote for a voltage while the regulator is disabled.
>
> Yeah, and I don't think that's unreasonable for the core to do - just
> drop the voltage to the constraint minimum after it has turned off the
> regulator, then recheck and raise if needed before it enables again.

Would it do this for all regulators, though?  Most regulators are
hooked up over a slow i2c bus, so that means that every regulator
disable would now do an extra i2c transfer even though for all
regulators (other than RPMh) the voltage of a regulator doesn't matter
when it's been "disabled' (from Linux's point of view).

Hrmmm, I suppose maybe it'd be OK though because for most regulators
we'd use "regcache" and most regulators that we enabled/disable a lot
are not expected to change voltage in Linux (so the regcache write
would hopefully be a noop), so maybe it wouldn't be _that_
inefficient...

-Doug

  reply	other threads:[~2018-05-30 16:42 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-12  2:28 [PATCH v3 0/2] regulator: add QCOM RPMh regulator driver David Collins
2018-05-12  2:28 ` [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings David Collins
2018-05-17 21:22   ` Doug Anderson
2018-05-18  0:16     ` David Collins
2018-05-18  1:01       ` Doug Anderson
2018-05-19  0:46         ` David Collins
2018-05-21 18:01           ` Doug Anderson
2018-05-22  0:00             ` David Collins
2018-05-22 16:43               ` Doug Anderson
2018-05-22 16:55                 ` Mark Brown
2018-05-22 22:46                 ` David Collins
2018-05-23  0:08                   ` Doug Anderson
2018-05-23  1:19                     ` David Collins
2018-05-23  5:10                       ` Doug Anderson
2018-05-23  8:29                     ` Mark Brown
2018-05-23 15:23                       ` Doug Anderson
2018-05-23 15:40                         ` Mark Brown
2018-05-23 15:50                           ` Doug Anderson
2018-05-23 15:56                             ` Mark Brown
2018-05-30  5:30                               ` Doug Anderson
2018-05-30  9:37                                 ` Mark Brown
2018-05-30 14:46                                   ` Doug Anderson
2018-05-30 15:02                                     ` Mark Brown
2018-05-30 15:34                                       ` Doug Anderson
2018-05-30 15:48                                         ` Mark Brown
2018-05-30 16:06                                           ` Doug Anderson
2018-05-30 16:07                                             ` Mark Brown
2018-05-30 16:09                                               ` Doug Anderson
2018-05-30 16:13                                                 ` Mark Brown
2018-05-30 16:31                                                   ` Doug Anderson
2018-05-30 16:36                                                     ` Mark Brown
2018-05-30 16:41                                                       ` Doug Anderson [this message]
2018-05-30 16:59                                                         ` Mark Brown
2018-05-18 22:24       ` Rob Herring
2018-05-12  2:28 ` [PATCH v3 2/2] regulator: add QCOM RPMh regulator driver David Collins
2018-05-17 21:23   ` Doug Anderson
2018-05-18  0:16     ` David Collins

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='CAD=FV=V1gGccKr1mHM0zx_-FFdLU1vrzUChwx6KTUyTGzj39Tw@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=broonie@kernel.org \
    --cc=collinsd@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rnayak@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --subject='Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).