All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Jagan Teki <jagan@amarulasolutions.com>
Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Chen-Yu Tsai <wens@csie.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
	dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	Michael Trimarchi <michael@amarulasolutions.com>,
	linux-amarula@amarulasolutions.com, linux-sunxi@googlegroups.com
Subject: Re: [PATCH v8 01/15] drm/sun4i: dsi: Fix video start delay computation
Date: Mon, 11 Mar 2019 16:37:34 +0100	[thread overview]
Message-ID: <20190311153734.izg44ijwqqh2vpxc@flea> (raw)
In-Reply-To: <20190311133637.18334-2-jagan@amarulasolutions.com>

[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]

On Mon, Mar 11, 2019 at 07:06:23PM +0530, Jagan Teki wrote:
> 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"?

> 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?

> 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@amarulasolutions.com>
> ---
>  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?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
To: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>,
	Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
	Michael Turquette
	<mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Michael Trimarchi
	<michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: [PATCH v8 01/15] drm/sun4i: dsi: Fix video start delay computation
Date: Mon, 11 Mar 2019 16:37:34 +0100	[thread overview]
Message-ID: <20190311153734.izg44ijwqqh2vpxc@flea> (raw)
In-Reply-To: <20190311133637.18334-2-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

On Mon, Mar 11, 2019 at 07:06:23PM +0530, Jagan Teki wrote:
> 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"?

> 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?

> 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?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Jagan Teki <jagan@amarulasolutions.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, David Airlie <airlied@linux.ie>,
	Michael Turquette <mturquette@baylibre.com>,
	linux-sunxi@googlegroups.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, Chen-Yu Tsai <wens@csie.org>,
	Rob Herring <robh+dt@kernel.org>, Daniel Vetter <daniel@ffwll.ch>,
	Michael Trimarchi <michael@amarulasolutions.com>,
	linux-amarula@amarulasolutions.com, linux-clk@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 01/15] drm/sun4i: dsi: Fix video start delay computation
Date: Mon, 11 Mar 2019 16:37:34 +0100	[thread overview]
Message-ID: <20190311153734.izg44ijwqqh2vpxc@flea> (raw)
In-Reply-To: <20190311133637.18334-2-jagan@amarulasolutions.com>


[-- Attachment #1.1: Type: text/plain, Size: 2569 bytes --]

On Mon, Mar 11, 2019 at 07:06:23PM +0530, Jagan Teki wrote:
> 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"?

> 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?

> 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@amarulasolutions.com>
> ---
>  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?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-11 15:37 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 13:36 [PATCH v8 00/15] drm/sun4i: Allwinner A64 MIPI-DSI support Jagan Teki
2019-03-11 13:36 ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 01/15] drm/sun4i: dsi: Fix video start delay computation Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 15:37   ` Maxime Ripard [this message]
2019-03-11 15:37     ` Maxime Ripard
2019-03-11 15:37     ` Maxime Ripard
2019-03-11 16:01     ` Jagan Teki
2019-03-11 16:01       ` Jagan Teki
2019-03-11 16:01       ` Jagan Teki
2019-03-19 10:25       ` Maxime Ripard
2019-03-19 10:25         ` Maxime Ripard
2019-03-19 10:25         ` Maxime Ripard
2019-03-21 14:38         ` Jagan Teki
2019-03-21 14:38           ` Jagan Teki
2019-04-02 13:34           ` Jagan Teki
2019-04-02 13:34             ` Jagan Teki
2019-04-02 14:45           ` Maxime Ripard
2019-04-02 14:45             ` Maxime Ripard
2019-04-02 14:45             ` Maxime Ripard
2019-03-11 13:36 ` [PATCH v8 02/15] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 15:38   ` Maxime Ripard
2019-03-11 15:38     ` Maxime Ripard
2019-03-11 16:06     ` Jagan Teki
2019-03-11 16:06       ` Jagan Teki
2019-03-18 18:24       ` Jagan Teki
2019-03-18 18:24         ` Jagan Teki
2019-03-19 10:53       ` Maxime Ripard
2019-03-19 10:53         ` Maxime Ripard
2019-03-19 10:53         ` Maxime Ripard
2019-03-19 12:17         ` Sergey Suloev
2019-03-21 14:11           ` Jagan Teki
2019-03-21 14:11             ` Jagan Teki
2019-03-21 14:11             ` Jagan Teki
2019-03-21 14:10         ` Jagan Teki
2019-03-21 14:10           ` Jagan Teki
2019-04-02 13:33           ` Jagan Teki
2019-04-02 13:33             ` Jagan Teki
2019-04-02 13:33             ` Jagan Teki
2019-04-02 14:39           ` Maxime Ripard
2019-04-02 14:39             ` Maxime Ripard
2019-04-02 14:39             ` Maxime Ripard
2019-03-11 13:36 ` [PATCH v8 03/15] drm/sun4i: tcon: Export get tcon0 routine Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 04/15] drm/sun4i: dsi: Probe tcon0 during dsi_bind Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 05/15] drm/sun4i: dsi: Get tcon0_div at runtime Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 06/15] dt-bindings: sun6i-dsi: Add VCC-DSI supply property Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 07/15] dt-bindings: sun6i-dsi: Add A64 MIPI-DSI compatible Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 08/15] dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback) Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 09/15] drm/sun4i: sun6i_mipi_dsi: Add has_mod_clk quirk Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 10/15] " Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 11/15] drm/sun4i: sun6i_mipi_dsi: Add Allwinner A64 MIPI DSI support Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 12/15] arm64: dts: allwinner: a64: Add MIPI DSI pipeline Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [PATCH v8 13/15] arm64: dts: allwinner: a64-amarula-relic: Add Techstar TS8550B MIPI-DSI panel Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [DO NOT MERGE] [PATCH v8 14/15] arm64: dts: allwinner: a64-pine64-lts: Enable Feiyang FY07024DI26A30-D DSI panel Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36 ` [DO NOT MERGE] [PATCH v8 15/15] arm64: dts: allwinner: bananapi-m64: Enable Bananapi S070WV20-CT16 " Jagan Teki
2019-03-11 13:36   ` Jagan Teki
2019-03-11 13:36   ` Jagan Teki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190311153734.izg44ijwqqh2vpxc@flea \
    --to=maxime.ripard@bootlin.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jagan@amarulasolutions.com \
    --cc=linux-amarula@amarulasolutions.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=mark.rutland@arm.com \
    --cc=michael@amarulasolutions.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.