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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84842C433F5 for ; Fri, 4 Mar 2022 00:16:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237349AbiCDAQ4 (ORCPT ); Thu, 3 Mar 2022 19:16:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231175AbiCDAQy (ORCPT ); Thu, 3 Mar 2022 19:16:54 -0500 Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A333C1768D3 for ; Thu, 3 Mar 2022 16:16:01 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id gm1so5447321qvb.7 for ; Thu, 03 Mar 2022 16:16:01 -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=eCjc4x4By6clCaeAiAFIhXtDZP9qpnoE7G+iXzZ8y04=; b=oP3Se4QqoP9oAlQ1HRVSjzyG5E2i34IxROypI6Bz8iIiSEekElY8/BTpuNTyk1HKwf G7LkEPxIO5SPYolkl29HrX0Ox50rktrbuHE/KZoQqyyZ1tJAlFmeVxoYHFGEQ363oRhz 9tD+IEJaGkj6cadV74LDDg52Z4I4om+nAsNfXOsMY2idn/iul+VqA9UBWw28A6N4VLom +qwsMv4qn+Uo3rXGbQA0+czOGICIRcUvvdyT6zxOqZm73F6dk9FgBbqu6vVsKwjAeDiJ uzugSydM4U8v9MWShFmWMA1PVBrpWbLrdJ0eDQlRjim8O8Xfk69nxx3+yR3Us6QdFQYH uWsg== 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=eCjc4x4By6clCaeAiAFIhXtDZP9qpnoE7G+iXzZ8y04=; b=fi243oAIxa0V+PTCYFFi0f8l7BXrYhAuhPOrbWqKi2VNyshjIiAUg/tFN4CmCof60y eQ1iAekvwO3kMTZ3EMlQhf/Cf5BKpc2P/63LljNR1z2PaiLJtI6ncLVgvjmwPJtaEYIt vIC2q0Gw+HlG27yjnGhlF7Audtf5jV0TNd6DZpSVW9ISUWk14L6mWCiob2mVCBnsK0dU bVD9bXvqPQMhYEwEVCfrd4uJAp060KelHp3qtbI/V2tcxMX03a2Ahu+zcoDbIO/By+F2 +IrYyrYbdOt8izLDdRjG2mrWNyWHC4bzdbeqAaV7T+5R8gBAQhndYFeHs/eDEajdW6gs xi0g== X-Gm-Message-State: AOAM532QCU0z4U6hCnFx+rC2a6kQC8LhONVmx1hGAxcIp1+qso1hQOrL vqgI0bzKVBr7t/aK1dEdbVZSls5yThbcND8Cbz8TQA== X-Google-Smtp-Source: ABdhPJxum/m+TEt3e7BQD9vNYZDUIpyt+gK4TZ209Fwn4ctVQ9miyXr7mySaKYi3BuSGNSTDSVnqVqbdgDlUxVbPp/Q= X-Received: by 2002:a0c:d807:0:b0:42c:1ff7:7242 with SMTP id h7-20020a0cd807000000b0042c1ff77242mr26194090qvj.119.1646352960853; Thu, 03 Mar 2022 16:16:00 -0800 (PST) MIME-Version: 1.0 References: <1646300401-9063-1-git-send-email-quic_vpolimer@quicinc.com> <1646300401-9063-5-git-send-email-quic_vpolimer@quicinc.com> In-Reply-To: From: Dmitry Baryshkov Date: Fri, 4 Mar 2022 03:15:49 +0300 Message-ID: Subject: Re: [PATCH v4 4/4] arm64/dts/qcom/sm8250: remove assigned-clock-rate property for mdp clk To: Stephen Boyd Cc: Vinod Polimera , dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, robdclark@gmail.com, dianders@chromium.org, quic_kalyant@quicinc.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Mar 2022 at 02:56, Stephen Boyd wrote: > > Quoting Dmitry Baryshkov (2022-03-03 15:50:50) > > On Thu, 3 Mar 2022 at 12:40, Vinod Polimera wrote: > > > > > > 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. > > > > > > Drop the assigned clock rate property and vote on the mdp clock as per > > > calculated value during the usecase. > > > > > > Fixes: 7c1dffd471("arm64: dts: qcom: sm8250.dtsi: add display system nodes") > > > > Please remove the Fixes tags from all commits. Otherwise the patches > > might be picked up into earlier kernels, which do not have a patch > > adding a vote on the MDP clock. > > What patch is that? The Fixes tag could point to that commit. Please correct me if I'm wrong. Currently the dtsi enforces bumping the MDP clock when the mdss device is being probed and when the dpu device is being probed. Later during the DPU lifetime the core_perf would change the clock's rate as it sees fit according to the CRTC requirements. However it would happen only when the during the dpu_crtc_atomic_flush(), before we call this function, the MDP clock is left in the undetermined state. The power rails controlled by the opp table are left in the undetermined state. I suppose that during the dpu_bind we should bump the clock to the max possible freq and let dpu_core_perf handle it afterwards. -- With best wishes Dmitry