- 30 6月, 2018 2 次提交
-
-
由 Dirk Hohndel (VMware) 提交于
This is dual licensed under GPL-2.0 or MIT. vmwgfx_msg.h is the odd one out that is GPL-2.0+ or MIT. Acked-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NDirk Hohndel (VMware) <dirk@hohndel.org> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180506231626.115996-9-dirk@hohndel.org
-
由 Dirk Hohndel (VMware) 提交于
These files are licensed under GPL-2.0. Removing the MIT boilerplate as that really didn't make any sense for those two header files. Acked-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NDirk Hohndel (VMware) <dirk@hohndel.org> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180506231626.115996-8-dirk@hohndel.org
-
- 20 6月, 2018 2 次提交
-
-
由 Christian König 提交于
Neither used nor correctly implemented anywhere. Just completely remove the interface. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NSumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/226645/
-
由 Christian König 提交于
The device parameter is completely unused because it is available in the attachment structure as well. v2: fix kerneldoc as well Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/226643/
-
- 12 6月, 2018 6 次提交
-
-
由 Ville Syrjälä 提交于
plane->fb/old_fb/crtc should no longer be used by atomic drivers. Stop messing about with them. Cc: Deepak Rawat <drawat@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-7-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Ville Syrjälä 提交于
Instead of looking at the (soon to be deprecated) plane->fb we'll examing plane->state->fb instead. We can do this because vmw_du_crtc_atomic_check() prevents us from enabling a crtc without the primary plane also being enabled. Due to that same reason, I'm actually not sure what the checks here are for NULL fb. If we can't enable the crtc without an enabled plane we should always have an fb. But I'll leave that for someone else to figure out. Cc: Deepak Rawat <drawat@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-6-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Ville Syrjälä 提交于
We want to get rid of plane->fb on atomic drivers. Stop setting it. Cc: Deepak Rawat <drawat@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-5-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Ville Syrjälä 提交于
The only caller of vmw_kms_update_implicit_fb() is the page_flip hook which itself gets called with the plane mutex already held. Hence we can look at plane->state safely. v2: Drop the bogus lockdep assert Cc: Deepak Rawat <drawat@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-4-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Ville Syrjälä 提交于
Instead of plane->fb (which we're going to deprecate for atomic drivers) we need to look at plane->state->fb. The maze of code leading to vmw_kms_helper_dirty() wasn't particularly clear, but my analysis concluded that the calls originating from vmw_*_primary_plane_atomic_update() all pass in the crtc which means we'll never end up in this branch of the function. All other callers use drm_modeset_lock_all() somewhere higher up, which means accessing plane->state is safe. v2: Drop the comment and make the code do what it did before (Thomas) v3: Drop the bogus lockdep assert Cc: Deepak Rawat <drawat@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-3-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Ville Syrjälä 提交于
Instead of looking at plane->fb let's look at the proper new plane state. Not that the code makes a ton of sense. It's only going through the crtcs in the atomic state, so assuming not all of them are included we're not even calculating the total bandwidth here. Also we're not considering whether each crtc is actually enabled or not. Cc: Deepak Rawat <drawat@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-2-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>
-
- 23 5月, 2018 3 次提交
-
-
由 Thomas Hellstrom 提交于
We have had problems displaying fbdev after a resume and as a workaround we have had to call vmw_fb_refresh(). This has had a number of unwanted side-effects. The root of the problem was, however that the coalesced fbdev dirty region was not empty on the first dirty_mark() after a resume, so a flush was never scheduled. Fix this by force scheduling an fbdev flush after resume, and remove the workaround. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com>
-
由 Thomas Hellstrom 提交于
The error paths were leaking opened channels. Fix by using dedicated error paths. Cc: <stable@vger.kernel.org> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Thomas Hellstrom 提交于
Depending on whether the kernel is compiled with frame-pointer or not, the temporary memory location used for the bp parameter in these macros is referenced relative to the stack pointer or the frame pointer. Hence we can never reference that parameter when we've modified either the stack pointer or the frame pointer, because then the compiler would generate an incorrect stack reference. Fix this by pushing the temporary memory parameter on a known location on the stack before modifying the stack- and frame pointers. Cc: <stable@vger.kernel.org> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
- 16 5月, 2018 1 次提交
-
-
由 Deepak Rawat 提交于
SOU primary plane prepare_fb hook depends upon dmabuf_size to pin up BO (and not call a new vmw_dmabuf_init) when a new fb size is same as current fb. This was changed in a recent commit which is causing page_flip to fail on VM with low display memory and multi-mon failure when cycle monitors from secondary display. Cc: <stable@vger.kernel.org> # 4.14, 4.16 Fixes: 20fb5a63 ("drm/vmwgfx: Unpin the screen object backup buffer when not used") Signed-off-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
- 03 5月, 2018 1 次提交
-
-
由 Daniel Vetter 提交于
Control nodes are no more! Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180420065159.4531-3-daniel.vetter@ffwll.ch
-
- 26 4月, 2018 2 次提交
-
-
由 Thomas Hellstrom 提交于
A buffer object leak was introduced when fixing a premature buffer object release. Fix this. Cc: <stable@vger.kernel.org> Fixes: 73a88250 ("Fix a destoy-while-held mutex problem.") Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Thomas Hellstrom 提交于
At least since the atomic port, the vmwgfx fbdev code is taking a number of unnecessary modeset locks. In particular the kms_set_config() function will grab its own locks, leading to locking retries. So avoid drm_modeset_lock_all() and instead provide a local acquire context for kms_set_config(). Also have the vmw_kms_fbdev_init data itself grab the lock that it needs. This also fixed a long standing problem that vmw_fb_close() didn't provide an acquire context for kms_set_config(), causing potential warnings and hangs during driver unload. This problem was uncovered by the recent commit "drm/vmwgfx: Improve on hibernation" Testing done: Repeated driver load and unload on Ubuntu 16.04.2 Fixes: c3b9b165 ("drm/vmwgfx: Improve on hibernation") Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
- 24 4月, 2018 1 次提交
-
-
由 Daniel Vetter 提交于
Less hits to go through when I git grep over all drivers. These callbacks are optional. Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-2-daniel.vetter@ffwll.ch
-
- 30 3月, 2018 1 次提交
-
-
由 Ville Syrjälä 提交于
We want to get rid of plane->fb on atomic drivers. Stop looking at it. Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-13-ville.syrjala@linux.intel.comReviewed-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 22 3月, 2018 18 次提交
-
-
由 Thomas Hellstrom 提交于
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Arnd Bergmann 提交于
DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit seconds/microseconds format. As of commit c61eef72 ("drm: add support for monotonic vblank timestamps"), other DRM drivers use monotonic times for drm_event_vblank, but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from the y2038/y2106 overflow as well as time jumps. For consistency, this changes vmwgfx to use ktime_get_ts64 as well, which solves those problems and avoids the deprecated do_gettimeofday() function. This should be transparent to to user space, as long as it doesn't compare the time against the result of gettimeofday(). Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Thomas Hellstrom 提交于
We were relying on the pinned screen object backup buffer to be destroyed when not used. But if we hold a copy of the atomic state, like when hibernating, the backup buffer might not be destroyed since it's refcounted by the atomic state. This causes us to hibernate with a buffer pinned in VRAM. Fix this by only having the buffer pinned when it is actually used by a screen object. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Thomas Hellstrom 提交于
For legacy surfaces, they were previously registered as device resources when the driver resources were created. Since they are evictable we instead register them as device resources once they are created on the device, just like for guest-backed surfaces. This has implications during hibernation where we can't hibernate with device resources active. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Himanshu Jha 提交于
Use kasprintf instead of combination of kmalloc and sprintf. Also, remove the local variables used for storing the string length as they are not required now. Signed-off-by: NHimanshu Jha <himanshujha199640@gmail.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Thomas Hellstrom 提交于
It was used to early block fbdev dirty processing. Replace it with an unprotected check of the par->dirty.active field. While this might race with the vmw_fb_off() function, we do a protected check later so the race will at worst lead to grabbing and releasing a couple of locks. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Thomas Hellstrom 提交于
Make it possible to hibernate also with masters that don't switch VT at hibernation time. We save and restore modesetting state unless fbdev is active and enabled at hibernation time. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Thomas Hellstrom 提交于
fbdev framebuffers were previously pinned to be able to keep them mapped across updates. This commit introduces a mechanism that instead revalidates the map on each update, keeping the map cached across updates. The cached map is torn down if the underlying pages change. Typically on buffer object moves and swapouts. This should be nicer to the system when we have resource contention. Testing done: Basic fbdev functionality under Fedora 27. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NSinclair Yeh <syeh@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com>
-
由 Thomas Hellstrom 提交于
The start / stop and preempt commands don't honor the context argument but rather acts on all available contexts. Also add detection for context 1 availability. Note that currently there's no driver interface for submitting buffers using the high-priority command queue (context 1). Testing done: Change the default context for command submission to 1 instead of 0, verify basic desktop functionality including faulty command injection and recovery. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NDeepak Rawat <drawat@vmware.com>
-
由 Thomas Hellstrom 提交于
This blit was previously performed using two large vmaps, one of which was teared down and remapped on each blit. Use the more resource- conserving TTM cpu blit instead. The blit is used in boundary-box computing mode which makes it possible to minimize the bounding box used in host operations. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com>
-
由 Thomas Hellstrom 提交于
The utility uses kmap_atomic() instead of vmapping the whole buffer object. As a result there will be more book-keeping but on some architectures this will help avoid exhausting vmalloc space and also avoid expensive TLB flushes. The blit utility also adds a provision to compute a bounding box of changed content, which is very useful to optimize presentation speed of ill-behaved applications that don't supply proper damage regions, and for page-flips. The cost of computing the bounding box is not that expensive when done in a cpu-blit utility like this. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com>
-
由 Thomas Hellstrom 提交于
Use drm_plane_helper_check_update also for the cursor plane. Some applications, like gdm on gnome shell still uses cursor front-buffer like rendering without notifying the kernel. We do need some kind of noficiation, but work around this for now by updating the cursor image on every cursor move. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com>
-
由 Deepak Rawat 提交于
Page flip can be slow for vmwgfx in some cases, like need to do surface copy to different surface or waiting for IN_FENCE_FD. Enabling nonblocking commits for vmwgfx in case userspace request it. Signed-off-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Deepak Rawat 提交于
Atomic ioctl can also send the same page flip flags as legacy ioctl. In those cases also need to send the vblank event to userspace. vmwgfx does not support flag DRM_MODE_PAGE_FLIP_ASYNC, so this flag is never expected. Signed-off-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Deepak Rawat 提交于
The dmabuf_dirty/surface_dirty in case of screen object is moved to plane atomic update, so that page flip in atomic ioctl also works. vmwgfx does not support DRM_MODE_PAGE_FLIP_ASYNC, so this flag is never expected. Signed-off-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Deepak Rawat 提交于
The function drm_crtc_arm_vblank_event should be used for the driver which have vblank interrupt support. In case of vmwgfx we do not have vblank interrupt. Signed-off-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Deepak Rawat 提交于
When display surface is different than the framebuffer surface, atomic path do not copy the surface data. This commit moved the code to copy surface from legacy to atomic path. Signed-off-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Deepak Rawat 提交于
In case of page flip there is no need to iterate over all display unit in the function "vmw_kms_helper_dirty". If crtc is available then dirty commands is performed on that crtc only. Signed-off-by: NDeepak Rawat <drawat@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
-
- 21 3月, 2018 2 次提交
-
-
由 Thomas Hellstrom 提交于
When validating legacy surfaces, the backup bo might be destroyed at surface validate time. However, the kms resource validation code may have the bo reserved, so we will destroy a locked mutex. While there shouldn't be any other users of that mutex when it is destroyed, it causes a lock leak and thus throws a lockdep error. Fix this by having the kms resource validation code hold a reference to the bo while we have it reserved. We do this by introducing a validation context which might come in handy when the kms code is extended to validate multiple resources or buffers. Cc: <stable@vger.kernel.org> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
由 Thomas Hellstrom 提交于
When we are running without fbdev, transitioning from the login screen to X or gnome-shell/wayland will cause a vt switch and the driver will disable svga mode, losing all modesetting resources. However, the kms atomic state does not reflect that and may think that a crtc is still turned on, which will cause device errors when we try to bind an fb to the crtc, and the screen will remain black. Fix this by turning off all kms resources before disabling svga mode. Cc: <stable@vger.kernel.org> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NSinclair Yeh <syeh@vmware.com>
-
- 15 3月, 2018 1 次提交
-
-
由 Christian König 提交于
Instead of calculating the size in bytes just to recalculate the number of pages from it pass the BO directly to the function. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NRoger He <Hongbo.He@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-