Skip to content

Commit 6b040fb

Browse files
mripardgregkh
authored andcommitted
drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
[ Upstream commit 2db9ef9 ] 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> Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
1 parent 644f1d4 commit 6b040fb

1 file changed

Lines changed: 5 additions & 3 deletions

File tree

drivers/gpu/drm/sun4i/sun4i_frontend.c

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
407407
struct drm_framebuffer *fb = state->fb;
408408
const struct drm_format_info *format = fb->format;
409409
uint64_t modifier = fb->modifier;
410+
unsigned int ch1_phase_idx;
410411
u32 out_fmt_val;
411412
u32 in_fmt_val, in_mod_val, in_ps_val;
412413
unsigned int i;
@@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
442443
* I have no idea what this does exactly, but it seems to be
443444
* related to the scaler FIR filter phase parameters.
444445
*/
446+
ch1_phase_idx = (format->num_planes > 1) ? 1 : 0;
445447
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
446448
frontend->data->ch_phase[0]);
447449
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
448-
frontend->data->ch_phase[1]);
450+
frontend->data->ch_phase[ch1_phase_idx]);
449451
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
450452
frontend->data->ch_phase[0]);
451453
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
452-
frontend->data->ch_phase[1]);
454+
frontend->data->ch_phase[ch1_phase_idx]);
453455
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
454456
frontend->data->ch_phase[0]);
455457
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
456-
frontend->data->ch_phase[1]);
458+
frontend->data->ch_phase[ch1_phase_idx]);
457459

458460
/*
459461
* Checking the input format is sufficient since we currently only

0 commit comments

Comments
 (0)