798805 Commits

Author SHA1 Message Date
Dave Airlie
02c4fb0210 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
2018-12-13 10:25:25 +10:00
Dave Airlie
29a1da27c4 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.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlwKeT4THHRyZWRpbmdA
 bnZpZGlhLmNvbQAKCRDdI6zXfz6zodDYEAC66KbXHSbu1Q4Y4gWA36bDS16F1MS6
 rPb0j0WkhsGejuIS5xbays1OSgtraQSMF7g1CE/kBBmiQj+LsEh/+g4QKdTIxCWn
 rjsM1ak3Z4uKnHgWt+mpR9wIg2WgnqzzJGVWHbX6mzL9Et5PWhqPtfgqqgUhiGJ9
 p/EqbSq0MeHgYs9z3F31P9dtnWrWrrTnlbajpEPeU+fvzBNnDLP75azZDfzE06qt
 d3y3e1clSQFHbEPuqqGzZyfs/aM4Fu/lLnJwgUd0bq5fVPLj7RQ8UUFz+ZmRb9py
 Z25Mu/Lnm6pw/FUGD50NYWuaseevLT2hmPAw2b2A95ST77TLsLRubu8wREF321GN
 yiAECjUNQhrfRX7NQ23ZlRDY5ExOWu57NRCYRleI3atDv+8/Is8faA60+s1EItyv
 rTB05GPPixFD/GZ5p2IR0rvUFc4B1Axdbbj2SDY/Ns/tB/he52YJaR1h+SjFaJ2O
 OBrErL46S/CTBIt9YLMnT1HjX8XPdZHR0YYZzs7EJ3pMa1hyIjTlbr/wb0VwzaTp
 H8j9+mlBTjD/iLW1QfSui/su+59r0DpsTy4n0MPrVC8cvpwSNDVw2u6x3TqAMxKw
 r0nb7vl9xF08Fx1ZviCkJ6tBnIWoLUzXqondNQQygwv7tH4dRb2elOTPhKPh3dUV
 OZNbiDTYdmH+6Q==
 =WHND
 -----END PGP SIGNATURE-----

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
2018-12-13 10:16:25 +10:00
Dave Airlie
e7df065a69 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
2018-12-13 10:06:34 +10:00
Nicholas Kazlauskas
674e78acae 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>
2018-12-12 15:32:10 -05:00
Andrey Grodzovsky
fc42d47ce0 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>
2018-12-12 14:26:40 -05:00
Nicholas Kazlauskas
922454c2e7 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>
2018-12-11 15:52:36 -05:00
Nicholas Kazlauskas
65276f2beb 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>
2018-12-11 15:52:36 -05:00
Nicholas Kazlauskas
28c5946930 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>
2018-12-11 15:43:24 -05:00
Kuehling, Felix
4f01b73e5a 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>
2018-12-11 13:40:58 -05:00
Ben Skeggs
8ff01abccc drm/nouveau/ce/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:01 +10:00
Ben Skeggs
1b2a5aff35 drm/nouveau/fifo/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:01 +10:00
Ben Skeggs
7f7bc32e23 drm/nouveau/disp/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:01 +10:00
Ben Skeggs
1a38496cdd drm/nouveau/dma/tu106: initial support
Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:00 +10:00
Ben Skeggs
bb1e3ff701 drm/nouveau/therm/tu106: initial support
Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:00 +10:00
Ben Skeggs
25a46a4a95 drm/nouveau/pmu/tu106: initial support
Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:00 +10:00
Ben Skeggs
f5459f34f5 drm/nouveau/fault/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:00 +10:00
Ben Skeggs
340e96a7c3 drm/nouveau/bar/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
70ec09080d drm/nouveau/mmu/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
13f91e8e5a drm/nouveau/ltc/tu106: initial support
Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
cfcfb6d0a3 drm/nouveau/fb/tu106: initial support
Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
75794c4124 drm/nouveau/imem/tu106: initial support
Appears to be compatible with NV50.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
2fedee302d drm/nouveau/tmr/tu106: initial support
Appears to be compatible with GK20A.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:58 +10:00
Ben Skeggs
25e6a89076 drm/nouveau/bus/tu106: initial support
Appears to be compatible with GF100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:58 +10:00
Ben Skeggs
476740843b drm/nouveau/mc/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:58 +10:00
Ben Skeggs
6a9207ecf5 drm/nouveau/fuse/tu106: initial support
Appears to be compatible with GM107.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:58 +10:00
Ben Skeggs
52c887539d drm/nouveau/i2c/tu106: initial support
Appears to be compatible with GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:57 +10:00
Ben Skeggs
1b0a475482 drm/nouveau/gpio/tu106: initial support
Appears to be compatible with GK104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:57 +10:00
Ben Skeggs
8d12c4846d drm/nouveau/ibus/tu106: initial support
Appears to be compatible with GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:57 +10:00
Ben Skeggs
73010b8e2b drm/nouveau/top/tu106: initial support
Appears to be compatible with GK104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:57 +10:00
Ben Skeggs
9d7693fe07 drm/nouveau/devinit/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:56 +10:00
Ben Skeggs
b0216803e3 drm/nouveau/bios/tu106: initial support
No real surprised here so far.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:56 +10:00
Ben Skeggs
a39cb42a75 drm/nouveau/pci/tu106: initial support
Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:56 +10:00
Ben Skeggs
2cc0d7c0f7 drm/nouveau/core: recognise TU106
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:56 +10:00
Ben Skeggs
2d583ade74 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>
2018-12-11 15:37:55 +10:00
Ben Skeggs
563737c525 drm/nouveau/kms/tu104: initial support
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:55 +10:00
Ben Skeggs
c36322d23d drm/nouveau/ce/tu104: initial support
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:55 +10:00
Ben Skeggs
641d0b3056 drm/nouveau/fifo/tu104: initial support
Various different bits and pieces vs GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:55 +10:00
Ben Skeggs
114b6556db drm/nouveau/disp/tu104: initial support
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:54 +10:00
Ben Skeggs
aff70760be drm/nouveau/dma/tu104: initial support
Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:54 +10:00
Ben Skeggs
5a991efdfa drm/nouveau/therm/tu104: initial support
Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:54 +10:00
Ben Skeggs
e7e0e946bb drm/nouveau/pmu/tu104: initial support
Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:54 +10:00
Ben Skeggs
17fb2807c6 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>
2018-12-11 15:37:54 +10:00
Ben Skeggs
838efaa574 drm/nouveau/bar/tu104: initial support
New registers.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:53 +10:00
Ben Skeggs
7986f813c6 drm/nouveau/mmu/tu104: initial support
New flush method.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:53 +10:00
Ben Skeggs
01e0930617 drm/nouveau/ltc/tu104: initial support
Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:53 +10:00
Ben Skeggs
5386148b31 drm/nouveau/fb/tu104: initial support
Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:53 +10:00
Ben Skeggs
c44349b054 drm/nouveau/imem/tu104: initial support
Appears to be compatible with NV50.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:52 +10:00
Ben Skeggs
ead5bf1e3c drm/nouveau/tmr/tu104: initial support
Appears to be compatible with GK20A.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:52 +10:00
Ben Skeggs
75ad1b0020 drm/nouveau/bus/tu104: initial support
Appears to be compatible with GF100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:52 +10:00
Ben Skeggs
f2e55b9ea9 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>
2018-12-11 15:37:52 +10:00