The typical pattern of these lookups are
-Lookup
-Put on validate list if not already there.
-Unreference
And since we are the exclusive user of the context during lookup time,
we can be sure that the resource will stay alive during the sequence.
So avoid taking a reference during lookup, and also avoid unreferencing
when done. There are two users outside of command buffer validation and
those are refcounted explicitly.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

The typical pattern of these lookups are
-Lookup
-Put on validate list if not already there.
-Unreference
And since we are the exclusive user of the context during lookup time,
we can be sure that the resource will stay alive during the sequence.
So avoid taking a reference during lookup, and also avoid unreferencing
when done.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Make the process of looking up a buffer object and adding it to the
validation list reference-free unless when it's actually added to the
validation list where a single reference is taken.
This saves two locked atomic operations per command stream buffer object
handle lookup.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Identically to how we look up ttm base objects witout reference, provide
the same functionality to vmw user buffer objects which derive from them.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Adapt the validation code so that vmw_validation_add[res|bo] can be called
under an rcu read lock (non-sleeping) and with rcu-only protected resource-
or buffer object pointers.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Export ttm_bo_get_unless_zero() to be used when looking up buffer
objects that are removed from the lookup structure in the destructor.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

Typically when we look up objects under the rcu lock, we take a reference
to make sure the returned object pointer is valid.
Now provide a function to look up an object and instead of taking a
reference to it, keep the rcu lock held when returning the object pointer.
This means that the object pointer is valid as long as the rcu lock is
held, but the object may be doomed (its refcount may be zero). Any
persistent usage of the object pointer outside of the rcu lock requires
a reference to be taken using kref_get_unless_zero().
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Instead of generating user-space object handles based on a, possibly
processed, hash of the kernel address of the object, use idr to generate
and lookup those handles. This might improve somewhat on security since
we loose all connections to the object's kernel address. Also idr is
designed to do just this.

As a todo-item, since user-space handles are now generated in sequence,
we can probably use a much simpler hash function to hash them.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>

We were checking that the resource destructor matched that of the
intended object type, to make sure the looked up resource was of the
right type.

But we already have an object type check in place which makes sure the
resource is of the right type.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.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: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>

Replace instances of WARN_ON[_ONCE](!mutex_is_held()) with
lockdep_assert_held(). This makes sure the checking process actually
holds the mutex and also removes the checks from release builds
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>

With the new allocator this leads to less consumed memory for each
user-space command submission
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>

A common trait of these objects are that they are allocated during the
command validation phase and freed after command submission. Furthermore
they are accessed by a single thread only. So provide a simple unprotected
stack-like allocator from which these objects can be allocated. Their
memory is freed with the validation context when the command submission
is done.

Note that the mm subsystem maintains a per-cpu cache of single pages to
make single page allocation and freeing efficient.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Strip the old KMS helpers and use the new validation interface also in
the modesetting code.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com> #v1
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Strip the old execbuf validation functionality and use the new API instead.
Also use the new API for a now removed execbuf function that was called
from the kms code.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Allow selecting interruptible or uninterruptible waits to match
expectations of callers.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Isolate the functionality needed for reservation, validation and fencing
of vmwgfx buffer objects and resources and publish an API for this.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com> #v1

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: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

This is a new pull for drm-next on top of last weeks with the following
changes:
- Fixed 64 bit divide
- Fixed vram type on vega20
- Misc vega20 fixes
- Misc DC fixes
- Fix GDS/GWS/OA domain handling

Previous changes from last week:
amdgpu/kfd:
- Picasso (new APU) support
- Raven2 (new APU) support
- Vega20 enablement
- ACP powergating improvements
- Add ABGR/XBGR display support
- VCN JPEG engine support
- Initial xGMI support
- Use load balancing for engine scheduling
- Lots of new documentation
- Rework and clean up i2c and aux handling in DC
- Add DP YCbCr 4:2:0 support in DC
- Add DMCU firmware loading for Raven (used for ABM and PSR)
- New debugfs features in DC
- LVDS support in DC
- Implement wave kill for gfx/compute (light weight reset for shaders)
- Use AGP aperture to avoid gart mappings when possible
- GPUVM performance improvements
- Bulk moves for more efficient GPUVM LRU handling
- Merge amdgpu and amdkfd into one module
- Enable gfxoff and stutter mode on Raven
- Misc cleanups

