LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: David Collins <collinsd@codeaurora.org>
Cc: Mark Brown <broonie@kernel.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: Thu, 17 May 2018 14:22:47 -0700	[thread overview]
Message-ID: <CAD=FV=XegPeFR8pdZM-YiBBJjrbej=C+2biBt4zJKnE90uTYZA@mail.gmail.com> (raw)
In-Reply-To: <41d5df73ddac772551d2966e0752bb0c357b1ded.1526088081.git.collinsd@codeaurora.org>

Hi,

On Fri, May 11, 2018 at 7:28 PM, David Collins <collinsd@codeaurora.org> wrote:
> +- qcom,regulator-initial-microvolt
> +       Usage:      optional; VRM regulators only
> +       Value type: <u32>
> +       Definition: Specifies the initial voltage in microvolts to request for a
> +                   VRM regulator.

Now that Mark has landed the patch adding support for the
-ENOTRECOVERABLE error code from get_voltage() / get_voltage_sel(), do
we still need the qcom,regulator-initial-microvolt property?  If this
is really still needed, can it be moved to the regulator core?


> +- regulator-initial-mode
> +       Usage:      optional; VRM regulators only
> +       Value type: <u32>
> +       Definition: Specifies the initial mode to request for a VRM regulator.
> +                   Supported values are RPMH_REGULATOR_MODE_* which are defined
> +                   in [1] (i.e. 0 to 3).  This property may be specified even
> +                   if the regulator-allow-set-load property is not specified.

Every time I read the above I wonder why you're documenting a standard
regulator regulator property in your bindings.  ...then I realize it's
because you're doing it because you want to explicitly document what
the valid modes are.  I wonder if it makes sense to just put a
reference somewhere else in this document to go look at the header
file where these are all nicely documented.

Speaking of documenting things like that, it might be worth finding
somewhere in this doc to mention that the "bob" regulator on PMI8998
can support "regulator-allow-bypass".  That tidbit got lost when we
moved to the standard regulator bindings for bypass.


> +- qcom,allowed-drms-modes
> +       Usage:      required if regulator-allow-set-load is specified;
> +                   VRM regulators only
> +       Value type: <prop-encoded-array>
> +       Definition: A list of integers specifying the PMIC regulator modes which
> +                   can be configured at runtime based upon consumer load needs.
> +                   Supported values are RPMH_REGULATOR_MODE_* which are defined
> +                   in [1] (i.e. 0 to 3).

Why is this still here?  You moved it to the core regulator framework,
right?  It's still in your examples too.  Shouldn't this be removed?
It looks like the driver still needs this and it needs to be an exact
duplicate of the common binding.  That doesn't seem right...


> +- qcom,drms-mode-max-microamps
> +       Usage:      required if regulator-allow-set-load is specified;
> +                   VRM regulators only
> +       Value type: <prop-encoded-array>
> +       Definition: A list of integers specifying the maximum allowed load
> +                   current in microamps for each of the modes listed in
> +                   qcom,allowed-drms-modes (matched 1-to-1 in order).  Elements
> +                   must be specified in order from lowest to highest value.

Any reason this can't go into the regulator core?  You'd basically
just take the existing concept of rpmh_regulator_vrm_set_load() and
put it in the core.


> +- qcom,headroom-microvolt
> +       Usage:      optional; VRM regulators only
> +       Value type: <u32>
> +       Definition: Specifies the headroom voltage in microvolts to request for
> +                   a VRM regulator.  RPMh hardware automatically ensures that
> +                   the parent of this regulator outputs a voltage high enough
> +                   to satisfy the requested headroom.  Supported values are
> +                   0 to 511000.

I'm curious: is this a voted-for value, or a global value?

Said another way: the whole point of RPMh is that there may be more
than one processor that needs the same rails, right?  So the AP might
request 1.1 V for a rail and the modem might request 1.3 V.  RPMh
would decide to pick the higher of those two (1.3 V), but if the modem
said it no longer needs the rail it will drop down to 1.1 V.

...and as an example of why the headroom needs to be in hardware, if
the source voltage was normally 1.4 V and the headroom was 200 mV then
the hardware would need to know to bump up the source voltage to 1.5V
during the period of of time that the modem wants the rail at 1.3V.

So my question is: do the AP and modem in the above situation
separately vote for headroom?  How is it aggregated?  ...or is it a
global value and this sets the headroom for all clients of RPMh?  It
would be interesting to document this as it might help with figuring
out how this value should be set.


> diff --git a/include/dt-bindings/regulator/qcom,rpmh-regulator.h b/include/dt-bindings/regulator/qcom,rpmh-regulator.h
> new file mode 100644
> index 0000000..4378c4b
> --- /dev/null
> +++ b/include/dt-bindings/regulator/qcom,rpmh-regulator.h
> +/*
> + * These mode constants may be used for regulator-initial-mode and
> + * qcom,allowed-drms-modes properties of an RPMh regulator device tree node.

Technically also for your new "regulator-allowed-modes".  Maybe just
say that they're used anywhere a regulator mode is needed in this
driver and give regulator-initial-mode as an example?


-Doug

  reply	other threads:[~2018-05-17 21:22 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 [this message]
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
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=XegPeFR8pdZM-YiBBJjrbej=C+2biBt4zJKnE90uTYZA@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).