* Add support for regulator operation mode of mt6397 @ 2016-05-23 7:13 Henry Chen 2016-05-23 7:13 ` [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration Henry Chen ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Henry Chen @ 2016-05-23 7:13 UTC (permalink / raw) To: Mark Brown, Rob Herring, Matthias Brugger Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Liam Girdwood, devicetree, linux-kernel, linux-arm-kernel, linux-mediatek Some regulators support different operating modes, but there is no suitable property that can pass the opeation mode constraints on runtime at present. This series making the change to specify supported modes as a devicetree list. Consumers can change or get the regulator operation mode by regulator_set_mode /regulator_get_mode and define the support operating mode on devicetree. There is a requirement from SVS driver. SVS calibartion requires that the regulator be in its low-noise (pwm mode) state at boot, but at all other times it can be normal mode for power saving. http://www.spinics.net/lists/devicetree/msg111204.html Changes in v2: - Separate patch for binding document changes. - Create a header to define operation mode on dt-bindings. - Remove the property "regulator-supported-modes". Henry Chen (3): regulator: DT: Add DT property for operation mode configuration regulator: of: Add support for parsing operation mode regulator: mt6397: Add buck change mode regulator interface for mt6397 .../devicetree/bindings/regulator/regulator.txt | 5 ++ drivers/regulator/mt6397-regulator.c | 89 +++++++++++++++++++--- drivers/regulator/of_regulator.c | 15 +++- include/dt-bindings/regulator/regulator.h | 14 ++++ 4 files changed, 113 insertions(+), 10 deletions(-) create mode 100644 include/dt-bindings/regulator/regulator.h -- 1.8.1.1.dirty ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration 2016-05-23 7:13 Add support for regulator operation mode of mt6397 Henry Chen @ 2016-05-23 7:13 ` Henry Chen 2016-05-23 10:47 ` Mark Rutland 2016-05-23 7:13 ` [PATCH v2 2/3] regulator: of: Add support for parsing operation mode Henry Chen 2016-05-23 7:13 ` [PATCH v2 3/3] regulator: mt6397: Add buck change mode regulator interface for mt6397 Henry Chen 2 siblings, 1 reply; 11+ messages in thread From: Henry Chen @ 2016-05-23 7:13 UTC (permalink / raw) To: Mark Brown, Rob Herring, Matthias Brugger Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Liam Girdwood, devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, Henry Chen Some regulators support their operating mode to be changed by consumers for module specific purpose. Add a DT property to support this. Signed-off-by: Henry Chen <henryc.chen@mediatek.com> --- Documentation/devicetree/bindings/regulator/regulator.txt | 5 +++++ include/dt-bindings/regulator/regulator.h | 14 ++++++++++++++ 2 files changed, 19 insertions(+) create mode 100644 include/dt-bindings/regulator/regulator.h diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index ecfc593..e505d0b 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -49,6 +49,11 @@ Optional properties: 0: Disable active discharge. 1: Enable active discharge. Absence of this property will leave configuration to default. +- regulator-supported-modes: Regulators can run in a variety of different + operating modes depending on output load. This allows further system power + savings by selecting the best (and most efficient) regulator mode for a + desired load. The definition for each of these operation is defined at + include/dt-bindings/regulator/regulator.h Deprecated properties: - regulator-compatible: If a regulator chip contains multiple diff --git a/include/dt-bindings/regulator/regulator.h b/include/dt-bindings/regulator/regulator.h new file mode 100644 index 0000000..2ed1dfd --- /dev/null +++ b/include/dt-bindings/regulator/regulator.h @@ -0,0 +1,14 @@ +/* + * This header provides constants for binding regulator. + */ + +#ifndef _DT_BINDINGS_REGULATOR_REGULATOR_H +#define _DT_BINDINGS_REGULATOR_REGULATOR_H + +/* Regulator operating modes */ +#define REGULATOR_OPERATION_MODE_FAST 0x0 +#define REGULATOR_OPERATION_MODE_NORMAL 0x1 +#define REGULATOR_OPERATION_MODE_IDLE 0x2 +#define REGULATOR_OPERATION_MODE_STANDBY 0x3 + +#endif -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration 2016-05-23 7:13 ` [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration Henry Chen @ 2016-05-23 10:47 ` Mark Rutland 2016-05-23 11:28 ` Mark Brown 0 siblings, 1 reply; 11+ messages in thread From: Mark Rutland @ 2016-05-23 10:47 UTC (permalink / raw) To: Henry Chen Cc: Mark Brown, Rob Herring, Matthias Brugger, Pawel Moll, Ian Campbell, Kumar Gala, Liam Girdwood, devicetree, linux-kernel, linux-arm-kernel, linux-mediatek On Mon, May 23, 2016 at 03:13:29PM +0800, Henry Chen wrote: > Some regulators support their operating mode to be changed by consumers for > module specific purpose. Add a DT property to support this. > > Signed-off-by: Henry Chen <henryc.chen@mediatek.com> > --- > Documentation/devicetree/bindings/regulator/regulator.txt | 5 +++++ > include/dt-bindings/regulator/regulator.h | 14 ++++++++++++++ > 2 files changed, 19 insertions(+) > create mode 100644 include/dt-bindings/regulator/regulator.h > > diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt > index ecfc593..e505d0b 100644 > --- a/Documentation/devicetree/bindings/regulator/regulator.txt > +++ b/Documentation/devicetree/bindings/regulator/regulator.txt > @@ -49,6 +49,11 @@ Optional properties: > 0: Disable active discharge. > 1: Enable active discharge. > Absence of this property will leave configuration to default. > +- regulator-supported-modes: Regulators can run in a variety of different > + operating modes depending on output load. This allows further system power > + savings by selecting the best (and most efficient) regulator mode for a > + desired load. The definition for each of these operation is defined at > + include/dt-bindings/regulator/regulator.h This doesen't tell me for the property is formatted. Is it a list? A mask? > > Deprecated properties: > - regulator-compatible: If a regulator chip contains multiple > diff --git a/include/dt-bindings/regulator/regulator.h b/include/dt-bindings/regulator/regulator.h > new file mode 100644 > index 0000000..2ed1dfd > --- /dev/null > +++ b/include/dt-bindings/regulator/regulator.h > @@ -0,0 +1,14 @@ > +/* > + * This header provides constants for binding regulator. > + */ > + > +#ifndef _DT_BINDINGS_REGULATOR_REGULATOR_H > +#define _DT_BINDINGS_REGULATOR_REGULATOR_H > + > +/* Regulator operating modes */ > +#define REGULATOR_OPERATION_MODE_FAST 0x0 > +#define REGULATOR_OPERATION_MODE_NORMAL 0x1 > +#define REGULATOR_OPERATION_MODE_IDLE 0x2 > +#define REGULATOR_OPERATION_MODE_STANDBY 0x3 These sound like they're tied to linux internal details (e.g. the implementation of idle and/or suspend). What do each of these actually mean? Mark. > + > +#endif > -- > 1.8.1.1.dirty > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration 2016-05-23 10:47 ` Mark Rutland @ 2016-05-23 11:28 ` Mark Brown 2016-05-31 8:20 ` Fan Chen 0 siblings, 1 reply; 11+ messages in thread From: Mark Brown @ 2016-05-23 11:28 UTC (permalink / raw) To: Mark Rutland Cc: Henry Chen, Rob Herring, Matthias Brugger, Pawel Moll, Ian Campbell, Kumar Gala, Liam Girdwood, devicetree, linux-kernel, linux-arm-kernel, linux-mediatek [-- Attachment #1: Type: text/plain, Size: 1357 bytes --] On Mon, May 23, 2016 at 11:47:04AM +0100, Mark Rutland wrote: > > +/* Regulator operating modes */ > > +#define REGULATOR_OPERATION_MODE_FAST 0x0 > > +#define REGULATOR_OPERATION_MODE_NORMAL 0x1 > > +#define REGULATOR_OPERATION_MODE_IDLE 0x2 > > +#define REGULATOR_OPERATION_MODE_STANDBY 0x3 > These sound like they're tied to linux internal details (e.g. the > implementation of idle and/or suspend). > What do each of these actually mean? They are not really at all general and I'm fairly sure I've provided the same feedback repeatedly on earlier versions of the patch set. They are not entirely based on Linux internal details (or at least the Linux internal details tend to flow from the hardware) - broadly fast is forced PWM, normal is default, idle is LDO mode and standby is a lower quality LDO mode - but how this translates into anything that a consumer could actually use is unclear since the supported output loads and quality of regulation can vary wildy. It's also somewhat implementation dependent what a given regulator does (and it's always possible that some regulators may have more modes to control or differing definitions in the hardware). Henry, *please* look at how the existing mode support in the bindings is done and consider how a consumer would use this given that it doesn't know anything about the regulator... [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration 2016-05-23 11:28 ` Mark Brown @ 2016-05-31 8:20 ` Fan Chen 2016-06-03 0:16 ` Mark Brown 0 siblings, 1 reply; 11+ messages in thread From: Fan Chen @ 2016-05-31 8:20 UTC (permalink / raw) To: Mark Brown Cc: Mark Rutland, devicetree, Pawel Moll, Ian Campbell, Liam Girdwood, Henry Chen, linux-kernel, Rob Herring, linux-mediatek, Kumar Gala, Matthias Brugger, linux-arm-kernel Hi Mark, On Mon, 2016-05-23 at 12:28 +0100, Mark Brown wrote: > On Mon, May 23, 2016 at 11:47:04AM +0100, Mark Rutland wrote: > > > > +/* Regulator operating modes */ > > > +#define REGULATOR_OPERATION_MODE_FAST 0x0 > > > +#define REGULATOR_OPERATION_MODE_NORMAL 0x1 > > > +#define REGULATOR_OPERATION_MODE_IDLE 0x2 > > > +#define REGULATOR_OPERATION_MODE_STANDBY 0x3 > > > These sound like they're tied to linux internal details (e.g. the > > implementation of idle and/or suspend). > > > What do each of these actually mean? > > They are not really at all general and I'm fairly sure I've provided the > same feedback repeatedly on earlier versions of the patch set. They are > not entirely based on Linux internal details (or at least the Linux > internal details tend to flow from the hardware) - broadly fast is > forced PWM, normal is default, idle is LDO mode and standby is a lower > quality LDO mode - but how this translates into anything that a consumer > could actually use is unclear since the supported output loads and > quality of regulation can vary wildy. It's also somewhat implementation > dependent what a given regulator does (and it's always possible that > some regulators may have more modes to control or differing definitions > in the hardware). > > Henry, *please* look at how the existing mode support in the bindings is > done and consider how a consumer would use this given that it doesn't > know anything about the regulator... Hi Mark, Thanks for your review and patiently explain your thought to us. In the case of svs[1], which Henry mentioned in cover letter, it can be regarded as a special consumer who requires very accurate voltage for calibration the hardware in its initialization stage. So, this kinds of consumers know their regulator very well and only need to switch to the modes they want in the particular conditions. However, IIUC, you want a proposal to provide a sort of QoS framework which can cover most of use cases who care about the regular quality in runtime, is that correct? IMHO, some quality index can be considered, for example: Minimum Current Requirement (mA): If a user specified this constraint in runtime, it means that he cares more about the supplying quality like transient voltage drop, ripple above certain load. Maximum Current Requirement (mA): If a user specified this constraint in runtime, it means that he cares more about the power consumption under certain load. It could be a flexible way instead to tie the operation modes directly. BTW, we should encourage people here to share more use cases related to regulator quality issues, especially in runtime, so we can evaluate the most suitable index to fit the requirements. What do you think? [1] http://www.spinics.net/lists/devicetree/msg111208.html Best regards, Fan > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration 2016-05-31 8:20 ` Fan Chen @ 2016-06-03 0:16 ` Mark Brown 2016-06-03 5:42 ` Fan Chen 0 siblings, 1 reply; 11+ messages in thread From: Mark Brown @ 2016-06-03 0:16 UTC (permalink / raw) To: Fan Chen Cc: Mark Rutland, devicetree, Pawel Moll, Ian Campbell, Liam Girdwood, Henry Chen, linux-kernel, Rob Herring, linux-mediatek, Kumar Gala, Matthias Brugger, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 2738 bytes --] On Tue, May 31, 2016 at 04:20:35PM +0800, Fan Chen wrote: > On Mon, 2016-05-23 at 12:28 +0100, Mark Brown wrote: > > Henry, *please* look at how the existing mode support in the bindings is > > done and consider how a consumer would use this given that it doesn't > > know anything about the regulator... > In the case of svs[1], which Henry mentioned in cover letter, it can be > regarded as a special consumer who requires very accurate voltage for > calibration the hardware in its initialization stage. So, this kinds of > consumers know their regulator very well and only need to switch to the > modes they want in the particular conditions. So what you're trying to do here is not so much set a specific mode as set maximum regulation accuracy for a period of time. > However, IIUC, you want a proposal to provide a sort of QoS framework > which can cover most of use cases who care about the regular quality in > runtime, is that correct? Well, we want a coherent general use case that doesn't require a user to know the specific details of the regulator they're working with since we need to hide that knowledge from the user. > IMHO, some quality index can be considered, for example: > Minimum Current Requirement (mA): If a user specified this constraint in > runtime, it means that he cares more about the supplying quality like > transient voltage drop, ripple above certain load. > Maximum Current Requirement (mA): If a user specified this constraint in > runtime, it means that he cares more about the power consumption under > certain load. > It could be a flexible way instead to tie the operation modes directly. I'm not sure I really understand these distinctions to be honest, and specifying minimum loads seems very tricky from a robustness point of view. If all you need right now is a way to maximize regulation quality that's probably a lot easier than anything based on absolute loads or on multiple "normal operation" modes - it takes a lot of the complexity out of things as there's no need to consider things like the distinctions between modes. We just need a standard operating mode and to know the highest available mode. I'm not sure exactly how to do that as an API though, let me think about it... your use case isn't one I'd come across before. > BTW, we should encourage people here to share more use cases related to > regulator quality issues, especially in runtime, so we can evaluate the > most suitable index to fit the requirements. More common use cases are around manually doing adaptive mode switching for regulators that are poor at automatically adjusting performance and handling of very low standby current situations where the adaption can consume enough power to register. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration 2016-06-03 0:16 ` Mark Brown @ 2016-06-03 5:42 ` Fan Chen 0 siblings, 0 replies; 11+ messages in thread From: Fan Chen @ 2016-06-03 5:42 UTC (permalink / raw) To: Mark Brown Cc: Mark Rutland, devicetree, Pawel Moll, Ian Campbell, Liam Girdwood, Henry Chen, linux-kernel, Rob Herring, linux-mediatek, Kumar Gala, Matthias Brugger, linux-arm-kernel Hi Mark, On Fri, 2016-06-03 at 01:16 +0100, Mark Brown wrote: > On Tue, May 31, 2016 at 04:20:35PM +0800, Fan Chen wrote: > > On Mon, 2016-05-23 at 12:28 +0100, Mark Brown wrote: > > In the case of svs[1], which Henry mentioned in cover letter, it can be > > regarded as a special consumer who requires very accurate voltage for > > calibration the hardware in its initialization stage. So, this kinds of > > consumers know their regulator very well and only need to switch to the > > modes they want in the particular conditions. > > So what you're trying to do here is not so much set a specific mode as > set maximum regulation accuracy for a period of time. exactly. > > However, IIUC, you want a proposal to provide a sort of QoS framework > > which can cover most of use cases who care about the regular quality in > > runtime, is that correct? > > Well, we want a coherent general use case that doesn't require a user to > know the specific details of the regulator they're working with since we > need to hide that knowledge from the user. Agreed, it is hard to control once expose too many details. But I think maybe there still be some parameter user has to aware to decide the performance/quality in the common use cases you said below. > > > IMHO, some quality index can be considered, for example: > > Minimum Current Requirement (mA): If a user specified this constraint in > > runtime, it means that he cares more about the supplying quality like > > transient voltage drop, ripple above certain load. > > Maximum Current Requirement (mA): If a user specified this constraint in > > runtime, it means that he cares more about the power consumption under > > certain load. > > It could be a flexible way instead to tie the operation modes directly. > > I'm not sure I really understand these distinctions to be honest, > and specifying minimum loads seems very tricky from a robustness point > of view. > > If all you need right now is a way to maximize regulation quality that's > probably a lot easier than anything based on absolute loads or on > multiple "normal operation" modes - it takes a lot of the complexity out > of things as there's no need to consider things like the distinctions > between modes. We just need a standard operating mode and to know the > highest available mode. I'm not sure exactly how to do that as an API > though, let me think about it... your use case isn't one I'd come > across before. Thanks. Please kindly give us suggestion for this case. > > > BTW, we should encourage people here to share more use cases related to > > regulator quality issues, especially in runtime, so we can evaluate the > > most suitable index to fit the requirements. > > More common use cases are around manually doing adaptive mode switching > for regulators that are poor at automatically adjusting performance and > handling of very low standby current situations where the adaption can > consume enough power to register. Best regards, Fan ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 2/3] regulator: of: Add support for parsing operation mode 2016-05-23 7:13 Add support for regulator operation mode of mt6397 Henry Chen 2016-05-23 7:13 ` [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration Henry Chen @ 2016-05-23 7:13 ` Henry Chen 2016-05-23 7:13 ` [PATCH v2 3/3] regulator: mt6397: Add buck change mode regulator interface for mt6397 Henry Chen 2 siblings, 0 replies; 11+ messages in thread From: Henry Chen @ 2016-05-23 7:13 UTC (permalink / raw) To: Mark Brown, Rob Herring, Matthias Brugger Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Liam Girdwood, devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, Henry Chen Some regulators support their operating mode to be changed by consumers for module specific purpose. This patch adds support to parse those properties and fill the regulator constraints so the regulator core can call the regualtor_set_mode to change the modes. Signed-off-by: Henry Chen <henryc.chen@mediatek.com> --- drivers/regulator/of_regulator.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c index 6b0aa80..7f8d82e 100644 --- a/drivers/regulator/of_regulator.c +++ b/drivers/regulator/of_regulator.c @@ -31,7 +31,7 @@ static void of_get_regulation_constraints(struct device_node *np, struct regulation_constraints *constraints = &(*init_data)->constraints; struct regulator_state *suspend_state; struct device_node *suspend_np; - int ret, i; + int ret, i, cnt; u32 pval; constraints->name = of_get_property(np, "regulator-name", NULL); @@ -167,6 +167,19 @@ static void of_get_regulation_constraints(struct device_node *np, suspend_state = NULL; suspend_np = NULL; } + cnt = of_property_count_elems_of_size(np, + "regulator-supported-modes", + sizeof(u32)); + if (cnt > 0) + constraints->valid_ops_mask |= REGULATOR_CHANGE_MODE; + + for (i = 0; i < cnt; i++) { + u32 mode; + + of_property_read_u32_index(np, "regulator-supported-modes", + i, &mode); + constraints->valid_modes_mask |= (1 << mode); + } } /** -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v2 3/3] regulator: mt6397: Add buck change mode regulator interface for mt6397 2016-05-23 7:13 Add support for regulator operation mode of mt6397 Henry Chen 2016-05-23 7:13 ` [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration Henry Chen 2016-05-23 7:13 ` [PATCH v2 2/3] regulator: of: Add support for parsing operation mode Henry Chen @ 2016-05-23 7:13 ` Henry Chen 2016-05-23 11:29 ` Mark Brown 2016-05-23 17:50 ` Applied "regulator: mt6397: Add buck change mode regulator interface for mt6397" to the regulator tree Mark Brown 2 siblings, 2 replies; 11+ messages in thread From: Henry Chen @ 2016-05-23 7:13 UTC (permalink / raw) To: Mark Brown, Rob Herring, Matthias Brugger Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Liam Girdwood, devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, Henry Chen BUCKs of mt6397 have auto mode and pwm mode. User can use regulator interfaces to control modes Signed-off-by: Henry Chen <henryc.chen@mediatek.com> --- drivers/regulator/mt6397-regulator.c | 89 ++++++++++++++++++++++++++++++++---- 1 file changed, 80 insertions(+), 9 deletions(-) diff --git a/drivers/regulator/mt6397-regulator.c b/drivers/regulator/mt6397-regulator.c index 1c45abb..c6c6aa85 100644 --- a/drivers/regulator/mt6397-regulator.c +++ b/drivers/regulator/mt6397-regulator.c @@ -23,6 +23,9 @@ #include <linux/regulator/mt6397-regulator.h> #include <linux/regulator/of_regulator.h> +#define MT6397_BUCK_MODE_AUTO 0 +#define MT6397_BUCK_MODE_FORCE_PWM 1 + /* * MT6397 regulators' information * @@ -38,10 +41,14 @@ struct mt6397_regulator_info { u32 vselon_reg; u32 vselctrl_reg; u32 vselctrl_mask; + u32 modeset_reg; + u32 modeset_mask; + u32 modeset_shift; }; #define MT6397_BUCK(match, vreg, min, max, step, volt_ranges, enreg, \ - vosel, vosel_mask, voselon, vosel_ctrl) \ + vosel, vosel_mask, voselon, vosel_ctrl, _modeset_reg, \ + _modeset_shift) \ [MT6397_ID_##vreg] = { \ .desc = { \ .name = #vreg, \ @@ -62,6 +69,9 @@ struct mt6397_regulator_info { .vselon_reg = voselon, \ .vselctrl_reg = vosel_ctrl, \ .vselctrl_mask = BIT(1), \ + .modeset_reg = _modeset_reg, \ + .modeset_mask = BIT(_modeset_shift), \ + .modeset_shift = _modeset_shift \ } #define MT6397_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel, \ @@ -145,6 +155,63 @@ static const u32 ldo_volt_table7[] = { 1300000, 1500000, 1800000, 2000000, 2500000, 2800000, 3000000, 3300000, }; +static int mt6397_regulator_set_mode(struct regulator_dev *rdev, + unsigned int mode) +{ + struct mt6397_regulator_info *info = rdev_get_drvdata(rdev); + int ret, val; + + switch (mode) { + case REGULATOR_MODE_FAST: + val = MT6397_BUCK_MODE_FORCE_PWM; + break; + case REGULATOR_MODE_NORMAL: + val = MT6397_BUCK_MODE_AUTO; + break; + default: + ret = -EINVAL; + goto err_mode; + } + + dev_dbg(&rdev->dev, "mt6397 buck set_mode %#x, %#x, %#x, %#x\n", + info->modeset_reg, info->modeset_mask, + info->modeset_shift, val); + + val <<= info->modeset_shift; + ret = regmap_update_bits(rdev->regmap, info->modeset_reg, + info->modeset_mask, val); +err_mode: + if (ret != 0) { + dev_err(&rdev->dev, + "Failed to set mt6397 buck mode: %d\n", ret); + return ret; + } + + return 0; +} + +static unsigned int mt6397_regulator_get_mode(struct regulator_dev *rdev) +{ + struct mt6397_regulator_info *info = rdev_get_drvdata(rdev); + int ret, regval; + + ret = regmap_read(rdev->regmap, info->modeset_reg, ®val); + if (ret != 0) { + dev_err(&rdev->dev, + "Failed to get mt6397 buck mode: %d\n", ret); + return ret; + } + + switch ((regval & info->modeset_mask) >> info->modeset_shift) { + case MT6397_BUCK_MODE_AUTO: + return REGULATOR_MODE_NORMAL; + case MT6397_BUCK_MODE_FORCE_PWM: + return REGULATOR_MODE_FAST; + default: + return -EINVAL; + } +} + static int mt6397_get_status(struct regulator_dev *rdev) { int ret; @@ -170,6 +237,8 @@ static const struct regulator_ops mt6397_volt_range_ops = { .disable = regulator_disable_regmap, .is_enabled = regulator_is_enabled_regmap, .get_status = mt6397_get_status, + .set_mode = mt6397_regulator_set_mode, + .get_mode = mt6397_regulator_get_mode, }; static const struct regulator_ops mt6397_volt_table_ops = { @@ -196,28 +265,30 @@ static const struct regulator_ops mt6397_volt_fixed_ops = { static struct mt6397_regulator_info mt6397_regulators[] = { MT6397_BUCK("buck_vpca15", VPCA15, 700000, 1493750, 6250, buck_volt_range1, MT6397_VCA15_CON7, MT6397_VCA15_CON9, 0x7f, - MT6397_VCA15_CON10, MT6397_VCA15_CON5), + MT6397_VCA15_CON10, MT6397_VCA15_CON5, MT6397_VCA15_CON2, 11), MT6397_BUCK("buck_vpca7", VPCA7, 700000, 1493750, 6250, buck_volt_range1, MT6397_VPCA7_CON7, MT6397_VPCA7_CON9, 0x7f, - MT6397_VPCA7_CON10, MT6397_VPCA7_CON5), + MT6397_VPCA7_CON10, MT6397_VPCA7_CON5, MT6397_VPCA7_CON2, 8), MT6397_BUCK("buck_vsramca15", VSRAMCA15, 700000, 1493750, 6250, buck_volt_range1, MT6397_VSRMCA15_CON7, MT6397_VSRMCA15_CON9, - 0x7f, MT6397_VSRMCA15_CON10, MT6397_VSRMCA15_CON5), + 0x7f, MT6397_VSRMCA15_CON10, MT6397_VSRMCA15_CON5, + MT6397_VSRMCA15_CON2, 8), MT6397_BUCK("buck_vsramca7", VSRAMCA7, 700000, 1493750, 6250, buck_volt_range1, MT6397_VSRMCA7_CON7, MT6397_VSRMCA7_CON9, - 0x7f, MT6397_VSRMCA7_CON10, MT6397_VSRMCA7_CON5), + 0x7f, MT6397_VSRMCA7_CON10, MT6397_VSRMCA7_CON5, + MT6397_VSRMCA7_CON2, 8), MT6397_BUCK("buck_vcore", VCORE, 700000, 1493750, 6250, buck_volt_range1, MT6397_VCORE_CON7, MT6397_VCORE_CON9, 0x7f, - MT6397_VCORE_CON10, MT6397_VCORE_CON5), + MT6397_VCORE_CON10, MT6397_VCORE_CON5, MT6397_VCORE_CON2, 8), MT6397_BUCK("buck_vgpu", VGPU, 700000, 1493750, 6250, buck_volt_range1, MT6397_VGPU_CON7, MT6397_VGPU_CON9, 0x7f, - MT6397_VGPU_CON10, MT6397_VGPU_CON5), + MT6397_VGPU_CON10, MT6397_VGPU_CON5, MT6397_VGPU_CON2, 8), MT6397_BUCK("buck_vdrm", VDRM, 800000, 1593750, 6250, buck_volt_range2, MT6397_VDRM_CON7, MT6397_VDRM_CON9, 0x7f, - MT6397_VDRM_CON10, MT6397_VDRM_CON5), + MT6397_VDRM_CON10, MT6397_VDRM_CON5, MT6397_VDRM_CON2, 8), MT6397_BUCK("buck_vio18", VIO18, 1500000, 2120000, 20000, buck_volt_range3, MT6397_VIO18_CON7, MT6397_VIO18_CON9, 0x1f, - MT6397_VIO18_CON10, MT6397_VIO18_CON5), + MT6397_VIO18_CON10, MT6397_VIO18_CON5, MT6397_VIO18_CON2, 8), MT6397_REG_FIXED("ldo_vtcxo", VTCXO, MT6397_ANALDO_CON0, 10, 2800000), MT6397_REG_FIXED("ldo_va28", VA28, MT6397_ANALDO_CON1, 14, 2800000), MT6397_LDO("ldo_vcama", VCAMA, ldo_volt_table1, -- 1.8.1.1.dirty ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v2 3/3] regulator: mt6397: Add buck change mode regulator interface for mt6397 2016-05-23 7:13 ` [PATCH v2 3/3] regulator: mt6397: Add buck change mode regulator interface for mt6397 Henry Chen @ 2016-05-23 11:29 ` Mark Brown 2016-05-23 17:50 ` Applied "regulator: mt6397: Add buck change mode regulator interface for mt6397" to the regulator tree Mark Brown 1 sibling, 0 replies; 11+ messages in thread From: Mark Brown @ 2016-05-23 11:29 UTC (permalink / raw) To: Henry Chen Cc: Rob Herring, Matthias Brugger, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Liam Girdwood, devicetree, linux-kernel, linux-arm-kernel, linux-mediatek [-- Attachment #1: Type: text/plain, Size: 227 bytes --] On Mon, May 23, 2016 at 03:13:31PM +0800, Henry Chen wrote: > BUCKs of mt6397 have auto mode and pwm mode. > User can use regulator interfaces to control modes This doesn't apply against current code, please check and resend. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Applied "regulator: mt6397: Add buck change mode regulator interface for mt6397" to the regulator tree 2016-05-23 7:13 ` [PATCH v2 3/3] regulator: mt6397: Add buck change mode regulator interface for mt6397 Henry Chen 2016-05-23 11:29 ` Mark Brown @ 2016-05-23 17:50 ` Mark Brown 1 sibling, 0 replies; 11+ messages in thread From: Mark Brown @ 2016-05-23 17:50 UTC (permalink / raw) To: Henry Chen Cc: Mark Brown, Mark Brown, Rob Herring, Matthias Brugger, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Liam Girdwood, devicetree, linux-kernel, linux-arm-kernel, linux-mediatek The patch regulator: mt6397: Add buck change mode regulator interface for mt6397 has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 6d26507bd45bf09374d3744ee07fabebc87266f5 Mon Sep 17 00:00:00 2001 From: Henry Chen <henryc.chen@mediatek.com> Date: Mon, 23 May 2016 15:13:31 +0800 Subject: [PATCH] regulator: mt6397: Add buck change mode regulator interface for mt6397 BUCKs of mt6397 have auto mode and pwm mode. User can use regulator interfaces to control modes Signed-off-by: Henry Chen <henryc.chen@mediatek.com> Signed-off-by: Mark Brown <broonie@kernel.org> --- drivers/regulator/mt6397-regulator.c | 89 ++++++++++++++++++++++++++++++++---- 1 file changed, 80 insertions(+), 9 deletions(-) diff --git a/drivers/regulator/mt6397-regulator.c b/drivers/regulator/mt6397-regulator.c index 1c45abb94409..c6c6aa85e4e8 100644 --- a/drivers/regulator/mt6397-regulator.c +++ b/drivers/regulator/mt6397-regulator.c @@ -23,6 +23,9 @@ #include <linux/regulator/mt6397-regulator.h> #include <linux/regulator/of_regulator.h> +#define MT6397_BUCK_MODE_AUTO 0 +#define MT6397_BUCK_MODE_FORCE_PWM 1 + /* * MT6397 regulators' information * @@ -38,10 +41,14 @@ struct mt6397_regulator_info { u32 vselon_reg; u32 vselctrl_reg; u32 vselctrl_mask; + u32 modeset_reg; + u32 modeset_mask; + u32 modeset_shift; }; #define MT6397_BUCK(match, vreg, min, max, step, volt_ranges, enreg, \ - vosel, vosel_mask, voselon, vosel_ctrl) \ + vosel, vosel_mask, voselon, vosel_ctrl, _modeset_reg, \ + _modeset_shift) \ [MT6397_ID_##vreg] = { \ .desc = { \ .name = #vreg, \ @@ -62,6 +69,9 @@ struct mt6397_regulator_info { .vselon_reg = voselon, \ .vselctrl_reg = vosel_ctrl, \ .vselctrl_mask = BIT(1), \ + .modeset_reg = _modeset_reg, \ + .modeset_mask = BIT(_modeset_shift), \ + .modeset_shift = _modeset_shift \ } #define MT6397_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel, \ @@ -145,6 +155,63 @@ static const u32 ldo_volt_table7[] = { 1300000, 1500000, 1800000, 2000000, 2500000, 2800000, 3000000, 3300000, }; +static int mt6397_regulator_set_mode(struct regulator_dev *rdev, + unsigned int mode) +{ + struct mt6397_regulator_info *info = rdev_get_drvdata(rdev); + int ret, val; + + switch (mode) { + case REGULATOR_MODE_FAST: + val = MT6397_BUCK_MODE_FORCE_PWM; + break; + case REGULATOR_MODE_NORMAL: + val = MT6397_BUCK_MODE_AUTO; + break; + default: + ret = -EINVAL; + goto err_mode; + } + + dev_dbg(&rdev->dev, "mt6397 buck set_mode %#x, %#x, %#x, %#x\n", + info->modeset_reg, info->modeset_mask, + info->modeset_shift, val); + + val <<= info->modeset_shift; + ret = regmap_update_bits(rdev->regmap, info->modeset_reg, + info->modeset_mask, val); +err_mode: + if (ret != 0) { + dev_err(&rdev->dev, + "Failed to set mt6397 buck mode: %d\n", ret); + return ret; + } + + return 0; +} + +static unsigned int mt6397_regulator_get_mode(struct regulator_dev *rdev) +{ + struct mt6397_regulator_info *info = rdev_get_drvdata(rdev); + int ret, regval; + + ret = regmap_read(rdev->regmap, info->modeset_reg, ®val); + if (ret != 0) { + dev_err(&rdev->dev, + "Failed to get mt6397 buck mode: %d\n", ret); + return ret; + } + + switch ((regval & info->modeset_mask) >> info->modeset_shift) { + case MT6397_BUCK_MODE_AUTO: + return REGULATOR_MODE_NORMAL; + case MT6397_BUCK_MODE_FORCE_PWM: + return REGULATOR_MODE_FAST; + default: + return -EINVAL; + } +} + static int mt6397_get_status(struct regulator_dev *rdev) { int ret; @@ -170,6 +237,8 @@ static const struct regulator_ops mt6397_volt_range_ops = { .disable = regulator_disable_regmap, .is_enabled = regulator_is_enabled_regmap, .get_status = mt6397_get_status, + .set_mode = mt6397_regulator_set_mode, + .get_mode = mt6397_regulator_get_mode, }; static const struct regulator_ops mt6397_volt_table_ops = { @@ -196,28 +265,30 @@ static const struct regulator_ops mt6397_volt_fixed_ops = { static struct mt6397_regulator_info mt6397_regulators[] = { MT6397_BUCK("buck_vpca15", VPCA15, 700000, 1493750, 6250, buck_volt_range1, MT6397_VCA15_CON7, MT6397_VCA15_CON9, 0x7f, - MT6397_VCA15_CON10, MT6397_VCA15_CON5), + MT6397_VCA15_CON10, MT6397_VCA15_CON5, MT6397_VCA15_CON2, 11), MT6397_BUCK("buck_vpca7", VPCA7, 700000, 1493750, 6250, buck_volt_range1, MT6397_VPCA7_CON7, MT6397_VPCA7_CON9, 0x7f, - MT6397_VPCA7_CON10, MT6397_VPCA7_CON5), + MT6397_VPCA7_CON10, MT6397_VPCA7_CON5, MT6397_VPCA7_CON2, 8), MT6397_BUCK("buck_vsramca15", VSRAMCA15, 700000, 1493750, 6250, buck_volt_range1, MT6397_VSRMCA15_CON7, MT6397_VSRMCA15_CON9, - 0x7f, MT6397_VSRMCA15_CON10, MT6397_VSRMCA15_CON5), + 0x7f, MT6397_VSRMCA15_CON10, MT6397_VSRMCA15_CON5, + MT6397_VSRMCA15_CON2, 8), MT6397_BUCK("buck_vsramca7", VSRAMCA7, 700000, 1493750, 6250, buck_volt_range1, MT6397_VSRMCA7_CON7, MT6397_VSRMCA7_CON9, - 0x7f, MT6397_VSRMCA7_CON10, MT6397_VSRMCA7_CON5), + 0x7f, MT6397_VSRMCA7_CON10, MT6397_VSRMCA7_CON5, + MT6397_VSRMCA7_CON2, 8), MT6397_BUCK("buck_vcore", VCORE, 700000, 1493750, 6250, buck_volt_range1, MT6397_VCORE_CON7, MT6397_VCORE_CON9, 0x7f, - MT6397_VCORE_CON10, MT6397_VCORE_CON5), + MT6397_VCORE_CON10, MT6397_VCORE_CON5, MT6397_VCORE_CON2, 8), MT6397_BUCK("buck_vgpu", VGPU, 700000, 1493750, 6250, buck_volt_range1, MT6397_VGPU_CON7, MT6397_VGPU_CON9, 0x7f, - MT6397_VGPU_CON10, MT6397_VGPU_CON5), + MT6397_VGPU_CON10, MT6397_VGPU_CON5, MT6397_VGPU_CON2, 8), MT6397_BUCK("buck_vdrm", VDRM, 800000, 1593750, 6250, buck_volt_range2, MT6397_VDRM_CON7, MT6397_VDRM_CON9, 0x7f, - MT6397_VDRM_CON10, MT6397_VDRM_CON5), + MT6397_VDRM_CON10, MT6397_VDRM_CON5, MT6397_VDRM_CON2, 8), MT6397_BUCK("buck_vio18", VIO18, 1500000, 2120000, 20000, buck_volt_range3, MT6397_VIO18_CON7, MT6397_VIO18_CON9, 0x1f, - MT6397_VIO18_CON10, MT6397_VIO18_CON5), + MT6397_VIO18_CON10, MT6397_VIO18_CON5, MT6397_VIO18_CON2, 8), MT6397_REG_FIXED("ldo_vtcxo", VTCXO, MT6397_ANALDO_CON0, 10, 2800000), MT6397_REG_FIXED("ldo_va28", VA28, MT6397_ANALDO_CON1, 14, 2800000), MT6397_LDO("ldo_vcama", VCAMA, ldo_volt_table1, -- 2.8.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-06-03 5:42 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-23 7:13 Add support for regulator operation mode of mt6397 Henry Chen 2016-05-23 7:13 ` [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration Henry Chen 2016-05-23 10:47 ` Mark Rutland 2016-05-23 11:28 ` Mark Brown 2016-05-31 8:20 ` Fan Chen 2016-06-03 0:16 ` Mark Brown 2016-06-03 5:42 ` Fan Chen 2016-05-23 7:13 ` [PATCH v2 2/3] regulator: of: Add support for parsing operation mode Henry Chen 2016-05-23 7:13 ` [PATCH v2 3/3] regulator: mt6397: Add buck change mode regulator interface for mt6397 Henry Chen 2016-05-23 11:29 ` Mark Brown 2016-05-23 17:50 ` Applied "regulator: mt6397: Add buck change mode regulator interface for mt6397" to the regulator tree Mark Brown
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).