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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel