lkml.org 
[lkml]   [2018]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From
Date
On 05/17/2018 02:22 PM, Doug Anderson wrote:
> 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?

Yes, this is still needed. The -ENOTRECOVERABLE patch ensures that
qcom-rpmh-regulator devices can be registered even if
qcom,regulator-initial-microvolt is not specified. However, that will
result in the regulators being configured for the minimum voltage
supported in the DT specified min/max range. The
qcom,regulator-initial-microvolt property allows us to set a specific
voltage that is larger than the min constraint.

> If this is really still needed, can it be moved to the regulator core?

I'm not opposed to the idea, but I think that Mark is [1]:

>> Do you have a preference for qcom,regulator-initial-microvolt vs a generic
>> framework supported regulator-initial-microvolt property for configuring a
>> specific voltage at registration time? We'll need to have support for one
>> or the other in order for the qcom_rpmh-regulator driver to be functional.
>
> This is basically specific to Qualcomm, I can't off hand think of any
> other devices with similar issues.


>> +- 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.

Isn't that what the [1] in the above snippet is currently doing. Further
down in qcom,rpmh-regulator.txt is this line:

+[1] include/dt-bindings/regulator/qcom,rpmh-regulator.h


> 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.

I suppose that I could add something like this:

+- regulator-allow-bypass
+ Usage: optional; BOB type VRM regulators only
+ Value type: <empty>
+ Definition: See [2] for details.
...
+[2]: Documentation/devicetree/bindings/regulator.txt

However, I don't want the patch to get NACKed because it is defining a
property that is already defined in the common regulator.txt file.


>> +- 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...

The qcom,allowed-drms-modes property supports a different feature than the
regulator-allowed-modes property accepted in [2]. The latter specifies
the modes that may be used at all (e.g. in regulator_set_mode() calls) and
it lists the mode values in an unordered fashion.

qcom,allowed-drms-modes defines a specific subset of the possible allowed
modes that should be set based on DRMS (e.g. in regulator_set_load()
calls). Its values are listed in a specific order and must match 1-to-1
with qcom,drms-mode-max-microamps entries.

It would probably be good to change the name of the property from
qcom,allowed-drms-modes to qcom,regulator-drms-modes.


>> +- 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.

This could be implemented in the core via new constraint elements parsed
in of_regulator and a helper function to specify in regulator_ops.
However, I'm not sure about the wide-spread applicability of this feature.
I'd prefer to leave it in the driver unless Mark would like me to add it
into 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.

The headroom voltage voting is supported in hardware per-regulator and
per-master (AP, modem, etc). The headroom voltage and output voltage are
each aggregated (using max) per-regulator across masters. If the
aggregated enable state for a regulator is on, then the aggregated output
voltage and headroom voltage are added together and applied as a min
constraint on the parent's output voltage (if there is a parent).


>> 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?

Sure, I'll update this description.

Take care,
David

[1]: https://lkml.org/lkml/2018/4/24/960
[2]: https://lkml.org/lkml/2018/5/11/696

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

\
 
 \ /
  Last update: 2018-05-18 02:17    [W:0.138 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site