Until now, when running at the maximum resolution of 1280x720 at 32bpp on the JZ4770 SoC the output was garbled, the X/Y position of the top-left corner of the framebuffer warping to a random position with the whole image being offset accordingly, every time a new frame was being submitted.
This problem can be eliminated by using a bigger burst size for the DMA.
Set in each soc_info structure the maximum burst size supported by the corresponding SoC, and use it in the driver.
Set the new value using regmap_update_bits() instead of regmap_set_bits(), since we do want to override the old value of the burst size. (Note that regmap_set_bits() wasn't really valid before for the same reason, but it never seemed to be a problem).
Cc: stable@vger.kernel.org Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs") Signed-off-by: Paul Cercueil paul@crapouillou.net --- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 10 ++++++++-- drivers/gpu/drm/ingenic/ingenic-drm.h | 3 +++ 2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index 2c559885347a..8ad6080b32b2 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -70,6 +70,7 @@ struct jz_soc_info { bool map_noncoherent; bool use_extended_hwdesc; bool plane_f0_not_working; + u32 max_burst; unsigned int max_width, max_height; const u32 *formats_f0, *formats_f1; unsigned int num_formats_f0, num_formats_f1; @@ -319,8 +320,9 @@ static void ingenic_drm_crtc_update_timings(struct ingenic_drm *priv, regmap_write(priv->map, JZ_REG_LCD_REV, mode->htotal << 16); }
- regmap_set_bits(priv->map, JZ_REG_LCD_CTRL, - JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16); + regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, + JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_MASK, + JZ_LCD_CTRL_OFUP | priv->soc_info->max_burst);
/* * IPU restart - specify how much time the LCDC will wait before @@ -1519,6 +1521,7 @@ static const struct jz_soc_info jz4740_soc_info = { .map_noncoherent = false, .max_width = 800, .max_height = 600, + .max_burst = JZ_LCD_CTRL_BURST_16, .formats_f1 = jz4740_formats, .num_formats_f1 = ARRAY_SIZE(jz4740_formats), /* JZ4740 has only one plane */ @@ -1530,6 +1533,7 @@ static const struct jz_soc_info jz4725b_soc_info = { .map_noncoherent = false, .max_width = 800, .max_height = 600, + .max_burst = JZ_LCD_CTRL_BURST_16, .formats_f1 = jz4725b_formats_f1, .num_formats_f1 = ARRAY_SIZE(jz4725b_formats_f1), .formats_f0 = jz4725b_formats_f0, @@ -1542,6 +1546,7 @@ static const struct jz_soc_info jz4770_soc_info = { .map_noncoherent = true, .max_width = 1280, .max_height = 720, + .max_burst = JZ_LCD_CTRL_BURST_64, .formats_f1 = jz4770_formats_f1, .num_formats_f1 = ARRAY_SIZE(jz4770_formats_f1), .formats_f0 = jz4770_formats_f0, @@ -1556,6 +1561,7 @@ static const struct jz_soc_info jz4780_soc_info = { .plane_f0_not_working = true, /* REVISIT */ .max_width = 4096, .max_height = 2048, + .max_burst = JZ_LCD_CTRL_BURST_64, .formats_f1 = jz4770_formats_f1, .num_formats_f1 = ARRAY_SIZE(jz4770_formats_f1), .formats_f0 = jz4770_formats_f0, diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.h b/drivers/gpu/drm/ingenic/ingenic-drm.h index cb1d09b62588..e5bd007ea93d 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm.h +++ b/drivers/gpu/drm/ingenic/ingenic-drm.h @@ -106,6 +106,9 @@ #define JZ_LCD_CTRL_BURST_4 (0x0 << 28) #define JZ_LCD_CTRL_BURST_8 (0x1 << 28) #define JZ_LCD_CTRL_BURST_16 (0x2 << 28) +#define JZ_LCD_CTRL_BURST_32 (0x3 << 28) +#define JZ_LCD_CTRL_BURST_64 (0x4 << 28) +#define JZ_LCD_CTRL_BURST_MASK (0x7 << 28) #define JZ_LCD_CTRL_RGB555 BIT(27) #define JZ_LCD_CTRL_OFUP BIT(26) #define JZ_LCD_CTRL_FRC_GRAYSCALE_16 (0x0 << 24)
Hi Paul,
On Sun, Jul 03, 2022 at 12:07:27AM +0100, Paul Cercueil wrote:
Until now, when running at the maximum resolution of 1280x720 at 32bpp on the JZ4770 SoC the output was garbled, the X/Y position of the top-left corner of the framebuffer warping to a random position with the whole image being offset accordingly, every time a new frame was being submitted.
This problem can be eliminated by using a bigger burst size for the DMA.
Are there any alignment constraints of the framebuffer that depends on the burst size? I am hit by this with some atmel IP - which is why I ask.
Patch looks good and is a-b.
Set in each soc_info structure the maximum burst size supported by the corresponding SoC, and use it in the driver.
Set the new value using regmap_update_bits() instead of regmap_set_bits(), since we do want to override the old value of the burst size. (Note that regmap_set_bits() wasn't really valid before for the same reason, but it never seemed to be a problem).
Cc: stable@vger.kernel.org Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs") Signed-off-by: Paul Cercueil paul@crapouillou.net
Acked-by: Sam Ravnborg sam@ravnborg.org
Hi Sam,
Le dim., juil. 3 2022 at 08:43:37 +0200, Sam Ravnborg sam@ravnborg.org a écrit :
Hi Paul,
On Sun, Jul 03, 2022 at 12:07:27AM +0100, Paul Cercueil wrote:
Until now, when running at the maximum resolution of 1280x720 at 32bpp on the JZ4770 SoC the output was garbled, the X/Y position of the top-left corner of the framebuffer warping to a random position with the whole image being offset accordingly, every time a new frame was being submitted.
This problem can be eliminated by using a bigger burst size for the DMA.
Are there any alignment constraints of the framebuffer that depends on the burst size? I am hit by this with some atmel IP - which is why I ask.
I would think that the framebuffer needs to be aligned with the burst size, indeed. Here, our buffers are always page-aligned so that's not a problem.
Patch looks good and is a-b.
Thanks!
Cheers, -Paul
Set in each soc_info structure the maximum burst size supported by the corresponding SoC, and use it in the driver.
Set the new value using regmap_update_bits() instead of regmap_set_bits(), since we do want to override the old value of the burst size. (Note that regmap_set_bits() wasn't really valid before for the same reason, but it never seemed to be a problem).
Cc: stable@vger.kernel.org Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs") Signed-off-by: Paul Cercueil paul@crapouillou.net
Acked-by: Sam Ravnborg sam@ravnborg.org
Hi Sam,
Le dim., juil. 3 2022 at 08:43:37 +0200, Sam Ravnborg sam@ravnborg.org a écrit :
Hi Paul,
On Sun, Jul 03, 2022 at 12:07:27AM +0100, Paul Cercueil wrote:
Until now, when running at the maximum resolution of 1280x720 at 32bpp on the JZ4770 SoC the output was garbled, the X/Y position of the top-left corner of the framebuffer warping to a random position with the whole image being offset accordingly, every time a new frame was being submitted.
This problem can be eliminated by using a bigger burst size for the DMA.
Are there any alignment constraints of the framebuffer that depends on the burst size? I am hit by this with some atmel IP - which is why I ask.
I verified this, and everything behaves correctly when the source address is not aligned to the burst size. So I believe in our case the DMA is smart enough to auto-select the best burst size, up to the configured value.
Cheers, -Paul
Patch looks good and is a-b.
Set in each soc_info structure the maximum burst size supported by the corresponding SoC, and use it in the driver.
Set the new value using regmap_update_bits() instead of regmap_set_bits(), since we do want to override the old value of the burst size. (Note that regmap_set_bits() wasn't really valid before for the same reason, but it never seemed to be a problem).
Cc: stable@vger.kernel.org Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs") Signed-off-by: Paul Cercueil paul@crapouillou.net
Acked-by: Sam Ravnborg sam@ravnborg.org
linux-stable-mirror@lists.linaro.org
-
Paul Cercueil -
Sam Ravnborg