[PATCH] drm: rcar-du: Fix DU3 start/stop on M3-N

[Laurent Pinchart]

Hello Hoan-san,

On Monday, 26 November 2018 11:46:56 EET Hoan wrote:
> Dear Laurent-san
> 
> Thank you for your comments on my patches! I understand.
> 
> With this patch,  the problem has been improved.
> 
> CC Simon-san
> 
> If you wait a little longer, the error log will look like this:

There is another display-related regression in v4.20, for which I have posted 
https://patchwork.linuxtv.org/patch/53083/. I believe it should fix the issue 
you're experienced.

> [    2.825800] [drm] No driver support for vblank timestamp query.
> [   13.027591] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
> [CRTC:55:crtc-2] flip_done timed out
> [   23.267575] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [CRTC:55:crtc-2] flip_done timed out
> [   33.507572] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [CONNECTOR:57:VGA-1] flip_done timed out
> [   43.747572] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [PLANE:30:plane-1] flip_done timed out
> [   53.987572] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
> [CRTC:55:crtc-2] flip_done timed out
> [   53.990386] Console: switching to colour frame buffer device 128x48
> [   64.227573] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [CRTC:55:crtc-2] flip_done timed out
> [   74.467571] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [CONNECTOR:57:VGA-1] flip_done timed out
> [   84.707570] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [PLANE:30:plane-1] flip_done timed out
> [   94.947573] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
> [CRTC:55:crtc-2] flip_done timed out
> [   95.040503] rcar-du feb00000.display: fb0: DRM emulated frame buffer
> device
> [   95.048144] [drm] Initialized rcar-du 1.0.0 20130110 for
> feb00000.display on minor 0
> [   95.055907] [drm] Device feb00000.display probed
> ...
> 
> On 2018/11/26 17:21, Simon Horman wrote:
> > On Fri, Nov 23, 2018 at 01:48:08PM +0200, Laurent Pinchart wrote:
> >> Group start/stop is controlled by the DRES and DEN bits of DSYSR0 for
> >> the first group and DSYSR2 for the second group. On most DU instances,
> >> this maps to the first CRTC of the group. On M3-N, however, DU2 doesn't
> >> exist, but DSYSR2 does. There is no CRTC object there that maps to the
> >> correct DSYSR register.
> >> 
> >> Commit 9144adc5e5a9 ("drm: rcar-du: Cache DSYSR value to ensure known
> >> initial value") switched group start/stop from using group read/write
> >> access to DSYSR to a CRTC-based API to cache the DSYSR value. While
> >> doing so, it introduced a regression on M3-N by accessing DSYSR3 instead
> >> of DSYSR2 to start/stop the second group.
> >> 
> >> To fix this, access the DSYSR register directly through group read/write
> >> if the SoC is missing the first DU channel of the group. Keep using the
> >> rcar_du_crtc_dsysr_clr_set() function otherwise, to retain the DSYSR
> >> caching feature.
> >> 
> >> Fixes: 9144adc5e5a9 ("drm: rcar-du: Cache DSYSR value to ensure known
> >> initial value") Reported-by: Hoan Nguyen An <na-hoan at jinso.co.jp>
> >> Signed-off-by: Laurent Pinchart
> >> <laurent.pinchart+renesas at ideasonboard.com>
> > 
> > Thanks Laurent,
> > 
> > I have confirmed that with this patch applied on top of
> > renesas-devel-20181123-v4.20-rc3 Salvator-XS / M3-N ES1.0
> > boots to user-space when the kernel is compiled using renesas_defconfig.
> > 
> > Tested-by: Simon Horman <horms+renesas at verge.net.au>
> > 
> > 
> > Without this patch applied the boot log looks this:
> > 
> > Starting kernel ...

[snip]

-- 
Regards,

Laurent Pinchart