linux/drivers/gpu/drm/amd/display/amdgpu_dm, branch v5.3

drm/amd/display: Calculate bpc based on max_requested_bpc

2019-08-21T22:33:32Z

[Why] The only place where state->max_bpc is updated on the connector is at the start of atomic check during drm_atomic_connector_check. It isn't updated when adding the connectors to the atomic state after the fact. It also doesn't necessarily reflect the right value when called in amdgpu during mode validation outside of atomic check. This can cause the wrong bpc to be used even if the max_requested_bpc is the correct value. [How] Don't rely on state->max_bpc reflecting the real bpc value and just do the min(...) based on display info bpc and max_requested_bpc. Fixes: 01933ba42d3d ("drm/amd/display: Use current connector state if NULL when checking bpc") Signed-off-by: Nicholas Kazlauskas Reviewed-by: Leo Li Signed-off-by: Alex Deucher

drm/amd/display: Force uclk to max for every state

2019-07-18T19:11:47Z

Workaround for now to avoid underflow. The uclk switch time should really be bumped up to 404, but doing so would expose p-state hang issues for higher bandwidth display configurations. Signed-off-by: Nicholas Kazlauskas Signed-off-by: Leo Li Signed-off-by: Alex Deucher

drm/amdgpu: Print out voltage in DM_PPLIB

2019-07-12T03:04:22Z

As the clock is already logged, also log the voltage. Signed-off-by: Paul Menzel Signed-off-by: Alex Deucher

drm/amd/display: Add drm_audio_component support to amdgpu_dm

2019-07-11T19:37:24Z

[Why] The drm_audio_component can be used to give pin ELD notifications directly to the sound driver. This fixes audio endpoints disappearing due to missing unsolicited notifications. [How] Send the notification via the audio component whenever we enable or disable audio state on a stream. This matches what i915 does with their drm_audio_component and what Takashi Iwai's proposed hack for radeon/amdpgu did. This is a bit delayed in when the notification actually occurs, however. We wait until after all the programming is complete rather than sending the notification mid sequence. Particular care is needed for the get ELD callback since it can happen outside the locking and fencing DRM does for atomic commits. Cc: Leo Li Cc: Harry Wentland Signed-off-by: Nicholas Kazlauskas Reviewed-by: Alex Deucher Reviewed-by: Takashi Iwai Signed-off-by: Alex Deucher

drm/amdgpu/display: fix interrupt client id for navi

2019-07-02T20:46:24Z

All asics newer than vega10 use client ids, so simplify the check. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher

drm/amd/amdgpu: Check stream in amdgpu_dm_commit_planes

2019-06-25T18:23:43Z

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 Signed-off-by: Alex Deucher

Merge branch 'drm-next' into drm-next-5.3

2019-06-25T13:42:25Z

Backmerge drm-next and fix up conflicts due to drmP.h removal. Signed-off-by: Alex Deucher

drm/amd/display: Rework CRTC color management

2019-06-22T14:34:13Z

[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: Nicholas Kazlauskas Reviewed-by: Sun peng Li Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

drm/amd/display: update DSC MST DP virtual DPCD peer device enumeration policy

2019-06-22T14:34:13Z

[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: Wenjing Liu Reviewed-by: Jun Lei Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

drm/amd/display: Add power down display on boot flag

2019-06-22T14:34:10Z

[Why] Due to the generic introduction of seamless boot, the display is no longer blanked upon boot. However, this causes corruption on some systems that does not lock the memory in the non-secure boot case, resulting in brief corruption on boot due to garbage being written into the frame buffer. [How] Add a flag, read during DC init, to determine whether display should be blanked on boot. Default to true. Signed-off-by: Thomas Lim Reviewed-by: Aric Cyr Acked-by: Anthony Koo Acked-by: Leo Li Acked-by: Hawking Zhang Signed-off-by: Alex Deucher