From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>,
Kiran Gunda <kgunda@codeaurora.org>,
Alexandru M Stan <amstan@chromium.org>,
Stephen Boyd <swboyd@chromium.org>,
Andy Gross <agross@kernel.org>, Rob Herring <robh+dt@kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64: dts: qcom: Clean up sc7180-trogdor voltage rails
Date: Mon, 11 Jan 2021 17:26:57 -0600 [thread overview]
Message-ID: <X/zewUR8Dc2Jf/MM@builder.lan> (raw)
In-Reply-To: <CAD=FV=VWEEP7xsD5-wBjtToB+Ke69vFXzvPoAoocWPyREdjjhw@mail.gmail.com>
On Mon 11 Jan 15:48 CST 2021, Doug Anderson wrote:
> Hi Bjorn,
>
> On Mon, Dec 7, 2020 at 2:33 PM Douglas Anderson <dianders@chromium.org> wrote:
> >
> > For a bunch of rails we really don't do anything with them in Linux.
> > These are things like modem voltage rails that the modem manages these
> > itself and core rails (like IO rails) that are setup to just
> > automagically do the right thing by the firmware.
> >
> > Let's stop even listing those rails in our device tree.
> >
> > The net result of this is that some of these rails might be able to go
> > down to a lower voltage or perhaps transition to LPM (low power mode)
> > sometimes.
> >
> > Here's a list of what we're doing and why:
> >
> > * L1A - only goes to SoC and doesn't seem associated with any
> > particular peripheral. Kernel isn't doing anything with
> > this. Removing from dts. NET IMPACT: rail might drop from 1.2V to
> > 1.178V and switch to LPM in some cases depending on firmware.
> > * L2A - only goes to SoC and doesn't seem associated with any
> > particular peripheral. Kernel isn't doing anything with
> > this. Removing from dts. NET IMPACT: rail might switch to LPM in
> > some cases depending on firmware.
> > * L3A - only goes to SoC and doesn't seem associated with any
> > particular peripheral. Kernel isn't doing anything with
> > this. Removing from dts. NET IMPACT: rail might switch to LPM in
> > some cases depending on firmware.
> > * L5A - seems to be totally unused as far as I can tell and doesn't
> > even come off QSIP. Removing from dts.
> > * L6A - only goes to SoC and doesn't seem associated with any
> > particular peripheral (I think?). Kernel isn't doing anything with
> > this. Removing from dts. NET IMPACT: rail might switch to LPM in
> > some cases depending on firmware.
> > * L16A - Looks like this is only used for internal RF stuff. Removing
> > from dts. NET IMPACT: rail might switch to LPM in some cases
> > depending on firmware.
> > * L1C - Just goes to WiFi / Bluetooth. Trust how IDP has this set and
> > put this back at 1.616V min.
> > * L4C - This goes out to the eSIM among other places. This looks like
> > it's intended to be for SIM card and modem manages. NET IMPACT:
> > rail might switch to LPM in some cases depending on firmware.
> > * L5C - This goes to the physical SIM. This looks like it's intended
> > to be for SIM card and modem manages. NET IMPACT: rail might drop
> > from 1.8V to 1.648V and switch to LPM in some cases depending on
> > firmware.
> >
> > NOTE: in general for anything which is supposed to be managed by Linux
> > I still left it all forced to HPM since I'm not 100% sure that all the
> > needed calls to regulator_set_load() are in place and HPM is safer.
> > Switching more things to LPM can happen in a future patch.
> >
> > ALSO NOTE: Power measurements showed no measurable difference after
> > applying this patch, so perhaps it should be viewed more as a cleanup
> > than any power savings.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> > arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 82 ++------------------
> > 1 file changed, 7 insertions(+), 75 deletions(-)
>
> We've been running with this in the downstream tree since December 8th
> and nobody has yelled. You can see <https://crrev.com/c/2573506>. Is
> it a good time for it to land upstream?
>
Sure thing, I will pick it up. Thanks for the ping!
Regards,
Bjorn
next prev parent reply other threads:[~2021-01-12 0:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 22:33 [PATCH] arm64: dts: qcom: Clean up sc7180-trogdor voltage rails Douglas Anderson
2020-12-09 1:07 ` Alexandru M Stan
2021-01-11 21:48 ` Doug Anderson
2021-01-11 23:26 ` Bjorn Andersson [this message]
2021-01-15 14:20 ` patchwork-bot+linux-arm-msm
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=X/zewUR8Dc2Jf/MM@builder.lan \
--to=bjorn.andersson@linaro.org \
--cc=agross@kernel.org \
--cc=amstan@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=kgunda@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mka@chromium.org \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.