- 16 2月, 2023 1 次提交
-
-
由 Leo Li 提交于
[Why] drm_atomic_normalize_zpos() can return an error code when there's modeset lock contention. This was being ignored. [How] Bail out of atomic check if normalize_zpos() returns an error. Fixes: b2615099 ("drm/amd/display: Fix double cursor on non-video RGB MPO") Signed-off-by: NLeo Li <sunpeng.li@amd.com> Tested-by: NMikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Reviewed-by: NHamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 09 2月, 2023 8 次提交
-
-
由 Alex Deucher 提交于
This reverts commit 3cc67fe1. Some users have reported flickerng with S/G display. We've tried extensively to reproduce and debug the issue on a wide variety of platform configurations (DRAM bandwidth, etc.) and a variety of monitors, but so far have not been able to. We disabled S/G display on a number of platforms to address this but that leads to failure to pin framebuffers errors and blank displays when there is memory pressure or no displays at all on systems with limited carveout (e.g., Chromebooks). We have a parameter to disable this as a debugging option as a way for users to disable this, depending on their use case, and for us to help debug this further. Having this enabled seems like the lesser of to evils. Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
This reverts commit 2404f9b0. Some users have reported flickerng with S/G display. We've tried extensively to reproduce and debug the issue on a wide variety of platform configurations (DRAM bandwidth, etc.) and a variety of monitors, but so far have not been able to. We disabled S/G display on a number of platforms to address this but that leads to failure to pin framebuffers errors and blank displays when there is memory pressure or no displays at all on systems with limited carveout (e.g., Chromebooks). We have a parameter to disable this as a debugging option as a way for users to disable this, depending on their use case, and for us to help debug this further. Having this enabled seems like the lesser of to evils. Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
This reverts commit f081cd4c. Some users have reported flickerng with S/G display. We've tried extensively to reproduce and debug the issue on a wide variety of platform configurations (DRAM bandwidth, etc.) and a variety of monitors, but so far have not been able to. We disabled S/G display on a number of platforms to address this but that leads to failure to pin framebuffers errors and blank displays when there is memory pressure or no displays at all on systems with limited carveout (e.g., Chromebooks). We have a parameter to disable this as a debugging option as a way for users to disable this, depending on their use case, and for us to help debug this further. Having this enabled seems like the lesser of to evils. Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Some users have reported flickerng with S/G display. We've tried extensively to reproduce and debug the issue on a wide variety of platform configurations (DRAM bandwidth, etc.) and a variety of monitors, but so far have not been able to. We disabled S/G display on a number of platforms to address this but that leads to failure to pin framebuffers errors and blank displays when there is memory pressure or no displays at all on systems with limited carveout (e.g., Chromebooks). Add a option to disable this as a debugging option as a way for users to disable this, depending on their use case, and for us to help debug this further. v2: fix typo Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
This reverts commit 9aa15370. This is fixed now so we can re-enable S/G display on DCN 3.1.4. Reviewed-by: NYifan Zhang <yifan1.zhang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x
-
由 Alex Deucher 提交于
Take into account whether or not the AGP aperture is enabled or not when calculating the system aperture. Fixes white screens with DCN 3.1.4. Based on a patch from Yifan Zhang <yifan1.zhang@amd.com> Cc: Yifan Zhang <yifan1.zhang@amd.com> Acked-by: NHarry Wentland <harry.wentland@amd.com> Reviewed-by: NYifan Zhang <yifan1.zhang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x
-
由 Alex Deucher 提交于
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2352 Cc: roman.li@amd.com Cc: yifan1.zhang@amd.com Reviewed-by: NYifan Zhang <yifan1.zhang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2352 Cc: roman.li@amd.com Cc: yifan1.zhang@amd.com Reviewed-by: NYifan Zhang <yifan1.zhang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 02 2月, 2023 1 次提交
-
-
由 Alex Deucher 提交于
There could be boards with DCN listed in IP discovery, but no display hardware actually wired up. In this case the vbios display table will not be populated. Detect this case and skip loading DM when we detect it. v2: Mark DCN as harvested as well so other display checks elsewhere in the driver are handled properly. Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: NAurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 27 1月, 2023 1 次提交
-
-
由 Dave Airlie 提交于
This fixes the build here locally on my 32-bit arm build. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 26 1月, 2023 3 次提交
-
-
由 Aurabindo Pillai 提交于
[Why&How] Switching between certain modes that are freesync video modes and those are not freesync video modes result in timing not changing as seen by the monitor due to incorrect timing being driven. The issue is fixed by ensuring that when a non freesync video mode is set, we reset the freesync status on the crtc. Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: NAlan Liu <HaoPing.Liu@amd.com> Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Wayne Lin 提交于
[Why] amdgpu expects to update payload table for one stream one time by calling dm_helpers_dp_mst_write_payload_allocation_table(). Currently, it get modified to try to update HW payload table at once by referring mst_state. [How] This is just a quick workaround. Should find way to remove the temporary struct dc_dp_mst_stream_allocation_table later if set struct link_mst_stream_allocatio directly is possible. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171Signed-off-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NHarry Wentland <harry.wentland@amd.com> Fixes: 4d07b0bc ("drm/display/dp_mst: Move all payload info into the atomic state") Cc: stable@vger.kernel.org # 6.1 Acked-by: NHarry Wentland <harry.wentland@amd.com> Reviewed-by: NLyude Paul <lyude@redhat.com> Tested-by: NDidier Raboud <odyx@debian.org> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lyude Paul 提交于
Looks like I made a pretty big mistake here without noticing: it seems when I moved the assignments of mst_state->pbn_div I completely missed the fact that the reason for us calling drm_dp_mst_update_slots() earlier was to account for the fact that we need to call this function using info from the root MST connector, instead of just trying to do this from each MST encoder's atomic check function. Otherwise, we end up filling out all of DC's link information with zeroes. So, let's restore that and hopefully fix this DSC regression. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171Signed-off-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NHarry Wentland <harry.wentland@amd.com> Fixes: 4d07b0bc ("drm/display/dp_mst: Move all payload info into the atomic state") Cc: stable@vger.kernel.org # 6.1 Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Tested-by: NDidier Raboud <odyx@debian.org> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 19 1月, 2023 5 次提交
-
-
由 Alex Deucher 提交于
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Cc: roman.li@amd.com Cc: yifan1.zhang@amd.com Acked-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NRoman Li <Roman.Li@amd.com> Reviewed-by: NYifan Zhang <yifan1.zhang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x
-
由 Alex Deucher 提交于
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2354 Cc: roman.li@amd.com Cc: yifan1.zhang@amd.com Acked-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NYifan Zhang <yifan1.zhang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x
-
由 Hamza Mahfooz 提交于
Currently, we run into a number of WARN()s when attempting to unload the amdgpu driver (e.g. using "modprobe -r amdgpu"). These all stem from calling drm_encoder_cleanup() too early. So, to fix this we can stop calling drm_encoder_cleanup() from amdgpu_dm_fini() and instead have it be called from amdgpu_dm_encoder_destroy(). Also, we don't need to free in amdgpu_dm_encoder_destroy() since mst_encoders[] isn't explicitly allocated by the slab allocator. Fixes: f74367e4 ("drm/amdgpu/display: create fake mst encoders ahead of time (v4)") Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NHamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Joshua Ashton 提交于
Code in get_output_color_space depends on knowing the pixel encoding to determine whether to pick between eg. COLOR_SPACE_SRGB or COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver. v2: Fixed patch being accidentally based on a personal feature branch, oops! Fixes: ea117312 ("drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded") Reviewed-by: NMelissa Wen <mwen@igalia.com> Signed-off-by: NJoshua Ashton <joshua@froggi.es> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 hongao 提交于
[Why] Setting scaling does not correctly update CRTC state. As a result dc stream state's src (composition area) && dest (addressable area) was not calculated as expected. This causes set scaling doesn's work. [How] Correctly update CRTC state when setting scaling property. Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Tested-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Nhongao <hongao@uniontech.com> Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 05 1月, 2023 1 次提交
-
-
由 Michel Dänzer 提交于
This reverts commit de05abe6. The bug referenced below was bisected to this commit. There has been no activity toward fixing it in 3 months, so let's revert for now. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2162Signed-off-by: NMichel Dänzer <mdaenzer@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 23 12月, 2022 1 次提交
-
-
由 Mario Limonciello 提交于
On desktop APUs amdgpu doesn't create a native backlight device as no eDP panels are found. However if the BIOS has reported backlight control methods in the ACPI tables then an acpi_video0 backlight device will be made 8 seconds after boot. This has manifested in a power slider on a number of desktop APUs ranging from Ryzen 5000 through Ryzen 7000 on various motherboard manufacturers. To avoid this, report to the acpi video detection that the system does not have any panel connected in the native driver. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1783786Reported-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NMario Limonciello <mario.limonciello@amd.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 14 12月, 2022 1 次提交
-
-
由 Yifan Zhang 提交于
Add display SG support for DCN 3.1.4. Signed-off-by: NYifan Zhang <yifan1.zhang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 02 12月, 2022 2 次提交
-
-
由 Hamza Mahfooz 提交于
Currently, userspace doesn't have a way to communicate selective updates to displays. So, enable support for FB_DAMAGE_CLIPS for DCN ASICs newer than DCN301, convert DRM damage clips to dc dirty rectangles and fill them into dirty_rects in fill_dc_dirty_rects(). Reviewed-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NHamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
This fixes DMCU initialization in APU GPU passthrough. The DMCU needs the GPU physical address, not the CPU physical address. This ends up working out on bare metal because we always use the physical address, but doesn't work in passthrough because the addresses are different. Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 30 11月, 2022 2 次提交
-
-
由 Stylon Wang 提交于
[Why] Tests need to tell if display is connected via USB4 DPIA link. Currently this is only possible via analyzing dmesg logs. [How] Create a per-connector debugfs entry to report if the link is tunneled via USB4 DPIA. Reviewed-by: NWayne Lin <Wayne.Lin@amd.com> Acked-by: NJasdeep Dhillon <jdhillon@amd.com> Signed-off-by: NStylon Wang <stylon.wang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Stylon Wang 提交于
[Why] This fix was intended for improving on coding style but in the process uncovers a race condition, which explains why we are getting incorrect length in DPIA AUX replies. Due to the call path of DPIA AUX going from DC back to DM layer then again into DC and the added complexities on top of current DC AUX implementation, a proper fix to rely on current dc_lock to address the race condition is difficult without a major overhual on how DPIA AUX is implemented. [How] - Add a mutex dpia_aux_lock to protect DPIA AUX transfers - Remove DMUB_ASYNC_TO_SYNC_ACCESS_* codes and rely solely on aux_return_code_type for error reporting and handling - Separate SET_CONFIG from DPIA AUX transfer because they have quiet different processing logic - Remove unnecessary type casting to and from void * type Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: NJasdeep Dhillon <jdhillon@amd.com> Signed-off-by: NStylon Wang <stylon.wang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 23 11月, 2022 3 次提交
-
-
由 Tsung-hua Lin 提交于
[why] First MST sideband message returns AUX_RET_ERROR_HPD_DISCON on certain intel platform. Aux transaction considered failure if HPD unexpected pulled low. The actual aux transaction success in such case, hence do not return error. [how] Not returning error when AUX_RET_ERROR_HPD_DISCON detected on the first sideband message. v2: squash in fix (Alex) Reviewed-by: NJerry Zuo <Jerry.Zuo@amd.com> Acked-by: NBrian Chang <Brian.Chang@amd.com> Signed-off-by: NTsung-hua Lin <Tsung-hua.Lin@amd.com> Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lyude Paul 提交于
Coverity noticed this one, so let's fix it. Fixes: 7cce4cd6 ("drm/amdgpu/mst: Stop ignoring error codes and deadlocking") Signed-off-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Cc: stable@vger.kernel.org # v5.6+
-
由 Tsung-hua Lin 提交于
[why] First MST sideband message returns AUX_RET_ERROR_HPD_DISCON on certain intel platform. Aux transaction considered failure if HPD unexpected pulled low. The actual aux transaction success in such case, hence do not return error. [how] Not returning error when AUX_RET_ERROR_HPD_DISCON detected on the first sideband message. v2: squash in fix (Alex) Reviewed-by: NJerry Zuo <Jerry.Zuo@amd.com> Acked-by: NBrian Chang <Brian.Chang@amd.com> Signed-off-by: NTsung-hua Lin <Tsung-hua.Lin@amd.com> Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 22 11月, 2022 4 次提交
-
-
由 Lyude Paul 提交于
Coverity noticed this one, so let's fix it. Fixes: ba891436 ("drm/amdgpu/mst: Stop ignoring error codes and deadlocking") Signed-off-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Cc: stable@vger.kernel.org # v5.6+
-
由 Lyude Paul 提交于
Now that we've fixed the issue with using the incorrect topology manager, we're actually grabbing the topology manager's lock - and consequently deadlocking. Luckily for us though, there's actually nothing in AMD's DSC state computation code that really should need this lock. The one exception is the mutex_lock() in dm_dp_mst_is_port_support_mode(), however we grab no locks beneath &mgr->lock there so that should be fine to leave be. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171Signed-off-by: NLyude Paul <lyude@redhat.com> Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share") Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lyude Paul 提交于
This bug hurt me. Basically, it appears that we've been grabbing the entirely wrong mutex in the MST DSC computation code for amdgpu! While we've been grabbing: amdgpu_dm_connector->mst_mgr That's zero-initialized memory, because the only connectors we'll ever actually be doing DSC computations for are MST ports. Which have mst_mgr zero-initialized, and instead have the correct topology mgr pointer located at: amdgpu_dm_connector->mst_port->mgr; I'm a bit impressed that until now, this code has managed not to crash anyone's systems! It does seem to cause a warning in LOCKDEP though: [ 66.637670] DEBUG_LOCKS_WARN_ON(lock->magic != lock) This was causing the problems that appeared to have been introduced by: commit 4d07b0bc ("drm/display/dp_mst: Move all payload info into the atomic state") This wasn't actually where they came from though. Presumably, before the only thing we were doing with the topology mgr pointer was attempting to grab mst_mgr->lock. Since the above commit however, we grab much more information from mst_mgr including the atomic MST state and respective modesetting locks. This patch also implies that up until now, it's quite likely we could be susceptible to race conditions when going through the MST topology state for DSC computations since we technically will not have grabbed any lock when going through it. So, let's fix this by adjusting all the respective code paths to look at the right pointer and skip things that aren't actual MST connectors from a topology. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171Signed-off-by: NLyude Paul <lyude@redhat.com> Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share") Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lyude Paul 提交于
It appears that amdgpu makes the mistake of completely ignoring the return values from the DP MST helpers, and instead just returns a simple true/false. In this case, it seems to have come back to bite us because as a result of simply returning false from compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a deadlock happened from these helpers. This could definitely result in some kernel splats. V2: * Address Wayne's comments (fix another bunch of spots where we weren't passing down return codes) Signed-off-by: NLyude Paul <lyude@redhat.com> Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share") Cc: Harry Wentland <harry.wentland@amd.com> Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 17 11月, 2022 3 次提交
-
-
由 Lyude Paul 提交于
Now that we've fixed the issue with using the incorrect topology manager, we're actually grabbing the topology manager's lock - and consequently deadlocking. Luckily for us though, there's actually nothing in AMD's DSC state computation code that really should need this lock. The one exception is the mutex_lock() in dm_dp_mst_is_port_support_mode(), however we grab no locks beneath &mgr->lock there so that should be fine to leave be. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171Signed-off-by: NLyude Paul <lyude@redhat.com> Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share") Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lyude Paul 提交于
This bug hurt me. Basically, it appears that we've been grabbing the entirely wrong mutex in the MST DSC computation code for amdgpu! While we've been grabbing: amdgpu_dm_connector->mst_mgr That's zero-initialized memory, because the only connectors we'll ever actually be doing DSC computations for are MST ports. Which have mst_mgr zero-initialized, and instead have the correct topology mgr pointer located at: amdgpu_dm_connector->mst_port->mgr; I'm a bit impressed that until now, this code has managed not to crash anyone's systems! It does seem to cause a warning in LOCKDEP though: [ 66.637670] DEBUG_LOCKS_WARN_ON(lock->magic != lock) This was causing the problems that appeared to have been introduced by: commit 4d07b0bc ("drm/display/dp_mst: Move all payload info into the atomic state") This wasn't actually where they came from though. Presumably, before the only thing we were doing with the topology mgr pointer was attempting to grab mst_mgr->lock. Since the above commit however, we grab much more information from mst_mgr including the atomic MST state and respective modesetting locks. This patch also implies that up until now, it's quite likely we could be susceptible to race conditions when going through the MST topology state for DSC computations since we technically will not have grabbed any lock when going through it. So, let's fix this by adjusting all the respective code paths to look at the right pointer and skip things that aren't actual MST connectors from a topology. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171Signed-off-by: NLyude Paul <lyude@redhat.com> Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share") Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lyude Paul 提交于
It appears that amdgpu makes the mistake of completely ignoring the return values from the DP MST helpers, and instead just returns a simple true/false. In this case, it seems to have come back to bite us because as a result of simply returning false from compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a deadlock happened from these helpers. This could definitely result in some kernel splats. V2: * Address Wayne's comments (fix another bunch of spots where we weren't passing down return codes) Signed-off-by: NLyude Paul <lyude@redhat.com> Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share") Cc: Harry Wentland <harry.wentland@amd.com> Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 16 11月, 2022 4 次提交
-
-
由 Perry Yuan 提交于
Use ip versions (10,3,1) to match the GPU after Vangogh switched to use IP discovery path. Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NPerry Yuan <Perry.Yuan@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Melissa Wen 提交于
DM maps DRM CRTC degamma to DPP (pre-blending) degamma block, but DCE doesn't support programmable degamma curve anywhere. Currently, a custom degamma is accepted by DM but just ignored by DCE driver and degamma correction isn't actually applied. There is no way to map custom degamma in DCE, therefore, DRM CRTC degamma property shouldn't be enabled for DCE drivers. Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NMelissa Wen <mwen@igalia.com> Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Melissa Wen 提交于
DM maps DRM CRTC degamma to DPP (pre-blending) degamma block, but DCE doesn't support programmable degamma curve anywhere. Currently, a custom degamma is accepted by DM but just ignored by DCE driver and degamma correction isn't actually applied. There is no way to map custom degamma in DCE, therefore, DRM CRTC degamma property shouldn't be enabled for DCE drivers. Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NMelissa Wen <mwen@igalia.com> Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Stylon Wang 提交于
[Why] Some DPIA AUX replies have incorrect data length from original request. This could lead to overwriting of destination buffer if reply length is larger, which could cause invalid access to stack since many destination buffers are declared as local variables. [How] Check for invalid length from DPIA AUX replies and trigger a retry if reply length is not the same as original request. A DRM_WARN() dmesg log is also produced. Reviewed-by: NRoman Li <Roman.Li@amd.com> Acked-by: NTom Chung <chiahsuan.chung@amd.com> Signed-off-by: NStylon Wang <stylon.wang@amd.com> Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.0.x
-