linux/drivers/gpu, branch v5.6

Merge tag 'amd-drm-fixes-5.6-2020-03-26' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2020-03-27T03:03:17Z

amd-drm-fixes-5.6-2020-03-26: Scheduler: - Fix a race condition that could result in a segfault Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20200326144538.3937-1-alexander.deucher@amd.com

Merge tag 'drm-misc-fixes-2020-03-26' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

2020-03-27T02:33:23Z

drm-misc-fixes for v5.6: - SG fixes for prime, radeon and amdgpu. Signed-off-by: Dave Airlie From: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/ef10e822-76dd-125d-ec1f-9a78c5f76bc3@linux.intel.com

drm/scheduler: fix rare NULL ptr race

2020-03-26T14:22:36Z

There is one one corner case at dma_fence_signal_locked which will raise the NULL pointer problem just like below. ->dma_fence_signal ->dma_fence_signal_locked ->test_and_set_bit here trigger dma_fence_release happen due to the zero of fence refcount. ->dma_fence_put ->dma_fence_release ->drm_sched_fence_release_scheduled ->call_rcu here make the union fled “cb_list” at finished fence to NULL because struct rcu_head contains two pointer which is same as struct list_head cb_list Therefore, to hold the reference of finished fence at drm_sched_process_job to prevent the null pointer during finished fence dma_fence_signal [ 732.912867] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 732.914815] #PF: supervisor write access in kernel mode [ 732.915731] #PF: error_code(0x0002) - not-present page [ 732.916621] PGD 0 P4D 0 [ 732.917072] Oops: 0002 [#1] SMP PTI [ 732.917682] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G OE 5.4.0-rc7 #1 [ 732.918980] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 [ 732.920906] RIP: 0010:dma_fence_signal_locked+0x3e/0x100 [ 732.938569] Call Trace: [ 732.939003] [ 732.939364] dma_fence_signal+0x29/0x50 [ 732.940036] drm_sched_fence_finished+0x12/0x20 [gpu_sched] [ 732.940996] drm_sched_process_job+0x34/0xa0 [gpu_sched] [ 732.941910] dma_fence_signal_locked+0x85/0x100 [ 732.942692] dma_fence_signal+0x29/0x50 [ 732.943457] amdgpu_fence_process+0x99/0x120 [amdgpu] [ 732.944393] sdma_v4_0_process_trap_irq+0x81/0xa0 [amdgpu] v2: hold the finished fence at drm_sched_process_job instead of amdgpu_fence_process v3: resume the blank line Signed-off-by: Yintian Tao Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/radeon: fix scatter-gather mapping with user pages

2020-03-25T16:10:55Z

Calls to dma_map_sg may return less segments / entries than requested if they fall on page bounderies. The old implementation did not support this use case. Fixes: be62dbf554c5 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206461 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206895 Bug: https://gitlab.freedesktop.org/drm/amd/issues/1056 Signed-off-by: Shane Francis Reviewed-by: Michael J. Ruhl Signed-off-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20200325090741.21957-4-bigbeeshane@gmail.com Cc: stable@vger.kernel.org

drm/amdgpu: fix scatter-gather mapping with user pages

2020-03-25T16:10:40Z

drm/prime: use dma length macro when mapping sg

2020-03-25T16:01:23Z

As dma_map_sg can reorganize scatter-gather lists in a way that can cause some later segments to be empty we should always use the sg_dma_len macro to fetch the actual length. This could now be 0 and not need to be mapped to a page or address array Fixes: be62dbf554c5 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206461 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206895 Bug: https://gitlab.freedesktop.org/drm/amd/issues/1056 Signed-off-by: Shane Francis Reviewed-by: Michael J. Ruhl Signed-off-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20200325090741.21957-2-bigbeeshane@gmail.com Cc: stable@vger.kernel.org

Merge tag 'drm-intel-fixes-2020-03-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

2020-03-20T02:52:35Z

drm/i915 fixes for v5.6-rc7: - Track active elements during dequeue - Fix failure to handle all MCR ranges - Revert unnecessary workaround Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/877dzgepvu.fsf@intel.com

Merge tag 'amd-drm-fixes-5.6-2020-03-19' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2020-03-20T02:48:17Z

amd-drm-fixes-5.6-2020-03-19: amdgpu: - Pageflip fix - VCN clockgating fixes - GPR debugfs fix for umr - GPU reset fix - eDP fix for MBP - DCN2.x fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20200319204054.1036478-1-alexander.deucher@amd.com

drm/amd/display: Fix pageflip event race condition for DCN.

2020-03-19T20:18:45Z

Commit '16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN")' introduces a new way of pageflip completion handling for DCN, and some trouble. The current implementation introduces a race condition, which can cause pageflip completion events to be sent out one vblank too early, thereby confusing userspace and causing flicker: prepare_flip_isr(): 1. Pageflip programming takes the ddev->event_lock. 2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED 3. Releases ddev->event_lock. --> Deadline for surface address regs double-buffering passes on target pipe. 4. dc_commit_updates_for_stream() MMIO programs the new pageflip into hw, but too late for current vblank. => pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete in current vblank due to missing the double-buffering deadline by a tiny bit. 5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires, dm_dcn_crtc_high_irq() gets called. 6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the pageflip has been completed/will complete in this vblank and sends out pageflip completion event to userspace and resets pflip_status = AMDGPU_FLIP_NONE. => Flip completion event sent out one vblank too early. This behaviour has been observed during my testing with measurement hardware a couple of time. The commit message says that the extra flip event code was added to dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events in case the pflip irq doesn't fire, because the "DCH HUBP" component is clock gated and doesn't fire pflip irqs in that state. Also that this clock gating may happen if no planes are active. This suggests that the problem addressed by that commit can't happen if planes are active. The proposed solution is therefore to only execute the extra pflip completion code iff the count of active planes is zero and otherwise leave pflip completion handling to the pflip irq handler, for a more race-free experience. Note that i don't know if this fixes the problem the original commit tried to address, as i don't know what the test scenario was. It does fix the observed too early pageflip events though and points out the problem introduced. Fixes: 16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN") Reviewed-by: Nicholas Kazlauskas Signed-off-by: Mario Kleiner Signed-off-by: Alex Deucher

Merge tag 'drm-misc-fixes-2020-03-18-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

2020-03-19T01:49:28Z

- drm/lease: fix WARNING in idr_destroy - Fix AVI frame colorimetry in the dw-hdmi bridge. - Fix compiler warning in komeda by annotating functions as __maybe_unused. - Downgrade bochs pci_request_region failure from error to warning to workaround firmware fb. Signed-off-by: Dave Airlie From: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/7654ac39-deb8-c9ca-9fd5-ef77b2636380@linux.intel.com