Re: drm/vc4: false-positive negative cursor position warning
Daniel J Bluemanwrites: > Hi Eric et al, > > In a number of windowing environments (eg GNOME 3) on Raspberry Pi 3B > on 4.16.0 arm64, the mouse cursor top-left gets down to x,y -4,-4, > tripping WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y > < 0) [1], which therefore seems false-positive. > > Git history doesn't turn up any reason, eg it could cause undefined > hardware behaviour, which it doesn't appear to, so would it be better > to drop the warning, or adjust it to trip on x or y < -4 or so? If so, > I'll prepare a patch to adjust it. Ccing Boris, who's been doing work on the async update path. Take a look at vc4_plane_setup_clipping_and_scaling(state) -- that has the corrections necessary for negative x/y. We're calling that too late (through the avc4_plane_atomic_check() path) for this function's usage of the offsets[]. Since it affects the computed src_w/h, we'd have to update those as well in our async update. Our async update is racy in a way that makes me uncomfortable -- the HVS could process our display list at any point in our writel() sequence, which is not very atomic. Maybe we should be using a double-buffered HVS display list per element, and then have the main display list jump into each element's current display list and back out, so that we can do async flips to new plane state by just commiting a single writel() to the new HVS display element list. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/vc4: false-positive negative cursor position warning
Hi Eric et al, In a number of windowing environments (eg GNOME 3) on Raspberry Pi 3B on 4.16.0 arm64, the mouse cursor top-left gets down to x,y -4,-4, tripping WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y < 0) [1], which therefore seems false-positive. Git history doesn't turn up any reason, eg it could cause undefined hardware behaviour, which it doesn't appear to, so would it be better to drop the warning, or adjust it to trip on x or y < -4 or so? If so, I'll prepare a patch to adjust it. [Side note: simply opening the GNOME 3 Activities menu with libgl1-mesa-dri 17.3.7 is a reliable way to reproduce "[drm] Resetting GPU"] Thanks, Dan -- [1] WARNING: CPU: 3 PID: 966 at drivers/gpu/drm/vc4/vc4_plane.c:771 vc4_plane_async_set_fb+0x98/0xa0 CPU: 3 PID: 966 Comm: Xorg Tainted: G S 4.16.0+ #13 Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) pstate: 0005 (nzcv daif -PAN -UAO) pc : vc4_plane_async_set_fb+0x98/0xa0 lr : vc4_plane_async_set_fb+0x4c/0xa0 sp : 086ab9b0 x29: 086ab9b0 x28: x27: 0009 x26: fffc x25: a81b36ca8b00 x24: a81b30667c00 x23: 0040 x22: a81b30790400 x21: a81b36ca8b00 x20: a81b30a53018 x19: a81b30667c00 x18: x17: b4fcec50 x16: 3447cc0e8588 x15: 3447d14fbf88 x14: 344851bb337f x13: 3447d1bb338d x12: 3447d153b000 x11: 3447d14fc7f0 x10: 3447ccb3dac8 x9 : ffd0 x8 : 0005 x7 : 3932373639343932 x6 : 056e x5 : x4 : x3 : x2 : ed59bd53d8905e00 x1 : fffc x0 : a81b30667c00 Call trace: vc4_plane_async_set_fb+0x98/0xa0 vc4_update_plane+0x124/0x1a0 __setplane_internal+0x1f4/0x260 drm_mode_cursor_universal+0xf4/0x220 drm_mode_cursor_common+0x19c/0x218 drm_mode_cursor2_ioctl+0x34/0x48 drm_ioctl_kernel+0x70/0xd8 drm_ioctl+0x30c/0x438 do_vfs_ioctl+0xc4/0x880 SyS_ioctl+0x8c/0xa8 el0_svc_naked+0x30/0x34 -- Daniel J Blueman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel