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: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NZack Rusin <zackr@vmware.com>
Fixes: 8772c0bb ("drm/vmwgfx: Cleanup pci resource allocation")
Link: https://patchwork.freedesktop.org/patch/msgid/20210408172245.673785-1-zackr@vmware.com

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: 8772c0bb ("drm/vmwgfx: Cleanup pci resource allocation")
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210128173756.121525-1-zackr@vmware.com
(cherry picked from commit 75ec69c7)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

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: be4f77ac ("drm/vmwgfx: Cleanup fifo mmio handling")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NZack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YA6FMboLhnE3uSvb@mwanda
(cherry picked from commit f3ebd4e6)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

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: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Roland Scheidegger <sroland@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201211162942.3399050-2-daniel.vetter@ffwll.ch

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: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Roland Scheidegger <sroland@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201211162942.3399050-1-daniel.vetter@ffwll.ch

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: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/414044/?series=85516&rev=2

Instead of doing it in multiple spots lets centralize the code
to handle pci resources. This also cleans up the error
handling a bit and will make it a lot easier to add additional
svga versions to the driver.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Link: https://patchwork.freedesktop.org/patch/414040/?series=85516&rev=2

Going forward the svga device might reuse mmio for general
register accesses, in order to prepare for that we need to
cleanup our naming and handling of fifo specific mmio reads
and writes. As part of this work lets switch to managed
mapping of the fifo mmio to make the error handling cleaner.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Link: https://patchwork.freedesktop.org/patch/414045/?series=85516&rev=2

To cleanup some of the error handling and prepare for some
other work lets switch to a managed drm device. It will
let us get a better handle on some of the error paths.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Link: https://patchwork.freedesktop.org/patch/414039/?series=85516&rev=2

Before drm got helpers for removing conflicting pci framebuffer devices
we implemented something known as "stealth" mode which allowed vmwgfx
to run even if it couldn't reserve pci resources. We can just switch
to regular drm helpers instead of keeping the stealth mode alive as
it makes our code a lot cleaner.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Link: https://patchwork.freedesktop.org/patch/414043/?series=85516&rev=2

Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
drm_device.dev. No functional changes.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NZack Rusin <zackr@vmware.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Roland Scheidegger <sroland@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201201103542.2182-20-tzimmermann@suse.de

ttm_module.h deals with internals of TTM and should never
be include outside of it.

v2: also move the file around
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/404885/

Only the following drivers aren't converted:
- amdgpu, because of the driver_feature mangling due to virt support.
  Subsequent patch will address this.
- nouveau, because DRIVER_ATOMIC uapi is still not the default on the
  platforms where it's supported (i.e. again driver_feature mangling)
- vc4, again because of driver_feature mangling
- qxl, because the ioctl table is somewhere else and moving that is
  maybe a bit too much, hence the num_ioctls assignment prevents a
  const driver structure.
- arcpgu, because that is stuck behind a pending tiny-fication series
  from me.
- legacy drivers, because legacy requires non-const drm_driver.

Note that for armada I also went ahead and made the ioctl array const.

Only cc'ing the driver people who've not been converted (everyone else
is way too much).

v2: Fix one misplaced const static, should be static const (0day)

v3:
- Improve commit message (Sam)
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Cc: kernel test robot <lkp@intel.com>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201104100425.1922351-5-daniel.vetter@ffwll.ch

Since commit 9a40401c ("lib/scatterlist: Do not limit max_segment to
PAGE_ALIGNED values") the max_segment input to sg_alloc_table_from_pages()
does not have to be any special value. The new algorithm will always
create something less than what the user provides. Thus eliminate this
confusing constant.

- vmwgfx should use the HW capability, not mix in the OS page size for
  calling dma_set_max_seg_size()

- i915 uses i915_sg_segment_size() both for sg_alloc_table_from_pages
  and for some open coded sgl construction. This doesn't change the value
  since rounddown(size, UINT_MAX) == SCATTERLIST_MAX_SEGMENT

- drm_prime_pages_to_sg uses it as a default if max_segment is zero,
  UINT_MAX is fine to use directly.

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Qian Cai <cai@lca.pw>
Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Suggested-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/0-v1-44733fccd781+13d-rm_scatterlist_max_jgg@nvidia.com

It should be able to handle all cases now.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NMadhav Chauhan <madhav.chauhan@amd.com>
Tested-by: NHuang Rui <ray.huang@amd.com>
Link: https://patchwork.freedesktop.org/patch/397083/?series=83051&rev=1

Provide the necessary parameters by all drivers and use the new pool alloc
when no driver specific function is provided.

v2: fix the GEM VRAM helpers
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NMadhav Chauhan <madhav.chauhan@amd.com>
Tested-by: NHuang Rui <ray.huang@amd.com>
Link: https://patchwork.freedesktop.org/patch/397081/?series=83051&rev=1

It is the sole user of this.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/393498/

Make it more clear what the resource manager function
does and nuke the wrapper function.

v2: nuke the wrapper
v3: fix typo in radeon, rebased
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2)
Link: https://patchwork.freedesktop.org/patch/393914/

Stop using TTM_PL_FLAG_NO_EVICT.

v2: fix unconditional pinning
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Link: https://patchwork.freedesktop.org/patch/391601/?series=81973&rev=1

Instead of letting TTM make an educated guess based on
some mask all drivers should just specify what caching
they want for their CPU mappings.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/390207/

As far as I can tell this was never used either and we just
always fallback to the order cached > wc > uncached anyway.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/390142/

I fixed the init path, but missed the cleanup path.

Fixes: e0830704 ("drm/vmwgfx: takedown vram manager")
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200810054110.4192239-1-airlied@gmail.com

This name makes a lot more sense, since these are about managing
driver resources rather than just memory ranges.
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-59-airlied@gmail.com

This converts vmwgfx over to using an interface to set the
in use and check the in use flag.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-57-airlied@gmail.com

This makes it easier to move these to a driver allocated system
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-47-airlied@gmail.com

Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-43-airlied@gmail.com

Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-34-airlied@gmail.com

Don't bother returning EBUSY, nobody cares enough,
if the driver has a problem, it should deal with it.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-29-airlied@gmail.com

Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-22-airlied@gmail.com

Split out the vram thp init path vs the range manager init.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-21-airlied@gmail.com

Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.

v2: keep extra system domain handling
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/382082/

Just drop the argument from this.

This does ask the question if this is the function vmwgfx
should be using or should it be doing an evict all like
the other drivers.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NZack Rusin <zackr@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200728034254.20114-1-airlied@gmail.com

The function always returns zero (success). Ideally we'll remove it all
together - although that's requires a little more work.

For now, we can drop the return type and simplify the drm core code
surrounding it.

v2: remove redundant assignment (Sam)

Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200530124640.4176323-1-emil.l.velikov@gmail.com

Start using the helpers that align buffer object user-space addresses and
buffer object vram addresses to huge page boundaries.
This is to improve the chances of allowing huge page-table entries.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NThomas Hellstrom (VMware) <thomas_os@shipmail.org>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Acked-by: NChristian König <christian.koenig@amd.com>

Virtual device added new register for suggested GB memory, read the new
register when available.
Signed-off-by: NDeepak Rawat <drawat.floss@gmail.com>
Reviewed-by: NThomas Hellström (VMware) <thomas_os@shipmail.org>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

A new enum to represent new SM5 graphics context capability in vmwgfx.

v2: use new correct cap bits (merged several later commits into it).
Signed-off-by: NDeepak Rawat <drawat.floss@gmail.com>
Signed-off-by: NThomas Hellström (VMware) <thomas_os@shipmail.org>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

Instead of having different bool in device private to represent
incremental graphics context capabilities, add a new sm type enum.

v2: Use enum instead of bit flag.

v3: Incorporated review comments.
Signed-off-by: NDeepak Rawat <drawat.floss@gmail.com>
Reviewed-by: NThomas Hellström (VMware) <thomas_os@shipmail.org>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

Virtual device consider SVGA_CAP_DX and SVGA3D_DEVCAP_DXCONTEXT
independent of each other. Some of the commands in cmd_buf depends on
SVGA_CAP_DX, so better to check for that as well.
Signed-off-by: NDeepak Rawat <drawat.floss@gmail.com>
Reviewed-by: NThomas Hellström (VMware) <thomas_os@shipmail.org>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Signed-off-by: NRoland Scheidegger <sroland@vmware.com>

TTM doesn't yet fully support mapping of DMA memory when SEV is active,
so in that case, refuse DMA operation. For guest-backed object operation
this means 3D acceleration will be disabled. For host-backed, VRAM will be
used for data transfer between the guest and the device.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

When we refuse DMA from system pages for whatever reason, we don't
handle that correctly when guest-backed objects was enabled.
Since guest-backed objects by definition require DMA to and from
system pages, disable all functionality that relies on them.
That basically amounts to 3D acceleration and screen targets.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>