linux-stable.git/drivers/gpu, branch v5.4.96 Linux kernel stable tree drm/amd/display: Change function decide_dp_link_settings to avoid infinite looping 2021-02-07T14:35:49+00:00 Bing Guo bing.guo@amd.com 2021-01-04T19:09:41+00:00 88240f7ac22147e7d831bf052085bb4bbf4d06e6 [ Upstream commit 4716a7c50c5c66d6ddc42401e1e0ba13b492e105 ] Why: Function decide_dp_link_settings() loops infinitely when required bandwidth can't be supported. How: Check the required bandwidth against verified_link_cap before trying to find a link setting for it. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Bing Guo <bing.guo@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Anson Jacob <anson.jacob@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4716a7c50c5c66d6ddc42401e1e0ba13b492e105 ]

Why:
Function decide_dp_link_settings() loops infinitely when required bandwidth
can't be supported.

How:
Check the required bandwidth against verified_link_cap before trying to
find a link setting for it.

Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Bing Guo <bing.guo@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Anson Jacob <anson.jacob@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amd/display: Update dram_clock_change_latency for DCN2.1 2021-02-07T14:35:49+00:00 Jake Wang haonan.wang2@amd.com 2021-01-08T17:27:51+00:00 53c10bbf9186086485990aed054d852940992d20 [ Upstream commit 901c1ec05ef277ce9d43cb806a225b28b3efe89a ] [WHY] dram clock change latencies get updated using ddr4 latency table, but does that update does not happen before validation. This value should not be the default and should be number received from df for better mode support. This may cause a PState hang on high refresh panels with short vblanks such as on 1080p 360hz or 300hz panels. [HOW] Update latency from 23.84 to 11.72. Signed-off-by: Sung Lee <sung.lee@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 901c1ec05ef277ce9d43cb806a225b28b3efe89a ]

[WHY]
dram clock change latencies get updated using ddr4 latency table, but
does that update does not happen before validation. This value
should not be the default and should be number received from
df for better mode support.
This may cause a PState hang on high refresh panels with short vblanks
such as on 1080p 360hz or 300hz panels.

[HOW]
Update latency from 23.84 to 11.72.

Signed-off-by: Sung Lee <sung.lee@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/i915: Check for all subplatform bits 2021-02-03T22:25:58+00:00 Umesh Nerlige Ramappa umesh.nerlige.ramappa@intel.com 2021-01-21T16:19:35+00:00 ad3d896ef55c5aa2d06027c08556928d96c37e70 commit 8f6d08c9af284d74276da6681348e4673f13caea upstream. Current code is checking only 2 bits in the subplatform, but actually 3 bits are allocated for the field. Check all 3 bits. Fixes: 805446c8347c ("drm/i915: Introduce concept of a sub-platform") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210121161936.746591-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 27b695ee1af9bb36605e67055874ec081306ac28) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8f6d08c9af284d74276da6681348e4673f13caea upstream.

Current code is checking only 2 bits in the subplatform, but actually 3
bits are allocated for the field. Check all 3 bits.

Fixes: 805446c8347c ("drm/i915: Introduce concept of a sub-platform")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210121161936.746591-1-tvrtko.ursulin@linux.intel.com
(cherry picked from commit 27b695ee1af9bb36605e67055874ec081306ac28)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/nouveau/svm: fail NOUVEAU_SVM_INIT ioctl on unsupported devices 2021-02-03T22:25:58+00:00 Karol Herbst kherbst@redhat.com 2021-01-18T17:16:06+00:00 59546420c51b3643a58d229f2c25b5351a9c3889 commit dcd602cc5fe2803bf532d407cde24ba0b7808ff3 upstream. Fixes a crash when trying to create a channel on e.g. Turing GPUs when NOUVEAU_SVM_INIT was called before. Fixes: eeaf06ac1a558 ("drm/nouveau/svm: initial support for shared virtual memory") Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit dcd602cc5fe2803bf532d407cde24ba0b7808ff3 upstream.

Fixes a crash when trying to create a channel on e.g. Turing GPUs when
NOUVEAU_SVM_INIT was called before.

Fixes: eeaf06ac1a558 ("drm/nouveau/svm: initial support for shared virtual memory")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0 2021-01-27T10:47:46+00:00 Ben Skeggs bskeggs@redhat.com 2021-01-13T07:12:52+00:00 73a229119983bc0bedd17604ef0b94c292230870 [ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ] VRAM offset 0 is a valid address, triggered on GA102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]

