linux-kernel - Re: [PATCH v4 4/4] arm64/dts/qcom/sm8250: remove assigned-clock-rate property for mdp clk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA8EJpq7XEy2C5=80HMHcy3wvB2CJetyQhcjQRcTtEafauy91g@mail.gmail.com>
Date:   Sat, 5 Mar 2022 01:11:42 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Stephen Boyd <swboyd@...omium.org>,
        Vinod Polimera <quic_vpolimer@...cinc.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        Rob Clark <robdclark@...il.com>, quic_kalyant@...cinc.com
Subject: Re: [PATCH v4 4/4] arm64/dts/qcom/sm8250: remove assigned-clock-rate
 property for mdp clk

On Sat, 5 Mar 2022 at 00:49, Doug Anderson <dianders@...omium.org> wrote:
> On Thu, Mar 3, 2022 at 4:16 PM Dmitry Baryshkov
> <dmitry.baryshkov@...aro.org> wrote:
> >
> > On Fri, 4 Mar 2022 at 02:56, Stephen Boyd <swboyd@...omium.org> wrote:
> > >
> > > Quoting Dmitry Baryshkov (2022-03-03 15:50:50)
> > > > On Thu, 3 Mar 2022 at 12:40, Vinod Polimera <quic_vpolimer@...cinc.com> 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.
>
> "Currently" means _before_ ${SUBJECT} patch lands, right? Since
> ${SUBJECT} patch is removing the bump to max.

Yes. 'Before this patch'.

>
>
> > 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.
>
> Definitely feels like seeing the clock to something predictable during
> the initial probe makes sense. If it's just for the initial probe then
> setting it to max (based on the opp table) seems fine.

Vinod, could you please implement it?

> I think an
> earlier version of this series set it to max every time we did runtime
> resume. We'd have to have a good reason to do that.

Yes, this is correct. Based on the comments I had the impression that
there was a suggestion that the place for the calls was wrong. Most
probably I was instead projecting my own thoughts.

-- 
With best wishes
Dmitry