Messages in this thread | | | From | Vinod Polimera <> | Subject | RE: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe | Date | Mon, 14 Mar 2022 14:51:20 +0000 |
| |
> -----Original Message----- > From: Doug Anderson <dianders@chromium.org> > Sent: Thursday, March 10, 2022 12:55 AM > To: quic_vpolimer <quic_vpolimer@quicinc.com> > Cc: dri-devel <dri-devel@lists.freedesktop.org>; linux-arm-msm <linux-arm- > msm@vger.kernel.org>; freedreno <freedreno@lists.freedesktop.org>; > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > <devicetree@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org>; Rob > Clark <robdclark@gmail.com>; Stephen Boyd <swboyd@chromium.org>; > quic_kalyant <quic_kalyant@quicinc.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@quicinc.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@quicinc.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?
| |