Merge branch 'linux-4.21' of git://github.com/skeggsb/linux into drm-next

Mostly just initial support for Turing TU104/TU106 chipsets.  Support
for TU102 is missing as I don't yet have HW, but it should be trivial
to add in later in the merge window (in theory).

It's a bit of a rough first pass that'll get improved in future
releases as a finish figuring out some of the other HW changes, but
it's good enough as it stands for modesetting and suspend/resume etc.

Acceleration bring-up is incomplete due to NVIDIA not yet having
provided FW images for me to use, though command submission and copy
engines are functional already.

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <skeggsb@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7KmfcQqZcx+wh_1UKjTovp4PH_5UVMfeyxUu-M9WLZfw@mail.gmail.com

Merge tag 'drm/tegra/for-4.21-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next

drm/tegra: Changes for v4.21-rc1

These changes contain a couple of minor fixes for host1x and the Falcon
library in Tegra DRM. There are also a couple of missing pieces that
finally enable support for host1x, VIC and display on Tegra194. I've
also added a patch that enables audio over HDMI using the SOR which has
been tested, and works, on both Tegra186 and Tegra194.

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thierry Reding <thierry.reding@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207134712.32683-1-thierry.reding@gmail.com

Merge branch 'drm-next-4.21' of git://people.freedesktop.org/~agd5f/linux into drm-next

[airlied: make etnaviv build again]

amdgpu:
- DC trace support
- More DC documentation
- XGMI hive reset support
- Rework IH interaction with KFD
- Misc fixes and cleanups
- Powerplay updates for newer polaris variants
- Add cursor plane update fast path
- Enable gpu reset by default on CI parts
- Fix config with KFD/HSA not enabled

amdkfd:
- Limit vram overcommit
- dmabuf support
- Support for doorbell BOs

ttm:
- Support for simultaneous submissions to multiple engines

scheduler:
- Add helpers for hw with preemption support

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207233119.16861-1-alexander.deucher@amd.com

drm/amd/display: Add fast path for cursor plane updates

[Why]
Legacy cursor plane updates from drm helpers go through the full
atomic codepath. A high volume of cursor updates through this slow
code path can cause subsequent page-flips to skip vblank intervals
since each individual update is slow.

This problem is particularly noticeable for the compton compositor.

[How]
A fast path for cursor plane updates is added by using DRM asynchronous
commit support provided by async_check and async_update. These don't do
a full state/flip_done dependency stall and they don't block other
commit work.

However, DC still expects itself to be single-threaded for anything
that can issue register writes. Screen corruption or hangs can occur
if write sequences overlap. Every call that potentially perform
register writes needs to be guarded for asynchronous updates to work.
The dc_lock mutex was added for this.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106175

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Enable GPU recovery by default for CI

I retested Bonaire (gfx7 dGPU) and it works fine.

Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/display: Fix duplicating scaling/underscan connector state

[Why]
These properties aren't being carried over when the atomic state.
This tricks atomic check and commit tail into performing underscan
and scaling operations when they aren't needed.

With the patch that forced scaling/RMX_ASPECT on by default this
results in many unnecessary surface updates and hangs under certain
conditions.

[How]
Duplicate the properties.

Fixes: 91b66c47ba34 ("drm/amd/display: Set RMX_ASPECT as default")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/display: Fix unintialized max_bpc state values

[Why]
If the "max bpc" isn't explicitly set in the atomic state then it
have a value of 0. This has the correct behavior of limiting a panel
to 8bpc in the case where the panel supports 8bpc. In the case of eDP
panels this isn't a true assumption - there are panels that can only
do 6bpc.

Banding occurs for these displays.

[How]
Initialize the max_bpc when the connector resets to 8bpc. Also carry
over the value when the state is duplicated.

Bugzilla: https://bugs.freedesktop.org/108825
Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector property")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Revert "drm/amd/display: Set RMX_ASPECT as default"

This reverts commit 91b66c47ba3468f7882ea4a84d5e0e0c186b638f.

Forcing RMX_ASPECT as default uses the preferred/native mode's timings
for any mode the user selects and scales the image. This provides a
a consistently nicer result in the case where the selected mode's
refresh rate matches the native mode's refresh but this isn't always
the case.

For example, if the monitor is 1080p@144Hz and the preferred mode is
60Hz then even if the user selects 1080p@144Hz as their selected mode
they'll get 1080p@60Hz.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Fix stub function name

This function was renamed in a previous commit. Update the stub
function name for builds with CONFIG_HSA_AMD disabled.

Fixes: 611736d8447c ("drm/amdgpu: Add KFD VRAM limit checking")
Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/nouveau/ce/tu106: initial support

Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/tu106: initial support

Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp/tu106: initial support

Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dma/tu106: initial support

Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm/tu106: initial support

Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pmu/tu106: initial support

Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fault/tu106: initial support

Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bar/tu106: initial support

Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/mmu/tu106: initial support

Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/ltc/tu106: initial support

Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/tu106: initial support

Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/imem/tu106: initial support

