From: Mark Brown <broonie@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Johan Hovold <johan@kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Liam Girdwood <lgirdwood@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] regulator: core: Allow for a base-load per client to come from dts
Date: Sat, 23 Jul 2022 20:23:03 +0100 [thread overview]
Message-ID: <YtxKl/GRKGZJwNN/@sirena.org.uk> (raw)
In-Reply-To: <YtxHwUe4W7+u3Lk3@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]
On Sat, Jul 23, 2022 at 08:11:01PM +0100, Mark Brown wrote:
> The more I think about this the more I think that what's
> practically going on here fits better with the mode interface
> than the load one, normally I'd not like doing a run around the
> abstractions the underlying thing is offering but it really does
> seem like someone has to bite the bullet and do that runaround
> and it's probably going to be less work all round at the
> regulator level.
Actually thinking about it even more for most cases it may even
just be that we need to add some number to the load request while
the regulator is powered on, the existing system-load property
would probably do the trick here if putting things in DT.
Depending on if the firmware counts loads from things that voted
off or not the driver might need to do an update on the load when
enabling and disabling. That is less of an end run around the
abstraction, though it does cause issues for the system-load's
intended use so perhaps a separate property might be safer.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-07-23 19:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-22 1:26 [RFC PATCH] regulator: core: Allow for a base-load per client to come from dts Douglas Anderson
2022-07-22 18:22 ` Mark Brown
2022-07-22 23:35 ` Doug Anderson
2022-07-23 19:10 ` Mark Brown
2022-07-23 19:23 ` Mark Brown [this message]
2022-07-26 0:31 ` Doug Anderson
2022-07-26 12:12 ` 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=YtxKl/GRKGZJwNN/@sirena.org.uk \
--to=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=johan@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@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;
as well as URLs for NNTP newsgroup(s).