All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] drm/sun4i: frontend: Rework a bit the phase data
@ 2020-10-15  9:36 ` Maxime Ripard
  0 siblings, 0 replies; 14+ messages in thread
From: Maxime Ripard @ 2020-10-15  9:36 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Taras Galchenko, Jernej Skrabec, Maarten Lankhorst, dri-devel,
	Paul Kocialkowski, Thomas Zimmermann, linux-arm-kernel

The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.

The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.

Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++++++--------------------
 drivers/gpu/drm/sun4i/sun4i_frontend.h |  6 +----
 2 files changed, 9 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ec2a032e07b9..7462801b1fa8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
 	 * related to the scaler FIR filter phase parameters.
 	 */
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
-		     frontend->data->ch_phase[0].horzphase);
+		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-		     frontend->data->ch_phase[1].horzphase);
+		     frontend->data->ch_phase[1]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
-		     frontend->data->ch_phase[0].vertphase[0]);
+		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-		     frontend->data->ch_phase[1].vertphase[0]);
+		     frontend->data->ch_phase[1]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
-		     frontend->data->ch_phase[0].vertphase[1]);
+		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-		     frontend->data->ch_phase[1].vertphase[1]);
+		     frontend->data->ch_phase[1]);
 
 	/*
 	 * Checking the input format is sufficient since we currently only
@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
 };
 
 static const struct sun4i_frontend_data sun4i_a10_frontend = {
-	.ch_phase		= {
-		{
-			.horzphase = 0,
-			.vertphase = { 0, 0 },
-		},
-		{
-			.horzphase = 0xfc000,
-			.vertphase = { 0xfc000, 0xfc000 },
-		},
-	},
+	.ch_phase		= { 0x000, 0xfc000 },
 	.has_coef_rdy		= true,
 };
 
 static const struct sun4i_frontend_data sun8i_a33_frontend = {
-	.ch_phase		= {
-		{
-			.horzphase = 0x400,
-			.vertphase = { 0x400, 0x400 },
-		},
-		{
-			.horzphase = 0x400,
-			.vertphase = { 0x400, 0x400 },
-		},
-	},
+	.ch_phase		= { 0x400, 0x400 },
 	.has_coef_access_ctrl	= true,
 };
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 0c382c1ddb0f..2e7b76e50c2b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -115,11 +115,7 @@ struct reset_control;
 struct sun4i_frontend_data {
 	bool	has_coef_access_ctrl;
 	bool	has_coef_rdy;
-
-	struct {
-		u32	horzphase;
-		u32	vertphase[2];
-	} ch_phase[2];
+	u32	ch_phase[2];
 };
 
 struct sun4i_frontend {
-- 
2.26.2


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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 1/3] drm/sun4i: frontend: Rework a bit the phase data
@ 2020-10-15  9:36 ` Maxime Ripard
  0 siblings, 0 replies; 14+ messages in thread
From: Maxime Ripard @ 2020-10-15  9:36 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Taras Galchenko, Jernej Skrabec, dri-devel, Paul Kocialkowski,
	Thomas Zimmermann, linux-arm-kernel

The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.

