* [PATCH v8 0/2] regulator: add QCOM RPMh regulator driver @ 2018-06-23 0:46 David Collins 2018-06-23 0:46 ` [PATCH v8 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings David Collins 2018-06-23 0:46 ` [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver David Collins 0 siblings, 2 replies; 17+ messages in thread From: David Collins @ 2018-06-23 0:46 UTC (permalink / raw) To: broonie, lgirdwood, robh+dt, mark.rutland Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree, linux-kernel, rnayak, sboyd, dianders, mka This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC. The final hardware state of a regulator is determined within RPMh by performing max aggregation of the requests made by all of the processors. The RPMh regulator driver depends upon the RPMh driver [1] and command DB driver [2] which are both still undergoing review. It also depends upon three recent regulator patches: [3], [4], and [5] as well as an RPMh helper patch [6]. Changes since v7 [7]: - Removed the cmd_db_ready() call from the driver probe function as it is now handled by the RPMh driver itself [6] - Added Reviewed-by tag for driver patch 2/2 Changes since v6 [8]: - Removed 'count' parameter from rpmh_regulator_send_request() since it is always 1 - Fixed _rpmh_regulator_vrm_set_voltage_sel() return value - Added a helper function to capture common code between rpmh_regulator_enable() and rpmh_regulator_disable() - Added an iterator for pmic_rpmh_data in rpmh_regulator_init_vreg() - Added Reviewed-by tag for both patches Changes since v5 [9]: - Removed unused constants - Added Reviewed-by tag for DT patch 1/2 Changes since v4 [10]: - Removed support for DT properties qcom,regulator-drms-modes and qcom,drms-mode-max-microamps - Specified fixed DRMS high power mode minimum limits for LDO type regulators - Removed DRMS support for SMPS and BOB type regulators - Simplified voltage caching logic Changes since v3 [11]: - Removed support for DT properties qcom,regulator-initial-microvolt and qcom,headroom-microvolt - Renamed DT property qcom,allowed-drms-modes to be qcom,regulator-drms-modes - Updated DT binding documentation to mention which common regulator bindings can be used for qcom-rpmh-regulator devices - Added voltage caching so that voltage requests are only sent to RPMh after the regulator has been enabled at least once - Changed 'voltage_selector' default value to be -ENOTRECOVERABLE to interact with [5] - Initialized 'enabled' to -EINVAL so that unused regulators are disabled by regulator_late_cleanup() - Removed rpmh_regulator_load_default_parameters() as it is no longer needed - Updated the mode usage description in qcom,rpmh-regulator.h Changes since v2 [12]: - Replaced '_' with '-' in device tree supply property names - Renamed qcom_rpmh-regulator.c to be qcom-rpmh-regulator.c - Updated various DT property names to use "microvolt" and "microamp" - Moved allowed modes constraint specification out of the driver [4] - Replaced rpmh_client with device pointer to match new RPMh API [1] - Corrected drms mode threshold checking - Initialized voltage_selector to -EINVAL when not specified in DT - Added constants for PMIC regulator hardware modes - Corrected type sign of mode mapping tables - Made variable names for mode arrays plural - Simplified Kconfig depends on - Removed unnecessary constants and struct fields - Added some descriptive comments Changes since v1 [13]: - Addressed review feedback from Doug, Mark, and Stephen - Replaced set_voltage()/get_voltage() callbacks with set_voltage_sel()/ get_voltage_sel() - Added set_bypass()/get_bypass() callbacks for BOB pass-through mode control - Removed top-level PMIC data structures - Removed initialization variables from structs and passed them as function parameters - Removed various comments and error messages - Simplified mode handling - Refactored per-PMIC rpmh-regulator data specification - Simplified probe function - Moved header into DT patch - Removed redundant property listings from DT binding documentation [1]: https://lkml.org/lkml/2018/6/20/519 [2]: https://lkml.org/lkml/2018/4/10/714 [3]: https://lkml.org/lkml/2018/4/18/556 [4]: https://lkml.org/lkml/2018/5/11/696 [5]: https://lkml.org/lkml/2018/5/15/1005 [6]: https://lkml.org/lkml/2018/6/18/1188 [7]: https://lkml.org/lkml/2018/6/8/573 [8]: https://lkml.org/lkml/2018/6/4/879 [9]: https://lkml.org/lkml/2018/6/1/895 [10]: https://lkml.org/lkml/2018/5/22/1168 [11]: https://lkml.org/lkml/2018/5/11/701 [12]: https://lkml.org/lkml/2018/4/13/687 [13]: https://lkml.org/lkml/2018/3/16/1431 David Collins (2): regulator: dt-bindings: add QCOM RPMh regulator bindings regulator: add QCOM RPMh regulator driver .../bindings/regulator/qcom,rpmh-regulator.txt | 160 +++++ drivers/regulator/Kconfig | 9 + drivers/regulator/Makefile | 1 + drivers/regulator/qcom-rpmh-regulator.c | 746 +++++++++++++++++++++ .../dt-bindings/regulator/qcom,rpmh-regulator.h | 36 + 5 files changed, 952 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt create mode 100644 drivers/regulator/qcom-rpmh-regulator.c create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v8 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings 2018-06-23 0:46 [PATCH v8 0/2] regulator: add QCOM RPMh regulator driver David Collins @ 2018-06-23 0:46 ` David Collins 2018-06-23 0:46 ` [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver David Collins 1 sibling, 0 replies; 17+ messages in thread From: David Collins @ 2018-06-23 0:46 UTC (permalink / raw) To: broonie, lgirdwood, robh+dt, mark.rutland Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree, linux-kernel, rnayak, sboyd, dianders, mka 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> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> --- .../bindings/regulator/qcom,rpmh-regulator.txt | 160 +++++++++++++++++++++ .../dt-bindings/regulator/qcom,rpmh-regulator.h | 36 +++++ 2 files changed, 196 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h 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..7ef2dbe --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt @@ -0,0 +1,160 @@ +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,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 +include/dt-bindings/regulator/qcom,rpmh-regulator.h. regulator-allow-bypass +may be specified for BOB type regulators managed via VRM. +regulator-allow-set-load may be specified for LDO type regulators managed via +VRM. + +======== +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_HPM>; + regulator-allowed-modes = + <RPMH_REGULATOR_MODE_LPM + RPMH_REGULATOR_MODE_HPM>; + regulator-allow-set-load; + }; + + 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 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-23 0:46 [PATCH v8 0/2] regulator: add QCOM RPMh regulator driver David Collins 2018-06-23 0:46 ` [PATCH v8 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings David Collins @ 2018-06-23 0:46 ` David Collins 2018-06-25 18:50 ` Doug Anderson 2018-07-02 10:28 ` Mark Brown 1 sibling, 2 replies; 17+ messages in thread From: David Collins @ 2018-06-23 0:46 UTC (permalink / raw) To: broonie, lgirdwood, robh+dt, mark.rutland Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree, linux-kernel, rnayak, sboyd, dianders, mka Add the QCOM RPMh regulator driver to manage PMIC regulators which are controlled via RPMh on some Qualcomm Technologies, Inc. SoCs. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC. The final hardware state of a regulator is determined within RPMh by performing max aggregation of the requests made by all of the processors. Add support for PMIC regulator control via the voltage regulator manager (VRM) and oscillator buffer (XOB) RPMh accelerators. VRM supports manipulation of enable state, voltage, and mode. XOB supports manipulation of enable state. Signed-off-by: David Collins <collinsd@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> --- drivers/regulator/Kconfig | 9 + drivers/regulator/Makefile | 1 + drivers/regulator/qcom-rpmh-regulator.c | 746 ++++++++++++++++++++++++++++++++ 3 files changed, 756 insertions(+) create mode 100644 drivers/regulator/qcom-rpmh-regulator.c diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index 2964eaea..f9ef567 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -682,6 +682,15 @@ config REGULATOR_QCOM_RPM Qualcomm RPM as a module. The module will be named "qcom_rpm-regulator". +config REGULATOR_QCOM_RPMH + tristate "Qualcomm Technologies, Inc. RPMh regulator driver" + depends on QCOM_RPMH || COMPILE_TEST + help + This driver supports control of PMIC regulators via the RPMh hardware + block found on Qualcomm Technologies Inc. SoCs. RPMh regulator + control allows for voting on regulator state between multiple + processors within the SoC. + config REGULATOR_QCOM_SMD_RPM tristate "Qualcomm SMD based RPM regulator driver" depends on QCOM_SMD_RPM diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index bd818ce..06e76a6 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -78,6 +78,7 @@ obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o +obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c new file mode 100644 index 0000000..422bb81 --- /dev/null +++ b/drivers/regulator/qcom-rpmh-regulator.c @@ -0,0 +1,746 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */ + +#define pr_fmt(fmt) "%s: " fmt, __func__ + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/of_device.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/string.h> +#include <linux/regulator/driver.h> +#include <linux/regulator/machine.h> +#include <linux/regulator/of_regulator.h> + +#include <soc/qcom/cmd-db.h> +#include <soc/qcom/rpmh.h> + +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> + +/** + * enum rpmh_regulator_type - supported RPMh accelerator types + * %VRM: RPMh VRM accelerator which supports voting on enable, voltage, + * and mode of LDO, SMPS, and BOB type PMIC regulators. + * %XOB: RPMh XOB accelerator which supports voting on the enable state + * of PMIC regulators. + */ +enum rpmh_regulator_type { + VRM, + XOB, +}; + +#define RPMH_REGULATOR_REG_VRM_VOLTAGE 0x0 +#define RPMH_REGULATOR_REG_ENABLE 0x4 +#define RPMH_REGULATOR_REG_VRM_MODE 0x8 + +#define RPMH_REGULATOR_MODE_COUNT 4 + +#define PMIC4_LDO_MODE_RETENTION 4 +#define PMIC4_LDO_MODE_LPM 5 +#define PMIC4_LDO_MODE_HPM 7 + +#define PMIC4_SMPS_MODE_RETENTION 4 +#define PMIC4_SMPS_MODE_PFM 5 +#define PMIC4_SMPS_MODE_AUTO 6 +#define PMIC4_SMPS_MODE_PWM 7 + +#define PMIC4_BOB_MODE_PASS 0 +#define PMIC4_BOB_MODE_PFM 1 +#define PMIC4_BOB_MODE_AUTO 2 +#define PMIC4_BOB_MODE_PWM 3 + +/** + * struct rpmh_vreg_hw_data - RPMh regulator hardware configurations + * @regulator_type: RPMh accelerator type used to manage this + * regulator + * @ops: Pointer to regulator ops callback structure + * @voltage_range: The single range of voltages supported by this + * PMIC regulator type + * @n_voltages: The number of unique voltage set points defined + * by voltage_range + * @hpm_min_load_uA: Minimum load current in microamps that requires + * high power mode (HPM) operation. This is used + * for LDO hardware type regulators only. + * @pmic_mode_map: Array indexed by regulator framework mode + * containing PMIC hardware modes. Must be large + * enough to index all framework modes supported + * by this regulator hardware type. + * @of_map_mode: Maps an RPMH_REGULATOR_MODE_* mode value defined + * in device tree to a regulator framework mode + */ +struct rpmh_vreg_hw_data { + enum rpmh_regulator_type regulator_type; + const struct regulator_ops *ops; + const struct regulator_linear_range voltage_range; + int n_voltages; + int hpm_min_load_uA; + const int *pmic_mode_map; + unsigned int (*of_map_mode)(unsigned int mode); +}; + +/** + * struct rpmh_vreg - individual RPMh regulator data structure encapsulating a + * single regulator device + * @dev: Device pointer for the top-level PMIC RPMh + * regulator parent device. This is used as a + * handle in RPMh write requests. + * @addr: Base address of the regulator resource within + * an RPMh accelerator + * @rdesc: Regulator descriptor + * @hw_data: PMIC regulator configuration data for this RPMh + * regulator + * @always_wait_for_ack: Boolean flag indicating if a request must always + * wait for an ACK from RPMh before continuing even + * if it corresponds to a strictly lower power + * state (e.g. enabled --> disabled). + * @enabled: Flag indicating if the regulator is enabled or + * not + * @bypassed: Boolean indicating if the regulator is in + * bypass (pass-through) mode or not. This is + * only used by BOB rpmh-regulator resources. + * @voltage_selector: Selector used for get_voltage_sel() and + * set_voltage_sel() callbacks + * @mode: RPMh VRM regulator current framework mode + */ +struct rpmh_vreg { + struct device *dev; + u32 addr; + struct regulator_desc rdesc; + const struct rpmh_vreg_hw_data *hw_data; + bool always_wait_for_ack; + + int enabled; + bool bypassed; + int voltage_selector; + unsigned int mode; +}; + +/** + * struct rpmh_vreg_init_data - initialization data for an RPMh regulator + * @name: Name for the regulator which also corresponds + * to the device tree subnode name of the regulator + * @resource_name: RPMh regulator resource name format string. + * This must include exactly one field: '%s' which + * is filled at run-time with the PMIC ID provided + * by device tree property qcom,pmic-id. Example: + * "ldo%s1" for RPMh resource "ldoa1". + * @supply_name: Parent supply regulator name + * @hw_data: Configuration data for this PMIC regulator type + */ +struct rpmh_vreg_init_data { + const char *name; + const char *resource_name; + const char *supply_name; + const struct rpmh_vreg_hw_data *hw_data; +}; + +/** + * rpmh_regulator_send_request() - send the request to RPMh + * @vreg: Pointer to the RPMh regulator + * @cmd: Pointer to the RPMh command to send + * @wait_for_ack: Boolean indicating if execution must wait until the + * request has been acknowledged as complete + * + * Return: 0 on success, errno on failure + */ +static int rpmh_regulator_send_request(struct rpmh_vreg *vreg, + struct tcs_cmd *cmd, bool wait_for_ack) +{ + int ret; + + if (wait_for_ack || vreg->always_wait_for_ack) + ret = rpmh_write(vreg->dev, RPMH_ACTIVE_ONLY_STATE, cmd, 1); + else + ret = rpmh_write_async(vreg->dev, RPMH_ACTIVE_ONLY_STATE, cmd, + 1); + + return ret; +} + +static int _rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev, + unsigned int selector, bool wait_for_ack) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + struct tcs_cmd cmd = { + .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_VOLTAGE, + }; + int ret; + + /* VRM voltage control register is set with voltage in millivolts. */ + cmd.data = DIV_ROUND_UP(regulator_list_voltage_linear_range(rdev, + selector), 1000); + + ret = rpmh_regulator_send_request(vreg, &cmd, wait_for_ack); + if (!ret) + vreg->voltage_selector = selector; + + return ret; +} + +static int rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev, + unsigned int selector) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + + if (vreg->enabled == -EINVAL) { + /* + * Cache the voltage and send it later when the regulator is + * enabled or disabled. + */ + vreg->voltage_selector = selector; + return 0; + } + + return _rpmh_regulator_vrm_set_voltage_sel(rdev, selector, + selector > vreg->voltage_selector); +} + +static int rpmh_regulator_vrm_get_voltage_sel(struct regulator_dev *rdev) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + + return vreg->voltage_selector; +} + +static int rpmh_regulator_is_enabled(struct regulator_dev *rdev) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + + return vreg->enabled; +} + +static int rpmh_regulator_set_enable_state(struct regulator_dev *rdev, + bool enable) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + struct tcs_cmd cmd = { + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE, + .data = enable, + }; + int ret; + + if (vreg->enabled == -EINVAL && + vreg->voltage_selector != -ENOTRECOVERABLE) { + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev, + vreg->voltage_selector, true); + if (ret < 0) + return ret; + } + + ret = rpmh_regulator_send_request(vreg, &cmd, enable); + if (!ret) + vreg->enabled = enable; + + return ret; +} + +static int rpmh_regulator_enable(struct regulator_dev *rdev) +{ + return rpmh_regulator_set_enable_state(rdev, true); +} + +static int rpmh_regulator_disable(struct regulator_dev *rdev) +{ + return rpmh_regulator_set_enable_state(rdev, false); +} + +static int rpmh_regulator_vrm_set_mode_bypass(struct rpmh_vreg *vreg, + unsigned int mode, bool bypassed) +{ + struct tcs_cmd cmd = { + .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_MODE, + }; + int pmic_mode; + + if (mode > REGULATOR_MODE_STANDBY) + return -EINVAL; + + pmic_mode = vreg->hw_data->pmic_mode_map[mode]; + if (pmic_mode < 0) + return pmic_mode; + + cmd.data = bypassed ? PMIC4_BOB_MODE_PASS : pmic_mode; + + return rpmh_regulator_send_request(vreg, &cmd, true); +} + +static int rpmh_regulator_vrm_set_mode(struct regulator_dev *rdev, + unsigned int mode) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + int ret; + + if (mode == vreg->mode) + return 0; + + ret = rpmh_regulator_vrm_set_mode_bypass(vreg, mode, vreg->bypassed); + if (!ret) + vreg->mode = mode; + + return ret; +} + +static unsigned int rpmh_regulator_vrm_get_mode(struct regulator_dev *rdev) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + + return vreg->mode; +} + +/** + * rpmh_regulator_vrm_set_load() - set the regulator mode based upon the load + * current requested + * @rdev: Regulator device pointer for the rpmh-regulator + * @load_uA: Aggregated load current in microamps + * + * This function is used in the regulator_ops for VRM type RPMh regulator + * devices. + * + * Return: 0 on success, errno on failure + */ +static int rpmh_regulator_vrm_set_load(struct regulator_dev *rdev, int load_uA) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + unsigned int mode; + + if (load_uA >= vreg->hw_data->hpm_min_load_uA) + mode = REGULATOR_MODE_FAST; + else + mode = REGULATOR_MODE_IDLE; + + return rpmh_regulator_vrm_set_mode(rdev, mode); +} + +static int rpmh_regulator_vrm_set_bypass(struct regulator_dev *rdev, + bool enable) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + int ret; + + if (vreg->bypassed == enable) + return 0; + + ret = rpmh_regulator_vrm_set_mode_bypass(vreg, vreg->mode, enable); + if (!ret) + vreg->bypassed = enable; + + return ret; +} + +static int rpmh_regulator_vrm_get_bypass(struct regulator_dev *rdev, + bool *enable) +{ + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev); + + *enable = vreg->bypassed; + + return 0; +} + +static const struct regulator_ops rpmh_regulator_vrm_ops = { + .enable = rpmh_regulator_enable, + .disable = rpmh_regulator_disable, + .is_enabled = rpmh_regulator_is_enabled, + .set_voltage_sel = rpmh_regulator_vrm_set_voltage_sel, + .get_voltage_sel = rpmh_regulator_vrm_get_voltage_sel, + .list_voltage = regulator_list_voltage_linear_range, + .set_mode = rpmh_regulator_vrm_set_mode, + .get_mode = rpmh_regulator_vrm_get_mode, +}; + +static const struct regulator_ops rpmh_regulator_vrm_drms_ops = { + .enable = rpmh_regulator_enable, + .disable = rpmh_regulator_disable, + .is_enabled = rpmh_regulator_is_enabled, + .set_voltage_sel = rpmh_regulator_vrm_set_voltage_sel, + .get_voltage_sel = rpmh_regulator_vrm_get_voltage_sel, + .list_voltage = regulator_list_voltage_linear_range, + .set_mode = rpmh_regulator_vrm_set_mode, + .get_mode = rpmh_regulator_vrm_get_mode, + .set_load = rpmh_regulator_vrm_set_load, +}; + +static const struct regulator_ops rpmh_regulator_vrm_bypass_ops = { + .enable = rpmh_regulator_enable, + .disable = rpmh_regulator_disable, + .is_enabled = rpmh_regulator_is_enabled, + .set_voltage_sel = rpmh_regulator_vrm_set_voltage_sel, + .get_voltage_sel = rpmh_regulator_vrm_get_voltage_sel, + .list_voltage = regulator_list_voltage_linear_range, + .set_mode = rpmh_regulator_vrm_set_mode, + .get_mode = rpmh_regulator_vrm_get_mode, + .set_bypass = rpmh_regulator_vrm_set_bypass, + .get_bypass = rpmh_regulator_vrm_get_bypass, +}; + +static const struct regulator_ops rpmh_regulator_xob_ops = { + .enable = rpmh_regulator_enable, + .disable = rpmh_regulator_disable, + .is_enabled = rpmh_regulator_is_enabled, +}; + +/** + * rpmh_regulator_init_vreg() - initialize all attributes of an rpmh-regulator + * vreg: Pointer to the individual rpmh-regulator resource + * dev: Pointer to the top level rpmh-regulator PMIC device + * node: Pointer to the individual rpmh-regulator resource + * device node + * pmic_id: String used to identify the top level rpmh-regulator + * PMIC device on the board + * pmic_rpmh_data: Pointer to a null-terminated array of rpmh-regulator + * resources defined for the top level PMIC device + * + * Return: 0 on success, errno on failure + */ +static int rpmh_regulator_init_vreg(struct rpmh_vreg *vreg, struct device *dev, + struct device_node *node, const char *pmic_id, + const struct rpmh_vreg_init_data *pmic_rpmh_data) +{ + struct regulator_config reg_config = {}; + char rpmh_resource_name[20] = ""; + const struct rpmh_vreg_init_data *rpmh_data; + struct regulator_init_data *init_data; + struct regulator_dev *rdev; + int ret; + + vreg->dev = dev; + + for (rpmh_data = pmic_rpmh_data; rpmh_data->name; rpmh_data++) + if (!strcmp(rpmh_data->name, node->name)) + break; + + if (!rpmh_data->name) { + dev_err(dev, "Unknown regulator %s\n", node->name); + return -EINVAL; + } + + scnprintf(rpmh_resource_name, sizeof(rpmh_resource_name), + rpmh_data->resource_name, pmic_id); + + vreg->addr = cmd_db_read_addr(rpmh_resource_name); + if (!vreg->addr) { + dev_err(dev, "%s: could not find RPMh address for resource %s\n", + node->name, rpmh_resource_name); + return -ENODEV; + } + + vreg->rdesc.name = rpmh_data->name; + vreg->rdesc.supply_name = rpmh_data->supply_name; + vreg->hw_data = rpmh_data->hw_data; + + vreg->enabled = -EINVAL; + vreg->voltage_selector = -ENOTRECOVERABLE; + vreg->mode = REGULATOR_MODE_INVALID; + + if (rpmh_data->hw_data->n_voltages) { + vreg->rdesc.linear_ranges = &rpmh_data->hw_data->voltage_range; + vreg->rdesc.n_linear_ranges = 1; + vreg->rdesc.n_voltages = rpmh_data->hw_data->n_voltages; + } + + vreg->always_wait_for_ack = of_property_read_bool(node, + "qcom,always-wait-for-ack"); + + vreg->rdesc.owner = THIS_MODULE; + vreg->rdesc.type = REGULATOR_VOLTAGE; + vreg->rdesc.ops = vreg->hw_data->ops; + vreg->rdesc.of_map_mode = vreg->hw_data->of_map_mode; + + init_data = of_get_regulator_init_data(dev, node, &vreg->rdesc); + if (!init_data) + return -ENOMEM; + + if (rpmh_data->hw_data->regulator_type == XOB && + init_data->constraints.min_uV && + init_data->constraints.min_uV == init_data->constraints.max_uV) { + vreg->rdesc.fixed_uV = init_data->constraints.min_uV; + vreg->rdesc.n_voltages = 1; + } + + reg_config.dev = dev; + reg_config.init_data = init_data; + reg_config.of_node = node; + reg_config.driver_data = vreg; + + rdev = devm_regulator_register(dev, &vreg->rdesc, ®_config); + if (IS_ERR(rdev)) { + ret = PTR_ERR(rdev); + dev_err(dev, "%s: devm_regulator_register() failed, ret=%d\n", + node->name, ret); + return ret; + } + + dev_dbg(dev, "%s regulator registered for RPMh resource %s @ 0x%05X\n", + node->name, rpmh_resource_name, vreg->addr); + + return 0; +} + +static const int pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = { + [REGULATOR_MODE_INVALID] = -EINVAL, + [REGULATOR_MODE_STANDBY] = PMIC4_LDO_MODE_RETENTION, + [REGULATOR_MODE_IDLE] = PMIC4_LDO_MODE_LPM, + [REGULATOR_MODE_NORMAL] = -EINVAL, + [REGULATOR_MODE_FAST] = PMIC4_LDO_MODE_HPM, +}; + +static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int mode) +{ + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = { + [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY, + [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE, + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_INVALID, + [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST, + }; + + if (mode >= RPMH_REGULATOR_MODE_COUNT) + return -EINVAL; + + return of_mode_map[mode]; +} + +static const int pmic_mode_map_pmic4_smps[REGULATOR_MODE_STANDBY + 1] = { + [REGULATOR_MODE_INVALID] = -EINVAL, + [REGULATOR_MODE_STANDBY] = PMIC4_SMPS_MODE_RETENTION, + [REGULATOR_MODE_IDLE] = PMIC4_SMPS_MODE_PFM, + [REGULATOR_MODE_NORMAL] = PMIC4_SMPS_MODE_AUTO, + [REGULATOR_MODE_FAST] = PMIC4_SMPS_MODE_PWM, +}; + +static unsigned int rpmh_regulator_pmic4_smps_of_map_mode(unsigned int mode) +{ + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = { + [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY, + [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE, + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_NORMAL, + [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST, + }; + + if (mode >= RPMH_REGULATOR_MODE_COUNT) + return -EINVAL; + + return of_mode_map[mode]; +} + +static const int pmic_mode_map_pmic4_bob[REGULATOR_MODE_STANDBY + 1] = { + [REGULATOR_MODE_INVALID] = -EINVAL, + [REGULATOR_MODE_STANDBY] = -EINVAL, + [REGULATOR_MODE_IDLE] = PMIC4_BOB_MODE_PFM, + [REGULATOR_MODE_NORMAL] = PMIC4_BOB_MODE_AUTO, + [REGULATOR_MODE_FAST] = PMIC4_BOB_MODE_PWM, +}; + +static unsigned int rpmh_regulator_pmic4_bob_of_map_mode(unsigned int mode) +{ + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = { + [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_INVALID, + [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE, + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_NORMAL, + [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST, + }; + + if (mode >= RPMH_REGULATOR_MODE_COUNT) + return -EINVAL; + + return of_mode_map[mode]; +} + +static const struct rpmh_vreg_hw_data pmic4_pldo = { + .regulator_type = VRM, + .ops = &rpmh_regulator_vrm_drms_ops, + .voltage_range = REGULATOR_LINEAR_RANGE(1664000, 0, 255, 8000), + .n_voltages = 256, + .hpm_min_load_uA = 10000, + .pmic_mode_map = pmic_mode_map_pmic4_ldo, + .of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode, +}; + +static const struct rpmh_vreg_hw_data pmic4_pldo_lv = { + .regulator_type = VRM, + .ops = &rpmh_regulator_vrm_drms_ops, + .voltage_range = REGULATOR_LINEAR_RANGE(1256000, 0, 127, 8000), + .n_voltages = 128, + .hpm_min_load_uA = 10000, + .pmic_mode_map = pmic_mode_map_pmic4_ldo, + .of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode, +}; + +static const struct rpmh_vreg_hw_data pmic4_nldo = { + .regulator_type = VRM, + .ops = &rpmh_regulator_vrm_drms_ops, + .voltage_range = REGULATOR_LINEAR_RANGE(312000, 0, 127, 8000), + .n_voltages = 128, + .hpm_min_load_uA = 30000, + .pmic_mode_map = pmic_mode_map_pmic4_ldo, + .of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode, +}; + +static const struct rpmh_vreg_hw_data pmic4_hfsmps3 = { + .regulator_type = VRM, + .ops = &rpmh_regulator_vrm_ops, + .voltage_range = REGULATOR_LINEAR_RANGE(320000, 0, 215, 8000), + .n_voltages = 216, + .pmic_mode_map = pmic_mode_map_pmic4_smps, + .of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode, +}; + +static const struct rpmh_vreg_hw_data pmic4_ftsmps426 = { + .regulator_type = VRM, + .ops = &rpmh_regulator_vrm_ops, + .voltage_range = REGULATOR_LINEAR_RANGE(320000, 0, 258, 4000), + .n_voltages = 259, + .pmic_mode_map = pmic_mode_map_pmic4_smps, + .of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode, +}; + +static const struct rpmh_vreg_hw_data pmic4_bob = { + .regulator_type = VRM, + .ops = &rpmh_regulator_vrm_bypass_ops, + .voltage_range = REGULATOR_LINEAR_RANGE(1824000, 0, 83, 32000), + .n_voltages = 84, + .pmic_mode_map = pmic_mode_map_pmic4_bob, + .of_map_mode = rpmh_regulator_pmic4_bob_of_map_mode, +}; + +static const struct rpmh_vreg_hw_data pmic4_lvs = { + .regulator_type = XOB, + .ops = &rpmh_regulator_xob_ops, + /* LVS hardware does not support voltage or mode configuration. */ +}; + +#define RPMH_VREG(_name, _resource_name, _hw_data, _supply_name) \ +{ \ + .name = _name, \ + .resource_name = _resource_name, \ + .hw_data = _hw_data, \ + .supply_name = _supply_name, \ +} + +static const struct rpmh_vreg_init_data pm8998_vreg_data[] = { + RPMH_VREG("smps1", "smp%s1", &pmic4_ftsmps426, "vdd-s1"), + RPMH_VREG("smps2", "smp%s2", &pmic4_ftsmps426, "vdd-s2"), + RPMH_VREG("smps3", "smp%s3", &pmic4_hfsmps3, "vdd-s3"), + RPMH_VREG("smps4", "smp%s4", &pmic4_hfsmps3, "vdd-s4"), + RPMH_VREG("smps5", "smp%s5", &pmic4_hfsmps3, "vdd-s5"), + RPMH_VREG("smps6", "smp%s6", &pmic4_ftsmps426, "vdd-s6"), + RPMH_VREG("smps7", "smp%s7", &pmic4_ftsmps426, "vdd-s7"), + RPMH_VREG("smps8", "smp%s8", &pmic4_ftsmps426, "vdd-s8"), + RPMH_VREG("smps9", "smp%s9", &pmic4_ftsmps426, "vdd-s9"), + RPMH_VREG("smps10", "smp%s10", &pmic4_ftsmps426, "vdd-s10"), + RPMH_VREG("smps11", "smp%s11", &pmic4_ftsmps426, "vdd-s11"), + RPMH_VREG("smps12", "smp%s12", &pmic4_ftsmps426, "vdd-s12"), + RPMH_VREG("smps13", "smp%s13", &pmic4_ftsmps426, "vdd-s13"), + RPMH_VREG("ldo1", "ldo%s1", &pmic4_nldo, "vdd-l1-l27"), + RPMH_VREG("ldo2", "ldo%s2", &pmic4_nldo, "vdd-l2-l8-l17"), + RPMH_VREG("ldo3", "ldo%s3", &pmic4_nldo, "vdd-l3-l11"), + RPMH_VREG("ldo4", "ldo%s4", &pmic4_nldo, "vdd-l4-l5"), + RPMH_VREG("ldo5", "ldo%s5", &pmic4_nldo, "vdd-l4-l5"), + RPMH_VREG("ldo6", "ldo%s6", &pmic4_pldo, "vdd-l6"), + RPMH_VREG("ldo7", "ldo%s7", &pmic4_pldo_lv, "vdd-l7-l12-l14-l15"), + RPMH_VREG("ldo8", "ldo%s8", &pmic4_nldo, "vdd-l2-l8-l17"), + RPMH_VREG("ldo9", "ldo%s9", &pmic4_pldo, "vdd-l9"), + RPMH_VREG("ldo10", "ldo%s10", &pmic4_pldo, "vdd-l10-l23-l25"), + RPMH_VREG("ldo11", "ldo%s11", &pmic4_nldo, "vdd-l3-l11"), + RPMH_VREG("ldo12", "ldo%s12", &pmic4_pldo_lv, "vdd-l7-l12-l14-l15"), + RPMH_VREG("ldo13", "ldo%s13", &pmic4_pldo, "vdd-l13-l19-l21"), + RPMH_VREG("ldo14", "ldo%s14", &pmic4_pldo_lv, "vdd-l7-l12-l14-l15"), + RPMH_VREG("ldo15", "ldo%s15", &pmic4_pldo_lv, "vdd-l7-l12-l14-l15"), + RPMH_VREG("ldo16", "ldo%s16", &pmic4_pldo, "vdd-l16-l28"), + RPMH_VREG("ldo17", "ldo%s17", &pmic4_nldo, "vdd-l2-l8-l17"), + RPMH_VREG("ldo18", "ldo%s18", &pmic4_pldo, "vdd-l18-l22"), + RPMH_VREG("ldo19", "ldo%s19", &pmic4_pldo, "vdd-l13-l19-l21"), + RPMH_VREG("ldo20", "ldo%s20", &pmic4_pldo, "vdd-l20-l24"), + RPMH_VREG("ldo21", "ldo%s21", &pmic4_pldo, "vdd-l13-l19-l21"), + RPMH_VREG("ldo22", "ldo%s22", &pmic4_pldo, "vdd-l18-l22"), + RPMH_VREG("ldo23", "ldo%s23", &pmic4_pldo, "vdd-l10-l23-l25"), + RPMH_VREG("ldo24", "ldo%s24", &pmic4_pldo, "vdd-l20-l24"), + RPMH_VREG("ldo25", "ldo%s25", &pmic4_pldo, "vdd-l10-l23-l25"), + RPMH_VREG("ldo26", "ldo%s26", &pmic4_nldo, "vdd-l26"), + RPMH_VREG("ldo27", "ldo%s27", &pmic4_nldo, "vdd-l1-l27"), + RPMH_VREG("ldo28", "ldo%s28", &pmic4_pldo, "vdd-l16-l28"), + RPMH_VREG("lvs1", "vs%s1", &pmic4_lvs, "vin-lvs-1-2"), + RPMH_VREG("lvs2", "vs%s2", &pmic4_lvs, "vin-lvs-1-2"), + {}, +}; + +static const struct rpmh_vreg_init_data pmi8998_vreg_data[] = { + RPMH_VREG("bob", "bob%s1", &pmic4_bob, "vdd-bob"), + {}, +}; + +static const struct rpmh_vreg_init_data pm8005_vreg_data[] = { + RPMH_VREG("smps1", "smp%s1", &pmic4_ftsmps426, "vdd-s1"), + RPMH_VREG("smps2", "smp%s2", &pmic4_ftsmps426, "vdd-s2"), + RPMH_VREG("smps3", "smp%s3", &pmic4_ftsmps426, "vdd-s3"), + RPMH_VREG("smps4", "smp%s4", &pmic4_ftsmps426, "vdd-s4"), + {}, +}; + +static int rpmh_regulator_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + const struct rpmh_vreg_init_data *vreg_data; + struct device_node *node; + struct rpmh_vreg *vreg; + const char *pmic_id; + int ret; + + vreg_data = of_device_get_match_data(dev); + if (!vreg_data) + return -ENODEV; + + ret = of_property_read_string(dev->of_node, "qcom,pmic-id", &pmic_id); + if (ret < 0) { + dev_err(dev, "qcom,pmic-id missing in DT node\n"); + return ret; + } + + for_each_available_child_of_node(dev->of_node, node) { + vreg = devm_kzalloc(dev, sizeof(*vreg), GFP_KERNEL); + if (!vreg) { + of_node_put(node); + return -ENOMEM; + } + + ret = rpmh_regulator_init_vreg(vreg, dev, node, pmic_id, + vreg_data); + if (ret < 0) { + of_node_put(node); + return ret; + } + } + + return 0; +} + +static const struct of_device_id rpmh_regulator_match_table[] = { + { + .compatible = "qcom,pm8998-rpmh-regulators", + .data = pm8998_vreg_data, + }, + { + .compatible = "qcom,pmi8998-rpmh-regulators", + .data = pmi8998_vreg_data, + }, + { + .compatible = "qcom,pm8005-rpmh-regulators", + .data = pm8005_vreg_data, + }, + {} +}; +MODULE_DEVICE_TABLE(of, rpmh_regulator_match_table); + +static struct platform_driver rpmh_regulator_driver = { + .driver = { + .name = "qcom-rpmh-regulator", + .of_match_table = of_match_ptr(rpmh_regulator_match_table), + }, + .probe = rpmh_regulator_probe, +}; +module_platform_driver(rpmh_regulator_driver); + +MODULE_DESCRIPTION("Qualcomm RPMh regulator driver"); +MODULE_LICENSE("GPL v2"); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-23 0:46 ` [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver David Collins @ 2018-06-25 18:50 ` Doug Anderson 2018-06-26 12:07 ` Mark Brown 2018-07-02 10:28 ` Mark Brown 1 sibling, 1 reply; 17+ messages in thread From: Doug Anderson @ 2018-06-25 18:50 UTC (permalink / raw) To: David Collins Cc: Mark Brown, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson Hi, On Fri, Jun 22, 2018 at 5:46 PM, David Collins <collinsd@codeaurora.org> wrote: > Add the QCOM RPMh regulator driver to manage PMIC regulators > which are controlled via RPMh on some Qualcomm Technologies, Inc. > SoCs. RPMh is a hardware block which contains several > accelerators which are used to manage various hardware resources > that are shared between the processors of the SoC. The final > hardware state of a regulator is determined within RPMh by > performing max aggregation of the requests made by all of the > processors. > > Add support for PMIC regulator control via the voltage regulator > manager (VRM) and oscillator buffer (XOB) RPMh accelerators. > VRM supports manipulation of enable state, voltage, and mode. > XOB supports manipulation of enable state. > > Signed-off-by: David Collins <collinsd@codeaurora.org> > Reviewed-by: Douglas Anderson <dianders@chromium.org> > Reviewed-by: Matthias Kaehlcke <mka@chromium.org> > --- > drivers/regulator/Kconfig | 9 + > drivers/regulator/Makefile | 1 + > drivers/regulator/qcom-rpmh-regulator.c | 746 ++++++++++++++++++++++++++++++++ > 3 files changed, 756 insertions(+) I've been working with David's v7 patch series for a bit of time now and things have been working well. v8 looks good. Feel free to add: Tested-by: Douglas Anderson <dianders@chromium.org> ...to this patch. Speaking of which it might be getting very close to time for this series to land along with David's other series, AKA: * [1/2] regulator: of: add property for allowed modes specification https://patchwork.kernel.org/patch/10395731/ * [2/2] regulator: of: add support for allowed modes configuration https://patchwork.kernel.org/patch/10395725/ Specifically I think we are mostly waiting for RPMh to land. This is on Andy's plate right now but I think it's happy and just waiting for the actual push from Andy. NOTE: I don't know if there anything special we need to do for landing this and RPMh across two git repositories. Offline Stephen Boyd mentioned to me that maybe it was fine to land this in Mark's tree without the RPMh code since it depends on "QCOM_RPMH", but the "|| COMPILE_TEST" worries me and makes me think auto-builders will start yelling. Andy and Mark: what do you think? If it's helpful to have a link to the latest RPMh, here are patchwork IDs on linux-arm-msm: 10477501 [v13,01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs 10477559 [v13,02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs 10477545 [v13,03/10] drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE 10477543 [v13,04/10] drivers: qcom: rpmh: add RPMH helper functions 10477537 [v13,05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS 10477539 [v13,06/10] drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS 10477533 [v13,07/10] drivers: qcom: rpmh: cache sleep/wake state requests 10477529 [v13,08/10] drivers: qcom: rpmh: allow requests to be sent asynchronously 10477525 [v13,09/10] drivers: qcom: rpmh: add support for batch RPMH request 10477519 [v13,10/10] drivers: qcom: rpmh-rsc: allow active requests from wake TCS -Doug ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-25 18:50 ` Doug Anderson @ 2018-06-26 12:07 ` Mark Brown 2018-06-26 15:00 ` Doug Anderson 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2018-06-26 12:07 UTC (permalink / raw) To: Doug Anderson Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson [-- Attachment #1: Type: text/plain, Size: 741 bytes --] On Mon, Jun 25, 2018 at 11:50:52AM -0700, Doug Anderson wrote: > ...to this patch. Speaking of which it might be getting very close to > time for this series to land along with David's other series, AKA: > * [1/2] regulator: of: add property for allowed modes specification > https://patchwork.kernel.org/patch/10395731/ > * [2/2] regulator: of: add support for allowed modes configuration > https://patchwork.kernel.org/patch/10395725/ Please do not submit new versions of already applied patches, please submit incremental updates to the existing code. Modifying existing commits creates problems for other users building on top of those commits so it's best practice to only change pubished git commits if absolutely essential. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-26 12:07 ` Mark Brown @ 2018-06-26 15:00 ` Doug Anderson 2018-06-26 15:02 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: Doug Anderson @ 2018-06-26 15:00 UTC (permalink / raw) To: Mark Brown Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson Hi, On Tue, Jun 26, 2018 at 5:07 AM, Mark Brown <broonie@kernel.org> wrote: > On Mon, Jun 25, 2018 at 11:50:52AM -0700, Doug Anderson wrote: > >> ...to this patch. Speaking of which it might be getting very close to >> time for this series to land along with David's other series, AKA: > >> * [1/2] regulator: of: add property for allowed modes specification >> https://patchwork.kernel.org/patch/10395731/ > >> * [2/2] regulator: of: add support for allowed modes configuration >> https://patchwork.kernel.org/patch/10395725/ > > Please do not submit new versions of already applied patches, please > submit incremental updates to the existing code. Modifying existing > commits creates problems for other users building on top of those > commits so it's best practice to only change pubished git commits if > absolutely essential. Sorry, wasn't suggesting making any changes to those two patches, just was noting the dependency. ...but, as you said, the two dependent patches have already landed and I just didn't notice. :( Sorry for the noise. -Doug ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-26 15:00 ` Doug Anderson @ 2018-06-26 15:02 ` Mark Brown 2018-06-26 18:15 ` Doug Anderson 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2018-06-26 15:02 UTC (permalink / raw) To: Doug Anderson Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson [-- Attachment #1: Type: text/plain, Size: 743 bytes --] On Tue, Jun 26, 2018 at 08:00:29AM -0700, Doug Anderson wrote: > On Tue, Jun 26, 2018 at 5:07 AM, Mark Brown <broonie@kernel.org> wrote: > > Please do not submit new versions of already applied patches, please > > submit incremental updates to the existing code. Modifying existing > > commits creates problems for other users building on top of those > > commits so it's best practice to only change pubished git commits if > > absolutely essential. > Sorry, wasn't suggesting making any changes to those two patches, just > was noting the dependency. ...but, as you said, the two dependent > patches have already landed and I just didn't notice. :( Sorry for > the noise. Ah, so there's no revisions that need merging? That's great. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-26 15:02 ` Mark Brown @ 2018-06-26 18:15 ` Doug Anderson 2018-06-27 15:01 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: Doug Anderson @ 2018-06-26 18:15 UTC (permalink / raw) To: Mark Brown Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson Hi, On Tue, Jun 26, 2018 at 8:02 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, Jun 26, 2018 at 08:00:29AM -0700, Doug Anderson wrote: >> On Tue, Jun 26, 2018 at 5:07 AM, Mark Brown <broonie@kernel.org> wrote: > >> > Please do not submit new versions of already applied patches, please >> > submit incremental updates to the existing code. Modifying existing >> > commits creates problems for other users building on top of those >> > commits so it's best practice to only change pubished git commits if >> > absolutely essential. > >> Sorry, wasn't suggesting making any changes to those two patches, just >> was noting the dependency. ...but, as you said, the two dependent >> patches have already landed and I just didn't notice. :( Sorry for >> the noise. > > Ah, so there's no revisions that need merging? That's great. Right. So all that's left to do is decide if ${SUBJECT} patch is ready to land and how to land it. Andy has landed RPMh into his for-next tree. You can see it at <https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git/log/?h=for-next>. I think he's still planning on re-shuffling his tree a bit. When he does this, do you need him to put the RPMh patches somewhere you can merge into your tree? Thanks! -Doug ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-26 18:15 ` Doug Anderson @ 2018-06-27 15:01 ` Mark Brown 2018-06-27 16:28 ` Doug Anderson 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2018-06-27 15:01 UTC (permalink / raw) To: Doug Anderson Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson [-- Attachment #1: Type: text/plain, Size: 466 bytes --] On Tue, Jun 26, 2018 at 11:15:14AM -0700, Doug Anderson wrote: > I think he's still planning on re-shuffling his tree a bit. When he > does this, do you need him to put the RPMh patches somewhere you can > merge into your tree? Well, I *think* there's no actual dependency here since it's a new driver with a Kconfig dependency. It really just needs me to get round to trawling through what's a fairly large patch with a troubled history now you've reviewed it. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-27 15:01 ` Mark Brown @ 2018-06-27 16:28 ` Doug Anderson 2018-06-28 10:18 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: Doug Anderson @ 2018-06-27 16:28 UTC (permalink / raw) To: Mark Brown Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson Hi, On Wed, Jun 27, 2018 at 8:01 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, Jun 26, 2018 at 11:15:14AM -0700, Doug Anderson wrote: > >> I think he's still planning on re-shuffling his tree a bit. When he >> does this, do you need him to put the RPMh patches somewhere you can >> merge into your tree? > > Well, I *think* there's no actual dependency here since it's a new > driver with a Kconfig dependency. It really just needs me to get round > to trawling through what's a fairly large patch with a troubled history > now you've reviewed it. OK, great. I guess I'm confused about the "|| COMPILE_TEST" causing problems then? I was worried that anyone trying to do "COMPILE_TEST" on your tree (or linuxnext if RPMh isn't there) would get failures due to the lack of header files. I guess if it's a problem you could just gut the "|| COMPILE_TEST" and it could be added back in later? Hoping my reviews saved you time overall. -Doug ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-27 16:28 ` Doug Anderson @ 2018-06-28 10:18 ` Mark Brown 2018-06-28 18:04 ` David Collins 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2018-06-28 10:18 UTC (permalink / raw) To: Doug Anderson Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson [-- Attachment #1: Type: text/plain, Size: 553 bytes --] On Wed, Jun 27, 2018 at 09:28:03AM -0700, Doug Anderson wrote: > OK, great. I guess I'm confused about the "|| COMPILE_TEST" causing > problems then? I was worried that anyone trying to do "COMPILE_TEST" > on your tree (or linuxnext if RPMh isn't there) would get failures due > to the lack of header files. I guess if it's a problem you could just > gut the "|| COMPILE_TEST" and it could be added back in later? Ugh, yes - that'll break things. In that case I can't apply this without a signed tag from Andy's tree with the dependency stuff in. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-28 10:18 ` Mark Brown @ 2018-06-28 18:04 ` David Collins 2018-06-29 11:06 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: David Collins @ 2018-06-28 18:04 UTC (permalink / raw) To: Mark Brown, Doug Anderson Cc: Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson Hello Mark, On 06/28/2018 03:18 AM, Mark Brown wrote: > On Wed, Jun 27, 2018 at 09:28:03AM -0700, Doug Anderson wrote: > >> OK, great. I guess I'm confused about the "|| COMPILE_TEST" causing >> problems then? I was worried that anyone trying to do "COMPILE_TEST" >> on your tree (or linuxnext if RPMh isn't there) would get failures due >> to the lack of header files. I guess if it's a problem you could just >> gut the "|| COMPILE_TEST" and it could be added back in later? > > Ugh, yes - that'll break things. In that case I can't apply this > without a signed tag from Andy's tree with the dependency stuff in. > Do you have any remaining concerns with the qcom-rpmh-regulator binding and driver patches that would keep you from applying them (other than the dependency patches being applied first)? Thanks, David -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-28 18:04 ` David Collins @ 2018-06-29 11:06 ` Mark Brown 0 siblings, 0 replies; 17+ messages in thread From: Mark Brown @ 2018-06-29 11:06 UTC (permalink / raw) To: David Collins Cc: Doug Anderson, Liam Girdwood, Rob Herring, Mark Rutland, linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak, Stephen Boyd, Matthias Kaehlcke, Andy Gross, Bjorn Andersson [-- Attachment #1: Type: text/plain, Size: 413 bytes --] On Thu, Jun 28, 2018 at 11:04:17AM -0700, David Collins wrote: > Do you have any remaining concerns with the qcom-rpmh-regulator binding > and driver patches that would keep you from applying them (other than the > dependency patches being applied first)? To repeat I need to find the time to sit down and go through them properly, the problems this driver has had mean I feel I need to be extra careful there. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-06-23 0:46 ` [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver David Collins 2018-06-25 18:50 ` Doug Anderson @ 2018-07-02 10:28 ` Mark Brown 2018-07-09 23:44 ` David Collins 1 sibling, 1 reply; 17+ messages in thread From: Mark Brown @ 2018-07-02 10:28 UTC (permalink / raw) To: David Collins Cc: lgirdwood, robh+dt, mark.rutland, linux-arm-msm, linux-arm-kernel, devicetree, linux-kernel, rnayak, sboyd, dianders, mka [-- Attachment #1: Type: text/plain, Size: 1528 bytes --] On Fri, Jun 22, 2018 at 05:46:14PM -0700, David Collins wrote: > --- /dev/null > +++ b/drivers/regulator/qcom-rpmh-regulator.c > @@ -0,0 +1,746 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */ > + Please make the entire header block C++ so it looks intentional. > + cmd.data = bypassed ? PMIC4_BOB_MODE_PASS : pmic_mode; Please just write normal if statements, the ternery operator isn't really helping legibility. > +static const int pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = { > + [REGULATOR_MODE_INVALID] = -EINVAL, > + [REGULATOR_MODE_STANDBY] = PMIC4_LDO_MODE_RETENTION, > + [REGULATOR_MODE_IDLE] = PMIC4_LDO_MODE_LPM, > + [REGULATOR_MODE_NORMAL] = -EINVAL, > + [REGULATOR_MODE_FAST] = PMIC4_LDO_MODE_HPM, > +}; This mapping is really weird, I'd expect one of the modes to correspond to the normal operating mode of the regulator. > +static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int mode) > +{ > + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = { > + [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY, > + [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE, > + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_INVALID, > + [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST, > + }; Same here, based on that it looks like auto mode is a good map for normal. > + if (mode >= RPMH_REGULATOR_MODE_COUNT) > + return -EINVAL; Why not use ARRAY_SIZE? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-07-02 10:28 ` Mark Brown @ 2018-07-09 23:44 ` David Collins 2018-07-12 16:54 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: David Collins @ 2018-07-09 23:44 UTC (permalink / raw) To: Mark Brown Cc: lgirdwood, robh+dt, mark.rutland, linux-arm-msm, linux-arm-kernel, devicetree, linux-kernel, rnayak, sboyd, dianders, mka Hello Mark, On 07/02/2018 03:28 AM, Mark Brown wrote: > On Fri, Jun 22, 2018 at 05:46:14PM -0700, David Collins wrote: > >> --- /dev/null >> +++ b/drivers/regulator/qcom-rpmh-regulator.c >> @@ -0,0 +1,746 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */ >> + > > Please make the entire header block C++ so it looks intentional. Sure, I'll change this. I was trying to follow the guideline that kernel C source files should use C style comments while at the same time following the SPDX guideline that C++ style comments are needed for the SPDX line in C source files [1]. >> + cmd.data = bypassed ? PMIC4_BOB_MODE_PASS : pmic_mode; > > Please just write normal if statements, the ternery operator isn't > really helping legibility. I'll change this. >> +static const int pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = { >> + [REGULATOR_MODE_INVALID] = -EINVAL, >> + [REGULATOR_MODE_STANDBY] = PMIC4_LDO_MODE_RETENTION, >> + [REGULATOR_MODE_IDLE] = PMIC4_LDO_MODE_LPM, >> + [REGULATOR_MODE_NORMAL] = -EINVAL, >> + [REGULATOR_MODE_FAST] = PMIC4_LDO_MODE_HPM, >> +}; > > This mapping is really weird, I'd expect one of the modes to correspond > to the normal operating mode of the regulator. My thinking here was to have a consistent mapping for consumers to use between REGULATOR_MODE_* and physical regulator modes for both LDO and SMPS type regulators: REGULATOR_MODE_STANDBY --> Retention (if supported) REGULATOR_MODE_IDLE --> Low power mode (if supported) LPM for LDO and PFM for SMPS REGULATOR_MODE_NORMAL --> Auto HW switching between low and high power mode (if supported) REGULATOR_MODE_FAST --> High power mode HPM for LDO and PWM for SMPS This allows a consumer to request NORMAL in typical use cases and FAST in use cases that require low voltage ripple. If NORMAL is not supported, then it automatically gets upgraded to FAST by the regulator framework. I could change it so that REGULATOR_MODE_NORMAL maps to LDO HPM mode. However, doing so would make it so that REGULATOR_MODE_FAST requests would fail for LDOs. Thus, consumers would need to know if their supply is an LDO or an SMPS (which seems undesirable). Would it be acceptable to have both NORMAL and FAST map to LDO HPM? >> +static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int mode) >> +{ >> + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = { >> + [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY, >> + [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE, >> + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_INVALID, >> + [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST, >> + }; > > Same here, based on that it looks like auto mode is a good map for > normal. LDO type regulators physically do not support AUTO mode. That is why I specified REGULATOR_MODE_INVALID in the mapping. >> + if (mode >= RPMH_REGULATOR_MODE_COUNT) >> + return -EINVAL; > > Why not use ARRAY_SIZE? I'll change this. Thanks, David [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst?h=v4.18-rc4#n74 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-07-09 23:44 ` David Collins @ 2018-07-12 16:54 ` Mark Brown 2018-07-13 1:34 ` David Collins 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2018-07-12 16:54 UTC (permalink / raw) To: David Collins Cc: lgirdwood, robh+dt, mark.rutland, linux-arm-msm, linux-arm-kernel, devicetree, linux-kernel, rnayak, sboyd, dianders, mka [-- Attachment #1: Type: text/plain, Size: 2696 bytes --] On Mon, Jul 09, 2018 at 04:44:14PM -0700, David Collins wrote: > On 07/02/2018 03:28 AM, Mark Brown wrote: > > On Fri, Jun 22, 2018 at 05:46:14PM -0700, David Collins wrote: > >> +static const int pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = { > >> + [REGULATOR_MODE_INVALID] = -EINVAL, > >> + [REGULATOR_MODE_STANDBY] = PMIC4_LDO_MODE_RETENTION, > >> + [REGULATOR_MODE_IDLE] = PMIC4_LDO_MODE_LPM, > >> + [REGULATOR_MODE_NORMAL] = -EINVAL, > >> + [REGULATOR_MODE_FAST] = PMIC4_LDO_MODE_HPM, > >> +}; > > This mapping is really weird, I'd expect one of the modes to correspond > > to the normal operating mode of the regulator. > My thinking here was to have a consistent mapping for consumers to use > between REGULATOR_MODE_* and physical regulator modes for both LDO and > SMPS type regulators: No, that's not useful or helpful - if there's any modes I'd *really* expect to see one of them be _NORMAL. > This allows a consumer to request NORMAL in typical use cases and FAST in > use cases that require low voltage ripple. If NORMAL is not supported, > then it automatically gets upgraded to FAST by the regulator framework. > I could change it so that REGULATOR_MODE_NORMAL maps to LDO HPM mode. > However, doing so would make it so that REGULATOR_MODE_FAST requests would > fail for LDOs. Thus, consumers would need to know if their supply is an > LDO or an SMPS (which seems undesirable). You've just discovered why it's a bad idea for consumers to do anything with modes directly! The mappings are just never going to be consistent given the massive variation in what regulators can support, the retention mode of one regulator might be able to deliver more power than the normal mode of another. > Would it be acceptable to have both NORMAL and FAST map to LDO HPM? Having something other than a 1:1 mapping is going to lead to pain at some point. > >> +static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int mode) > >> +{ > >> + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = { > >> + [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY, > >> + [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE, > >> + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_INVALID, > >> + [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST, > >> + }; > > Same here, based on that it looks like auto mode is a good map for > > normal. > LDO type regulators physically do not support AUTO mode. That is why I > specified REGULATOR_MODE_INVALID in the mapping. The other question here is why this is even in the table if it's not valid (I'm not seeing a need for the MODE_COUNT define)? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver 2018-07-12 16:54 ` Mark Brown @ 2018-07-13 1:34 ` David Collins 0 siblings, 0 replies; 17+ messages in thread From: David Collins @ 2018-07-13 1:34 UTC (permalink / raw) To: Mark Brown Cc: lgirdwood, robh+dt, mark.rutland, linux-arm-msm, linux-arm-kernel, devicetree, linux-kernel, rnayak, sboyd, dianders, mka On 07/12/2018 09:54 AM, Mark Brown wrote: > On Mon, Jul 09, 2018 at 04:44:14PM -0700, David Collins wrote: >> On 07/02/2018 03:28 AM, Mark Brown wrote: >>> On Fri, Jun 22, 2018 at 05:46:14PM -0700, David Collins wrote: >>>> +static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int mode) >>>> +{ >>>> + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = { >>>> + [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY, >>>> + [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE, >>>> + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_INVALID, >>>> + [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST, >>>> + }; > >>> Same here, based on that it looks like auto mode is a good map for >>> normal. > >> LDO type regulators physically do not support AUTO mode. That is why I >> specified REGULATOR_MODE_INVALID in the mapping. > > The other question here is why this is even in the table if it's not > valid (I'm not seeing a need for the MODE_COUNT define)? I thought that having a table would be more concise and easier to follow. I can change this to a switch case statement. Take care, David -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-07-13 1:34 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-06-23 0:46 [PATCH v8 0/2] regulator: add QCOM RPMh regulator driver David Collins 2018-06-23 0:46 ` [PATCH v8 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings David Collins 2018-06-23 0:46 ` [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver David Collins 2018-06-25 18:50 ` Doug Anderson 2018-06-26 12:07 ` Mark Brown 2018-06-26 15:00 ` Doug Anderson 2018-06-26 15:02 ` Mark Brown 2018-06-26 18:15 ` Doug Anderson 2018-06-27 15:01 ` Mark Brown 2018-06-27 16:28 ` Doug Anderson 2018-06-28 10:18 ` Mark Brown 2018-06-28 18:04 ` David Collins 2018-06-29 11:06 ` Mark Brown 2018-07-02 10:28 ` Mark Brown 2018-07-09 23:44 ` David Collins 2018-07-12 16:54 ` Mark Brown 2018-07-13 1:34 ` David Collins
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).