Thread (31 messages) 31 messages, 3 authors, 2019-04-02

Re: [PATCH v8 01/15] drm/sun4i: dsi: Fix video start delay computation

From: Maxime Ripard <hidden>
Date: 2019-03-19 10:25:29
Also in: dri-devel, linux-arm-kernel, linux-clk, lkml

On Mon, Mar 11, 2019 at 09:31:11PM +0530, Jagan Teki wrote:
On Mon, Mar 11, 2019 at 9:07 PM Maxime Ripard [off-list ref] wrote:
quoted
On Mon, Mar 11, 2019 at 07:06:23PM +0530, Jagan Teki wrote:
quoted
Vertical video start delay is computed by excluding vertical front
porch value from total vertical timings.

This clearly confirmed from BSP code and here how it computed,

(drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
=> (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp)
=> (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
   - panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y
                           - panel->lcd_y - panel->lcd_vbp
=> timmings->ver_front_porch

But the current driver is assuming it can exclude vertical front
porch along with vertical sync values from total vertical timings,
which resulting wrong start delay indeed wrong picture rendering
in the panel.
Same story here: which panel, which datasheet, which "wrong picture
rendering"?
It's bananapi,s070wv20-ct16 DSI
You're answering one out of three questions.
quoted
quoted
Example: timings, where it produces the issue.
{
      .vdisplay       = 600,
      .vsync_start    = 600 + 12,
      .vsync_end      = 600 + 12 + 2,
      .vtotal         = 600 + 12 + 2 + 21,
}
Can you 100% trust those timings?
ie. reason, I have given the Mainline timings [1]. The above timings
are wrongly mentioned actual timings are from [1]
You're still answering partially here. Those timings are working for
RGB, you have no proof that we need to make the same adjustments for
DSI.
quoted
quoted
It produces the desired start delay value as 19 but the correct working
value should be 513.

So, Fix it by computing proper video start delay.

Fixes: 69006ef0ecb1 ("drm/sun4i: dsi: Change the start delay calculation")
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 62a508420227..8d6292c0158b 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -364,8 +364,14 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
 static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
                                         struct drm_display_mode *mode)
 {
-     u16 start = clamp(mode->vtotal - mode->vdisplay - 10, 8, 100);
-     u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start;
+     u16 delay = mode->vtotal - (mode->vsync_start - mode->vdisplay);
+
+     /**
+      * BSP comment:
+      * put start_delay to tcon. set ready sync early to dramfreq,
+      * so set start_delay 1
+      */
That doesn't make any sense to me... What does it mean?
Which is meaning as above stated as "BSP comment" from here[2]
It doesn't matter where you took it from. If you cannot explain what
happen, putting a random label that doesn't explain anything will not
help.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help