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

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/amdgpu:Support new VCN FW version naming convention

2018-06-27T19:34:04+00:00

Support new VCN FW version naming convention:
  [31, 28] for VEP interface major version if applicable
  [27, 24] for decode interface major version
  [23, 20] for encode interface major version
  [19, 12] for encode interface minor version
  [11, 0]  for firmware revision
Bit 20-23, it is encode major and non-zero for new naming convention.
This field is part of version minor and DRM_DISABLED_FLAG in old naming
convention. Since the latest version minor is 0x5B and DRM_DISABLED_FLAG
is zero in old naming convention, this field is always zero so far.
These four bits are used to tell which naming convention is present.

Signed-off-by: James Zhu 
Reviewed-by: Fang, Peter 
Signed-off-by: Alex Deucher

drm/amdgpu: fix UBSAN: Undefined behaviour for amdgpu_fence.c

2018-06-27T19:33:19+00:00

Here is the UBSAN dump:

[    3.866656] index 2 is out of range for type 'amdgpu_uvd_inst [2]'
[    3.866693] Workqueue: events work_for_cpu_fn
[    3.866702] Call Trace:
[    3.866710]  dump_stack+0x85/0xc5
[    3.866719]  ubsan_epilogue+0x9/0x40
[    3.866727]  __ubsan_handle_out_of_bounds+0x89/0x90
[    3.866737]  ? rcu_read_lock_sched_held+0x58/0x60
[    3.866746]  ? __kmalloc+0x26c/0x2d0
[    3.866846]  amdgpu_fence_driver_start_ring+0x259/0x280 [amdgpu]
[    3.866896]  amdgpu_ring_init+0x12c/0x710 [amdgpu]
[    3.866906]  ? sprintf+0x42/0x50
[    3.866956]  amdgpu_gfx_kiq_init_ring+0x1bc/0x3a0 [amdgpu]
[    3.867009]  gfx_v8_0_sw_init+0x1ad3/0x2360 [amdgpu]
[    3.867062]  ? smu7_init+0xec/0x160 [amdgpu]
[    3.867109]  amdgpu_device_init+0x112c/0x1dc0 [amdgpu]

'ring->me' might be set as 2 with 'amdgpu_gfx_kiq_init_ring', that would
cause out of range for 'amdgpu_uvd_inst[2]'.

v2: simplified with ring type

Signed-off-by: Leo Liu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: GPU vs CPU page size fixes in amdgpu_vm_bo_split_mapping

2018-06-22T19:57:17+00:00

start / last / max_entries are numbers of GPU pages, pfn / count are
numbers of CPU pages. Convert between them accordingly.

Fixes badness on systems with > 4K page size.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/106258
Reported-by: Matt Corallo 
Tested-by: foxbat@ruin.net
Reviewed-by: Alex Deucher 
Reviewed-by: Christian König 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher

drm/amdgpu: Make amdgpu_vram_mgr_bo_invisible_size always accurate

2018-06-19T18:51:45+00:00

Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least
partially in CPU visible VRAM, in particular when all VRAM is visible.

v2:
* Don't take VRAM mgr spinlock, not needed (Christian König)
* Make loop logic simpler and clearer.

Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher