Re: drm/imx: lock scanout transfers for consecutive bursts

[Philipp Zabel <p.zabel@pengutronix.de>]

Hi Patrick,

On Tue, 2017-10-10 at 10:24 +0000, Patrick Brünn wrote:
> Hi Philipp,
> 
> since commit 790cb4c7c9545953d22d3d425e49b36a711bae5b my display on CX9020 (a i.MX53 based machine) stopped working:
> 
>  # dmesg | grep -i drm
> [    0.141829] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [    0.141838] [drm] No driver support for vblank timestamp query.
> [    0.142016] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
> [    0.142114] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
> [    0.142219] imx-drm display-subsystem: bound display-0 (ops imx_pd_ops)
> [    0.167491] drm: XXXXX: num_bursts: 8
> [    0.242633] imx-drm display-subsystem: fb0:  frame buffer device
> [    0.243172] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0
> [   11.366172] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:28:crtc-0] flip_done timed out
> [   21.606164] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:28:crtc-0] flip_done timed out
> 
> When I remove the new call to ipu_idmac_lock_enable(ipu_plane->ipu_ch, num_bursts) (attached patch),
> "[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:28:crtc-0] flip_done timed out"
> messages disappear and I get my display back:
> # dmesg | grep -i drm
> [    0.142292] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [    0.142302] [drm] No driver support for vblank timestamp query.
> [    0.142484] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
> [    0.142587] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
> [    0.142693] imx-drm display-subsystem: bound display-0 (ops imx_pd_ops)
> [    0.167917] drm: XXXXX: num_bursts: 8
> [    0.243023] imx-drm display-subsystem: fb0:  frame buffer device
> [    0.243566] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0
> 
> Is your patch supposed to work on i.MX53, too? Did I miss some configuration [1], to make it work correctly?
> If you need any additional info, just let me know.

Thank you for the report. I can confirm that on i.MX53 QSB, VGA output
breaks with the arbitration locking enabled: I see a picture, the timing
signals are stable, but it looks like bursts are getting lost. The image
data is not horizontally synchronised.

According to the reference manual, the IPU_IDMAC_LOCK_EN_1 register on
i.MX53 / IPUv3M should work the same as on i.MX6Q / IPUv3H. Searching
around a bit, I found patches that do enable 8-burst locking for IPUv3M
in some ancient Freescale BSP, but I don't know what prerequisites have
to be met for this to work properly.

I'll send a patch to disable this on all but i.MX6 / IPUv3H for now.

regards
Philipp