From: Mark Brown <broonie@kernel.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
David Collins <collinsd@codeaurora.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH] regulator: Add SPMI regulator driver
Date: Wed, 13 May 2015 12:41:18 +0100 [thread overview]
Message-ID: <20150513114118.GJ3066@sirena.org.uk> (raw)
In-Reply-To: <1431466787-32247-1-git-send-email-sboyd@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]
On Tue, May 12, 2015 at 02:39:47PM -0700, Stephen Boyd wrote:
Lots of things with the DT bindings here. In general if you're
introducing lots of custom properties I'd recommend doing a patch series
which starts off with the generic, bog standard driver and then adds on
the fancy bells and whistles later. That way the simple stuff can get
merged easily which cuts down on review effort.
> +- qcom,system-load:
> + Usage: optional
> + Value type: <u32>
> + Description: Load in uA present on regulator that is not captured by
> + any consumer request.
This doesn't seem at all specific to this hardware - please add it as a
generic property.
> +- qcom,auto-mode-enable:
> + Usage: optional
> + Value type: <u32>
> + Description: 1 = Enable automatic hardware selection of regulator
> + mode (HPM vs LPM); not available on boost type
> + regulators. 0 = Disable auto mode selection.
Can we come up with a different name for this - IIRC (I'm working
offline as I reply to this) this is not about pulse skipping enabling
type automatic mode selection but rather about allowing other processors
to control things. The current name makes me think of the former thing.
Perhaps just hpm-enable or something, or key it off specifying the
signal to be used?
> +- qcom,bypass-mode-enable:
> + Usage: optional
> + Value type: <u32>
> + Description: 1 = Enable bypass mode for an LDO type regulator so that
> + it acts like a switch and simply outputs its input
> + voltage. 0 = Do not enable bypass mode.
We have generic regulator API support for this, we should have a generic
DT binding for it.
> +- qcom,pull-down-enable:
> + Usage: optional
> + Value type: <u32>
> + Description: 1 = Enable output pull down resistor when the regulator
> + is disabled. 0 = Disable pull down resistor
> +
> +- qcom,soft-start-enable:
> + Usage: optional
> + Value type: <u32>
> + Description: 1 = Enable soft start for LDO and voltage switch type
> + regulators so that output voltage slowly ramps up when the
> + regulator is enabled. 0 = Disable soft start
These also seem like generic properties (we don't currently have generic
APIs for them but these are by no means the only regulators I've seen
with these features).
> +- qcom,boost-current-limit:
> + Usage: optional
> + Value type: <u32>
> + Description: This property sets the current limit of boost type
> + regulators; supported values are:
> + 0 = 300 mA
> + 1 = 600 mA
> + 2 = 900 mA
> + 3 = 1200 mA
> + 4 = 1500 mA
> + 5 = 1800 mA
> + 6 = 2100 mA
> + 7 = 2400 mA
Again seems generic - there seems like overlap with your own OCP
properties further above.
> +#define VOLTAGE_RANGE(_range_sel, _min_uV, _set_point_min_uV, \
> + _set_point_max_uV, _max_uV, _step_uV) \
> + { \
> + .min_uV = _min_uV, \
> + .max_uV = _max_uV, \
> + .set_point_min_uV = _set_point_min_uV, \
> + .set_point_max_uV = _set_point_max_uV, \
> + .step_uV = _step_uV, \
> + .range_sel = _range_sel, \
> + }
A lot of these macros have very generic names. Also I have to say I'm a
bit confused about what a set point is and how it's used, "allowed
voltage" doesn't mean a huge amount in comparison with "programmable
voltage".
I got a bit lost with all this so I've not really got any comments on
the rest of the code as is, sorry.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-05-13 12:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 21:39 Stephen Boyd
2015-05-13 11:41 ` Mark Brown [this message]
2015-05-14 1:02 ` Stephen Boyd
2015-05-14 19:20 ` Mark Brown
2015-05-16 1:50 ` Frank Rowand
2015-05-16 10:54 ` 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=20150513114118.GJ3066@sirena.org.uk \
--to=broonie@kernel.org \
--cc=collinsd@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@codeaurora.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
all inboxes | Powered by JetHome®