lkml.org 
[lkml]   [2020]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [Freedreno] [PATCH 3/3] drm/msm/dpu: add support for clk and bw scaling for display
On 2020-11-08 23:25, Amit Pundir wrote:
> On Tue, 4 Aug 2020 at 21:09, Rob Clark <robdclark@gmail.com> wrote:
>>
>> On Thu, Jul 16, 2020 at 4:36 AM Kalyan Thota <kalyan_t@codeaurora.org>
>> wrote:
>> >
>> > This change adds support to scale src clk and bandwidth as
>> > per composition requirements.
>> >
>> > Interconnect registration for bw has been moved to mdp
>> > device node from mdss to facilitate the scaling.
>> >
>> > Changes in v1:
>> > - Address armv7 compilation issues with the patch (Rob)
>> >
>> > Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
>>
>> Reviewed-by: Rob Clark <robdclark@chromium.org>
>>
>
> Hi Kalyan, Rob,
>
> This patch broke the display on the PocoF1 phone
> (sdm845-xiaomi-beryllium.dts) running AOSP.
> I can boot to UI but the display is frozen soon after that and
> dmesg is full of following errors:
>
> [drm:dpu_core_perf_crtc_update:397] [dpu error]crtc-65: failed to
> update bus bw vote
> [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth:
> 7649746kb > 6800000kb
> [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance
> check -7
> [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth:
> 7649746kb > 6800000kb
> [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance
> check -7
> [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth:
> 7649746kb > 6800000kb
> [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance
> check -7
>
> Here is the full dmesg https://pastebin.ubuntu.com/p/PcSdNgMnYw/.
> Georgi pointed out following patch but it didn't help,
> https://lore.kernel.org/dri-devel/20201027102304.945424-1-dmitry.baryshkov@linaro.org/
> Am I missing any other followup fix?
>
> Regards,
> Amit Pundir
> __

Hi Amit,

Apologies for the delay.

I have gone through the logs and referred to the below panel file for
the timings.
https://github.com/Matheus-Garbelini/Kernel-Sphinx-Pocophone-F1/blob/master/arch/arm64/boot/dts/qcom/dsi-panel-tianma-fhd-nt36672a-video.dtsi

if the above is correct file, then below could be the possible root
cause.

The panel back porch and pw is less and it is causing the prefill bw
requirement to shoot up per layer as currently we are not considering
front porch in the calculation. can you please try the attached patch in
the email as a solution and provide me the feedback, i'll post it as a
formal change.

Thanks,
Kalyan

_____________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
From 028fb47ccc5a3f8f8e51513bd2719aa14c68ac09 Mon Sep 17 00:00:00 2001
From: Kalyan Thota <kalyan_t@codeaurora.org>
Date: Tue, 24 Nov 2020 02:39:52 -0800
Subject: [PATCH] drm: msm: dpu: consider front porch in the prefill
calculation

In case of panels with low vertical back porch and pw,
the prefill bw will increase as we will have less time to fetch
and fill all the hw latency buffers.

for ex: hw_latnecy_lines = 24, and if vbp+pw = 10 then we need to
fetch 24 lines of data in 10 line times. This will increase prefill
bw requirement.

DPU hw can fetch data during front porch also provided prefetch is
enabled. Use front porch also into the prefill caluculation as
driver enables prefetch if the blanking is not sufficient to fill
the latency lines.

Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 7ea90d2..315b999 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -151,7 +151,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
u64 plane_bw;
u32 hw_latency_lines;
u64 scale_factor;
- int vbp, vpw;
+ int vbp, vpw, vfp;

pstate = to_dpu_plane_state(plane->state);
mode = &plane->state->crtc->mode;
@@ -164,6 +164,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
fps = drm_mode_vrefresh(mode);
vbp = mode->vtotal - mode->vsync_end;
vpw = mode->vsync_end - mode->vsync_start;
+ vfp = mode->vsync_start - mode->vdisplay;
hw_latency_lines = dpu_kms->catalog->perf.min_prefill_lines;
scale_factor = src_height > dst_height ?
mult_frac(src_height, 1, dst_height) : 1;
@@ -176,7 +177,13 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
src_width * hw_latency_lines * fps * fmt->bpp *
scale_factor * mode->vtotal;

- do_div(plane_prefill_bw, (vbp+vpw));
+ if ((vbp+vpw) > hw_latency_lines)
+ do_div(plane_prefill_bw, (vbp+vpw));
+ else if ((vbp+vpw+vfp) < hw_latency_lines)
+ do_div(plane_prefill_bw, (vbp+vpw+vfp));
+ else
+ do_div(plane_prefill_bw, hw_latency_lines);
+

pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw);
}
--
2.7.4
\
 
 \ /
  Last update: 2020-11-24 14:01    [W:0.056 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site