From: Stanimir Varbanov <stanimir.varbanov@linaro.org>
To: Rajendra Nayak <rnayak@codeaurora.org>,
robh+dt@kernel.org, agross@kernel.org,
bjorn.andersson@linaro.org
Cc: linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
mka@chromium.org
Subject: Re: [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus
Date: Fri, 24 Jul 2020 17:09:48 +0300 [thread overview]
Message-ID: <94581989-e069-55e5-6b70-919185eda33e@linaro.org> (raw)
In-Reply-To: <e68ff810-362a-5b99-206b-f676b204101d@linaro.org>
Hi,
On 7/23/20 9:06 PM, Stanimir Varbanov wrote:
> Hi Rajendra,
>
> After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I see
> below messages on db845:
>
> qcom-venus aa00000.video-codec: dev_pm_opp_set_rate: failed to find
> current OPP for freq 533000097 (-34)
>
> ^^^ This one is new.
>
> qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x30000
>
> ^^^ and this message is annoying, can we make it pr_debug in rpmh?
>
> On 7/23/20 2:26 PM, Rajendra Nayak wrote:
>> Add the OPP tables in order to be able to vote on the performance state of
>> a power-domain.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>> ---
>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 40 ++++++++++++++++++++++++++++++++++--
>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index e506793..5ca2265 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -3631,8 +3631,10 @@
>> interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>> power-domains = <&videocc VENUS_GDSC>,
>> <&videocc VCODEC0_GDSC>,
>> - <&videocc VCODEC1_GDSC>;
>> - power-domain-names = "venus", "vcodec0", "vcodec1";
>> + <&videocc VCODEC1_GDSC>,
>> + <&rpmhpd SDM845_CX>;
>> + power-domain-names = "venus", "vcodec0", "vcodec1", "cx";
>> + operating-points-v2 = <&venus_opp_table>;
>> clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
>> <&videocc VIDEO_CC_VENUS_AHB_CLK>,
>> <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
>> @@ -3654,6 +3656,40 @@
>> video-core1 {
>> compatible = "venus-encoder";
>> };
>> +
>> + venus_opp_table: venus-opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-100000000 {
>> + opp-hz = /bits/ 64 <100000000>;
>> + required-opps = <&rpmhpd_opp_min_svs>;
>> + };
>> +
>> + opp-200000000 {
>> + opp-hz = /bits/ 64 <200000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> +
>> + opp-320000000 {
>> + opp-hz = /bits/ 64 <320000000>;
>> + required-opps = <&rpmhpd_opp_svs>;
>> + };
>> +
>> + opp-380000000 {
>> + opp-hz = /bits/ 64 <380000000>;
>> + required-opps = <&rpmhpd_opp_svs_l1>;
>> + };
>> +
>> + opp-444000000 {
>> + opp-hz = /bits/ 64 <444000000>;
>> + required-opps = <&rpmhpd_opp_nom>;
>> + };
>> +
>> + opp-533000000 {
>> + opp-hz = /bits/ 64 <533000000>;
Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
defines 533000000 but the real calculated freq is 533000097.
If I change to opp-hz = /bits/ 64 <533000097> the error disappear.
I guess we have to revisit m/n and/or pre-divider for this freq when the
source pll is P_VIDEO_PLL0_OUT_MAIN PLL?
>> + required-opps = <&rpmhpd_opp_turbo>;
>> + };
>> + };
>> };
>>
>> videocc: clock-controller@ab00000 {
>>
>
--
regards,
Stan
next prev parent reply other threads:[~2020-07-24 14:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 11:26 [PATCH v4 0/5] DVFS support for Venus Rajendra Nayak
2020-07-23 11:26 ` [PATCH v4 1/5] dt-bindings: media: venus: Add an optional power domain for perf voting Rajendra Nayak
2020-07-23 17:30 ` Rob Herring
2020-07-23 11:26 ` [PATCH v4 2/5] media: venus: core: Fix error handling in probe Rajendra Nayak
2020-07-24 14:55 ` Stanimir Varbanov
2020-07-23 11:26 ` [PATCH v4 3/5] media: venus: core: Add support for opp tables/perf voting Rajendra Nayak
2020-07-26 12:47 ` Stanimir Varbanov
2020-07-23 11:26 ` [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus Rajendra Nayak
2020-07-23 18:06 ` Stanimir Varbanov
2020-07-24 8:49 ` Rajendra Nayak
2020-07-24 10:16 ` Stanimir Varbanov
2020-07-24 9:02 ` Rajendra Nayak
2020-07-24 16:28 ` Lina Iyer
2020-07-24 16:52 ` Stanimir Varbanov
2020-07-24 17:00 ` Stanimir Varbanov
2020-07-28 0:45 ` Stephen Boyd
2020-07-28 16:52 ` Lina Iyer
2020-07-28 19:51 ` Stephen Boyd
2020-07-28 20:11 ` Lina Iyer
2020-07-29 18:10 ` Doug Anderson
2020-07-29 20:38 ` Bjorn Andersson
2020-07-24 14:09 ` Stanimir Varbanov [this message]
2020-07-27 5:53 ` Rajendra Nayak
2020-07-27 12:08 ` Rajendra Nayak
2020-07-27 15:38 ` Viresh Kumar
2020-07-28 0:52 ` Stephen Boyd
2020-07-28 4:17 ` Rajendra Nayak
2020-07-28 19:54 ` Stephen Boyd
2020-07-23 11:26 ` [PATCH v4 5/5] arm64: dts: sc7180: " Rajendra Nayak
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=94581989-e069-55e5-6b70-919185eda33e@linaro.org \
--to=stanimir.varbanov@linaro.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mka@chromium.org \
--cc=rnayak@codeaurora.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;
as well as URLs for NNTP newsgroup(s).