linux-kernel - Re: imx-drm: Possible regression after update to atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 28 Aug 2016 12:17:14 +0200
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Peter Senna Tschudin <peter.senna@...labora.co.uk>,
        airlied@...ux.ie, linux-kernel@...r.kernel.org,
        peter.senna@...il.com, p.zabel@...gutronix.de,
        dri-devel@...ts.freedesktop.org, gnuiyl@...il.com
Subject: Re: imx-drm: Possible regression after update to atomic

Lo! Dave, below report made it to the list of regression for 4.8, but
afaics nothing happened after the initial report. Was it discussed (and
maybe even fixed?) elsewhere? Or is there some reason why it shouldn't
be on the list of regressions at all?

Ciao, Thorsten

On 13.08.2016 14:37, Peter Senna Tschudin wrote:
> 
> d7868cb7ac58640e9c0383205ba31bd6a985cc6f is the last commit that works for me. I'm experiencing black screen after Weston starts in two different i.MX based devices:
> 
>  - i.MX6 -> arch/arm/boot/dts/imx6q-b850v3.dts
>  - i.MX53 based device
> 
> Weston starts, but nothing is shown on screen. fb works fine. Disabling fb on Kconfig or simply commenting out drm_fbdev_cma_init() solves the black screen issue.
> 
> The tests that are causing the black screen:
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 4ad67d0..52dc1b7 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -325,7 +325,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
>         if (old_fb && (state->src_w != old_state->src_w ||
>                               state->src_h != old_state->src_h ||
>                               fb->pixel_format != old_fb->pixel_format))
> -               return -EINVAL;
>  
>         eba = drm_plane_state_to_eba(state);
>  
> @@ -336,7 +336,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
>                 return -EINVAL;
>  
>         if (old_fb && fb->pitches[0] != old_fb->pitches[0])
> -               return -EINVAL;
>  
>         switch (fb->pixel_format) {
>         case DRM_FORMAT_YUV420:
> @@ -372,7 +372,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
>                         return -EINVAL;
>  
>                 if (old_fb && old_fb->pitches[1] != fb->pitches[1])
> -                       return -EINVAL;
>         }
> 
> I tried to replace the return -EINVAL by crtc_state->mode_changed = true with no positive results.
> 
> I'm trying to understand what is the difference with and without fb, but I have no conclusions yet.
> 
> Hints on what could be the cause here?
> 
> Thank you,
> 
> Peter
> 
> P.S. This is what I get after replacing the return -EINVAL(the mode is correct): https://goo.gl/photos/1eRdcco9GpszgvzM8