kernel/linux.git/drivers/gpu/drm, branch v4.18.18

drm/sun4i: Fix an ulong overflow in the dotclock driver

2018-11-10T15:49:47+00:00

commit e84cb605e02f1b3d0aee8d7157419cd8aaa06038 upstream. The calculated ideal rate can easily overflow an unsigned long, thus making the best div selection buggy as soon as no ideal match is found before the overflow occurs. Fixes: 4731a72df273 ("drm/sun4i: request exact rates to our parents") Cc: Signed-off-by: Boris Brezillon Acked-by: Maxime Ripard Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20181018100250.12565-1-boris.brezillon@bootlin.com Signed-off-by: Greg Kroah-Hartman

drm: fb-helper: Reject all pixel format changing requests

2018-11-10T15:49:46+00:00

commit db05c481977599236f12a85e55de9f5ab37b0a2c upstream. drm fbdev emulation doesn't support changing the pixel format at all, so reject all pixel format changing requests. Cc: stable@vger.kernel.org Signed-off-by: Eugeniy Paltsev Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181003164538.5534-1-Eugeniy.Paltsev@synopsys.com Signed-off-by: Greg Kroah-Hartman

drm/edid: VSDB yCBCr420 Deep Color mode bit definitions

2018-11-10T15:49:45+00:00

commit 9068e02f58740778d8270840657f1e250a2cc60f upstream. HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct definitions in the header for the mask to work correctly. Fixes: e6a9a2c3dc43 ("drm/edid: parse ycbcr 420 deep color information") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893 Cc: # v4.14+ Signed-off-by: Clint Taylor Reviewed-by: Jani Nikula Reviewed-by: Shashank Sharma Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/1538776335-12569-1-git-send-email-clinton.a.taylor@intel.com Signed-off-by: Greg Kroah-Hartman

drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl

2018-11-10T15:49:45+00:00

commit 0711a43b6d84ff9189adfbf83c8bbf56eef794bf upstream. There's another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc instead of 8 bpc. Apply 6 bpc quirk for the panel to fix it. BugLink: https://bugs.launchpad.net/bugs/1794387 Cc: # v4.8+ Signed-off-by: Kai-Heng Feng Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181002152911.4370-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Signal hw_done() after waiting for flip_done()

2018-11-04T13:51:47+00:00

[ Upstream commit 987bf116445db5d63a5c2ed94c4479687d9c9973 ] In amdgpu_dm_commit_tail(), wait until flip_done() is signaled before we signal hw_done(). [Why] This is to temporarily address a paging error that occurs when a nonblocking commit contends with another commit, particularly in a mirrored display configuration where at least 2 CRTCs are updated. The error occurs in drm_atomic_helper_wait_for_flip_done(), when we attempt to access the contents of new_crtc_state->commit. Here's the sequence for a mirrored 2 display setup (irrelevant steps left out for clarity): **THREAD 1** | **THREAD 2** | Initialize atomic state for flip | | Queue worker | ... | Do work for flip | | Signal hw_done() on CRTC 1 | Signal hw_done() on CRTC 2 | | Wait for flip_done() on CRTC 1 <---- **PREEMPTED BY THREAD 1** Initialize atomic state for cursor | update (1) | | Do cursor update work on both CRTCs | | Clear atomic state (2) | **DONE** | ... | | Wait for flip_done() on CRTC 2 | *ERROR* | The issue starts with (1). When the atomic state is initialized, the current CRTC states are duplicated to be the new_crtc_states, and referenced to be the old_crtc_states. (The new_crtc_states are to be filled with update data.) Some things to note: * Due to the mirrored configuration, the cursor updates on both CRTCs. * At this point, the pflip IRQ has already been handled, and flip_done signaled on all CRTCs. The cursor commit can therefore continue. * The old_crtc_states used by the cursor update are the **same states** as the new_crtc_states used by the flip worker. At (2), the old_crtc_state is freed (*), and the cursor commit completes. We then context switch back to the flip worker, where we attempt to access the new_crtc_state->commit object. This is problematic, as this state has already been freed. (*) Technically, 'state->crtcs[i].state' is freed, which was made to reference old_crtc_state in drm_atomic_helper_swap_state() [How] By moving hw_done() after wait_for_flip_done(), we're guaranteed that the new_crtc_state (from the flip worker's perspective) still exists. This is because any other commit will be blocked, waiting for the hw_done() signal. Note that both the i915 and imx drivers have this sequence flipped already, masking this problem. Signed-off-by: Shirish S Signed-off-by: Leo Li Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/i2c: tda9950: set MAX_RETRIES for errors only

2018-11-04T13:51:40+00:00

[ Upstream commit e0dccce1193f87597548d0db6ecc942fb92c04cd ] The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to prevent the CEC framework from retrying the transmit. If the transmit was successful, then don't set this flag. Found by running 'cec-compliance -A' on a beaglebone box. Signed-off-by: Hans Verkuil Signed-off-by: Russell King Signed-off-by: Sasha Levin

drm/i2c: tda9950: fix timeout counter check

2018-11-04T13:51:40+00:00

[ Upstream commit d98627d1360d55e3b28f702caca8b6342c4a4e45 ] Currently the check to see if the timeout has reached zero is incorrect and the check is instead checking if the timeout is non-zero and not zero, hence it will break out of the loop on the first iteration and the msleep is never executed. Fix this by breaking from the loop when timeout is zero. Detected by CoverityScan, CID#1469404 ("Logically Dead Code") Fixes: f0316f93897c ("drm/i2c: tda9950: add CEC driver") Signed-off-by: Colin Ian King Signed-off-by: Russell King Signed-off-by: Sasha Levin

drm: mali-dp: Call drm_crtc_vblank_reset on device init

2018-10-20T07:47:08+00:00

[ Upstream commit 69be1984ded00a11b1ed0888c6d8e4f35370372f ] Currently, if userspace calls drm_wait_vblank before the crtc is activated the crtc vblank_enable hook is called, which in case of malidp driver triggers some warninngs. This happens because on device init we don't inform the drm core about the vblank state by calling drm_crtc_vblank_on/off/reset which together with drm_vblank_get have some magic that prevents calling drm_vblank_enable when crtc is off. Signed-off-by: Alexandru Gheorghe Acked-by: Liviu Dudau Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/nouveau/drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()

2018-10-18T07:18:19+00:00

commit e46368cf77f2cb6304c51d9ff5f147cfb7dc0074 upstream. While we currently grab a runtime PM ref in nouveau's normal connector detection code, we apparently don't do this for MST. This means if we're in a scenario where the GPU is suspended and userspace attempts to do a connector probe on an MSTC connector, the probe will fail entirely due to the DP aux channel and GPU not being woken up: [ 316.633489] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff [ 316.635713] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff [ 316.637785] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff ... So, grab a runtime PM ref here. Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Reviewed-by: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman

drm/amdkfd: Fix ATS capablity was not reported correctly on some APUs

2018-10-18T07:18:17+00:00

[ Upstream commit 44d8cc6f1a905e4bb1d4221a898abb0d7e9d100a ] Because CRAT_CU_FLAGS_IOMMU_PRESENT was not set in some BIOS crat, we need to workaround this. For future compatibility, we also overwrite the bit in capability according to the value of needs_iommu_device. Acked-by: Alex Deucher Signed-off-by: Yong Zhao Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman