<div dir="ltr"><div>Hello, fixes the hdmi glitches for me on jz4770.<br></div><div><br></div><div>Tested-by: Christophe Branchereau <<a href="mailto:cbranchereau@gmail.com">cbranchereau@gmail.com</a>></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 3, 2022 at 8:43 AM Sam Ravnborg <<a href="mailto:sam@ravnborg.org">sam@ravnborg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Paul,<br>
<br>
On Sun, Jul 03, 2022 at 12:07:27AM +0100, Paul Cercueil wrote:<br>
> Until now, when running at the maximum resolution of 1280x720 at 32bpp<br>
> on the JZ4770 SoC the output was garbled, the X/Y position of the<br>
> top-left corner of the framebuffer warping to a random position with<br>
> the whole image being offset accordingly, every time a new frame was<br>
> being submitted.<br>
> <br>
> This problem can be eliminated by using a bigger burst size for the DMA.<br>
<br>
Are there any alignment constraints of the framebuffer that depends on<br>
the burst size? I am hit by this with some atmel IP - which is why I<br>
ask.<br>
<br>
Patch looks good and is a-b.<br>
<br>
> <br>
> Set in each soc_info structure the maximum burst size supported by the<br>
> corresponding SoC, and use it in the driver.<br>
> <br>
> Set the new value using regmap_update_bits() instead of<br>
> regmap_set_bits(), since we do want to override the old value of the<br>
> burst size. (Note that regmap_set_bits() wasn't really valid before for<br>
> the same reason, but it never seemed to be a problem).<br>
> <br>
> Cc: <<a href="mailto:stable@vger.kernel.org" target="_blank">stable@vger.kernel.org</a>><br>
> Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")<br>
> Signed-off-by: Paul Cercueil <<a href="mailto:paul@crapouillou.net" target="_blank">paul@crapouillou.net</a>><br>
Acked-by: Sam Ravnborg <<a href="mailto:sam@ravnborg.org" target="_blank">sam@ravnborg.org</a>><br>
</blockquote></div>