VRAM offset 0 is a valid address, triggered on GA102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/nouveau/mmu: fix vram heap sizing 2021-01-27T10:47:46+00:00 Ben Skeggs bskeggs@redhat.com 2021-01-13T07:12:52+00:00 af91a2e7fb5e03401dbddfa6f9f91998616b1995 [ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ] Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields 2021-01-27T10:47:46+00:00 Ben Skeggs bskeggs@redhat.com 2021-01-13T07:12:52+00:00 ee2c9e58f430ff60ab77df6ce29320e6231b348f [ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ] Noticed while debugging GA102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]

Noticed while debugging GA102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/nouveau/privring: ack interrupts the same way as RM 2021-01-27T10:47:46+00:00 Ben Skeggs bskeggs@redhat.com 2021-01-13T07:12:52+00:00 38f35023fd301abeb01cfd81e73caa2e4e7ec0b1 [ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ] Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ]

Whatever it is that we were doing before doesn't work on Ampere.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/nouveau/bios: fix issue shadowing expansion ROMs 2021-01-27T10:47:46+00:00 Ben Skeggs bskeggs@redhat.com 2021-01-13T07:12:52+00:00 8c3d3b385ed868660c7dff0336da1bd5a9fb134d [ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ] This issue has generally been covered up by the presence of additional expansion ROMs after the ones we're interested in, with header fetches of subsequent images loading enough of the ROM to hide the issue. Noticed on GA102, which lacks a type 0x70 image compared to TU102,. [ 906.364197] nouveau 0000:09:00.0: bios: 00000000: type 00, 65024 bytes [ 906.381205] nouveau 0000:09:00.0: bios: 0000fe00: type 03, 91648 bytes [ 906.405213] nouveau 0000:09:00.0: bios: 00026400: type e0, 22016 bytes [ 906.410984] nouveau 0000:09:00.0: bios: 0002ba00: type e0, 366080 bytes vs [ 22.961901] nouveau 0000:09:00.0: bios: 00000000: type 00, 60416 bytes [ 22.984174] nouveau 0000:09:00.0: bios: 0000ec00: type 03, 71168 bytes [ 23.010446] nouveau 0000:09:00.0: bios: 00020200: type e0, 48128 bytes [ 23.028220] nouveau 0000:09:00.0: bios: 0002be00: type e0, 140800 bytes [ 23.080196] nouveau 0000:09:00.0: bios: 0004e400: type 70, 7168 bytes Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]

This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.

Noticed on GA102, which lacks a type 0x70 image compared to TU102,.

[  906.364197] nouveau 0000:09:00.0: bios: 00000000: type 00, 65024 bytes
[  906.381205] nouveau 0000:09:00.0: bios: 0000fe00: type 03, 91648 bytes
[  906.405213] nouveau 0000:09:00.0: bios: 00026400: type e0, 22016 bytes
[  906.410984] nouveau 0000:09:00.0: bios: 0002ba00: type e0, 366080 bytes

vs

[   22.961901] nouveau 0000:09:00.0: bios: 00000000: type 00, 60416 bytes
[   22.984174] nouveau 0000:09:00.0: bios: 0000ec00: type 03, 71168 bytes
[   23.010446] nouveau 0000:09:00.0: bios: 00020200: type e0, 48128 bytes
[   23.028220] nouveau 0000:09:00.0: bios: 0002be00: type e0, 140800 bytes
[   23.080196] nouveau 0000:09:00.0: bios: 0004e400: type 70, 7168 bytes

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amd/display: Fix to be able to stop crc calculation 2021-01-27T10:47:45+00:00 Wayne Lin Wayne.Lin@amd.com 2020-11-24T11:57:03+00:00 f5dc9627ac04a98afefcf05035239e0001d6c393 [ Upstream commit 02ce73b01e09e388614b22b7ebc71debf4a588f0 ] [Why] Find out when we try to disable CRC calculation, crc generation is still enabled. Main reason is that dc_stream_configure_crc() will never get called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE. [How] Add checking condition that when source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call dc_stream_configure_crc() to disable crc calculation. Also, clean up crc window when disable crc calculation. Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 02ce73b01e09e388614b22b7ebc71debf4a588f0 ]

[Why]
Find out when we try to disable CRC calculation,
crc generation is still enabled. Main reason is
that dc_stream_configure_crc() will never get
called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE.

[How]
Add checking condition that when source is
AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call
dc_stream_configure_crc() to disable crc calculation.
Also, clean up crc window when disable crc calculation.

Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>