The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.

Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++++++--------------------
 drivers/gpu/drm/sun4i/sun4i_frontend.h |  6 +----
 2 files changed, 9 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ec2a032e07b9..7462801b1fa8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
 	 * related to the scaler FIR filter phase parameters.
 	 */
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
-		     frontend->data->ch_phase[0].horzphase);
+		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-		     frontend->data->ch_phase[1].horzphase);
+		     frontend->data->ch_phase[1]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
-		     frontend->data->ch_phase[0].vertphase[0]);
+		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-		     frontend->data->ch_phase[1].vertphase[0]);
+		     frontend->data->ch_phase[1]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
-		     frontend->data->ch_phase[0].vertphase[1]);
+		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-		     frontend->data->ch_phase[1].vertphase[1]);
+		     frontend->data->ch_phase[1]);
 
 	/*
 	 * Checking the input format is sufficient since we currently only
@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
 };
 
 static const struct sun4i_frontend_data sun4i_a10_frontend = {
-	.ch_phase		= {
-		{
-			.horzphase = 0,
-			.vertphase = { 0, 0 },
-		},
-		{
-			.horzphase = 0xfc000,
-			.vertphase = { 0xfc000, 0xfc000 },
-		},
-	},
+	.ch_phase		= { 0x000, 0xfc000 },
 	.has_coef_rdy		= true,
 };
 
 static const struct sun4i_frontend_data sun8i_a33_frontend = {
-	.ch_phase		= {
-		{
-			.horzphase = 0x400,
-			.vertphase = { 0x400, 0x400 },
-		},
-		{
-			.horzphase = 0x400,
-			.vertphase = { 0x400, 0x400 },
-		},
-	},
+	.ch_phase		= { 0x400, 0x400 },
 	.has_coef_access_ctrl	= true,
 };
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 0c382c1ddb0f..2e7b76e50c2b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -115,11 +115,7 @@ struct reset_control;
 struct sun4i_frontend_data {
 	bool	has_coef_access_ctrl;
 	bool	has_coef_rdy;
-
-	struct {
-		u32	horzphase;
-		u32	vertphase[2];
-	} ch_phase[2];
+	u32	ch_phase[2];
 };
 
 struct sun4i_frontend {
-- 
2.26.2

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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
  2020-10-15  9:36 ` Maxime Ripard
@ 2020-10-15  9:36   ` Maxime Ripard
  -1 siblings, 0 replies; 14+ messages in thread
From: Maxime Ripard @ 2020-10-15  9:36 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Taras Galchenko, Jernej Skrabec, Maarten Lankhorst, dri-devel,
	Paul Kocialkowski, Thomas Zimmermann, linux-arm-kernel

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>
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 7462801b1fa8..d32b12cbbb60 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
 	struct drm_framebuffer *fb = state->fb;
 	const struct drm_format_info *format = fb->format;
 	uint64_t modifier = fb->modifier;
+	unsigned ch1_phase_idx;
 	u32 out_fmt_val;
 	u32 in_fmt_val, in_mod_val, in_ps_val;
 	unsigned int i;
@@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
 	 * I have no idea what this does exactly, but it seems to be
 	 * related to the scaler FIR filter phase parameters.
 	 */
+	ch1_phase_idx = (format->num_planes > 1) ? 1 : 0;
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
 		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-		     frontend->data->ch_phase[1]);
+		     frontend->data->ch_phase[ch1_phase_idx]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
 		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-		     frontend->data->ch_phase[1]);
+		     frontend->data->ch_phase[ch1_phase_idx]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
 		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-		     frontend->data->ch_phase[1]);
+		     frontend->data->ch_phase[ch1_phase_idx]);
 
 	/*
 	 * Checking the input format is sufficient since we currently only
-- 
2.26.2


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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
@ 2020-10-15  9:36   ` Maxime Ripard
  0 siblings, 0 replies; 14+ messages in thread
From: Maxime Ripard @ 2020-10-15  9:36 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Taras Galchenko, Jernej Skrabec, dri-devel, Paul Kocialkowski,
	Thomas Zimmermann, linux-arm-kernel

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>
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 7462801b1fa8..d32b12cbbb60 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
 	struct drm_framebuffer *fb = state->fb;
 	const struct drm_format_info *format = fb->format;
 	uint64_t modifier = fb->modifier;
+	unsigned ch1_phase_idx;
 	u32 out_fmt_val;
 	u32 in_fmt_val, in_mod_val, in_ps_val;
 	unsigned int i;
@@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
 	 * I have no idea what this does exactly, but it seems to be
 	 * related to the scaler FIR filter phase parameters.
 	 */
+	ch1_phase_idx = (format->num_planes > 1) ? 1 : 0;
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
 		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-		     frontend->data->ch_phase[1]);
+		     frontend->data->ch_phase[ch1_phase_idx]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
 		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-		     frontend->data->ch_phase[1]);
+		     frontend->data->ch_phase[ch1_phase_idx]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
 		     frontend->data->ch_phase[0]);
 	regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-		     frontend->data->ch_phase[1]);
