[v2,1/3] regulator: DT: Add DT property for operation mode configuration

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

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
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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,

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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, May 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.

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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html