user/sven/linux.git/include/drm/drm_gem.h, branch v6.4.3

Merge tag 'drm-msm-next-2023-04-10' of https://gitlab.freedesktop.org/drm/msm into drm-next

2023-04-11T10:21:50Z

main pull request for v6.4 Core Display: ============ * Bugfixes for error handling during probe * rework UBWC decoder programming * prepare_commit cleanup * bindings for SM8550 (MDSS, DPU), SM8450 (DP) * timeout calculation fixup * atomic: use drm_crtc_next_vblank_start() instead of our own custom thing to calculate the start of next vblank DP: == * interrupts cleanup DPU: === * DSPP sub-block flush on sc7280 * support AR30 in addition to XR30 format * Allow using REC_0 and REC_1 to handle wide (4k) RGB planes * Split the HW catalog into individual per-SoC files DSI: === * rework DSI instance ID detection on obscure platforms GPU: === * uapi C++ compatibility fix * a6xx: More robust gdsc reset * a3xx and a4xx devfreq support * update generated headers * various cleanups and fixes * GPU and GEM updates to avoid allocations which could trigger reclaim (shrinker) in fence signaling path * dma-fence deadline hint support and wait-boost * a640 speedbin support * a650 speedbin support Conflicts in drivers/gpu/drm/msm/adreno/adreno_gpu.c: Conflict between the 7fa5047a436b ("drm: Use of_property_present() for testing DT property presence") and 9f251f934012 ("drm/msm/adreno: Use OPP for every GPU generation"). The latter removed the of_ function call outright, so I went with what's in the PR unchanged. From: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvwuj5tabyW910+N-B=5kFNAC7QNYoQ=0xi3roBjQvFFQ@mail.gmail.com Signed-off-by: Daniel Vetter

Merge v6.3-rc4 into drm-next

2023-03-29T14:00:23Z

I just landed the fence deadline PR from Rob that a bunch of drivers want/need to apply driver-specific patches. Backmerge -rc4 so that they don't have to be stuck on -rc2 for no reason at all. Signed-off-by: Daniel Vetter

drm/gem: Export drm_gem_lru_move_tail_locked()

2023-03-25T23:31:44Z

Export the locked version or lru's move_tail(). Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/527835/ Link: https://lore.kernel.org/r/20230320144356.803762-7-robdclark@gmail.com

Merge drm/drm-fixes into drm-misc-fixes

2023-03-13T09:14:05Z

Backmerging to get latest upstream. Signed-off-by: Thomas Zimmermann

drm/gem: Add evict() callback to drm_gem_object_funcs

2023-02-27T04:09:41Z

Add new common evict() callback to drm_gem_object_funcs and corresponding drm_gem_object_evict() helper. This is a first step on a way to providing common GEM-shrinker API for DRM drivers. Reviewed-by: Thomas Zimmermann Suggested-by: Thomas Zimmermann Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/all/20230108210445.3948344-4-dmitry.osipenko@collabora.com/

drm/msm/gem: Prevent blocking within shrinker loop

2023-02-27T04:06:56Z

Consider this scenario: 1. APP1 continuously creates lots of small GEMs 2. APP2 triggers `drop_caches` 3. Shrinker starts to evict APP1 GEMs, while APP1 produces new purgeable GEMs 4. msm_gem_shrinker_scan() returns non-zero number of freed pages and causes shrinker to try shrink more 5. msm_gem_shrinker_scan() returns non-zero number of freed pages again, goto 4 6. The APP2 is blocked in `drop_caches` until APP1 stops producing purgeable GEMs To prevent this blocking scenario, check number of remaining pages that GPU shrinker couldn't release due to a GEM locking contention or shrinking rejection. If there are no remaining pages left to shrink, then there is no need to free up more pages and shrinker may break out from the loop. This problem was found during shrinker/madvise IOCTL testing of virtio-gpu driver. The MSM driver is affected in the same way. Reviewed-by: Rob Clark Reviewed-by: Thomas Zimmermann Fixes: b352ba54a820 ("drm/msm/gem: Convert to using drm_gem_lru") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/all/20230108210445.3948344-2-dmitry.osipenko@collabora.com/

drm/gem-shmem: When drm_gem_object_init failed, should release object

2022-11-21T15:55:52Z

when goto err_free, the object had init, so it should be release when fail. Signed-off-by: ChunyouTang Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20221119064131.364-1-tangchunyou@163.com

Merge drm/drm-next into drm-misc-next

2022-10-18T13:00:03Z

Let's kick-off this release cycle. Signed-off-by: Maxime Ripard

drm/gem: Take reservation lock for vmap/vunmap operations

2022-10-17T22:21:38Z

The new common dma-buf locking convention will require buffer importers to hold the reservation lock around mapping operations. Make DRM GEM core to take the lock around the vmapping operations and update DRM drivers to use the locked functions for the case where DRM core now holds the lock. This patch prepares DRM core and drivers to the common dynamic dma-buf locking convention. Acked-by: Christian König Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20221017172229.42269-4-dmitry.osipenko@collabora.com

Merge tag 'drm-msm-next-2022-09-22' of https://gitlab.freedesktop.org/drm/msm into drm-next

2022-09-28T01:35:25Z

msm-next for v6.1 DPU: - simplified VBIF configuration - cleaned up CTL interfaces to accept indices rather than flush masks DSI: - removed unused msm_display_dsc_config struct - switch regulator calls to new bulk API - switched to use PANEL_BRIDGE for directly attached panels DSI PHY: - converted drivers to use parent_hws instead of parent_names DP: - cleaned up pixel_rate handling HDMI PHY: - turned hdmi-phy-8996 into OF clk provider core: - misc dt-bindings fixes - choose eDP as primary display if it's available - support getting interconnects from either the mdss or the mdp5/dpu device nodes gpu+gem: - Shrinker + LRU re-work: - adds a shared GEM LRU+shrinker helper and moves msm over to that - reduces lock contention between retire and submit by avoiding the need to acquire obj lock in retire path (and instead using resv seeing obj's busyness in the shrinker - fix reclaim vs submit issues - GEM fault injection for triggering userspace error paths - Map/unmap optimization - Improved robustness for a6xx GPU recovery Signed-off-by: Dave Airlie From: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsrfrr9v1oR9S4oYfOs9jm=jbKQiwPBTrCRHrjYerJJFA@mail.gmail.com