From: menghui.lin@mediatek.com (menghui lin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
Date: Fri, 29 Jan 2016 20:11:19 +0800 [thread overview]
Message-ID: <1454069479.10861.30.camel@mtksdaap41> (raw)
In-Reply-To: <20160129112717.GP4130@sirena.org.uk>
On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote:
> On Fri, Jan 29, 2016 at 05:52:14PM +0800, menghui lin wrote:
> > On Fri, 2016-01-29 at 00:13 +0100, Mark Brown wrote:
>
> > > I'm not convinced this binding makes sense, how would a user of the API
> > > (currently there are none in tree) know what the modes mean? It's a bit
> > > different when the user is supplying configuration for a specific
> > > regulator but this needs to be something that can be used by consumers.
>
> > > What are you actually trying to do with this?
>
> > In this patch, we want to support both normal/standby modes for mt6323
> > regulators due to mt6323 regulators support low power mode which
> > provides better power efficiency for standby case.
>
> > We expect user of mt6323 regulators could dynamically change power mode
> > by regulator_set_mode(). -EINVAL is returned if the given mode is not
> > supported.
>
> > The regulator_set_mode() API looks very straightforward and possible
> > modes are already defined in consumer.h. It looks like we don't have to
> > list possible modes for mt6323 additionally in binding document.
>
> None of this is answering my question - I know what the current API is,
> describing it doesn't tell me about actual users or how they are able to
> sensibly use the interface. Bear in mind that the definitions of the
> various modes are all relative and what one device thinks is high usage
> may be low usage for another device.
Assuming valid_modes_mask and initial_mode are specified, a possible
way to modify regulator_set_mode() is to allow mode change only if the
regulator is controlled exclusively by a certain consumer or the
requested mode provides stronger power capability than current mode.
Here I assume that power capability fast > normal > idle > standby.
next prev parent reply other threads:[~2016-01-29 12:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 12:00 [PATCH V4 1/2] regulator: Add document for MT6323 regulator John Crispin
2016-01-27 12:00 ` [PATCH V4 2/2] regulator: mt6323: Add support " John Crispin
2016-01-27 14:41 ` Mark Brown
2016-01-28 7:16 ` Henry Chen
2016-01-28 11:38 ` Mark Brown
2016-01-28 18:13 ` John Crispin
2016-01-28 23:13 ` Mark Brown
2016-01-29 9:52 ` menghui lin
2016-01-29 11:27 ` Mark Brown
2016-01-29 12:11 ` menghui lin [this message]
2016-02-02 19:38 ` Mark Brown
2016-02-03 5:39 ` menghui lin
2016-02-03 12:29 ` Mark Brown
2016-02-04 2:42 ` menghui lin
2016-02-02 19:39 ` Mark Brown
2016-02-08 12:14 ` kbuild test robot
2016-02-01 15:40 ` [PATCH V4 1/2] regulator: Add document " Rob Herring
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=1454069479.10861.30.camel@mtksdaap41 \
--to=menghui.lin@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