From: fan.chen@mediatek.com (Fan Chen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] regulator: DT: Add DT property for operation mode configuration
Date: Fri, 3 Jun 2016 13:42:08 +0800 [thread overview]
Message-ID: <1464932528.18889.12.camel@mtksdaap41> (raw)
In-Reply-To: <20160603001600.GX2282@sirena.org.uk>
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
next prev parent reply other threads:[~2016-06-03 5:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1464932528.18889.12.camel@mtksdaap41 \
--to=fan.chen@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox