From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7130C433E3 for ; Mon, 27 Jul 2020 12:09:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BDF3620786 for ; Mon, 27 Jul 2020 12:09:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="kaYEU75S" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726620AbgG0MJu (ORCPT ); Mon, 27 Jul 2020 08:09:50 -0400 Received: from mail29.static.mailgun.info ([104.130.122.29]:29951 "EHLO mail29.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728071AbgG0MJs (ORCPT ); Mon, 27 Jul 2020 08:09:48 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1595851786; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: References: Cc: To: From: Subject: Sender; bh=N+OxDCRHWtMXnNN00q7isorslYGD8DlcIAQ4ZVsCYVs=; b=kaYEU75SNFrNUxW3zDSdGym1UPdpoHy+Plf83OF3IGWceg+pUz91AZ7pFgoU6d4iRBqTvj/0 MSWrjboCNefYpiDZr0Zp+aP6sHovdCj0E59KmhpFMmkTfdiDiBrUh8B6ibdntoO0AUOZ8if3 IYIAWbEGacp5JvkWl9OLtIQuUZI= X-Mailgun-Sending-Ip: 104.130.122.29 X-Mailgun-Sid: WyI1MzIzYiIsICJsaW51eC1hcm0tbXNtQHZnZXIua2VybmVsLm9yZyIsICJiZTllNGEiXQ== Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n11.prod.us-west-2.postgun.com with SMTP id 5f1ec3bac7e7bf09e0188357 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 27 Jul 2020 12:08:26 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 426CDC43391; Mon, 27 Jul 2020 12:08:26 +0000 (UTC) Received: from [192.168.1.12] (unknown [61.1.231.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rnayak) by smtp.codeaurora.org (Postfix) with ESMTPSA id 8B373C433C9; Mon, 27 Jul 2020 12:08:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 8B373C433C9 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=rnayak@codeaurora.org Subject: Re: [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus From: Rajendra Nayak To: Stanimir Varbanov , 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, Taniya Das , Stephen Boyd , Viresh Kumar References: <1595503612-2901-1-git-send-email-rnayak@codeaurora.org> <1595503612-2901-5-git-send-email-rnayak@codeaurora.org> <94581989-e069-55e5-6b70-919185eda33e@linaro.org> Message-ID: <5a8af2da-cc3f-005d-47e6-b36be1104d6a@codeaurora.org> Date: Mon, 27 Jul 2020 17:38:17 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 7/27/2020 11:23 AM, Rajendra Nayak wrote: > > > On 7/24/2020 7:39 PM, Stanimir Varbanov wrote: >> 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 >>>> --- >>>>   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 = ; >>>>               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. > > I still don't quite understand why the videocc driver returns this > frequency despite this not being in the freq table. Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to return whats in the freq table, but clk_set_rate() goes ahead and sets it to 533000097. Subsequently when we try to set a different OPP, it fails to find the 'current' OPP entry for 533000097. This sounds like an issue with the OPP framework? Should we not fall back to the highest OPP as the current OPP? Stephen/Viresh, any thoughts? > I would expect a clk_round_rate() when called with 533000097 to return > a 533000000. > > Taniya, Do you know why? > >> >> 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 { >>>> >>> >> > -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation