Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp256447pxp; Fri, 11 Mar 2022 03:49:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJwf5paHpz/9u9RAg1N+cOfzrMa1gtm3TQedwkliJjFpXthvzfJ8Jd8YerflDRKt/06lbvsK X-Received: by 2002:a17:907:97c1:b0:6da:bd15:cca0 with SMTP id js1-20020a17090797c100b006dabd15cca0mr8070147ejc.327.1646999341161; Fri, 11 Mar 2022 03:49:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646999341; cv=none; d=google.com; s=arc-20160816; b=EZTrLRLSRG6ruXzRgWoAPTIJ3nPQDvuA71cVQmKqiJU6f1HMCYODTSyXiW3hCPmryH 1Wuf7r4IStCl1NYOUDBpf5P901y7xtCauziq1L0nFrlQ62px6V2S8Qwcl8frqUBv7GEV 0lIvtFV6M6KniyGa35gf6vzFGdwR1/Hyq59ajIPeU8IM0DEE4EmmJIqgQCCJCcP8kMAP Wl7BLzJTilX+KAE6YzLyZQHGZ5af2JID+BozRAsuzE+LIsRFPT9bDBgrlrzQVt2YJ7dD UES2erhaeQAmAouRXiqN1ABujbDVO1q+bDodMDwj5WR35y8acGjRhFBsf8MiIhd1hl8j TbIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5yB2ssbuBZx5F0u4321kFXuP4TmIeDrCq6d7hvGDPTg=; b=Sr2wmTL1twI73fsb78EqwT5HcAEY39wEowMb38Zy8b07av0diDCIq8XojwmNlPxiv3 0xhaw9j7b9r79PaDX9FXMwL+siTjIrp86ym7KL35hXhD9YPU9YIe2uKlWCJpFerZtjRM Xvt9+cU0asw0ErUk1yI4SdcdsYYHWdW2ESCxMrcQtaqUFBxjDYS7zGSmHqr/IUe7yw/y c0uRbOlewyndKOgrc+VSdIBpnIW8+AZa7zx9zNb3bBbtEfzJFXee5EXcalkpe532Nu3N ekFawpdrifIg0vSsYICBXYjUqSB7eyrvbfCX+w/hhOa32hADgvNawwPtMSkijjdT92uH KWYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cmhwVxbw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z8-20020a17090665c800b006b54b51c672si4950541ejn.699.2022.03.11.03.48.35; Fri, 11 Mar 2022 03:49:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cmhwVxbw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347449AbiCKJX7 (ORCPT + 99 others); Fri, 11 Mar 2022 04:23:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347460AbiCKJXz (ORCPT ); Fri, 11 Mar 2022 04:23:55 -0500 Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CB1397BBF for ; Fri, 11 Mar 2022 01:22:49 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id 10so4326012qtz.11 for ; Fri, 11 Mar 2022 01:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5yB2ssbuBZx5F0u4321kFXuP4TmIeDrCq6d7hvGDPTg=; b=cmhwVxbwFxNLFe88VcQKADx1bM2QPDytOUGUzFpRUf6kfONBxDn3fCJJOWbMgyIjs6 3yt7nNySNS+pzTrYw7kFmgPCgeP0SelBrffzhy6vkhYUV0d1GxoU4+IP8ni5VXNhmUoK YQ55VpIVgQaGYdtng2Eeo7b4RnlHMaLiEy74J5StS34Vh/N6krSkcs4cei7tRYFp0d80 xuLVy+IBziQVmOGUOBjc7ZYIzcOs46V4I6n7GWZfn99mNWEZbJs+YFt8c0Na1fELKSvr 3sz+5TA/n9KvE8/j+epguoOl7q2qml6OHE+q3Iiyuz2taFl3vqChrstWFhg02cyHpE5v tarw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5yB2ssbuBZx5F0u4321kFXuP4TmIeDrCq6d7hvGDPTg=; b=DgwzDND1Otg8UzuH5xR9mk8gM65QlvsRSEJ4eb54nievWiOBxsuO3rj3Cyun/hTBu+ 6zR7SvLo7GVUqBEDORnr/HAv6LNKRjpuzQUikotMF2jSaH4uyBIwlKupatGvBHc5EB+j ZPCUKtk1SLC+ncgiJ63KFuLJYra8IzdzwpkTca6opesy2P/RIe8jQlHzm7nkEenumY9I cZRney4eFYpoelvZKleJaXXYQXdiOtez0R2r891rP/Y/jPY0pVY2hrOL/auaY9aE648l 52OX4Sb6vlKYUB21O+fnBKofQKI1QlbHaNOuza0eOIad+M9PKlEccr2Xvk45rxbz3Qhd dn4w== X-Gm-Message-State: AOAM5307kaAt/9EoHNNWlZyaLNDsZtbZH4GrgLPr2tfpfTeNAZqeSO4b fooNW59O+gkLZZee+GfdsgA5tm/aHzD1BFObUzA+zw== X-Received: by 2002:ac8:7d0a:0:b0:2e0:4e16:d3fb with SMTP id g10-20020ac87d0a000000b002e04e16d3fbmr7249289qtb.295.1646990568534; Fri, 11 Mar 2022 01:22:48 -0800 (PST) MIME-Version: 1.0 References: <1646758500-3776-1-git-send-email-quic_vpolimer@quicinc.com> <1646758500-3776-2-git-send-email-quic_vpolimer@quicinc.com> In-Reply-To: From: Dmitry Baryshkov Date: Fri, 11 Mar 2022 12:22:37 +0300 Message-ID: Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk To: Vinod Polimera Cc: Stephen Boyd , quic_vpolimer , "devicetree@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "freedreno@lists.freedesktop.org" , "linux-arm-msm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "robdclark@gmail.com" , "dianders@chromium.org" , quic_kalyant Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 11 Mar 2022 at 11:06, Vinod Polimera wrote: > > > > > -----Original Message----- > > From: Stephen Boyd > > Sent: Wednesday, March 9, 2022 1:36 AM > > To: quic_vpolimer ; > > devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org; > > freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com; > > dianders@chromium.org; quic_kalyant > > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock- > > rate property for mdp clk > > > > WARNING: This email originated from outside of Qualcomm. Please be wary > > of any links or attachments, and do not enable macros. > > > > Quoting Vinod Polimera (2022-03-08 08:54:56) > > > Kernel clock driver assumes that initial rate is the > > > max rate for that clock and was not allowing it to scale > > > beyond the assigned clock value. > > > > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and > > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver > > is preventing the frequency from changing beyond the assigned value. > > Folowing the comment of Stephen, i have checked a bit more. it appears that clock driver is not setting the max clock from assgined clocks, dpu driver is doing that. > i am planning to fix it as below. > 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver. > 2) remove unnecessary checks in the core_perf library. If rate doesn't match with the entries in the opp table, it will throw error, hence furthur checks are not needed. > 3) no changes in dt are required. (we can drop all the posted ones) Why? They made perfect sense. The dts assignments should be replaced by the opp setting in the bind function, as this would also set the performance point of the respective power domain. > > Changes : > ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c > @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc) > } > } > > -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate) > -{ > - struct dss_clk *core_clk = kms->perf.core_clk; > - > - if (core_clk->max_rate && (rate > core_clk->max_rate)) > - rate = core_clk->max_rate; > - > - core_clk->rate = rate; > - return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate); > -} > - > static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms) > { > u64 clk_rate = kms->perf.perf_tune.min_core_clk; > @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc, > > trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate); > > - ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate); > + ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate); > if (ret) { > DPU_ERROR("failed to set %s clock rate %llu\n", > kms->perf.core_clk->clk_name, clk_rate); > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c This file has been removed in msm/next > @@ -175,7 +175,7 @@ int msm_dss_parse_clock(struct platform_device *pdev, > continue; > mp->clk_config[i].rate = rate; > mp->clk_config[i].type = DSS_CLK_PCLK; > - mp->clk_config[i].max_rate = rate; > + mp->clk_config[i].max_rate = ULONG_MAX; > } > > mp->num_clk = num_clk; > --``` > > Thanks, > Vinod. > > > > > > > > > Drop the assigned clock rate property and vote on the mdp clock as per > > > calculated value during the usecase. > > > > > > Changes in v2: > > > - Remove assigned-clock-rate property and set mdp clk during resume > > sequence. > > > - Add fixes tag. > > > > > > Changes in v3: > > > - Remove extra line after fixes tag.(Stephen Boyd) > > > > This changelog should be removed. > > > > > > > > Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes") > > > > I thought folks were saying that this is bad to keep? I don't really > > mind either way, but I guess it's better to drop the fixes tag because > > this is largely a performance improvement? > > > > > Signed-off-by: Vinod Polimera > > > Reviewed-by: Stephen Boyd -- With best wishes Dmitry