#
7a47c882 |
| 04-Nov-2021 |
Jimmy Kizito <Jimmy.Kizito@amd.com> |
drm/amd/display: Initialise encoder assignment when initialising dc_state
[Why] Link encoder assignment tracking variables need to be (re)initialised whenever dc_state is (re)initialised. Otherwise
drm/amd/display: Initialise encoder assignment when initialising dc_state
[Why] Link encoder assignment tracking variables need to be (re)initialised whenever dc_state is (re)initialised. Otherwise variables used for dynamic encoder assignment (especially the link encoder availability pool) are out of sync with dc_state and future encoder assignments are invalid.
[How] Initialise encoder assignment variables when creating new dc_state resource.
Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
7db581d6 |
| 19-Jul-2021 |
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> |
drm/amd/display: allow windowed mpo + odm
This change adds a config flag to allow non fullscreen MPO during ODM. Scaling calculation will still fail configurations where video is only one one side o
drm/amd/display: allow windowed mpo + odm
This change adds a config flag to allow non fullscreen MPO during ODM. Scaling calculation will still fail configurations where video is only one one side of the screen.
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Acked-by: Agustin Gutierrez <agustin.gutierrez@amd.com> Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
94e587b8 |
| 28-Sep-2021 |
Aric Cyr <aric.cyr@amd.com> |
drm/amd/display: Validate plane rects before use
[Why] Calculation of scaling ratio can result in a crash due to zero'd src or dst plane rects.
[How] Validate that src and dst rects are valid befor
drm/amd/display: Validate plane rects before use
[Why] Calculation of scaling ratio can result in a crash due to zero'd src or dst plane rects.
[How] Validate that src and dst rects are valid before using for scaling calculations.
Reviewed-by: Josip Pavic <Josip.Pavic@amd.com> Acked-by: Agustin Gutierrez Sanchez <agustin.gutierrez@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
519607a2 |
| 01-Oct-2021 |
Alex Deucher <alexander.deucher@amd.com> |
drm/amdgpu/display: fold DRM_AMD_DC_DCN201 into DRM_AMD_DC_DCN
No need for a separate kconfig option at this point.
Reviewed-by: Zhan Liu <zhan.liu@amd.com> Signed-off-by: Alex Deucher <alexander.d
drm/amdgpu/display: fold DRM_AMD_DC_DCN201 into DRM_AMD_DC_DCN
No need for a separate kconfig option at this point.
Reviewed-by: Zhan Liu <zhan.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
3f68c01b |
| 25-Sep-2021 |
Zhan Liu <zhan.liu@amd.com> |
drm/amd/display: add cyan_skillfish display support
[Why] add display related cyan_skillfish files in.
makefile controlled by CONFIG_DRM_AMD_DC_DCN201 flag.
v2: squash in clang fixes from Harry, N
drm/amd/display: add cyan_skillfish display support
[Why] add display related cyan_skillfish files in.
makefile controlled by CONFIG_DRM_AMD_DC_DCN201 flag.
v2: squash in clang fixes from Harry, Nathan v3: squash in missing CONFIG_DRM_AMD_DC check (Alex)
Signed-off-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Acked-by: Jun Lei <jun.lei@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
0d4b4253 |
| 02-Sep-2021 |
Jimmy Kizito <Jimmy.Kizito@amd.com> |
drm/amd/display: Fix dynamic encoder reassignment
[Why] Incorrect encoder assignments were being used while applying a new state to hardware.
(1) When committing a new state to hardware requires re
drm/amd/display: Fix dynamic encoder reassignment
[Why] Incorrect encoder assignments were being used while applying a new state to hardware.
(1) When committing a new state to hardware requires resetting the back-end, the encoder assignments of the current or old state should be used when disabling the back-end; and the encoder assignments for the next or new state should be used when re-enabling the back-end.
(2) Link training on hot plug could take over an encoder already in use by another stream without first disabling it.
[How]
(1) Introduce a resource context 'link_enc_cfg_context' which includes: - a mode to indicate when transitioning from current to next state. - transient encoder assignments to use during this state transition.
Update the encoder configuration interface to respond to queries about encoder assignment based on the mode of operation.
(2) Check if an encoder is already in use before attempting to perform link training on hot plug.
Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
b3492ed1 |
| 28-Aug-2021 |
Jimmy Kizito <Jimmy.Kizito@amd.com> |
drm/amd/display: Fix concurrent dynamic encoder assignment
[Why] Trying to enable multiple displays simultaneously exposed shortcomings with the algorithm for dynamic link encoder assignment.
The m
drm/amd/display: Fix concurrent dynamic encoder assignment
[Why] Trying to enable multiple displays simultaneously exposed shortcomings with the algorithm for dynamic link encoder assignment.
The main problems were: - Assuming stream order remained constant across states would sometimes lead to invalid DIG encoder assignment. - Incorrect logic for deciding whether or not a DIG could support a stream would also sometimes lead to invalid DIG encoder assignment. - Changes in encoder assignment were wholesale while updating of the pipe backend is incremental. This would lead to the hardware state not matching the software state even with valid encoder assignments.
[How]
The following changes fix the identified problems. - Use stream pointer rather than stream index to track streams across states. - Fix DIG compatibility check by examining the link signal type rather than the stream signal type. - Modify assignment algorithm to make incremental updates so software and hardware states remain coherent.
Additionally: - Add assertions and an encoder assignment validation function link_enc_cfg_validate() to detect potential problems with encoder assignment closer to their root cause. - Reduce the frequency with which the assignment algorithm is executed. It should not be necessary for fast state validation.
Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
64d283cb |
| 10-Aug-2021 |
Jimmy Kizito <Jimmy.Kizito@amd.com> |
drm/amd/display: Fix dynamic link encoder access.
[Why] Assuming DIG link encoders are statically mapped to links can cause system instability due to null pointer accesses.
[How] - Add checks for n
drm/amd/display: Fix dynamic link encoder access.
[Why] Assuming DIG link encoders are statically mapped to links can cause system instability due to null pointer accesses.
[How] - Add checks for non-null link encoder pointers before trying to access them. - When a hardware platform uses dynamic DIG assignment (i.e. resource function 'link_encs_assign' defined) and a link supports flexible mapping to DIGs, use the link_enc_cfg API to access the DIG assigned to a link or stream.
Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Acked-by: Mikita Lipski <mikita.lipski@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
f01ee019 |
| 03-Aug-2021 |
Fangzhi Zuo <Jerry.Zuo@amd.com> |
drm/amd/display: Add DP 2.0 SST DC Support
1. Retrieve 128/132b link cap. 2. 128/132b link training and payload allocation. 3. UHBR10 link rate support.
[squash in warning fixes - Alex]
Signed-off
drm/amd/display: Add DP 2.0 SST DC Support
1. Retrieve 128/132b link cap. 2. 128/132b link training and payload allocation. 3. UHBR10 link rate support.
[squash in warning fixes - Alex]
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cded1186 |
| 11-Jul-2022 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requir
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
[ Upstream commit add61d3c31de6a4b5e11a2ab96aaf4c873481568 ]
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes, last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I found out that on DCE-11.2 it causes dithering when there shouldn't be any, so identity pixel passthrough with identity gamma LUTs doesn't work when it should. This breaks various important neuroscience applications, as reported to me by scientific users of Polaris cards under Ubuntu 22.04 with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it is both necessary for high color precision output, e.g., RGBA16 fb's, and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so this ("famous last words") depth 30 should hopefully fix all known problems without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
b054e818 |
| 07-Mar-2022 |
Charlene Liu <Charlene.Liu@amd.com> |
drm/amd/display: fix audio format not updated after edid updated
[ Upstream commit 5e8a71cf13bc9184fee915b2220be71b4c6cac74 ]
[why] for the case edid change only changed audio format. driver still
drm/amd/display: fix audio format not updated after edid updated
[ Upstream commit 5e8a71cf13bc9184fee915b2220be71b4c6cac74 ]
[why] for the case edid change only changed audio format. driver still need to update stream.
Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|