linux.git/drivers/gpu/drm/amd, branch v4.18-rc4

drm/amd/display: add a check for display depth validity

2018-07-05T15:19:53+00:00

[why]
HDMI 2.0 fails to validate 4K@60 timing with 10 bpc
[how]
Adding a helper function that would verify if the display depth
assigned would pass a bandwidth validation.
Drop the display depth by one level till calculated pixel clk
is lower than maximum TMDS clk.

Bugzilla: https://bugs.freedesktop.org/106959

Tested-by: Mike Lothian 
Reviewed-by: Harry Wentland 
Signed-off-by: Mikita Lipski 
Signed-off-by: Alex Deucher

drm/amd/display: adding ycbcr420 pixel encoding for hdmi

2018-07-05T15:19:18+00:00

[why]
HDMI EDID's VSDB contains spectial timings for specifically
YCbCr 4:2:0 colour space. In those cases we need to verify
if the mode provided is one of the special ones has to use
YCbCr 4:2:0 pixel encoding for display info.
[how]
Verify if the mode is using specific ycbcr420 colour space with
the help of DRM helper function and assign the mode to use
ycbcr420 pixel encoding.

Tested-by: Mike Lothian 
Reviewed-by: Harry Wentland 
Signed-off-by: Mikita Lipski 
Signed-off-by: Alex Deucher

drm/amdgpu: fix user fence write race condition

2018-07-04T07:40:18+00:00

The buffer object backing the user fence is reserved using the non-user
fence, i.e., as soon as the non-user fence is signaled, the user fence
buffer object can be moved or even destroyed.

Therefore, emit the user fence first.

Both fences have the same cache invalidation behavior, so this should
have no user-visible effect.

Signed-off-by: Nicolai Hähnle 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amdgpu/pm: fix display count in non-DC path

2018-07-02T18:41:11+00:00

new_active_crtcs is a bitmask, new_active_crtc_count is the
actual count.

Reviewed-by: Rex Zhu 
Signed-off-by: Alex Deucher

drm/amdgpu: fix swapped emit_ib_size in vce3

2018-07-02T18:40:55+00:00

The phys and vm versions had the values swapped.

Reviewed-by: Junwei Zhang 
Signed-off-by: Alex Deucher

drm/amdgpu: Dynamically probe for ATIF handle (v2)

2018-06-28T20:32:46+00:00

The other day I was testing one of the HP laptops at my office with an
i915/amdgpu hybrid setup and noticed that hotplugging was non-functional
on almost all of the display outputs. I eventually discovered that all
of the external outputs were connected to the amdgpu device instead of
i915, and that the hotplugs weren't being detected so long as the GPU
was in runtime suspend. After some talking with folks at AMD, I learned
that amdgpu is actually supposed to support hotplug detection in runtime
suspend so long as the OEM has implemented it properly in the firmware.

On this HP ZBook 15 G4 (the machine in question), amdgpu wasn't managing
to find the ATIF handle at all despite the fact that I could see acpi
events being sent in response to any hotplugging. After going through
dumps of the firmware, I discovered that this machine did in fact
support ATIF, but that it's ATIF method lived in an entirely different
namespace than this device's handle (the device handle was
\_SB_.PCI0.PEG0.PEGP, but ATIF lives in ATPX's handle at
\_SB_.PCI0.GFX0).

So, fix this by probing ATPX's ACPI parent's namespace if we can't find
ATIF elsewhere, along with storing a pointer to the proper handle to use
for ATIF and using that instead of the device's handle.

This fixes HPD detection while in runtime suspend for this ZBook!

v2: Update the comment to reflect how the namespaces are arranged
based on the system configuration. (Alex)

Signed-off-by: Lyude Paul 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amdgpu: Add amdgpu_atpx_get_dhandle()

2018-06-28T20:32:18+00:00

Since it seems that some vendors are storing the ATIF ACPI methods under
the same handle that ATPX lives under instead of the device's own
handle, we're going to need to be able to retrieve this handle later so
we can probe for ATIF there.

Signed-off-by: Lyude Paul 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amdgpu: Make struct amdgpu_atif private to amdgpu_acpi.c

2018-06-28T20:31:45+00:00

Currently, there is nothing in amdgpu that actually uses these structs
other than amdgpu_acpi.c. Additionally, since we're about to start
saving the correct ACPI handle to use for calling ATIF in this struct
this saves us from having to handle making sure that the acpi_handle
(and by proxy, the type definition for acpi_handle and all of the other
acpi headers) doesn't need to be included within the amdgpu_drv struct
itself. This follows the example set by amdgpu_atpx_handler.c.

Signed-off-by: Lyude Paul 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amd/powerplay: smc_dpm_info structure change

2018-06-28T19:06:10+00:00

A new member Vr2_I2C_address is added.

Signed-off-by: Evan Quan 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amd/powerplay: correct vega12 bootup values settings

2018-06-28T19:06:10+00:00

The vbios firmware structure changed between v3_1 and v3_2. So,
the code to setup bootup values needs different paths based
on header version.

Signed-off-by: Evan Quan 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher