linux-kernel - Re: [i.MX6 DRM IPUv3] Regression 4.9-rc5: greenish screen with YUV420 video

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:   Thu, 01 Dec 2016 15:54:07 +0100
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Krzysztof Hałasa <khalasa@...p.pl>
Cc:     David Airlie <airlied@...ux.ie>, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Subject: Re: [i.MX6 DRM IPUv3] Regression 4.9-rc5: greenish screen with
 YUV420 video

Hi Krzysztof,

Am Donnerstag, den 17.11.2016, 10:43 +0100 schrieb Krzysztof Hałasa:
> Hi,
> 
> The following GStreamer pipeline causes screen to become green with
> v4.9-rc4+:
> 
> gst-launch-1.0 udpsrc uri=udp://239.1.2.2:5100 reuse=true caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" ! rtph264depay ! h264parse ! v4l2video1dec capture-io-mode=dmabuf ! kmssink name=imx-drm sync=0
> 
> Reverting "drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't
> need modeset", commit 81d553545a1510ff7c7c00cbc9b57d6172d411a4, fixes
> the problem.
> 
> Hardware is Gateworks Ventana GW5400, i.MX6Q, HDMI output, no X (console
> only).

I had already (accidentally) fixed this with 3fd8b292ae6b ("drm/imx:
ipuv3-plane: merge ipu_plane_atomic_set_base into atomic_update").

The bug is in this hunk in commit 81d553545a15:
 @@ -118,7 +117,7 @@ static void ipu_plane_atomic_set_base(struct ipu_plane *ipu_plane,
        switch (fb->pixel_format) {
        case DRM_FORMAT_YUV420:
        case DRM_FORMAT_YVU420:
-               if (old_state->fb)
+               if (!drm_atomic_crtc_needs_modeset(crtc_state))
                        break;
 
                /*

When the plane is first enabled, a modeset is not needed, so
drm_atomic_crtc_needs_modeset(crtc_state) is false and
ipu_plane_atomic_set_base then skipped the ubo/vbo setup.

When moving the code around in 3fd8b292ae6b I assumed that this
condition should never be true where the code ended up (as it was for
old_state->fb before), and I removed it.

regards
Philipp