kernel/linux.git/drivers/gpu/drm/vmwgfx, branch v5.12.1

drm/vmwgfx: Make sure bo's are unpinned before putting them back

2021-04-14T20:41:31+00:00

During cotable resize we pin the backup buffer to make sure the trylock doesn't fail. We were never unpinning the backup buffer resulting in every subsequent cotable resize trying to release a pinned bo. After we copy the old backup to the new we can release the pin. Mob's are always pinned so we just have to make sure we unpin them before releasing them. Reviewed-by: Thomas Hellström (Intel) Fixes: d1a73c641afd ("drm/vmwgfx: Make sure we unpin no longer needed buffers") Link: https://patchwork.freedesktop.org/patch/msgid/20210413205938.788366-1-zackr@vmware.com Signed-off-by: Zack Rusin

drm/vmwgfx: Fix the lockdep breakage

2021-04-14T20:41:17+00:00

Thomas has noticed that the lockdep was broken in vmwgfx. It was broken during the pci initialization rework. This fixes the breakage by making sure we initialize the locking code before doing anything else. This was independently spotted and fixed by Tetsuo Handa as well. Reviewed-by: Martin Krastev Reviewed-by: Roland Scheidegger Cc: Tetsuo Handa Cc: dri-devel@lists.freedesktop.org Signed-off-by: Zack Rusin Fixes: 8772c0bb58bbf98a ("drm/vmwgfx: Cleanup pci resource allocation") Link: https://patchwork.freedesktop.org/patch/msgid/20210408172245.673785-1-zackr@vmware.com

drm/vmwgfx: Make sure we unpin no longer needed buffers

2021-04-14T20:41:02+00:00

We were not correctly unpinning no longer needed buffers. In particular vmw_buffer_object, which is internally often pinned on creation wasn't unpinned on destruction and none of the internal MOB buffers were unpinned before being put back. Technically this existed for a long time but commit 57fcd550eb15 ("drm/ttm: Warn on pinning without holding a reference") introduced a WARN_ON which was filling up the kernel logs rather quickly. Quite frankly internal usage of vmw_buffer_object and in general pinning needs to be refactored in vmwgfx but for now this makes it work. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Reviewed-by: Roland Scheidegger Fixes: 57fcd550eb15 ("drm/ttm: Warn on pinning without holding a reference") Link: https://patchwork.freedesktop.org/patch/414984/?series=86052&rev=1 Cc: Huang Rui Cc: Christian König Cc: Daniel Vetter Cc: Christian Koenig Cc: dri-devel@lists.freedesktop.org

mm: use is_cow_mapping() across tree where proper

2021-03-13T19:27:30+00:00

After is_cow_mapping() is exported in mm.h, replace some manual checks elsewhere throughout the tree but start to use the new helper. Link: https://lkml.kernel.org/r/20210217233547.93892-5-peterx@redhat.com Signed-off-by: Peter Xu Reviewed-by: Jason Gunthorpe Cc: VMware Graphics Cc: Roland Scheidegger Cc: David Airlie Cc: Daniel Vetter Cc: Mike Kravetz Cc: Alexey Dobriyan Cc: Andrea Arcangeli Cc: Christoph Hellwig Cc: David Gibson Cc: Gal Pressman Cc: Jan Kara Cc: Jann Horn Cc: Kirill Shutemov Cc: Kirill Tkhai Cc: Matthew Wilcox Cc: Miaohe Lin Cc: Mike Rapoport Cc: Wei Zhang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drm/vmwgfx: Fix some memory leaks on errors

2021-02-09T16:16:57+00:00

Dan noticed some issues with pci_release_region, this builds upon that and fixes some other lingering issues. As part of this we also can stop trying to manually free our managed device; there's no need for it, it will be cleaned up automatically for us. Fixes: 8772c0bb58bb ("drm/vmwgfx: Cleanup pci resource allocation") Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Reviewed-by: Roland Scheidegger Reported-by: kernel test robot Reported-by: Dan Carpenter Link: https://patchwork.freedesktop.org/patch/msgid/20210128173756.121525-1-zackr@vmware.com (cherry picked from commit 75ec69c79ebcae0ad16baf2249e378f5b02bdc12) Signed-off-by: Maarten Lankhorst

drm/vmwgfx/vmwgfx_drv: Fix an error path in vmw_setup_pci_resources()

2021-02-09T16:14:11+00:00

The devm_memremap() function never returns NULL, it returns error pointers so the test needs to be fixed. Also we need to call pci_release_regions() to avoid a memory leak. Fixes: be4f77ac6884 ("drm/vmwgfx: Cleanup fifo mmio handling") Signed-off-by: Dan Carpenter Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/YA6FMboLhnE3uSvb@mwanda (cherry picked from commit f3ebd4e6b692ab7af464561410a1f05dfc850823) Signed-off-by: Maarten Lankhorst

drm/vmwgfx: Always evict vram _before_ disabling it

2021-01-18T13:15:20+00:00

Other way round is a bit inconsistent (but not buggy in any kind). This is prep work so that ttm_resource_manager_set_used can assert that the resource manager is empty. Signed-off-by: Daniel Vetter Reviewed-by: Roland Scheidegger Cc: VMware Graphics Cc: Roland Scheidegger Link: https://patchwork.freedesktop.org/patch/msgid/20201211162942.3399050-2-daniel.vetter@ffwll.ch

drm/vmwgfx: Drop svga_lock

2021-01-18T13:15:20+00:00

This isn't actually protecting anything becuase: - when running, ttm_resource_manager->use_type is protected through vmw_private->reservation_semaphore against concurrent execbuf or well anything else that might evict or reserve buffers - during suspend/resume there's nothing else running, hence vmw_pm_freeze and vmw_pm_restore do not need to take the same lock. - this also holds for the SVGA_REG_ENABLE register write Hence it is safe to just remove that spinlock. Signed-off-by: Daniel Vetter Reviewed-by: Zack Rusin Reviewed-by: Roland Scheidegger Cc: VMware Graphics Cc: Roland Scheidegger Link: https://patchwork.freedesktop.org/patch/msgid/20201211162942.3399050-1-daniel.vetter@ffwll.ch

drm/vmwgfx: Fix display register usage for some older configs

2021-01-14T17:16:47+00:00

We can't be setting the display_id register to an invalid value because that makes our device reset the fb which causes nasty flicker (due to destruction and creation of a new fb). Also we can't be using the BITS_PER_PIXEL register if the 8BIT_EMULATION is not supported. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Reviewed-by: Roland Scheidegger Link: https://patchwork.freedesktop.org/patch/414041/?series=85516&rev=2

drm/vmwgfx: Cleanup the cmd/fifo split

2021-01-14T17:15:49+00:00

Lets try to cleanup the usage of the term FIFO which we used for both our MMIO based cmd queue processing and for general command processing which could have been using command buffers interface. We're going to rename the functions which are processing commands (and work either via MMIO or command buffers) as _cmd_ and functions which operate on the MMIO based commands as FIFO to match the SVGA device naming. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/414044/?series=85516&rev=2