[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF6AEGv4w=a8kpkM63OU8DJ_nND5acG6nNuz8r4qnAT8Acyw+g@mail.gmail.com>
Date: Tue, 31 Oct 2023 05:46:28 -0700
From: Rob Clark <robdclark@...il.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Bjorn Andersson <quic_bjorande@...cinc.com>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Sean Paul <sean@...rly.run>,
Marijn Suijten <marijn.suijten@...ainline.org>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Bjorn Andersson <andersson@...nel.org>,
Kuogee Hsieh <quic_khsieh@...cinc.com>,
Johan Hovold <johan@...nel.org>, linux-arm-msm@...r.kernel.org,
dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Doug Anderson <dianders@...omium.org>,
Rob Clark <robdclark@...omium.org>
Subject: Re: [PATCH] drm/msm/dpu: Add missing safe_lut_tbl in sc8280xp catalog
On Tue, Oct 31, 2023 at 1:19 AM Manivannan Sadhasivam
<manivannan.sadhasivam@...aro.org> wrote:
>
> On Mon, Oct 30, 2023 at 04:23:20PM -0700, Bjorn Andersson wrote:
> > During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
> > typically take 1-2ms to complete. As expected this results in poor
> > performance, something that has been mitigated by proposing running the
> > iommu in non-strict mode (boot with iommu.strict=0).
> >
> > This turns out to be related to the SAFE logic, and programming the QOS
> > SAFE values in the DPU (per suggestion from Rob and Doug) reduces the
> > TLB sync time to below 10us, which means significant less time spent
> > with interrupts disabled and a significant boost in throughput.
> >
> > Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
> > Cc: stable@...r.kernel.org
> > Suggested-by: Doug Anderson <dianders@...omium.org>
> > Suggested-by: Rob Clark <robdclark@...omium.org>
> > Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> > index 1ccd1edd693c..4c0528794e7a 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> > @@ -406,6 +406,7 @@ static const struct dpu_perf_cfg sc8280xp_perf_data = {
> > .min_llcc_ib = 0,
> > .min_dram_ib = 800000,
> > .danger_lut_tbl = {0xf, 0xffff, 0x0},
> > + .safe_lut_tbl = {0xfe00, 0xfe00, 0xffff},
>
> What does these values represent? And how SAFE is to override the default QoS
> values?
>
> I'm not too familiar with the MSM DRM driver, so please excuse my ignorance.
for realtime dma (like scanout) there is a sort of "safe" signal from
the dma master to the smmu to indicate when it has enough data
buffered for it to be safe to do tlbinv without risking underflow.
When things aren't "safe" the smmu will stall tlbinv. This is just
configuring the thresholds for the "safe" signal.
BR,
-R
> - Mani
>
> > .qos_lut_tbl = {
> > {.nentry = ARRAY_SIZE(sc8180x_qos_linear),
> > .entries = sc8180x_qos_linear
> >
> > ---
> > base-commit: c503e3eec382ac708ee7adf874add37b77c5d312
> > change-id: 20231030-sc8280xp-dpu-safe-lut-9769027b8452
> >
> > Best regards,
> > --
> > Bjorn Andersson <quic_bjorande@...cinc.com>
> >
>
> --
> மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists