Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
[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>
|
|
[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>
|
|
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>
|
|
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>
|
|
Appears to be compatible with TU104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GV100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GP100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GP102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GP102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GV100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with NV50.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GK20A.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GF100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GM107.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GM200.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GK104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GM200.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GK104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with TU104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
No real surprised here so far.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GP100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
RTX2070 appears to have 3 copies of the engine.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Various different bits and pieces vs GV100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GV100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GP100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GP102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
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>
|
|
New registers.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
New flush method.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GP102.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GV100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with NV50.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GK20A.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GF100.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
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>
|
|
Appears to be compatible with GM107.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GM200.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GK104.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Appears to be compatible with GM200.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|