devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      reply	other threads:[~2021-01-12  0:30 UTC|newest]

Thread overview: 4+ 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]

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 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).