| Message ID | 6d03576cf90f06afb1194301cb41fc31704def1d.1527040878.git.collinsd@codeaurora.org (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Andy Gross |
| Headers | show |
On Tue, May 22, 2018 at 07:43:17PM -0700, David Collins wrote: > Introduce bindings for RPMh regulator devices found on some > Qualcomm Technlogies, Inc. SoCs. These devices allow a given > processor within the SoC to make PMIC regulator requests which > are aggregated within the RPMh hardware block along with requests > from other processors in the SoC to determine the final PMIC > regulator hardware state. > > Signed-off-by: David Collins <collinsd@codeaurora.org> > --- > .../bindings/regulator/qcom,rpmh-regulator.txt | 185 +++++++++++++++++++++ > .../dt-bindings/regulator/qcom,rpmh-regulator.h | 36 ++++ > 2 files changed, 221 insertions(+) > create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt > create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h Reviewed-by: Rob Herring <robh@kernel.org> -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote: > +======== > +Examples > +======== > + > +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> > + > +&apps_rsc { > + pm8998-rpmh-regulators { > + compatible = "qcom,pm8998-rpmh-regulators"; > + qcom,pmic-id = "a"; > + > + vdd-l7-l12-l14-l15-supply = <&pm8998_s5>; > + > + smps2 { > + regulator-min-microvolt = <1100000>; > + regulator-max-microvolt = <1100000>; > + }; > + > + pm8998_s5: smps5 { > + regulator-min-microvolt = <1904000>; > + regulator-max-microvolt = <2040000>; > + }; > + > + ldo7 { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>; > + regulator-allowed-modes = > + <RPMH_REGULATOR_MODE_LPM > + RPMH_REGULATOR_MODE_HPM>; > + regulator-allow-set-load; > + qcom,regulator-drms-modes = > + <RPMH_REGULATOR_MODE_LPM > + RPMH_REGULATOR_MODE_HPM>; > + qcom,drms-mode-max-microamps = <10000 1000000>; Things look pretty good to me now. I'm still hesitant about the whole need to list the modes twice (once using the unordered "regulator-allowed-modes" and once to match up against the ordered "qcom,drms-mode-max-microamps"). I'm also still of the opinion that the whole "drms-mode-max-microamps" ought to be a standard property (not a qcom specific one) and handled in the regulator core. However, for both of these things I leave it to the discretion of Mark to choose what he wants. Thus assuming Mark is OK with these two things, feel free to add my Reviewed-by. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 29, 2018 at 10:23:20PM -0700, Doug Anderson wrote: > > + qcom,drms-mode-max-microamps = <10000 1000000>; > Things look pretty good to me now. I'm still hesitant about the whole > need to list the modes twice (once using the unordered > "regulator-allowed-modes" and once to match up against the ordered > "qcom,drms-mode-max-microamps"). I'm also still of the opinion that > the whole "drms-mode-max-microamps" ought to be a standard property > (not a qcom specific one) and handled in the regulator core. I'm confused as to why we are specifying the maximum current the device can deliver in a given mode in the DT - surely that's a fixed property of the hardware?
Hi, On Wed, May 30, 2018 at 3:37 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, May 29, 2018 at 10:23:20PM -0700, Doug Anderson wrote: > >> > + qcom,drms-mode-max-microamps = <10000 1000000>; > >> Things look pretty good to me now. I'm still hesitant about the whole >> need to list the modes twice (once using the unordered >> "regulator-allowed-modes" and once to match up against the ordered >> "qcom,drms-mode-max-microamps"). I'm also still of the opinion that >> the whole "drms-mode-max-microamps" ought to be a standard property >> (not a qcom specific one) and handled in the regulator core. > > I'm confused as to why we are specifying the maximum current the device > can deliver in a given mode in the DT - surely that's a fixed property > of the hardware? Said another way: you're saying that you'd expect the "max-microamps" table to have one fewer element than the listed modes? So in the above example you'd have: drms-modes: LPM, HPM max-microamps: 10000 ...or in a more complicated case, you could have: drms-modes: RET, LPM, AUTO, HPM max-microamps: 1, 100, 10000 Did I understand you correctly? I'm personally OK with that color for the shed. I kinda like the symmetry of having the same number of elements in both lists (and being able to print an error message if someone ends up asking for too much current), but it's not a big deal for me either way. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 30, 2018 at 07:54:47AM -0700, Doug Anderson wrote: > On Wed, May 30, 2018 at 3:37 AM, Mark Brown <broonie@kernel.org> wrote: > > I'm confused as to why we are specifying the maximum current the device > > can deliver in a given mode in the DT - surely that's a fixed property > > of the hardware? > Said another way: you're saying that you'd expect the "max-microamps" > table to have one fewer element than the listed modes? So in the > above example you'd have: No, I'm saying that I don't know why that property exists at all. This sounds like it's intended to be the amount of current the regulator can deliver in each mode which is normally a design property of the silicon.
Hi, On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote: > On Wed, May 30, 2018 at 07:54:47AM -0700, Doug Anderson wrote: >> On Wed, May 30, 2018 at 3:37 AM, Mark Brown <broonie@kernel.org> wrote: > >> > I'm confused as to why we are specifying the maximum current the device >> > can deliver in a given mode in the DT - surely that's a fixed property >> > of the hardware? > >> Said another way: you're saying that you'd expect the "max-microamps" >> table to have one fewer element than the listed modes? So in the >> above example you'd have: > > No, I'm saying that I don't know why that property exists at all. This > sounds like it's intended to be the amount of current the regulator can > deliver in each mode which is normally a design property of the silicon. Ah, got it. So the whole point here is to be able to implement either the function "set_load" or the function "get_optimum_mode". We need some sort of table to convert from current to mode. That's what this table does. My argument to David was that since set_load / get_optimum_mode were features of the regulator core these should actually be standard properties and not Qualcomm-specific ones. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 30, 2018 at 09:12:25AM -0700, Doug Anderson wrote: > On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote: > > No, I'm saying that I don't know why that property exists at all. This > > sounds like it's intended to be the amount of current the regulator can > > deliver in each mode which is normally a design property of the silicon. > Ah, got it. So the whole point here is to be able to implement either > the function "set_load" or the function "get_optimum_mode". We need > some sort of table to convert from current to mode. That's what this > table does. We do need that table, my expectation would be that this table would be in the driver as it's not something I'd expect to vary between different systems but rather be a property of the silicon design. No sense in every single board having to copy it in.
Hi, On Wed, May 30, 2018 at 9:20 AM, Mark Brown <broonie@kernel.org> wrote: > On Wed, May 30, 2018 at 09:12:25AM -0700, Doug Anderson wrote: >> On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote: > >> > No, I'm saying that I don't know why that property exists at all. This >> > sounds like it's intended to be the amount of current the regulator can >> > deliver in each mode which is normally a design property of the silicon. > >> Ah, got it. So the whole point here is to be able to implement either >> the function "set_load" or the function "get_optimum_mode". We need >> some sort of table to convert from current to mode. That's what this >> table does. > > We do need that table, my expectation would be that this table would be > in the driver as it's not something I'd expect to vary between different > systems but rather be a property of the silicon design. No sense in > every single board having to copy it in. Ah, got it! I'd be OK with it being hardcoded in the driver. At one point I think David was making the argument that some boards have different noise needs for the rails and thus you might want to change modes at different currents. I don't know if this is realistic but I believe it was part of his original argument for why this needed to be specified. If we can hardcode this in the driver I'm fine with it... That would actually solve many of my objections too... -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Mark and Doug, On 05/30/2018 09:24 AM, Doug Anderson wrote: > On Wed, May 30, 2018 at 9:20 AM, Mark Brown <broonie@kernel.org> wrote: >> On Wed, May 30, 2018 at 09:12:25AM -0700, Doug Anderson wrote: >>> On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote: >> >>>> No, I'm saying that I don't know why that property exists at all. This >>>> sounds like it's intended to be the amount of current the regulator can >>>> deliver in each mode which is normally a design property of the silicon. >> >>> Ah, got it. So the whole point here is to be able to implement either >>> the function "set_load" or the function "get_optimum_mode". We need >>> some sort of table to convert from current to mode. That's what this >>> table does. >> >> We do need that table, my expectation would be that this table would be >> in the driver as it's not something I'd expect to vary between different >> systems but rather be a property of the silicon design. No sense in >> every single board having to copy it in. > > Ah, got it! I'd be OK with it being hardcoded in the driver. > > At one point I think David was making the argument that some boards > have different noise needs for the rails and thus you might want to > change modes at different currents. I don't know if this is realistic > but I believe it was part of his original argument for why this needed > to be specified. If we can hardcode this in the driver I'm fine with > it... That would actually solve many of my objections too... The DRMS modes to use and max allowed current per mode need to be specified at the board level in device tree instead of hard-coded per regulator type in the driver. There are at least two use cases driving this need: LDOs shared between RPMh client processors and SMPSes requiring PWM mode in certain circumstances. For LDOs the maximum low power mode (LPM) current is typically 10 mA or 30 mA (depending upon subtype) per hardware documentation. Unfortunately, sharing control of regulators with other processors adds some subtlety to the LPM current limit that should actually be applied at runtime. Consider the case of a regulator with physical 10 mA LPM max current. Say that modem and application processors each have a load on the regulator that draws 9 mA. If they each respect the 10 mA limit, then they'd each vote for LPM. The VRM block in RPMh hardware will aggregate these requests together using a max function which will result in the regulator being set to LPM, even though the total load is 18 mA (which would require high power mode (HPM)). To get around this corner case, a LPM max current of 1 uA can be used for all LDO supplies that have non-application processor consumers. Thus, any non-zero regulator_set_load() current request will result in setting the regulator to HPM (which is always safe). The second situation that needs board-level DRMS mode and current limit specification is SMPS regulator AUTO mode to PWM (HPM) mode switching. SMPS regulators should theoretically always be able to operate in AUTO mode as it switches automatically between PWM mode (which can provide the maximum current) and PFM mode (which supports lower current but has higher efficiency). However, there may be board/system issues that require switching to PWM mode for certain use cases as it has better load regulation (i.e. no PFM ripple for lower loads) and supports more aggressive load current steps (i.e. greater A/ns). If a Linux consumer requires the ability to force a given SMPS regulator from AUTO mode into PWM mode and that SMPS is shared by other Linux consumers (which may be the case, but at least must be guaranteed to work architecturally), then regulator_set_load() is the only option since it provides aggregation, where as regulator_set_mode() does not. regulator_set_load() can be utilized in this case by specifying AUTO mode and PWM mode as drms modes and specifying some particular AUTO mode maximum current (that is known by the consumer) in device tree. The consumer can then call regulator_set_load() with the imposed AUTO mode limit + delta when PWM mode is required and a lower value when AUTO mode is sufficient. Note that I previously mentioned the need for board-level drms mode and current limit specification in [1]. Take care, David [1]: https://lkml.org/lkml/2018/3/22/802
Hi, On Wed, May 30, 2018 at 4:39 PM, David Collins <collinsd@codeaurora.org> wrote: > Consider the case of a regulator with physical 10 mA LPM max current. Say > that modem and application processors each have a load on the regulator > that draws 9 mA. If they each respect the 10 mA limit, then they'd each > vote for LPM. The VRM block in RPMh hardware will aggregate these requests > together using a max function which will result in the regulator being set > to LPM, even though the total load is 18 mA (which would require high > power mode (HPM)). To get around this corner case, a LPM max current of 1 > uA can be used for all LDO supplies that have non-application processor > consumers. Thus, any non-zero regulator_set_load() current request will > result in setting the regulator to HPM (which is always safe). Is there any plan to change the way this works for future versions of RPMh? > The second situation that needs board-level DRMS mode and current limit > specification is SMPS regulator AUTO mode to PWM (HPM) mode switching. > SMPS regulators should theoretically always be able to operate in AUTO > mode as it switches automatically between PWM mode (which can provide the > maximum current) and PFM mode (which supports lower current but has higher > efficiency). However, there may be board/system issues that require > switching to PWM mode for certain use cases as it has better load > regulation (i.e. no PFM ripple for lower loads) and supports more > aggressive load current steps (i.e. greater A/ns). > > If a Linux consumer requires the ability to force a given SMPS regulator > from AUTO mode into PWM mode and that SMPS is shared by other Linux > consumers (which may be the case, but at least must be guaranteed to work > architecturally), then regulator_set_load() is the only option since it > provides aggregation, where as regulator_set_mode() does not. > regulator_set_load() can be utilized in this case by specifying AUTO mode > and PWM mode as drms modes and specifying some particular AUTO mode > maximum current (that is known by the consumer) in device tree. The > consumer can then call regulator_set_load() with the imposed AUTO mode > limit + delta when PWM mode is required and a lower value when AUTO mode > is sufficient. Mark: I'm leaving this firmly in your hands. I can see David's points here. I could even believe that some of this stuff could be board specific where one board might have slightly different capacitors or they might be placed differently and might need a higher power mode to keep the signal clean. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Doug, On 05/30/2018 05:34 PM, Doug Anderson wrote: > On Wed, May 30, 2018 at 4:39 PM, David Collins <collinsd@codeaurora.org> wrote: >> Consider the case of a regulator with physical 10 mA LPM max current. Say >> that modem and application processors each have a load on the regulator >> that draws 9 mA. If they each respect the 10 mA limit, then they'd each >> vote for LPM. The VRM block in RPMh hardware will aggregate these requests >> together using a max function which will result in the regulator being set >> to LPM, even though the total load is 18 mA (which would require high >> power mode (HPM)). To get around this corner case, a LPM max current of 1 >> uA can be used for all LDO supplies that have non-application processor >> consumers. Thus, any non-zero regulator_set_load() current request will >> result in setting the regulator to HPM (which is always safe). > > Is there any plan to change the way this works for future versions of RPMh? As far as I know, no. Adding VRM logic to sum RPMh client load current requests, compare the sums to thresholds, select corresponding modes, and override with explicit modes was determined to be too complex for RPMh. Instead, much simpler max aggregation was implemented along with design guidelines for PMICs to ensure that mode values are ordered from strictly lower to higher power. Take care, David
On Wed, May 30, 2018 at 04:39:10PM -0700, David Collins wrote: > The DRMS modes to use and max allowed current per mode need to be > specified at the board level in device tree instead of hard-coded per > regulator type in the driver. There are at least two use cases driving > this need: LDOs shared between RPMh client processors and SMPSes requiring > PWM mode in certain circumstances. Is there really no way to improve the RPM firmware? > Consider the case of a regulator with physical 10 mA LPM max current. Say > that modem and application processors each have a load on the regulator > that draws 9 mA. If they each respect the 10 mA limit, then they'd each > vote for LPM. The VRM block in RPMh hardware will aggregate these requests This is, of course, why the regulator API aggregates this stuff based on the current not based on having every individual user select a mode. > together using a max function which will result in the regulator being set > to LPM, even though the total load is 18 mA (which would require high > power mode (HPM)). To get around this corner case, a LPM max current of 1 > uA can be used for all LDO supplies that have non-application processor > consumers. Thus, any non-zero regulator_set_load() current request will > result in setting the regulator to HPM (which is always safe). That's obviously just never going to work well, the best you can do here is just pretend that the other components are always operating at full power (which I assume all the other components are doing too...) or not try to use load based mode switching in the first place. > The second situation that needs board-level DRMS mode and current limit > specification is SMPS regulator AUTO mode to PWM (HPM) mode switching. > SMPS regulators should theoretically always be able to operate in AUTO > mode as it switches automatically between PWM mode (which can provide the > maximum current) and PFM mode (which supports lower current but has higher > efficiency). However, there may be board/system issues that require > switching to PWM mode for certain use cases as it has better load > regulation (i.e. no PFM ripple for lower loads) and supports more > aggressive load current steps (i.e. greater A/ns). > If a Linux consumer requires the ability to force a given SMPS regulator > from AUTO mode into PWM mode and that SMPS is shared by other Linux > consumers (which may be the case, but at least must be guaranteed to work > architecturally), then regulator_set_load() is the only option since it > provides aggregation, where as regulator_set_mode() does not. That's obviously broken though, what you're describing is just clearly nothing to do with load so trying to configure it using load is just going to lead to problems later on. Honestly it sounds like you just want to force the regulator into forced PWM mode all the time, otherwise you need to look into implementing support for describing the thing you're actually trying to do and add a mechanism for per consumer mode configuration. This has been a frequent pattern with these RPM drivers, trying to find some way to shoehorn something that happens to work right now into the code. That's going to make things fragile and hard to maintain, we need code that does the thing it's saying it does so that it's easier to understand and work with - getting things running isn't enough, they need to be clear.
Hello Mark, On 05/31/2018 04:48 AM, Mark Brown wrote: > On Wed, May 30, 2018 at 04:39:10PM -0700, David Collins wrote: >> The DRMS modes to use and max allowed current per mode need to be >> specified at the board level in device tree instead of hard-coded per >> regulator type in the driver. There are at least two use cases driving >> this need: LDOs shared between RPMh client processors and SMPSes requiring >> PWM mode in certain circumstances. > > Is there really no way to improve the RPM firmware? This aggregation takes place in a discrete hardware block, not in a general purpose processor. Theoretically, future chips could have redesigned VRM hardware; however, there is no plan to make such a change. >> Consider the case of a regulator with physical 10 mA LPM max current. Say >> that modem and application processors each have a load on the regulator >> that draws 9 mA. If they each respect the 10 mA limit, then they'd each >> vote for LPM. The VRM block in RPMh hardware will aggregate these requests > > This is, of course, why the regulator API aggregates this stuff based on > the current not based on having every individual user select a mode. > >> together using a max function which will result in the regulator being set >> to LPM, even though the total load is 18 mA (which would require high >> power mode (HPM)). To get around this corner case, a LPM max current of 1 >> uA can be used for all LDO supplies that have non-application processor >> consumers. Thus, any non-zero regulator_set_load() current request will >> result in setting the regulator to HPM (which is always safe). > > That's obviously just never going to work well, the best you can do here > is just pretend that the other components are always operating at full > power (which I assume all the other components are doing too...) or not > try to use load based mode switching in the first place. I will remove the DT-based mode and max load current mapping support. In its place, I'll implement hard coded LPM current limits for LDOs of 10 mA or 30 mA (depending upon subtype) like is done in other regulator drivers. If we actually encounter an issue caused by the APPS processor and another RPMh client both voting for LPM when HPM is needed for the combination, then we can disable load-based mode control for the affected regulator in DT and configure its initial mode as HPM. >> The second situation that needs board-level DRMS mode and current limit >> specification is SMPS regulator AUTO mode to PWM (HPM) mode switching. >> SMPS regulators should theoretically always be able to operate in AUTO >> mode as it switches automatically between PWM mode (which can provide the >> maximum current) and PFM mode (which supports lower current but has higher >> efficiency). However, there may be board/system issues that require >> switching to PWM mode for certain use cases as it has better load >> regulation (i.e. no PFM ripple for lower loads) and supports more >> aggressive load current steps (i.e. greater A/ns). > >> If a Linux consumer requires the ability to force a given SMPS regulator >> from AUTO mode into PWM mode and that SMPS is shared by other Linux >> consumers (which may be the case, but at least must be guaranteed to work >> architecturally), then regulator_set_load() is the only option since it >> provides aggregation, where as regulator_set_mode() does not. > > That's obviously broken though, what you're describing is just clearly > nothing to do with load so trying to configure it using load is just > going to lead to problems later on. Honestly it sounds like you just > want to force the regulator into forced PWM mode all the time, otherwise > you need to look into implementing support for describing the thing > you're actually trying to do and add a mechanism for per consumer mode > configuration. > > This has been a frequent pattern with these RPM drivers, trying to find > some way to shoehorn something that happens to work right now into the > code. That's going to make things fragile and hard to maintain, we need > code that does the thing it's saying it does so that it's easier to > understand and work with - getting things running isn't enough, they > need to be clear. I agree that using regulator_set_load() to handle SMPS AUTO mode to PWM mode switching is hacky. Since there is no natural way to pick SMPS modes based on load current, I will remove the functionality completely. In its place, we can configure the SMPSes to have an initial mode of AUTO. If a use case requiring PWM mode arises, then the consumer driver responsible for it can call regulator_set_mode() to switch between AUTO and PWM modes explicitly. Since regulator_set_mode() does not support aggregation currently, this technique would work only if there is exactly one consumer per regulator that needs explicit mode control. Should we hit a situation that needs multiple consumers to have such mode control, then we could simply default the SMPS to PWM mode. I'll also start looking into per-consumer mode configuration and regulator_set_mode() aggregation within the regulator framework. I think that we should be able to function without it for now; however, it would be good to have going forward. Take care, David
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt new file mode 100644 index 0000000..aaac975 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt @@ -0,0 +1,185 @@ +Qualcomm Technologies, Inc. RPMh Regulators + +rpmh-regulator devices support PMIC regulator management via the Voltage +Regulator Manager (VRM) and Oscillator Buffer (XOB) RPMh accelerators. The APPS +processor communicates with these hardware blocks via a Resource State +Coordinator (RSC) using command packets. The VRM allows changing three +parameters for a given regulator: enable state, output voltage, and operating +mode. The XOB allows changing only a single parameter for a given regulator: +its enable state. Despite its name, the XOB is capable of controlling the +enable state of any PMIC peripheral. It is used for clock buffers, low-voltage +switches, and LDO/SMPS regulators which have a fixed voltage and mode. + +======================= +Required Node Structure +======================= + +RPMh regulators must be described in two levels of device nodes. The first +level describes the PMIC containing the regulators and must reside within an +RPMh device node. The second level describes each regulator within the PMIC +which is to be used on the board. Each of these regulators maps to a single +RPMh resource. + +The names used for regulator nodes must match those supported by a given PMIC. +Supported regulator node names: + PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2 + PMI8998: bob + PM8005: smps1 - smps4 + +======================== +First Level Nodes - PMIC +======================== + +- compatible + Usage: required + Value type: <string> + Definition: Must be one of: "qcom,pm8998-rpmh-regulators", + "qcom,pmi8998-rpmh-regulators" or + "qcom,pm8005-rpmh-regulators". + +- qcom,pmic-id + Usage: required + Value type: <string> + Definition: RPMh resource name suffix used for the regulators found on + this PMIC. Typical values: "a", "b", "c", "d", "e", "f". + +- vdd-s1-supply +- vdd-s2-supply +- vdd-s3-supply +- vdd-s4-supply + Usage: optional (PM8998 and PM8005 only) + Value type: <phandle> + Definition: phandle of the parent supply regulator of one or more of the + regulators for this PMIC. + +- vdd-s5-supply +- vdd-s6-supply +- vdd-s7-supply +- vdd-s8-supply +- vdd-s9-supply +- vdd-s10-supply +- vdd-s11-supply +- vdd-s12-supply +- vdd-s13-supply +- vdd-l1-l27-supply +- vdd-l2-l8-l17-supply +- vdd-l3-l11-supply +- vdd-l4-l5-supply +- vdd-l6-supply +- vdd-l7-l12-l14-l15-supply +- vdd-l9-supply +- vdd-l10-l23-l25-supply +- vdd-l13-l19-l21-supply +- vdd-l16-l28-supply +- vdd-l18-l22-supply +- vdd-l20-l24-supply +- vdd-l26-supply +- vin-lvs-1-2-supply + Usage: optional (PM8998 only) + Value type: <phandle> + Definition: phandle of the parent supply regulator of one or more of the + regulators for this PMIC. + +- vdd-bob-supply + Usage: optional (PMI8998 only) + Value type: <phandle> + Definition: BOB regulator parent supply phandle + +=============================== +Second Level Nodes - Regulators +=============================== + +- qcom,regulator-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). + +- 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,regulator-drms-modes (matched 1-to-1 in order). + Elements must be specified in order from lowest to highest + value. + +- qcom,always-wait-for-ack + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the application processor + must wait for an ACK or a NACK from RPMh for every request + sent for this regulator including those which are for a + strictly lower power state. + +Other properties defined in Documentation/devicetree/bindings/regulator.txt +may also be used. regulator-initial-mode and regulator-allowed-modes may be +specified for VRM regulators using mode values from [1]. regulator-allow-bypass +may be specified for BOB type regulators managed via VRM. +regulator-allow-set-load may be specified for VRM regulators. It is used in +conjunction with qcom,regulator-drms-modes and qcom,drms-mode-max-microamps to +define a dynamic total load current to mode mapping. + +[1] include/dt-bindings/regulator/qcom,rpmh-regulator.h + +======== +Examples +======== + +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> + +&apps_rsc { + pm8998-rpmh-regulators { + compatible = "qcom,pm8998-rpmh-regulators"; + qcom,pmic-id = "a"; + + vdd-l7-l12-l14-l15-supply = <&pm8998_s5>; + + smps2 { + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + }; + + pm8998_s5: smps5 { + regulator-min-microvolt = <1904000>; + regulator-max-microvolt = <2040000>; + }; + + ldo7 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>; + regulator-allowed-modes = + <RPMH_REGULATOR_MODE_LPM + RPMH_REGULATOR_MODE_HPM>; + regulator-allow-set-load; + qcom,regulator-drms-modes = + <RPMH_REGULATOR_MODE_LPM + RPMH_REGULATOR_MODE_HPM>; + qcom,drms-mode-max-microamps = <10000 1000000>; + }; + + lvs1 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + }; + + pmi8998-rpmh-regulators { + compatible = "qcom,pmi8998-rpmh-regulators"; + qcom,pmic-id = "b"; + + bob { + regulator-min-microvolt = <3312000>; + regulator-max-microvolt = <3600000>; + regulator-allowed-modes = + <RPMH_REGULATOR_MODE_AUTO + RPMH_REGULATOR_MODE_HPM>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>; + }; + }; +}; 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..86713dc --- /dev/null +++ b/include/dt-bindings/regulator/qcom,rpmh-regulator.h @@ -0,0 +1,36 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */ + +#ifndef __QCOM_RPMH_REGULATOR_H +#define __QCOM_RPMH_REGULATOR_H + +/* + * These mode constants may be used to specify modes for various RPMh regulator + * device tree properties (e.g. regulator-initial-mode). Each type of regulator + * supports a subset of the possible modes. + * + * %RPMH_REGULATOR_MODE_RET: Retention mode in which only an extremely small + * load current is allowed. This mode is supported + * by LDO and SMPS type regulators. + * %RPMH_REGULATOR_MODE_LPM: Low power mode in which a small load current is + * allowed. This mode corresponds to PFM for SMPS + * and BOB type regulators. This mode is supported + * by LDO, HFSMPS, BOB, and PMIC4 FTSMPS type + * regulators. + * %RPMH_REGULATOR_MODE_AUTO: Auto mode in which the regulator hardware + * automatically switches between LPM and HPM based + * upon the real-time load current. This mode is + * supported by HFSMPS, BOB, and PMIC4 FTSMPS type + * regulators. + * %RPMH_REGULATOR_MODE_HPM: High power mode in which the full rated current + * of the regulator is allowed. This mode + * corresponds to PWM for SMPS and BOB type + * regulators. This mode is supported by all types + * of regulators. + */ +#define RPMH_REGULATOR_MODE_RET 0 +#define RPMH_REGULATOR_MODE_LPM 1 +#define RPMH_REGULATOR_MODE_AUTO 2 +#define RPMH_REGULATOR_MODE_HPM 3 + +#endif
Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine the final PMIC regulator hardware state. Signed-off-by: David Collins <collinsd@codeaurora.org> --- .../bindings/regulator/qcom,rpmh-regulator.txt | 185 +++++++++++++++++++++ .../dt-bindings/regulator/qcom,rpmh-regulator.h | 36 ++++ 2 files changed, 221 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h