user/sven/linux.git/include/drm, branch v5.4.38

drm: mst: Fix query_payload ack reply struct

2019-12-31T15:42:19Z

[ Upstream commit 268de6530aa18fe5773062367fd119f0045f6e88 ] Spec says[1] Allocated_PBN is 16 bits [1]- DisplayPort 1.2 Spec, Section 2.11.9.8, Table 2-98 Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Lyude Paul Cc: Todd Previte Cc: Dave Airlie Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190829165223.129662-1-sean@poorly.run Signed-off-by: Sasha Levin

drm/shmem: Add docbook comments for drm_gem_shmem_object madvise fields

2019-11-06T23:57:42Z

Add missing docbook comments to madvise fields in struct drm_gem_shmem_object which fixes these warnings: include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member 'madv' not described in 'drm_gem_shmem_object' include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member 'madv_list' not described in 'drm_gem_shmem_object' Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Reported-by: Sean Paul Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Rob Herring Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191101153754.22803-1-robh@kernel.org

drm/atomic: fix self-refresh helpers crtc state dereference

2019-11-06T18:00:21Z

drm_self_refresh_helper_update_avg_times() was incorrectly accessing the new incoming state after drm_atomic_helper_commit_hw_done(). But this state might have already been superceeded by an !nonblock atomic update resulting in dereferencing an already free'd crtc_state. TODO I *think* this will more or less do the right thing.. althought I'm not 100% sure if, for example, we enter psr in a nonblock commit, and then leave psr in a !nonblock commit that overtakes the completion of the nonblock commit. Not sure if this sort of scenario can happen in practice. But not crashing is better than crashing, so I guess we should either take this patch or rever the self-refresh helpers until Sean can figure out a better solution. Fixes: d4da4e33341c ("drm: Measure Self Refresh Entry/Exit times to avoid thrashing") Cc: Sean Paul Signed-off-by: Rob Clark [seanpaul fixed up some checkpatch warns] Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191104173737.142558-1-robdclark@gmail.com

drm: Measure Self Refresh Entry/Exit times to avoid thrashing

2019-09-19T14:03:32Z

Currently the self refresh idle timer is a const set by the crtc. This is fine if the self refresh entry/exit times are well-known for all panels used on that crtc. However panels and workloads can vary quite a bit, and a timeout which works well for one doesn't work well for another. In the extreme, if the timeout is too short we could get in a situation where the self refresh exits are taking so long we queue up a self refresh entry before the exit commit is even finished. This patch changes the idle timeout to a moving average of the entry times + a moving average of exit times + the crtc constant. This patch was tested on rockchip, with a kevin CrOS panel the idle delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On the same board, the bob panel idle delay lands around ~340ms (90 entry + 150 exit + 100 const). WRT the dedicated mutex in self_refresh_data, it would be nice if we could rely on drm_crtc.mutex to protect the average times, but there are a few reasons why a separate lock is a better choice: - We can't rely on drm_crtc.mutex being held if we're doing a nonblocking commit - We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us whether the lock was already held in the acquire context (it eats -EALREADY), so we can't tell if we should drop it or not - We don't need such a heavy-handed lock for what we're trying to do, commit ordering doesn't matter, so a point-of-use lock will be less contentious Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-sean@poorly.run Link: https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-2-sean@poorly.run Changes in v2: - Migrate locking explanation from comment to commit msg (Daniel) - Turf constant entry delay and multiply the avg times by 2 (Daniel)

drm: Fix kerneldoc and remove unused struct member in self_refresh helper

2019-09-19T14:03:19Z

Artifacts of previous revisions. Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-1-sean@poorly.run Link: https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-1-sean@poorly.run Changes in v2: - None

drm/atomic: Rename crtc_state->pageflip_flags to async_flip

2019-09-18T16:43:36Z

It's the only flag anyone actually cares about. Plus if we're unlucky, the atomic ioctl might need a different flag for async flips. So better to abstract this away from the uapi a bit. Reviewed-by: Maarten Lankhorst Reviewed-by: Nicholas Kazlauskas Cc: Maarten Lankhorst Cc: Michel Dänzer Cc: Alex Deucher Cc: Adam Jackson Cc: Sean Paul Cc: David Airlie Signed-off-by: Daniel Vetter Cc: Maxime Ripard Cc: Daniel Vetter Cc: Nicholas Kazlauskas Cc: Leo Li Cc: Harry Wentland Cc: David Francis Cc: Mario Kleiner Cc: Bhawanpreet Lakha Cc: Ben Skeggs Cc: "Christian König" Cc: Ilia Mirkin Cc: Sam Ravnborg Cc: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20190903190642.32588-3-daniel.vetter@ffwll.ch

drm/shmem: Use mutex_trylock in drm_gem_shmem_purge

2019-08-28T15:02:39Z

