vmwgfx currently cannot support non-blocking commit because when
vmw_*_crtc_page_flip is called, drm_atomic_nonblocking_commit()
schedules the update on a thread.  This means vmw_*_crtc_page_flip
cannot rely on the new surface being bound before the subsequent
dirty and flush operations happen.

Cc: <stable@vger.kernel.org> # 4.12.x
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NCharmaine Lee <charmainel@vmware.com>

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
  13765	    800	     20	  14585	   38f9	gpu/drm/vmwgfx/vmwgfx_drv.o

File size After adding 'const':
   text	   data	    bss	    dec	    hex	filename
  13829	    736	     20	  14585	   38f9	gpu/drm/vmwgfx/vmwgfx_drv.o
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

The current code does not look correct, and the reason for it is
probably lost.  Since this now generates a compiler warning,
fix it to what makes sense.

Cc: <stable@vger.kernel.org>
Reported-by: NArnd Bergmann <arnd@arndb.de>
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

Parts of commit <8fbf9d92> (“drm/vmwgfx: Implement the
cursor_set2 callback v2”) were not moved over when we started
atomic mode set development because at that time the DRM did
not support cursor hotspots in the fb struct.

This patch fixes what was not moved over.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Tested-by: NBrian Paul <brianp@vmware.com>

This was originally chosen to be an arbitrarily large number.  However,
some user mode may actually try to set a 16Kx16K mode and run into other
issues.

Since 8Kx8K is the current texture limit for Mesa LLVM driver, we will
just use this limit for now.

Cc: <stable@vger.kernel.org> # 4.12.x
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by <drm/ttm/ttm_placement.h> work
with const ttm_place. So mark the non-const structs as const.

File size before:
  text   data    bss     dec     hex filename
  3172    796     16    3984     f90 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o

File size After adding 'const':
  text   data    bss     dec     hex filename
  3456    512     16    3984     f90 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Comment fix.
Signed-off-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NNeha Bhende <bhenden@vmware.com>

We should use dma_pool_zalloc instead of dma_pool_alloc/memset
Signed-off-by: NSouptick joarder <jrdr.linux@gmail.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NSinclair Yeh <syeh@vmware.com>

'vmw_cotable_alloc()' returns an error pointer on error, not NULL.
Propagate the error code, instead of returning -ENOMEM unconditionally
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NSinclair Yeh <syeh@vmware.com>

Replace direct comparisons to NULL i.e.
'x == NULL' with '!x'. As per coding standard.
Signed-off-by: NRavikant B Sharma <ravikant.s2@samsung.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NSinclair Yeh <syeh@vmware.com>

The hash table created during vmw_cmdbuf_res_man_create was
never freed. This causes memory leak in context creation.
Added the corresponding drm_ht_remove in vmw_cmdbuf_res_man_destroy.

Tested for memory leak by running piglit overnight and kernel
memory is not inflated which earlier was.

Cc: <stable@vger.kernel.org>
Signed-off-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

While the atomic modesetting capability is signaled also elsewhere, also
reflect it by a driver minor bump.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

These function implementations and/or declarations are no longer used
now that atomic is enabled.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reported-by: NDaniel Vetter <daniel@ffwll.ch>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Trivial fix to spelling mistake in DRM_ERROR error message.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

The previous attempt at this had an issue with with num_clips > 1
because it would always end up using the coordinates of the last
clip while using width and height calculated from the bounding
box of all the clips.

So if the last clip happens to be not at the top-left corner of
the bounding box, the CPU blit operation would go out of bounds.

The original intent was to coalesce all the clips into one blit,
and to do that we need to also track the starting point of the
content buffer.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

When a new FB is bound, we have to send an update command otherwise
the new FB may not be shown
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

When vmw_gb_surface_define_ioctl() is called with an existing buffer,
we end up returning an uninitialized variable in the backup_handle.

The fix is to first initialize backup_handle to 0 just to be sure, and
second, when a user-provided buffer is found, we will use the
req->buffer_handle as the backup_handle.

Cc: <stable@vger.kernel.org>
Reported-by: NMurray McAllister <murray.mcallister@insomniasec.com>
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

If vmalloc() fails then we need to a bit of cleanup before returning.

Cc: <stable@vger.kernel.org>
Fixes: fb1d9738 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

With atomic, the cursor surface is treated like a FB.  Creating
a proxy surface for cursor doesn't gain us much benefit.

This fixes the issue on atomic enabled 2D VMs where the cursor
disappears.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
a user-controlled 'uint32_t' value which is used as a loop count limit.
This can lead to a kernel lockup and DoS. Add check for 'req->mip_levels'.

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1437431

Cc: <stable@vger.kernel.org>
Signed-off-by: NVladis Dronov <vdronov@redhat.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI
as a convenience.

Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
through the atomic API, but realizing that userspace is likely to take
shortcuts and assume that the enum values are what is sent over the
wire.

As a result these defines are provided purely as a convenience to
userspace applications.

Changes since v3:
 - Switched away from past tense in comments
 - Add define name change to previously mis-spelled DRM_REFLECT_X comment
 - Improved the comment for the DRM_MODE_REFLECT_<axis> comment

Changes since v2:
 - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_
 - Fix compilation errors
 - Changed comment formatting
 - Deduplicated comment lines
 - Clarified DRM_MODE_PROP_REFLECT_ comment

Changes since v1:
 - Moved defines from drm.h to drm_mode.h
 - Changed define prefix from DRM_ to DRM_MODE_PROP_
 - Updated uses of the defines to the new prefix
 - Removed include from drm_rect.c
 - Stopped using the BIT() macro
Signed-off-by: NRobert Foss <robert.foss@collabora.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com

Include <drm/*.h> instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1493009447-31524-18-git-send-email-yamada.masahiro@socionext.com

Change "S_IRUSR | S_IWUSR" to "0600", it's easier to parse mentally.

This change should be part of commit 50f83737 ("drm/vmwgfx: Revert
"drm/vmwgfx: Replace numeric parameter like 0444 with macro""), but the
patch was truncated somewhere in the patch route, so add the missing
change. Extract from the original commit message:

  commit 50f83737
  Author: Øyvind A. Holm <sunny@sunbase.org>
  Date:   Thu Mar 23 14:54:48 2017 -0700

    drm/vmwgfx: Revert "drm/vmwgfx: Replace numeric parameter like 0444
    with macro"

    This reverts commit 2d8e60e8 ("drm/vmwgfx: Replace numeric
    parameter like 0444 with macro")

    The commit belongs to the series of 1285 patches sent to LKML on
    2016-08-02, it changes the representation of file permissions from
    the octal value "0600" to "S_IRUSR | S_IWUSR".

    The general consensus was that the changes does not increase
    readability, quite the opposite; 0600 is easier to parse mentally
    than S_IRUSR | S_IWUSR.
Signed-off-by: NØyvind A. Holm <sunny@sunbase.org>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.htmlSigned-off-by: NLogan Gunthorpe <logang@deltatee.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1492630570-879-1-git-send-email-logang@deltatee.com

I've broken this by removing the backoff handling from the
set_config2atomic helper in

commit 38b6441e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 22 22:50:58 2017 +0100

    drm/atomic-helper: Remove the backoff hack from set_config

Fixing this properly would mean we get to wire the acquire_ctx all the
way through vmwgfx fbdev code, and doing the same was tricky for the
shared fbdev layer. Probably much better to look into refactoring the
entire code to use the helpers, but since that's not a viable
long-term solution fix the issue by open-coding a vmwgfx version of
set_config, that does the legacy backoff dance internally.

Note: Just compile-tested. The idea is to take
drm_mode_set_config_internal(), remove the "is this a legacy driver"
check, and whack the drm_atomic_legacy_backoff trickery at the end.
Since drm_atomic_legacy_backoff is for atomic commits only we need to
open-code it.

Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170406200256.26040-1-daniel.vetter@ffwll.ch

Atomic helpers really want this instead of the hacked-up legacy
backoff trick, which unfortunately prevents drivers from using their
own private drm_modeset_locks.

Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which
don't yet use the new atomic color mgmt/gamma table stuff. Would be
nice if they could switch over and just hook up
drm_atomic_helper_legacy_gamma_set() instead.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-13-daniel.vetter@ffwll.ch

This allows the driver to handle io_mem mappings on their own.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NNicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The scanout surface size is the smaller of max texture size and
max STDU size.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Most of the display servers today use a single surface to represent the
entire desktop even if it's stretched across multiple screens.

For vmwgfx with STDU, the maximum surface size is limited to the
maximum texture size on the host.  On a 2D VM, this limits our
ability to support configurations with more than one 4K monitor.

To get past this limitation, we will now allow using a large DMA buf
as the framebuffer, and take care of blitting contents from this DMA buf
to the display buffer.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Provide and document a reference implementation.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

The callbacks we need to provide to many resources are very similar, so
provide a simple resource type with a number of helpers for these
callbacks.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

This reverts commit 2d8e60e8 ("drm/vmwgfx: Replace numeric
parameter like 0444 with macro")

The commit belongs to the series of 1285 patches sent to LKML on
2016-08-02, it changes the representation of file permissions from the
octal value "0600" to "S_IRUSR | S_IWUSR".

The general consensus was that the changes does not increase
readability, quite the opposite; 0600 is easier to parse mentally than
S_IRUSR | S_IWUSR.

It also causes argument inconsistency, due to commit 04319d89
("drm/vmwgfx: Add an option to change assumed FB bpp") that added
another call to module_param_named() where the permissions are written
as 0600.
Signed-off-by: NØyvind A. Holm <sunny@sunbase.org>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

vmw_ldu_crtc_helper_commit() is not called if
drm_atomic_crtc_needs_modeset() decides nothing related to CRTC timing has
changed.

So a better place for this code is in vmw_ldu_primary_plane_atomic_update()
since we will need to update ld->fb every time the FB is updated.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Pinning fbdev's FB at the start of VRAM prevents X from pinning
its FB.  Since for ldu, the fb would be pinned anyway during a
mode set, just skip pinning it in fbdev.

This is not the best solution, but since ldu is not used much
anymore, it seems like a reasonable workaround.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

We can no longer make the assumption that vmw_stdu_update_st() will
be called when there's a valid display surface attached.  So
instead of using display_srf for width and height, make a record of
these paremeters when the screen target is first defined.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Now that the legacy path has been tested, turn on the
DRIVER_ATOMIC flag so user mode driver can start going through
the Atomic path.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>

Switch over to internal atomic API.  This completes the atomic
internal atomic switch for all the Display Units.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Switch over to using internal atomic API for mode set.

This removes the legacy set_config API, replacing it with
drm_atomic_helper_set_config().  The DRM helper will use various
vmwgfx-specific atomic functions to set a mode.

DRIVER_ATOMIC capability flag is not yet set, so the user mode
will still use the legacy mode set IOCTL.

v2:
* Avoid a clash between page-flip pinning and setcrtc pinning, modify
the page-flip code to use the page-flip helper and the atomic callbacks.
To enable this, we will need to add a wrapper around atomic_commit.

* Add vmw_kms_set_config() to work around vmwgfx xorg driver bug
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

1.  When unsetting a mode, num_connector should be set to zero
2.  The pixel_format field needs to be initialized as newer DRM internal
    functions checks this field
3.  Take the drm_modeset_lock_all() because vmw_fb_kms_detach() can
    change current mode
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

This connects the main state object check and commit function.

v2
* Use drm_atomic_helper_commit() rather than a vmwgfx-specific one
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>