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: <BN0PR02MB817391C539C90651850391F6E40F9@BN0PR02MB8173.namprd02.prod.outlook.com>
Date:   Mon, 14 Mar 2022 14:51:20 +0000
From:   Vinod Polimera <vpolimer@....qualcomm.com>
To:     Doug Anderson <dianders@...omium.org>,
        quic_vpolimer <quic_vpolimer@...cinc.com>
CC:     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>,
        Stephen Boyd <swboyd@...omium.org>,
        quic_kalyant <quic_kalyant@...cinc.com>
Subject: RE: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum
 frequency in opp table during probe



> -----Original Message-----
> From: Doug Anderson <dianders@...omium.org>
> Sent: Thursday, March 10, 2022 12:55 AM
> To: quic_vpolimer <quic_vpolimer@...cinc.com>
> Cc: 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>; Stephen Boyd <swboyd@...omium.org>;
> quic_kalyant <quic_kalyant@...cinc.com>
> Subject: Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the
> maximum frequency in opp table during probe
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Hi,
> 
> On Tue, Mar 8, 2022 at 8:55 AM Vinod Polimera
> <quic_vpolimer@...cinc.com> wrote:
> >
> > use max clock during probe/bind sequence from the opp table.
> > The clock will be scaled down when framework sends an update.
> >
> > Signed-off-by: Vinod Polimera <quic_vpolimer@...cinc.com>
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
> >  1 file changed, 3 insertions(+)
> 
> In addition to Dmitry's requests, can you also make this patch #1 in
> the series since the DTS stuff really ought to come _after_ this one.
> 
> ...and actually, thinking about it further:
> 
> 1. If we land this fix, we actually don't _need_ the dts patches,
> right? Sure, the clock rate will get assigned before probe but then
> we'll change it right away in probe, right?
> 
> 2. If we land the dts patches _before_ the driver patch then it will
> be a regression, right?
> 
> 3. The dts patches and driver patch will probably land through
> separate trees. The driver patch will go through the MSM DRM tree and
> the device tree patches through the Qualcomm armsoc tree, right?
> 
> 
> Assuming that the above is right, we should:
> 
> 1. Put the driver patch first.
> 
Moved driver patch first.

> 2. Remove the "Fixes" tag on the dts patches. I guess in theory we
> could have a FIxes tag on this patch?
> 
- Removed fixed tag on dt patches and added on driver patch.

> 3. Note in the dts patches commit messages that they depend on the driver
> patch.
> 
- Added dependency patch on driver patch for dt patch.

> 4. Delay the dts patches until the driver change has made it to mainline.
> 
> Does that sound reasonable?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