Lockdep reports a circular locking dependency with pages_lock taken in the shrinker callback. The deadlock can't actually happen with current users at least as a BO will never be purgeable when pages_lock is held. To be safe, let's use mutex_trylock() instead and bail if a BO is locked already. WARNING: possible circular locking dependency detected 5.3.0-rc1+ #100 Tainted: G L ------------------------------------------------------ kswapd0/171 is trying to acquire lock: 000000009b9823fd (&shmem->pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40 but task is already holding lock: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (fs_reclaim){+.+.}: fs_reclaim_acquire.part.18+0x34/0x40 fs_reclaim_acquire+0x20/0x28 __kmalloc_node+0x6c/0x4c0 kvmalloc_node+0x38/0xa8 drm_gem_get_pages+0x80/0x1d0 drm_gem_shmem_get_pages+0x58/0xa0 drm_gem_shmem_get_pages_sgt+0x48/0xd0 panfrost_mmu_map+0x38/0xf8 [panfrost] panfrost_gem_open+0xc0/0xe8 [panfrost] drm_gem_handle_create_tail+0xe8/0x198 drm_gem_handle_create+0x3c/0x50 panfrost_gem_create_with_handle+0x70/0xa0 [panfrost] panfrost_ioctl_create_bo+0x48/0x80 [panfrost] drm_ioctl_kernel+0xb8/0x110 drm_ioctl+0x244/0x3f0 do_vfs_ioctl+0xbc/0x910 ksys_ioctl+0x78/0xa8 __arm64_sys_ioctl+0x1c/0x28 el0_svc_common.constprop.0+0x90/0x168 el0_svc_handler+0x28/0x78 el0_svc+0x8/0xc -> #0 (&shmem->pages_lock){+.+.}: __lock_acquire+0xa2c/0x1d70 lock_acquire+0xdc/0x228 __mutex_lock+0x8c/0x800 mutex_lock_nested+0x1c/0x28 drm_gem_shmem_purge+0x20/0x40 panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost] do_shrink_slab+0x208/0x500 shrink_slab+0x10c/0x2c0 shrink_node+0x28c/0x4d8 balance_pgdat+0x2c8/0x570 kswapd+0x22c/0x638 kthread+0x128/0x130 ret_from_fork+0x10/0x18 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&shmem->pages_lock); lock(fs_reclaim); lock(&shmem->pages_lock); *** DEADLOCK *** 3 locks held by kswapd0/171: #0: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 #1: 00000000ceb37808 (shrinker_rwsem){++++}, at: shrink_slab+0xbc/0x2c0 #2: 00000000f31efa81 (&pfdev->shrinker_lock){+.+.}, at: panfrost_gem_shrinker_scan+0x34/0x180 [panfrost] Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Rob Herring Reviewed-by: Steven Price Acked-by: Alyssa Rosenzweig Link: https://patchwork.freedesktop.org/patch/msgid/20190823021216.5862-6-robh@kernel.org

Merge tag 'drm-next-5.4-2019-08-23' of git://people.freedesktop.org/~agd5f/linux into drm-next

2019-08-27T07:22:15Z

drm-next-5.4-2019-08-23: amdgpu: - Enable power features on Navi12 - Enable power features on Arcturus - RAS updates - Initial Renoir APU support - Enable power featyres on Renoir - DC gamma fixes - DCN2 fixes - GPU reset support for Picasso - Misc cleanups and fixes scheduler: - Possible race fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20190823202620.3870-1-alexander.deucher@amd.com

Merge drm/drm-next into drm-intel-next-queued

2019-08-22T07:10:36Z

We need the rename of reservation_object to dma_resv. The solution on this merge came from linux-next: From: Stephen Rothwell Date: Wed, 14 Aug 2019 12:48:39 +1000 Subject: [PATCH] drm: fix up fallout from "dma-buf: rename reservation_object to dma_resv" Signed-off-by: Stephen Rothwell --- drivers/gpu/drm/i915/gt/intel_engine_pool.c | 8 ++++---- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.c b/drivers/gpu/drm/i915/gt/intel_engine_pool.c index 03d90b49584a..4cd54c569911 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_pool.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_pool.c @@ -43,12 +43,12 @@ static int pool_active(struct i915_active *ref) { struct intel_engine_pool_node *node = container_of(ref, typeof(*node), active); - struct reservation_object *resv = node->obj->base.resv; + struct dma_resv *resv = node->obj->base.resv; int err; - if (reservation_object_trylock(resv)) { - reservation_object_add_excl_fence(resv, NULL); - reservation_object_unlock(resv); + if (dma_resv_trylock(resv)) { + dma_resv_add_excl_fence(resv, NULL); + dma_resv_unlock(resv); } err = i915_gem_object_pin_pages(node->obj); which is a simplified version from a previous one which had: Reviewed-by: Christian König Signed-off-by: Rodrigo Vivi

Merge tag 'drm-misc-next-2019-08-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2019-08-21T06:44:41Z

drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: add reservation_object_fences helper, relax reservation_object_add_shared_fence, remove reservation_object seq number (and then restored) - dma-fence: Shrinkage of the dma_fence structure, Merge dma_fence_signal and dma_fence_signal_locked, Store the timestamp in struct dma_fence in a union with cb_list Driver Changes: - More dt-bindings YAML conversions - More removal of drmP.h includes - dw-hdmi: Support get_eld and various i2s improvements - gm12u320: Few fixes - meson: Global cleanup - panfrost: Few refactors, Support for GPU heap allocations - sun4i: Support for DDC enable GPIO - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02, Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1 Toppoly TD043MTEA1 Signed-off-by: Dave Airlie [airlied: fixup dma_resv rename fallout] From: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20190819141923.7l2adietcr2pioct@flea