Appears to be compatible with NV50.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/tmr/tu106: initial support

Appears to be compatible with GK20A.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bus/tu106: initial support

Appears to be compatible with GF100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/mc/tu106: initial support

Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fuse/tu106: initial support

Appears to be compatible with GM107.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/i2c/tu106: initial support

Appears to be compatible with GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/gpio/tu106: initial support

Appears to be compatible with GK104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/ibus/tu106: initial support

Appears to be compatible with GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/top/tu106: initial support

Appears to be compatible with GK104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/devinit/tu106: initial support

Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios/tu106: initial support

No real surprised here so far.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pci/tu106: initial support

Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/core: recognise TU106

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/core: increase maximum number of nvdec instances to 3

RTX2070 appears to have 3 copies of the engine.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/tu104: initial support

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/ce/tu104: initial support

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/tu104: initial support

Various different bits and pieces vs GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp/tu104: initial support

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dma/tu104: initial support

Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm/tu104: initial support

Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pmu/tu104: initial support

Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fault/tu104: initial support

New registers.

Currently uncertain how exactly to mask fault buffer interrupts.  This will
likely be corrected at around the same time as the new MC interrupt stuff
has been properly figured out and implemented.

For the moment, it shouldn't matter too much.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bar/tu104: initial support

New registers.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/mmu/tu104: initial support

New flush method.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/ltc/tu104: initial support

Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/tu104: initial support

Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/imem/tu104: initial support

Appears to be compatible with NV50.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/tmr/tu104: initial support

Appears to be compatible with GK20A.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bus/tu104: initial support

Appears to be compatible with GF100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/mc/tu104: initial support

Things are a bit different here on Turing, and will require further changes
yet once I've investigated them more thoroughly.

For now though, the existing GP100 code is compatible enough with one small
hack to forward on fault buffer interrupts.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fuse/tu104: initial support

Appears to be compatible with GM107.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/i2c/tu104: initial support

Appears to be compatible with GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/gpio/tu104: initial support

Appears to be compatible with GK104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/ibus/tu104: initial support

Appears to be compatible with GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/top/tu104: initial support

Appears to be compatible with GK104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/devinit/tu104: initial support

The GPU executes DEVINIT itself now, which makes our lives a bit easier.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios/tu104: initial support

No real surprises here so far.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pci/tu104: initial support

Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/core: recognise TU104

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50-: allow more flexibility with lut formats

Will be required for Turing.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: remove left-over struct member

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gv100: return work submission token in channel ctor args

The token will also contain runlist ID on Turing, so instead expose it as
an opaque value from NVKM so the client doesn't need to care.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gv100: allocate method buffer

The GPU saves off some stuff to the address specified in this part of RAMFC
when the channel faults, so we should probably point it at a valid address.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gm200-: read pbdma count more directly

The trick we used (and still use for older GPUs) doesn't work on Turing.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gk104-: virtualise pbdma enable function

Turing will require different code.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gk104-: group pbdma functions together

We're about to be adding more of them.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gk104-: separate runlist building from committing to hw

We will need to bash different registers on Turing.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gk104-: support enabling privileged ce functions

Will be used by SVM code to allow direct (without going through MMU) memcpy
using the GPU copy engines.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gk104-: return channel instance in ctor args

Will be used to match fault buffer entries with a channel.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/gf100-: call into BAR to reset BARs after MMU fault

This is needed for Turing, but we're supposed to wait for completion after
re-writing the value on older GPUs anyway.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp/gv100: fix name of window channels in debug output

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/mmu: add more general vmm free/node handling functions

Aside from being a nice cleanup, these will to allow the upcoming direct
page mapping interfaces to play nicely with normal mappings.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fault: add explicit control over fault buffer interrupts

The GPU will continually fire interrupts while a fault buffer GET != PUT,
and to stop the spurious interrupts while the handler does its thing, we
were disabling the fault buffer temporarily.

This is not actually a great idea to begin with, and made worse by Volta
resetting GET/PUT when it's reactivated.  So, let's not do that.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fault: store get/put pri address in nvkm_fault_buffer

Will allow more shared fault buffer handling code between Pascal/Volta.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fault: remove manual mapping of fault buffers into BAR2

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/imem/nv50: support pinning objects in BAR2 and returning address

Various structures are accessed by the GPU through BAR2 for some reason
on newer GPUs.  This commit makes it more convenient to handle.

Will be used for GP100- fault buffers, and GV100- fault method buffers.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/tmr: detect stalled gpu timer and break out of waits

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/devinit/gm200-: export function to upload+execute PMU/PRE_OS

Will be used for Turing.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios: translate USB-C connector type

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios: translate additional memory types

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/core: support multiple nvdec instances

Turing GPUs can have more than one.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/drm/nouveau: Don't forget to label dp_aux devices

This makes debugging with DP tracing a lot harder to interpret, so name
each i2c based off the name of the encoder that it's for

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/drm/nouveau: Check rc from drm_dp_mst_topology_mgr_resume()

We need to actually make sure we check this on resume since otherwise we
won't know whether or not the topology is still there once we've
resumed, which will cause us to still think the topology is connected
even after it's been removed if the removal happens mid-suspend.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: Add size to vbios.rom file in debugfs

With this, nvbios /sys/kernel/debug/dri/*/vbios.rom now works!

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: Add strap_peek to debugfs

Since we already expose the vbios.rom file here, why not also expose the
strap_peek?

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/amdgpu/powerplay: Add special avfs cases for some polaris asics (v3)

Add special avfs handling for some polaris variants.

v2: fix copy paste typo.
v3: fix asic rid check

Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: remove set but not used variable 'grbm_soft_reset'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function 'gfx_v8_0_pre_soft_reset':
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:4950:27: warning:
 variable 'srbm_soft_reset' set but not used [-Wunused-but-set-variable]

drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function 'gfx_v8_0_post_soft_reset':
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:5054:27: warning:
 variable 'srbm_soft_reset' set but not used [-Wunused-but-set-variable]

It never used since introduction in commit d31a501ead7f ("drm/amdgpu: add
pre_soft_reset ip func") and e4ae0fc33631 ("drm/amdgpu: implement
gfx8 post_soft_reset")

Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Limit vm max ctx number to 4096

driver need to reserve resource for each ctx for
some hw features. so add this limitation.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: bypass RLC init under sriov for Tonga (v2)

RLC will go wrong in soft_reset under sriov

Workaroound: only need to init RLC csb, and skip RLC stop, reset, start
    this is because host-driver has already done full initialization on RLC

v2: squash in build fix

Signed-off-by: Tiecehng Zhou <Tiecheng.Zhou@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: move IV prescreening into the GMC code

The GMC/VM subsystem is causing the faults, so move the handling here as
well.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: remove VM fault_credit handling

printk_ratelimit() is much better suited to limit the number of reported
VM faults.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: send IVs to the KFD only after processing them v3

This allows us to filter out VM faults in the GMC code.

v2: don't filter out all faults
v3: fix copy&paste typo, send all IV to the KFD, don't change message level

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdkfd: Add support for doorbell BOs

This allows user mode to map doorbell pages into GPUVM address space.
That way GPUs can submit to user mode queues (self-dispatch).

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdkfd: Add DMABuf import functionality

This is used for interoperability between ROCm compute and graphics
APIs. It allows importing graphics driver BOs into the ROCm SVM
address space for zero-copy GPU access.

The API is split into two steps (query and import) to allow user mode
to manage the virtual address space allocation for the imported buffer.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdkfd: Add NULL-pointer check

top_dev->gpu is NULL for CPUs. Avoid dereferencing it if NULL.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Add KFD VRAM limit checking

We don't want KFD processes evicting each other over VRAM usage.
Therefore prevent overcommitting VRAM among KFD applications with
a per-GPU limit. Also leave enough room for page tables on top
of the application memory usage.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Eric Huang <JinHuiEric.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Workaround build failure due to trace conflict

Avoid including mmu_context.h in amdgpu_amdkfd.h since that may be
included in other header files that define traces. This leads to
conflicts due to traces defined in other headers included via
mmu_context.h.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/powerplay: rv dal-pplib interface refactor powerplay part

[WHY] clarify dal input parameters to pplib interface, remove
un-used parameters. dal knows exactly which parameters needed
and their effects at pplib and smu sides.

current dal sequence for dcn1_update_clock to pplib:

1.smu10_display_clock_voltage_request for dcefclk
2.smu10_display_clock_voltage_request for fclk
3.phm_store_dal_configuration_data {
  set_min_deep_sleep_dcfclk
  set_active_display_count
  store_cc6_data --- this data never be referenced

new sequence will be:

1. set_display_count  --- need add new pplib interface
2. set_min_deep_sleep_dcfclk -- new pplib interface
3. set_hard_min_dcfclk_by_freq
4. set_hard_min_fclk_by_freq

after this code refactor, smu10_display_clock_voltage_request,
phm_store_dal_configuration_data will not be needed for rv.

[HOW] step 1: add new functions at pplib interface
      step 2: add new functions at amdgpu dm and dc

Signed-off-by: hersen wu <hersenxs.wu@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Skip ring soft recovery when fence was NULL

amdgpu_ring_soft_recovery would have Call-Trace,
when s_fence->parent was NULL inside amdgpu_job_timedout.
Check fence first, as drm_sched_hw_job_reset did.

Signed-off-by: Wentao Lou <Wentao.Lou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/psp: Destroy psp ring when doing gpu reset

PSP ring need to be destroy before starting reinit for vf.
This patche move it from hypervisor driver into guest.

Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Signed-off-by: Frank Min <Frank.Min@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>