linux/drivers/gpu/drm/vmwgfx, branch v4.7

drm/vmwgfx: Fix error paths when mapping framebuffer

2016-07-08T15:30:35Z

Rather than returning immediately, make sure to unlock the mutexes first. Signed-off-by: Sinclair Yeh Reviewed-by: Charmaine Lee Reported-by: Emil Velikov Cc:

drm/vmwgfx: Fix corner case screen target management

2016-07-01T17:47:51Z

When the surface backing a framebuffer doesn't match the framebuffer's dimensions, the screen target code would test the framebuffer dimensions rather than the surface dimensions when deciding whether to bind the surface as a screen target directly. This causes a screen target - surface dimension mismatch and a subsequent device error. Fix this by testing against the surface dimension. v2: Fix review comments by Sinclair Yeh. Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh Cc:

drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set

2016-07-01T17:47:50Z

For the Screen Object display unit, we need to reserve a guest-invisible region equal to the size of the framebuffer for the host. This region can only be reserved in VRAM, whereas the guest-visible framebuffer can be reserved in either VRAM or GMR. As such priority should be given to the guest-invisible region otherwise in a limited VRAM situation, we can fail to allocate this region. This patch makes it so that vmw_sou_backing_alloc() is called before the framebuffer is pinned. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Cc: --- This is the last patch of a 3-patch series to fix console black screen issue on Ubuntu 16.04 server

drm/vmwgfx: Check pin count before attempting to move a buffer

2016-07-01T17:47:50Z

In certain scenarios, e.g. when fbdev is enabled, we can get into a situation where a vmw_framebuffer_pin() is called on a buffer that is already pinned. When this happens, ttm_bo_validate() will unintentially remove the TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way to actually pin the buffer again. To prevent this, if a buffer is already pinned, then instead of calling ttm_bo_validate(), just make sure the proposed placement is compatible with the existing placement. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Cc: --- This is the 2nd patch in a 3-patch series to fix a console black screen issue on Ubuntu 16.04 server. This fixes a BUG_ON() condition where a pinned buffer gets accidentally put onto the LRU list.

drm/vmwgfx: Add an option to change assumed FB bpp

2016-07-01T17:47:48Z

Offer an option for advanced users who want larger modes at 16bpp. This becomes necessary after the fix: "Work around mode set failure in 2D VMs." Without this patch, there would be no way for existing advanced users to get to a high res mode, and the regression is they will likely get a black screen after a software update on their current VM. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Cc:

drm/vmwgfx: Work around mode set failure in 2D VMs

2016-07-01T17:47:48Z

In a low-memory 2D VM, fbdev can take up a large percentage of available memory, making them unavailable for other DRM clients. Since we do not take fbdev into account when filtering modes, we end up claiming to support more modes than we actually do. As a result, users get a black screen when setting a mode too large for current available memory. In a low-memory VM configuration, users can get a black screen for a mode as low as 1024x768. The current mode filtering mechanism keys off of SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount of surface memory we have. Since this value is a performance suggestion, not a hard limit, and since there should not be much of a performance impact for a 2D VM, rather than filtering out more modes, we will just allow ourselves to exceed the SVGA's performance suggestion. Also changed assumed bpp to 32 from 16 to make sure we can actually support all the modes listed. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom Cc:

drm/vmwgfx: Add a check to handle host message failure

2016-07-01T17:47:47Z

Discovered by static code analysis tool. If for some reason communication with the host fails more than preset number of retries, return an error instead of return garbage. Signed-off-by: Sinclair Yeh Reviewed-by: Charmaine Lee Reported-by: Dan Carpenter

objtool, drm/vmwgfx: Fix "duplicate frame pointer save" warning

2016-06-08T13:36:18Z

objtool reports the following warnings: drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: warning: objtool: vmw_send_msg()+0x107: duplicate frame pointer save drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: warning: objtool: vmw_host_get_guestinfo()+0x252: duplicate frame pointer save To quote Linus: "The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence (a "rep outsb") to communicate with the hypervisor (it's a virtual GPU driver for vmware), and %rbp is part of the communication. So the inline asm does a save-and-restore of the frame pointer around the instruction sequence. I actually find the objtool warning to be quite reasonable, so it's not exactly a false positive, since in this case it actually does point out that the frame pointer won't be reliable over that instruction sequence. But in this particular case it just ends up being the wrong thing - the code is what it is, and %rbp just can't have the frame information due to annoying magic calling conventions." Silence the warnings by telling objtool to ignore the two functions which use the VMW_PORT_HB_{IN,OUT} macros. Reported-by: Linus Torvalds Signed-off-by: Josh Poimboeuf Acked-by: Linus Torvalds Cc: DRI Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20160526184343.fdtjjjg67smmeekt@treble Signed-off-by: Ingo Molnar

drm/vmwgfx: Report vmwgfx version to vmware.log

2016-05-20T15:40:07Z

When tracking down a customer issue, it is useful to know exactly which version of the vmwgfx they are using. Since vmware.log is often the only available debug log, report vmwgfx version in there. Signed-off-by: Sinclair Yeh Signed-off-by: Thomas Hellstrom

drm/vmwgfx: Add VMWare host messaging capability

2016-05-20T15:12:33Z

This patch adds capabilities for a VMWare guest to send and receive messages from the host, and adds functions to sending log messages to vmware.log and to request device settings that aren't available through the virtual hardware, e.g. certain settings in the VMX file. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom