The parameter file_page_offset is a constant shared by all drivers. Just
replace it with the constant itself.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Most TTM drivers define the constant DRM_FILE_PAGE_OFFSET of the same
value. The only exception is vboxvideo, which is being converted to the
new offset by this patch. Unifying the constants in a single place
simplifies the driver code.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

instead of relying on intel_iommu_enabled, use the fact that the
dma_map_ops::map_page != dma_direct_map_page.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initially set to 64 bits.

Cc: <stable@vger.kernel.org>
Fixes: 0d00c488: ("drm/vmwgfx: Fix the driver for large dma addresses")
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

This is only used by drm_irq_install(), which is an optional helper.
For legacy pci devices this is required (due to interrupt sharing without
msi/msi-x), and just making this the default exactly matches the behaviour
of all existing drivers using the drm_irq_install() helpers. In case that
ever becomes wrong drivers can roll their own irq handling, as many
drivers already do (for other reasons like needing a threaded interrupt
handler, or having an entire pile of different interrupt sources).

v2: Rebase

v3: Improve commit message (Emil)

Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129104248.26607-3-daniel.vetter@ffwll.ch

If a non-legacy driver calls these it's valid to assume there is
interrupt support. The flag is really only needed for legacy drivers,
which control IRQ enabling/disabling through the DRM_IOCTL_CONTROL
legacy IOCTL.

Also remove all the flag usage from non-legacy drivers.

v2: Review from Emil:
- improve commit message
- I forgot hibmc, fix that

Cc: linux-arm-kernel@lists.infradead.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: virtualization@lists.linux-foundation.org
Cc: spice-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129104248.26607-1-daniel.vetter@ffwll.ch

Just use a simple if/else chain to select the DMA mode.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

Since Linux 4.21 we merged the swiotlb ops into the DMA direct ops,
so they would always have a the sync_single methods.  But late in
the cicle we also removed the direct ops entirely, so we'd see NULL
DMA ops.  Switch vmw_dma_select_mode to only detect swiotlb presence
using swiotlb_nr_tbl() instead.

Fixes: 55897af6 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code")
Fixes: 356da6d0 ("dma-mapping: bypass indirect calls for dma-direct")
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

intel_iommu_enabled is defined as always false for !CONFIG_INTEL_IOMMU,
so remove the ifdefs around it.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

The driver depends on CONFIG_X86 so these are dead code.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

Avoid expensive indirect calls in the fast path DMA mapping
operations by directly calling the dma_direct_* ops if we are using
the directly mapped DMA operations.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
Tested-by: NJesper Dangaard Brouer <brouer@redhat.com>
Tested-by: NTony Luck <tony.luck@intel.com>

With the new validation code, a malicious user-space app could
potentially submit command streams with enough buffer-object and resource
references in them to have the resulting allocated validion nodes and
relocations make the kernel run out of GFP_KERNEL memory.

Protect from this by having the validation code reserve TTM graphics
memory when allocating.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
---
v2: Removed leftover debug printouts

This fixes a layout update race condition. We make sure
the crtc mutex is locked before we dereference crtc->state. Otherwise the
state might change under us.

Since now we're already holding the crtc mutexes when reading the gui
coordinates, protect them with the crtc mutexes rather than with the
requested_layout mutex.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Commit e61d98d8 ("x64, x2apic/intr-remap: Intel vt-d, IOMMU
code reorganization") moved dma_remapping.h from drivers/pci/ to
current place. It is entirely VT-d specific, but uses a generic
name. This merges dma_remapping.h with include/linux/intel-iommu.h
and removes dma_remapping.h as the result.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Sohil Mehta <sohil.mehta@intel.com>
Suggested-by: NChristoph Hellwig <hch@infradead.org>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NLiu, Yi L <yi.l.liu@intel.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Make sure that the global BO state is always correctly initialized.

This allows removing all the device code to initialize it.

v2: fix up vbox (Alex)
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

As the name says we only need one global instance of ttm_mem_global.

Drop all the driver initialization and just use a single exported
instance which is initialized during BO global initialization.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This field was previously used to prevent a lookup of a resource before its
constructor had run to its end. This was mainly intended for an interface
that is now removed that allowed looking up a resource by its device id.

Currently all affected resources are added to the lookup mechanism (its
TTM prime object is initialized) late in the constructor where it's OK to
look up the resource.

This means we can change the device resource_lock to an ordinary spinlock
instead of an rwlock and remove a locking sequence during lookup.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

No other driver is using this functionality so move it out of TTM and
into the vmwgfx driver. Update includes and remove exports.
Also annotate to remove false static analyzer lock balance warnings.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

New ioctls DRM_VMW_GB_SURFACE_CREATE_EXT and DRM_VMW_GB_SURFACE_REF_EXT
are added which support 64-bit wide svga device surface flags, quality
level and multisample pattern.
Signed-off-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NCharmaine Lee <charmainel@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

A boolean flag in device private structure to specify if the device
support SM4_1.
Signed-off-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

The device exposes a new capability register. Add support for it.
Signed-off-by: NNeha Bhende <bhenden@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

This change updates the device headers to the latest device version.
Where renaming affects the existing code, it's updated accordingly.
Signed-off-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

To avoid race condition between update_layout ioctl and modeset ioctl
for access to gui_x/y positioning added a new mutex
requested_layout_mutex.

Also used drm_for_each_connector_iter to iterate over connector list.
Signed-off-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

Initially vmware buffer objects were only used as DMA buffers, so the name
DMA buffer was a natural one. However, currently they are used also as
dumb buffers and MOBs backing guest backed objects so renaming them to
buffer objects is logical. Particularly since there is a dmabuf subsystem
in the kernel where a dma buffer means something completely different.

This also renames user-space api structures and IOCTL names
correspondingly, but the old names remain defined for now and the ABI
hasn't changed.

There are a couple of minor style changes to make checkpatch happy.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

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

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>

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

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>

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>

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>

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>

This is an extension of Commit 7c20d213 ("drm/vmwgfx: Work
around mode set failure in 2D VMs")

With Wayland desktop and atomic mode set, during the mode setting
process there is a moment when two framebuffer sized surfaces
are being pinned.  This was not an issue with Xorg.

Since this only happens during a mode change, there should be no
performance impact by increasing allowable mem_size.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Cc: stable@vger.kernel.org

We're not allowed to change the upstream version of the drm_irq_install
function to be able to incorporate threaded irqs. So roll our own irq
install- and uninstall functions instead of relying on the drm core ones.
Signed-off-by: NThomas Hellstrom <thellstrom@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>

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 magic switching between proper pci driver and shadow-attach isn't
useful anymore since there's no ums+kms drivers left. Let's split this
up properly, calling pci_register_driver for kms drivers and renaming
the shadow-attach init to drm_legacy_pci_init/exit.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-6-daniel.vetter@ffwll.ch

The only special-case is pci devices, and we can easily handle this in
the core. Do so and drop a pile of boilerplate from drivers.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-5-daniel.vetter@ffwll.ch

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>

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>

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>