All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jernej Škrabec" <jernej.skrabec@siol.net>
To: Chen-Yu Tsai <wens@csie.org>, Maxime Ripard <maxime@cerno.tech>,
	Maxime Ripard <maxime@cerno.tech>
Cc: Taras Galchenko <tpgalchenko@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	dri-devel@lists.freedesktop.org,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
Date: Wed, 21 Oct 2020 19:18:37 +0200	[thread overview]
Message-ID: <3169628.grsLiRHT83@kista> (raw)
In-Reply-To: <20201015093642.261440-2-maxime@cerno.tech>

Hi!

Dne četrtek, 15. oktober 2020 ob 11:36:41 CEST je Maxime Ripard napisal(a):
> When using the scaler on the A10-like frontend with single-planar formats,
> the current code will setup the channel 0 filter (used for the R or Y
> component) with a different phase parameter than the channel 1 filter (used
> for the G/B or U/V components).
> 
> This creates a bleed out that keeps repeating on of the last line of the
> RGB plane across the rest of the display. The Allwinner BSP either applies
> the same phase parameter over both channels or use a separate one, the
> condition being whether the input format is YUV420 or not.
> 
> Since YUV420 is both subsampled and multi-planar, and since YUYV is
> subsampled but single-planar, we can rule out the subsampling and assume
> that the condition is actually whether the format is single or
> multi-planar. And it looks like applying the same phase parameter over both
> channels for single-planar formats fixes our issue, while we keep the
> multi-planar formats working properly.
> 
> Reported-by: Taras Galchenko <tpgalchenko@gmail.com>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Acked-by: Jernej Skrabec <jernej.skrabec@siol.net>

Best regards,
Jernej



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

WARNING: multiple messages have this Message-ID (diff)
From: "Jernej Škrabec" <jernej.skrabec@siol.net>
To: Chen-Yu Tsai <wens@csie.org>, Maxime Ripard <maxime@cerno.tech>,
	Maxime Ripard <maxime@cerno.tech>
Cc: Taras Galchenko <tpgalchenko@gmail.com>,
	dri-devel@lists.freedesktop.org,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
Date: Wed, 21 Oct 2020 19:18:37 +0200	[thread overview]
Message-ID: <3169628.grsLiRHT83@kista> (raw)
In-Reply-To: <20201015093642.261440-2-maxime@cerno.tech>

Hi!

Dne četrtek, 15. oktober 2020 ob 11:36:41 CEST je Maxime Ripard napisal(a):
> When using the scaler on the A10-like frontend with single-planar formats,
> the current code will setup the channel 0 filter (used for the R or Y
> component) with a different phase parameter than the channel 1 filter (used
> for the G/B or U/V components).
> 
> This creates a bleed out that keeps repeating on of the last line of the
> RGB plane across the rest of the display. The Allwinner BSP either applies
> the same phase parameter over both channels or use a separate one, the
> condition being whether the input format is YUV420 or not.
> 
> Since YUV420 is both subsampled and multi-planar, and since YUYV is
> subsampled but single-planar, we can rule out the subsampling and assume
> that the condition is actually whether the format is single or
> multi-planar. And it looks like applying the same phase parameter over both
> channels for single-planar formats fixes our issue, while we keep the
> multi-planar formats working properly.
> 
> Reported-by: Taras Galchenko <tpgalchenko@gmail.com>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Acked-by: Jernej Skrabec <jernej.skrabec@siol.net>

Best regards,
Jernej


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-10-21 17:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15  9:36 [PATCH 1/3] drm/sun4i: frontend: Rework a bit the phase data Maxime Ripard
2020-10-15  9:36 ` Maxime Ripard
2020-10-15  9:36 ` [PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats Maxime Ripard
2020-10-15  9:36   ` Maxime Ripard
2020-10-21 17:18   ` Jernej Škrabec [this message]
2020-10-21 17:18     ` Jernej Škrabec
2020-10-15  9:36 ` [PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33 Maxime Ripard
2020-10-15  9:36   ` Maxime Ripard
2020-10-21 17:16   ` Jernej Škrabec
2020-10-21 17:16     ` Jernej Škrabec
2020-10-26 10:22     ` Maxime Ripard
2020-10-26 10:22       ` Maxime Ripard
2020-10-21 17:16 ` [PATCH 1/3] drm/sun4i: frontend: Rework a bit the phase data Jernej Škrabec
2020-10-21 17:16   ` Jernej Škrabec

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=3169628.grsLiRHT83@kista \
    --to=jernej.skrabec@siol.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maxime@cerno.tech \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=tpgalchenko@gmail.com \
    --cc=tzimmermann@suse.de \
    --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.