- 25 Jun, 2019 13 commits
-
-
Ernst Sjöstrand authored
Inconsistent indentation and mixed use of brackets. Signed-off-by:
Ernst Sjöstrand <ernstp@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Ernst Sjöstrand authored
Reported by smatch: amdgpu_dm.c:5637 amdgpu_dm_commit_planes() error: we previously assumed 'acrtc_state->stream' could be null This seems to be checked for null pretty consistently elsewhere. Signed-off-by:
-
Ernst Sjöstrand authored
Reported by smatch: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:1496 amdgpu_hwmon_show_temp() error: uninitialized symbol 'temp'. Signed-off-by:
-
Ernst Sjöstrand authored
Reported by smatch: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:693 amdgpu_set_pp_od_clk_voltage() error: uninitialized symbol 'ret'. Signed-off-by:
-
Ernst Sjöstrand authored
Reported by smatch: drivers/gpu/drm/amd/amdgpu/soc15.c:715 soc15_get_pcie_usage() warn: inconsistent indenting And a similar one in si.c. Signed-off-by:
-
Alex Deucher authored
No need to protect the comments. The DCN1_01 config was dopped anyway. Got accidently brought back with the navi merge. Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Alex Deucher authored
We may need to sleep for up to 80ms (8ms per each of up to 10 loop iterations): /* First DPCD read after VDD ON can fail if the particular board * does not have HPD pin wired correctly. So if DPCD read fails, * which it should never happen, retry a few times. Target worst * case scenario of 80 ms. */ Switch udelay to msleep to avoid limits on arm. Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Alex Deucher authored
ULL is needed for 32 bit arches. Reviewed-by:
-
Alex Deucher authored
Backmerge drm-next and fix up conflicts due to drmP.h removal. Signed-off-by: -
Andres Rodriguez authored
Replace the duplicated versions of the while loop with the new macro. Signed-off-by:
Andres Rodriguez <andresx7@gmail.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Andres Rodriguez authored
DisplayID blocks allow embedding of CEA blocks. The payloads are identical to traditional top level CEA extension blocks, but the header is slightly different. This change allows the CEA parser to find a CEA block inside a DisplayID block. Additionally, it adds support for parsing the embedded CTA header. No further changes are necessary due to payload parity. This change fixes audio support for the Valve Index HMD. Signed-off-by:
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/tegra: Changes for v5.3-rc1 This contains a couple of small improvements and cleanups for the Tegra DRM driver. Signed-off-by:
-
git://linux-arm.org/linux-ldDave Airlie authored
Picking up pace on the upstreaming of Komeda driver, with quite a lot of new features added this time. On top of that we have the small cleanups and improved usage of the debugfs functions. Please pull! Signed-off-by:
-
- 24 Jun, 2019 2 commits
-
-
tiancyin authored
The gfxoff brings unstability, disable it by default Reviewed-by:
tiancyin <tianci.yin@amd.com> Signed-off-by:
-
Hawking Zhang authored
For uvd_4/5/6, amdgpu driver will only power on them when there are jobs assigned to decode/enc rings.uvd_4/5/6 dpm was broken since amdgpu_dpm_set_powergating_by_smu only covers gfx block. The change would add more IP block support in amdgpu_dpm_set_powergating_by_smu For GFX/UVD/VCN/VCE, if the new SMU driver is supported, invoke new power gate helper function smu_dpm_set_power_gate, otherwise, fallback to legacy powerplay helper function pp_set_powergating_by_smu. For other IP blocks always invoke legacy powerplay helper function. Signed-off-by:
-
- 22 Jun, 2019 25 commits
-
-
Alex Deucher authored
It was replaced with the sw_init callback so is no longer needed. Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Jonathan Kim authored
change df_init to df_sw_init df 1.7 to prevent regression issues on pre-vega20 products when callback is called in sw_common_sw_init. Reviewed-by:
Jonathan Kim <Jonathan.Kim@amd.com> Signed-off-by:
-
Oak Zeng authored
Previous kfd doesn't use gws so this mask was set to 0. Set it to 64 bit 1s because now kfd can use all 64 gws resources. Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
-
hersen wu authored
during navi10 bring up, dwb causes system hang. to continue debug major issue, disable dwb by set num-dwb = 0. the hang issue is not reproduced now by enable num-dwb =1. dc source is shared by all os. win needs num-dwb = 1. Signed-off-by:
hersen wu <hersenxs.wu@amd.com> Acked-by:
Roman Li <Roman.Li@amd.com> Signed-off-by:
-
Su Sung Chung authored
[why] Before for raven and navi we are calling pp_smu functions for pme [how] refactor a code so we will call clk_mgr's enable_pme_wa function so we can use pme_wa for future asics. This way we don't need to worry about different ASIC since clk_mgr already have that information Signed-off-by:
Su Sung Chung <Su.Chung@amd.com> Reviewed-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
-
Charlene Liu authored
for future use Signed-off-by:
Charlene Liu <charlene.liu@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
Dmytro Laktyushkin authored
mod_vmid is missing a destructor. Signed-off-by:
-
Thomas Lim authored
[Why] For debugging underflow issues it can be useful to have asserts when the underflow initially occurs. [How] Read the underflow status registers after actions that have a high risk of causing underflow and assert that no underflow occurred. If underflow occurred, clear the bit. Signed-off-by:
Thomas Lim <Thomas.Lim@amd.com> Reviewed-by:
-
Dmytro Laktyushkin authored
Currently vmid is decided internally inside dc. With the introduction of new asics we are required to coordinate vmid use with external components. This change converts vmid logic to a DAL module allowing vmid to be passed in as a parameter to DC. Signed-off-by:
-
Charlene Liu authored
[Description] dcn2 use fixed clocks and not program DPP CLK or Disp_CLK. Signed-off-by:
-
Charlene Liu authored
for future use Signed-off-by:
Chris Park <Chris.Park@amd.com> Acked-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Signed-off-by:
-
Jun Lei authored
[why] value commited to by HW team is going to be higher than pre-silicon, and will cause underflow if driver not updated [how] update hardcoded value, update pstate switching logic to fix case where with long uclk time we won't allow switch even when we should Signed-off-by:
Jun Lei <Jun.Lei@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] To prepare for the upcoming DRM plane color management properties we need to correct a lot of wrong behavior and assumptions made for CRTC color management. The documentation added by this commit in amdgpu_dm_color explains how the HW color pipeline works and its limitations with the DRM interface. The current implementation does the following wrong: - Implicit sRGB DGM when no CRTC DGM is set - Implicit sRGB RGM when no CRTC RGM is set - No way to specify a non-linear DGM matrix that produces correct output - No way to specify a correct RGM when a linear DGM is used We had workarounds for passing kms_color tests but not all of the behavior we had wrong was covered by these tests (especially when it comes to non-linear DGM). Testing both DGM and RGM at the same time isn't something kms_color tests well either. [How] The specifics for how color management works in AMDGPU and the new behavior can be found by reading the documentation added to amdgpu_dm_color.c from this patch. All of the incorrect cases from the old implementation have been addressed for the atomic interface, but there still a few TODOs for the legacy one. Note: this does cause regressions for kms_color@pipe-a-ctm-* over HDMI. The result looks correct from visual inspection but the CRC no longer matches. For reference, the test was previously doing the following: linear degamma -> CTM -> sRGB regamma -> RGB to YUV (709) -> ... Now the test is doing: linear degamma -> CTM -> linear regamma -> RGB to YUV (709) -> ... Signed-off-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by:
-
Wesley Chalmers authored
[WHY] This is meant to make it clearer that 0xf is not a valid OPP ID, and that code making use of OPP IDs should not accept this value. Signed-off-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by:
-
Eric Bernstein authored
expose this function for future use Implementation of DCN3 DIO Link Encoder including dpcs register headers. Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
-
Charlene Liu authored
add dwb stereo caps and ver for future use Signed-off-by:
-
Eric Bernstein authored
Add Alpha surface type for future use Signed-off-by:
-
Jun Lei authored
[why] Existing behavior has overlapping ranges resulting in path dependent SMU selection [how] Make ranges non-overlapping, resulting in non-path dependent selection Signed-off-by:
-
Wenjing Liu authored
[why] According to the latest specs, the max_target bpp sink can support is 16 bpp. [how] update dsc max_target_bpp to 16 Signed-off-by:
Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by:
-
Charlene Liu authored
required for new checks. Signed-off-by:
-
Wenjing Liu authored
[why] Current policy assumes virtual DPCD peer device as an individual MST branch device with 1 input and 1 output. However this is only true for virtual DP-to-DP peer device. In general there are three types of virtual DP peer devices. 1. Sink peer device with virtual DPCD. 2. Virtual DP-to-DP Peer device with virtual DPCD. 3. Virtual DP-to-HDMI Protocol Converter Peer Device with Virtual DPCD. So we should break the assumption and handle all three types. [how] DP-to-DP peer device will have virtual DPCD cap upstream. Sink peer device will have virtual DPCD on the logical port. Dp to HDMI protocol converter peer device will have virtual DPCD on its converter port. For DSC capable Synaptics non VGA port we workaround by enumerating a virutal DPCD peer device on its upstream even if it doesn't have one. Signed-off-by:
-
Jun Lei authored
[why] useful for debugging [how] plumb a debug option in dc Signed-off-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] Almost every function in DC that works with stream state expects that the current state on the stream is the one that it should be writing out. These functions are typically triggered by specifying a particular stream update - but the actual contents of the stream update itself are ignored, leaving it to the DM to actually update the stream state itself. The problem with doing this in DM is a matter of timing. On Linux most of this is incorrectly done in atomic check, when we actually want it to be done during atomic commit tail while access to DC is locked. To give an example, a commit requesting to modify color management state for DM could come in, be rejected, but still have modified the actual system state for the stream since it's shared memory. The next time color management gets programmed it'll use the rejected color management info - which might not even still be around if it's a custom transfer function. So a reasonable place to perform this is within DC itself and this is the model that's currently in use for surface updates. DC can even compare the current system state to the incoming surface update to determine update level, something that can't currnetly be done with the framework for stream updates. [How] Duplicate the framework used for surface updates for stream updates as well. Copy all the updates after checking the update type. Signed-off-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
-
Ilya Bakoulin authored
SwathWidthCThisState is expected to be an unsigned int array. Signed-off-by:
Ilya Bakoulin <Ilya.Bakoulin@amd.com> Reviewed-by:
-
Martin Leung authored
[why] when resetting pipes from 480p to dual-pipe 8k, modulo reg write for video optimized rate updated one pipe without changing the other, causing sync error [how] removed code from dcn2 Signed-off-by:
Martin Leung <martin.leung@amd.com> Reviewed-by:
-
