From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Konrad Dybcio <konrad.dybcio@somainline.org>,
linux-arm-msm@vger.kernel.org, agross@kernel.org,
kernel@gpiccoli.net
Subject: Re: [PATCH] arm64: dts: qcom: db820c: Improve regulator voltage range and mark it as always-on
Date: Tue, 28 Sep 2021 18:54:47 -0300 [thread overview]
Message-ID: <77a76065-d797-b59d-5570-d1b9606b79fb@igalia.com> (raw)
In-Reply-To: <YVKFeqpe/sWj3h6K@builder.lan>
Bjorn, first of all, thanks a *lot* for your great/informative response!
Much appreciated =)
I'll respond more inline, below:
On 28/09/2021 00:01, Bjorn Andersson wrote:
>
> The regulator range described in the datasheet and in the regulator
> driver defines what the PMIC can do, the dts refines this to a range
> that it suitable for this particular board. So it's expected to be more
> narrow.
>
> The problem with vdd_gfx is that we don't have anything voting for an
> actual voltage, so you will either continue to run with whatever voltage
> we got from the power-on state (or bootloader), or
> regulator-min-microvolt. Until someone could come up with this support
> 0.98V seems to have been picked as some good enough number...
>
>
> The right thing would be to ensure that the voltage is scaled with the
> GPU clock, presumably with some reference from gpu_opp_table. This can
> perhaps be done using static voltages, but should in the long run be
> done by votes against the performance states exposed by the CPR block
> attached to the vdd_gfx - which will then ensure that the voltage level
> is adjusted as needed on a per-device basis.
>
Very interesting...thanks for the details. Just confirming: CPR is Core
Power Reduction, right?
Found its (DTS) documentation at
devicetree/bindings/power/avs/qcom,cpr.txt, I'll study more and also the
driver counter-part.
>> More than that, my experiment showed that this regulator must be set to
>> always-on - this idea came from a commit in Linaro's tree, from Rajendra [2].
>
> The regulator should be enabled whenever someone is voting for the
> GPU_GX_GDSC power domain of mmcc. Question is why this isn't enough.
>
This is very interesting, I'll investigate more! I just tested and
indeed, without that setting, the board reboots suddenly.
>> With the voltage range updated plus set as always-on, the GPU is working
>> correctly, in a stable fashion.
>>
>
> Could you perhaps check /sys/kernel/debug/regulator/regulator_summary to
> see the voltage level you get for your VDD_GFX when it works?
>
Sure! This is the output:
VDD_GFX 1 1 0 fast 1000mV 0mA 350mV 1350mV
8c0000.clock-controller-vdd-gfx 0 0mA 0mV 0mV
So, 1000mV is enough it seems.
> [...]
>
> No need to apologize, the patch itself looks really good and nice to see
> that you tested it on both v5.14 and linux-next!
>
Thank you =)
>>
> status = "okay" is the default value, so unless you want to disable a
> node in the dtsi by default, or override it to "okay" when it was
> previously disabled, there's no need to provide "status" here.
>
>> +
>
> And this empty line is undesirable.
>
>
> So to summarize, I do think there might be cases where your patch
> lowers the GPU voltage from 0.98V to 0.35V, which would result in a sad
> outcome. I think we should try to plug some voltages into gpu_opp_table,
> but perhaps we need to look into CPR to figure out what those voltages
> should be?
>
OK cool, removed the okay status, worked fine as you suggested.
Now, regarding this approach of plugging the voltages on gpu_opp, I can
study more and try to come up with something. But it'll take some days
at least - for now, do you think that'd be interesting to adjust the
regulator voltage with min == 980mV and max == 1000mV? I tried here, and
it worked!
Let me know your thoughts!
Cheers,
Guilherme
next prev parent reply other threads:[~2021-09-28 21:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-27 16:37 [PATCH] arm64: dts: qcom: db820c: Improve regulator voltage range and mark it as always-on Guilherme G. Piccoli
2021-09-27 16:39 ` Guilherme G. Piccoli
2021-09-28 3:01 ` Bjorn Andersson
2021-09-28 21:54 ` Guilherme G. Piccoli [this message]
2021-09-28 22:55 ` Bjorn Andersson
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=77a76065-d797-b59d-5570-d1b9606b79fb@igalia.com \
--to=gpiccoli@igalia.com \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=kernel@gpiccoli.net \
--cc=konrad.dybcio@somainline.org \
--cc=linux-arm-msm@vger.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