BMC/Intel-BMC/linux.git/drivers/gpu/drm/vkms, branch dev-5.2

drm/vkms: Forward timer right after drm_crtc_handle_vblank

2019-07-31T05:24:37+00:00

[ Upstream commit 7355965da22b8d9ebac8bce4b776399fb0bb9d32 ] In commit def35e7c592616bc09be328de8795e5e624a3cf8 Author: Shayenne Moura Date: Wed Jan 30 14:06:36 2019 -0200 drm/vkms: Bugfix extra vblank frame we fixed the vblank counter to give accurate results outside of drm_crtc_handle_vblank, which fixed bugs around vblank timestamps being off-by-one and causing the vblank counter to jump when it shouldn't. The trouble is that this completely broke crc generation. Shayenne and Rodrigo tracked this down to the vblank timestamp going backwards in time somehow. Which then resulted in an underflow in drm_vblank.c code, which resulted in all kinds of things breaking really badly. The reason for this is that once we've called drm_crtc_handle_vblank and the hrtimer isn't forwarded yet, we're returning a vblank timestamp in the past. This race is really hard to hit since it's small, except when you enable crc generation: In that case there's a call to drm_crtc_accurate_vblank right in-betwen, so we're guaranteed to hit the bug. The fix is to roll the hrtimer forward _before_ we do the vblank processing (which has a side-effect of incrementing the vblank counter), and we always subtract one frame from the hrtimer - since now it's always one frame in the future. To make sure we don't hit this again also add a WARN_ON checking for whether our timestamp is somehow moving into the past, which is never should. This also aligns more with how real hw works: 1. first all registers are updated with the new timestamp/vblank counter values. 2. then an interrupt is generated 3. kernel interrupt handler eventually fires. So doing this aligns vkms closer with what drm_vblank.c expects. Document this also in a comment. Cc: Shayenne Moura Cc: Rodrigo Siqueira Signed-off-by: Daniel Vetter Tested-by: Rodrigo Siqueira Reviewed-by: Rodrigo Siqueira Signed-off-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/20190606084404.12014-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46+00:00

Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

BackMerge v5.1-rc5 into drm-next

2019-04-15T05:51:49+00:00

Need rc5 for udl fix to add udl cleanups on top. Signed-off-by: Dave Airlie

drm: vkms: check status of alloc_ordered_workqueue

2019-03-25T08:33:42+00:00

alloc_ordered_workqueue may fail and return NULL. The fix returns ENOMEM when it fails to avoid potential NULL pointer dereference. Signed-off-by: Kangjie Lu Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190309043628.6078-1-kjlu@umn.edu

drm/vkms: fix use-after-free when drm_gem_handle_create() fails

2019-03-18T07:45:57+00:00

If drm_gem_handle_create() fails in vkms_gem_create(), then the vkms_gem_object is freed twice: once when the reference is dropped by drm_gem_object_put_unlocked(), and again by the extra calls to drm_gem_object_release() and kfree(). Fix it by skipping the second release and free. This bug was originally found in the vgem driver by syzkaller using fault injection, but I noticed it's also present in the vkms driver. Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations") Cc: Rodrigo Siqueira Cc: Haneen Mohammed Cc: Daniel Vetter Cc: Chris Wilson Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Chris Wilson Reviewed-by: Rodrigo Siqueira Signed-off-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/20190226220858.214438-1-ebiggers@kernel.org Signed-off-by: Maxime Ripard

Merge v5.0-rc7 into drm-next

2019-02-18T03:27:15+00:00

Backmerging for nouveau and imx that needed some fixes for next pulls. Signed-off-by: Dave Airlie

drm/vkms: Fix license inconsistent

2019-02-10T12:23:06+00:00

Fixes license inconsistent related to the VKMS driver and remove the redundant boilerplate comment. Fixes: 854502fa0a38 ("drm/vkms: Add basic CRTC initialization") Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Siqueira Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190206140116.7qvy2lpwbcd7wds6@smtp.gmail.com

drm/vkms: WARN when hrtimer_forward_now fails

2019-02-10T11:51:11+00:00

Add a warn to verify the hrtimer_forward_now return and changes ret_overrun from int to u64 to match the return value provided by hrtimer_forward_now. Signed-off-by: Shayenne Moura Signed-off-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/20190206200813.d5w7gjpepoeeadiy@smtp.gmail.com

drm/vkms: Bugfix racing hrtimer vblank handle

2019-02-03T21:28:21+00:00

When the vblank irq happens, kernel time subsystem executes `vkms_vblank_simulate`. In parallel or not, it prepares all stuff necessary to the next vblank with arm, and it must flush these stuff before the next vblank irq. However, vblank counter is ahead when arm is executed in parallel with handle vblank. CPU 0: CPU 1: | | atomic_commit_tail is ongoing | | | | hrtimer: vkms_vblank_simulate() | | | drm_crtc_handle_vblank() | | drm_crtc_arm_vblank() | | | ->get_vblank_timestamp() | | | | hrtimer_forward_now() Then, we should guarantee that the vblank interval time is correct (not changed) before finish the vblank handle. Fix the bug including the call to `hrtimer_forward_now()` in the same lock of `drm_crtc_handle_vblank()` to ensure that the timestamp update is correct when finish the vblank handle. Signed-off-by: Shayenne Moura Signed-off-by: Daniel Vetter Reviewed-by: Rodrigo Siqueira Signed-off-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/e2e4b8f3a5cab7b2dba75bf1930f86b0a4ee08c9.1548856186.git.shayenneluzmoura@gmail.com

drm/vkms: Bugfix extra vblank frame

2019-02-03T21:26:14+00:00

kms_flip tests are breaking on vkms when simulate vblank because vblank event sequence count returns one extra frame after arm vblank event to make a page flip. When vblank interrupt happens, userspace processes the vblank event and issues the next page flip command. Kernel calls queue_work to call commit_planes and arm the new page flip. The next vblank picks up the newly armed vblank event and vblank interrupt happens again. The arm and vblank event are asynchronous, then, on the next vblank, we receive x+2 from `get_vblank_timestamp`, instead x+1, although timestamp and vblank seqno matches. Function `get_vblank_timestamp` is reached by 2 ways: - from `drm_mode_page_flip_ioctl`: driver is doing one atomic operation to synchronize planes in the same output. There is no vblank simulation, the `drm_crtc_arm_vblank_event` function adds 1 on vblank count, and the variable in_vblank_irq is false - from `vkms_vblank_simulate`: since the driver is doing a vblank simulation, the variable in_vblank_irq is true. Fix this problem subtracting one vblank period from vblank_time when `get_vblank_timestamp` is called from trace `drm_mode_page_flip_ioctl`, i.e., is not a real vblank interrupt, and getting the timestamp and vblank seqno when it is a real vblank interrupt. The reason for all this is that get_vblank_timestamp always supplies the timestamp for the next vblank event. The hrtimer is the vblank simulator, and it needs the correct previous value to present the next vblank. Since this is how hw timestamp registers work and what the vblank core expects. Signed-off-by: Shayenne Moura Signed-off-by: Daniel Vetter Reviewed-by: Rodrigo Siqueira Signed-off-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/171e6e1c239cbca0c3df7183ed8acdfeeace9cf4.1548856186.git.shayenneluzmoura@gmail.com