From: Mark Brown <broonie@kernel.org>
To: Niklas Cassel <niklas.cassel@linaro.org>
Cc: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Andy Gross <andy.gross@linaro.org>,
David Brown <david.brown@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Khasim Syed Mohammed <khasim.mohammed@linaro.org>
Subject: Re: [PATCH] arm64: dts: qcs404: evb: Fix voltages for s5 and l3
Date: Mon, 4 Feb 2019 11:43:47 +0100 [thread overview]
Message-ID: <20190204104347.GD23441@sirena.org.uk> (raw)
In-Reply-To: <20190129224652.GB11349@centauri.lan>
[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]
On Tue, Jan 29, 2019 at 11:46:52PM +0100, Niklas Cassel wrote:
> Adding Mark Brown on CC.
It really helps if you ask a specific question when doing something like
this rather than just have a big quoted mail - it makes it much easier
to find what's relevant rather than trying to find things, especially
when they're buried behind several layers of quoting.
> On Tue, Jan 29, 2019 at 10:58:47PM +0100, Jorge Ramirez wrote:
> > On 1/26/19 00:29, Bjorn Andersson wrote:
> > the question is, should this property contain only hardware achievable
> > values? or should drivers only request hardware achievable values? the
> > way the constrains are implemented it has to be one of the two (I think
> > the former would be more intuitive - ie if the dts
> > regulator-min-microvolt is a valid value)
Drivers should not be coded with a specific regulator or board in mind
and should just request whatever they need. This will then be matched
with whatever the board is actually able to deliver. Similarly there is
no requirement that machine constraints be written with specific
reference to what the physical regulator on the board is able to do, for
example the constraints will come from electrical engineering
restrictions like the specifications of the parts connected to the
regulator rather than from what the regulator can actually do so people
should feel free to just write down the actual physical constraint and
let the regulator API ensure that the constraint is met.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-02-04 10:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-25 23:29 [PATCH] arm64: dts: qcs404: evb: Fix voltages for s5 and l3 Bjorn Andersson
2019-01-29 21:58 ` Jorge Ramirez
2019-01-29 22:46 ` Niklas Cassel
2019-02-04 10:43 ` Mark Brown [this message]
2019-02-04 16:03 ` Bjorn Andersson
2019-02-04 18:23 ` Mark Brown
2019-02-04 19:25 ` Bjorn Andersson
2019-02-04 20:59 ` 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=20190204104347.GD23441@sirena.org.uk \
--to=broonie@kernel.org \
--cc=andy.gross@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jorge.ramirez-ortiz@linaro.org \
--cc=khasim.mohammed@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=niklas.cassel@linaro.org \
--cc=robh+dt@kernel.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