+		     frontend->data->ch_phase[ch1_phase_idx]);
 
 	/*
 	 * Checking the input format is sufficient since we currently only
-- 
2.26.2

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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33
  2020-10-15  9:36 ` Maxime Ripard
@ 2020-10-15  9:36   ` Maxime Ripard
  -1 siblings, 0 replies; 14+ messages in thread
From: Maxime Ripard @ 2020-10-15  9:36 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Taras Galchenko, Jernej Skrabec, Maarten Lankhorst, dri-devel,
	Paul Kocialkowski, Thomas Zimmermann, linux-arm-kernel

The A33 has a different phase parameter in the Allwinner BSP on the
channel1 than the one currently applied. Fix this.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index d32b12cbbb60..ff4187eab519 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend = {
 };
 
 static const struct sun4i_frontend_data sun8i_a33_frontend = {
-	.ch_phase		= { 0x400, 0x400 },
+	.ch_phase		= { 0x400, 0xfc400 },
 	.has_coef_access_ctrl	= true,
 };
 
-- 
2.26.2


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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33
@ 2020-10-15  9:36   ` Maxime Ripard
  0 siblings, 0 replies; 14+ messages in thread
From: Maxime Ripard @ 2020-10-15  9:36 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Taras Galchenko, Jernej Skrabec, dri-devel, Paul Kocialkowski,
	Thomas Zimmermann, linux-arm-kernel

The A33 has a different phase parameter in the Allwinner BSP on the
channel1 than the one currently applied. Fix this.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index d32b12cbbb60..ff4187eab519 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend = {
 };
 
 static const struct sun4i_frontend_data sun8i_a33_frontend = {
-	.ch_phase		= { 0x400, 0x400 },
+	.ch_phase		= { 0x400, 0xfc400 },
 	.has_coef_access_ctrl	= true,
 };
 
-- 
2.26.2

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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/3] drm/sun4i: frontend: Rework a bit the phase data
  2020-10-15  9:36 ` Maxime Ripard
@ 2020-10-21 17:16   ` Jernej Škrabec
  -1 siblings, 0 replies; 14+ messages in thread
From: Jernej Škrabec @ 2020-10-21 17:16 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Maxime Ripard
  Cc: Taras Galchenko, Maarten Lankhorst, dri-devel, Paul Kocialkowski,
	Thomas Zimmermann, linux-arm-kernel

Hi!

Dne četrtek, 15. oktober 2020 ob 11:36:40 CEST je Maxime Ripard napisal(a):
> The scaler filter phase setup in the allwinner kernel has two different
> cases for setting up the scaler filter, the first one using different phase
> parameters for the two channels, and the second one reusing the first
> channel parameters on the second channel.
> 
> The allwinner kernel has a third option where the horizontal phase of the
> second channel will be set to a different value than the vertical one (and
> seems like it's the same value than one used on the first channel).
> However, that code path seems to never be taken, so we can ignore it for
> now, and it's essentially what we're doing so far as well.
> 
> Since we will have always the same values across each components of the
> filter setup for a given channel, we can simplify a bit our frontend
> structure by only storing the phase value we want to apply to a given
> channel.
> 
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/3] drm/sun4i: frontend: Rework a bit the phase data
@ 2020-10-21 17:16   ` Jernej Škrabec
  0 siblings, 0 replies; 14+ messages in thread
From: Jernej Škrabec @ 2020-10-21 17:16 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Maxime Ripard
  Cc: Taras Galchenko, dri-devel, Paul Kocialkowski, Thomas Zimmermann,
	linux-arm-kernel

Hi!

Dne četrtek, 15. oktober 2020 ob 11:36:40 CEST je Maxime Ripard napisal(a):
> The scaler filter phase setup in the allwinner kernel has two different
> cases for setting up the scaler filter, the first one using different phase
> parameters for the two channels, and the second one reusing the first
> channel parameters on the second channel.
> 
> The allwinner kernel has a third option where the horizontal phase of the
> second channel will be set to a different value than the vertical one (and
> seems like it's the same value than one used on the first channel).
> However, that code path seems to never be taken, so we can ignore it for
> now, and it's essentially what we're doing so far as well.
> 
> Since we will have always the same values across each components of the
> filter setup for a given channel, we can simplify a bit our frontend
> structure by only storing the phase value we want to apply to a given
> channel.
> 
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33
  2020-10-15  9:36   ` Maxime Ripard
@ 2020-10-21 17:16     ` Jernej Škrabec
  -1 siblings, 0 replies; 14+ messages in thread
From: Jernej Škrabec @ 2020-10-21 17:16 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Maxime Ripard
  Cc: Taras Galchenko, Maarten Lankhorst, dri-devel, Paul Kocialkowski,
	Thomas Zimmermann, linux-arm-kernel

Hi!

Dne četrtek, 15. oktober 2020 ob 11:36:42 CEST je Maxime Ripard napisal(a):
> The A33 has a different phase parameter in the Allwinner BSP on the
> channel1 than the one currently applied. Fix this.
> 
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33
@ 2020-10-21 17:16     ` Jernej Škrabec
  0 siblings, 0 replies; 14+ messages in thread
From: Jernej Škrabec @ 2020-10-21 17:16 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Maxime Ripard
  Cc: Taras Galchenko, dri-devel, Paul Kocialkowski, Thomas Zimmermann,
	linux-arm-kernel

Hi!

Dne četrtek, 15. oktober 2020 ob 11:36:42 CEST je Maxime Ripard napisal(a):
> The A33 has a different phase parameter in the Allwinner BSP on the
> channel1 than the one currently applied. Fix this.
> 
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
  2020-10-15  9:36   ` Maxime Ripard
@ 2020-10-21 17:18     ` Jernej Škrabec
  -1 siblings, 0 replies; 14+ messages in thread
From: Jernej Škrabec @ 2020-10-21 17:18 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Maxime Ripard
  Cc: Taras Galchenko, Maarten Lankhorst, dri-devel, Paul Kocialkowski,
	Thomas Zimmermann, linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
@ 2020-10-21 17:18     ` Jernej Škrabec
  0 siblings, 0 replies; 14+ messages in thread
From: Jernej Škrabec @ 2020-10-21 17:18 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Maxime Ripard
  Cc: Taras Galchenko, dri-devel, Paul Kocialkowski, Thomas Zimmermann,
	linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33
  2020-10-21 17:16     ` Jernej Škrabec
@ 2020-10-26 10:22       ` Maxime Ripard
  -1 siblings, 0 replies; 14+ messages in thread
From: Maxime Ripard @ 2020-10-26 10:22 UTC (permalink / raw)
  To: Jernej Škrabec
  Cc: Taras Galchenko, Maarten Lankhorst, dri-devel, Paul Kocialkowski,
	Chen-Yu Tsai, Thomas Zimmermann, linux-arm-kernel


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

On Wed, Oct 21, 2020 at 07:16:52PM +0200, Jernej Škrabec wrote:
> Hi!
> 
> Dne četrtek, 15. oktober 2020 ob 11:36:42 CEST je Maxime Ripard napisal(a):
> > The A33 has a different phase parameter in the Allwinner BSP on the
> > channel1 than the one currently applied. Fix this.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> Acked-by: Jernej Skrabec <jernej.skrabec@siol.net>

Thanks for reviewing those patches, I've merged them

Maxime

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33
@ 2020-10-26 10:22       ` Maxime Ripard
  0 siblings, 0 replies; 14+ messages in thread
From: Maxime Ripard @ 2020-10-26 10:22 UTC (permalink / raw)
  To: Jernej Škrabec
  Cc: Taras Galchenko, dri-devel, Paul Kocialkowski, Chen-Yu Tsai,
	Thomas Zimmermann, linux-arm-kernel


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

On Wed, Oct 21, 2020 at 07:16:52PM +0200, Jernej Škrabec wrote:
> Hi!
> 
> Dne četrtek, 15. oktober 2020 ob 11:36:42 CEST je Maxime Ripard napisal(a):
> > The A33 has a different phase parameter in the Allwinner BSP on the
> > channel1 than the one currently applied. Fix this.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> Acked-by: Jernej Skrabec <jernej.skrabec@siol.net>

Thanks for reviewing those patches, I've merged them

Maxime

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

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2020-10-26 18:02 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.