Scheduler:
- Load balancing support
- Bug fixes

ttm:
- Bulk move functionality
- Bug fixes

radeon:
- Misc cleanups
Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180920150438.12693-1-alexander.deucher@amd.com

R-Car DU changes for v4.20

The pull request mostly contains updates to the R-Car DU driver, notably
support for interlaced modes on Gen3 hardware, support for the LVDS output on
R8A77980, and a set of miscellaneous bug fixes. There are also two SPDX
conversion patches for the drm shmobile and panel-lvds drivers, as well as an
update to MAINTAINERS to add Kieran Bingham as a co-maintainer for the DU
driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3273568.LdoAI77IYW@avalon

Temporary disable UVD/VCE block if is virtual device
Signed-off-by: Frank Min <Frank.Min@amd.com>
Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Add sriov capability detection for vega20, then can check if device is
virtual device.
Signed-off-by: Frank Min <Frank.Min@amd.com>
Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm-misc-next for 4.20:

UAPI Changes:
- None

Cross-subsystem Changes:
- None

Core Changes:
- Allow drivers to disable features with per-device granularity (Ville)
- Use EOPNOTSUPP when iface/feature is unsupported instead of
  EINVAL/errno soup (Chris)
- Simplify M/N DP quirk by using constant N to limit size of M/N (Shawn)
- add quirk for LG LP140WF6-SPM1 eDP panel (Shawn)

Driver Changes:
- i915/amdgpu: Disable DRIVER_ATOMIC for older/unsupported devices (Ville)
- sun4i: add support for R40 HDMI PHY (Icenowy)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20180919200218.GA186644@art_vandelay

We don't need that in the per ASIC code.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Stops crashing on SI.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

That only worked by pure coincident. Completely remove the shifting and
always apply correct PAGE_SHIFT.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Don't grab the reservation lock any more and simplify the handling quite
a bit.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

It shouldn't add much overhead and we should make sure that critical
VRAM content is always restored.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

They aren't directly used by the hardware.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Even when GPU recovery is disabled we could run into a manually
triggered recovery.

v2: keep accidental removed comments
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

We are going to need this for recoverable page fault handling and it
makes shadow handling during GPU reset much more easier.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

DC doesn't seem to have a fallback path either.

So when interrupts doesn't work any more we are pretty much busted no
matter what.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

With OD settings applied, the clock table will be updated accordingly.
We need to retrieve the new clock tables then.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

With the latest SMC fw, we are able to get the voltage value for
specific frequency point. So, we update the OD relates to take
absolute voltage instead of offset.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Update the conditions to judge whether an OD feature
should be supported on vega20.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

vega20 should use umc_info v3_3 instead of v3_1. There are
serveral versions of umc_info for vega series. Compared to
various versions of these structures, vram_info strucure is
unified for vega series. The patch switch to query mem_type
from vram_info structure for all the vega series dGPU.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

atomfirmware has structure changes in varm_info. Updated it
to the latest one.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
255 is done. Since it is always false, change the signature of this
function to use an `int` instead, which match the type used in caller:
`radeon_atom_hw_i2c_xfer`.

Fix the following warning triggered with W=1:

  CC [M]  drivers/gpu/drm/radeon/atombios_i2c.o
  drivers/gpu/drm/radeon/atombios_i2c.c: In function ‘radeon_process_i2c_ch’:
  drivers/gpu/drm/radeon/atombios_i2c.c:71:11: warning: comparison is always false due to limited range of data type [-Wtype-limits]
   if (num > ATOM_MAX_HW_I2C_READ) {
           ^
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

adev->gfx.rlc has the values from rlc_hdr already processed by
le32_to_cpu.  Using the rlc_hdr values on big-endian machines causes
a kernel Oops due to writing well outside of the array (0x24000000
instead of 0x24).
Signed-off-by: A. Wilcox <AWilcox@Wilcox-Tech.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>