linux-toradex.git/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h, branch v4.14-rc5

drm/amdgpu: fix amdgpu_ring_write_multiple

2017-07-14T15:05:56+00:00

Overwriting still used ring content has a low probability to cause
problems, not writing at all has 100% probability to cause problems.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
Acked-by: Felix Kuehling

drm/amdgpu: move ring helpers to amdgpu_ring.h

2017-07-14T15:05:56+00:00

Keep them where they belong.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
Acked-by: Felix Kuehling

drm/amdgpu: Move compute vm bug logic to amdgpu_vm.c

2017-06-01T20:00:20+00:00

  In review, Christian would like to keep the logic
  inside amdgpu_vm.c with a cost of slightly slower.
  The loop is still optimized out with this patch.

v2: remove the if statement. Now it is not slower.

Signed-off-by: Alex Xie 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher

drm/amdgpu: guarantee bijective mapping of ring ids for LRU v3

2017-05-31T20:49:03+00:00

Depending on usage patterns, the current LRU policy may create a
non-injective mapping between userspace ring ids and kernel rings.

This behaviour is undesired as apps that attempt to fill all HW blocks
would be unable to reach some of them.

This change forces the LRU policy to create bijective mappings only.

v2: compress ring_blacklist
v3: simplify amdgpu_ring_is_blacklisted() logic

Signed-off-by: Andres Rodriguez 
Reviewed-by: Nicolai Hähnle 
Signed-off-by: Alex Deucher

drm/amdgpu: implement lru amdgpu_queue_mgr policy for compute v4

2017-05-31T20:49:02+00:00

Use an LRU policy to map usermode rings to HW compute queues.

Most compute clients use one queue, and usually the first queue
available. This results in poor pipe/queue work distribution when
multiple compute apps are running. In most cases pipe 0 queue 0 is
the only queue that gets used.

In order to better distribute work across multiple HW queues, we adopt
a policy to map the usermode ring ids to the LRU HW queue.

This fixes a large majority of multi-app compute workloads sharing the
same HW queue, even though 7 other queues are available.

v2: use ring->funcs->type instead of ring->hw_ip
v3: remove amdgpu_queue_mapper_funcs
v4: change ring_lru_list_lock to spinlock, grab only once in lru_get()

Signed-off-by: Andres Rodriguez 
Signed-off-by: Alex Deucher

drm/amdgpu: Optimize a function called by every IB sheduling

2017-05-31T18:16:38+00:00

  Move several if statements and a loop statment from
  run time to initialization time.

Signed-off-by: Alex Xie 
Reviewed-by: Chunming Zhou 
Signed-off-by: Alex Deucher

drm/amdgpu: add vcn enc ring type and functions

2017-05-24T21:41:41+00:00

Add the ring function callbacks for the encode rings.

Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: add a ring func for vcn start command

2017-05-24T21:41:31+00:00

Needed for the proper command sequence for VCN.

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

drm/amdgpu: add vcn decode ring type and functions

2017-05-24T21:41:25+00:00

Add the ring function callbacks for the decode ring.

Signed-off-by: Leo Liu 
Acked-by: Chunming Zhou 
Acked-by: Hawking Zhang 
Signed-off-by: Alex Deucher

drm/amdgpu/SRIOV:implement guilty job TDR for(V2)

2017-05-24T21:40:40+00:00

1,TDR will kickout guilty job if it hang exceed the threshold
of the given one from kernel paramter "job_hang_limit", that
way a bad command stream will not infinitly cause GPU hang.

by default this threshold is 1 so a job will be kicked out
after it hang.

2,if a job timeout TDR routine will not reset all sched/ring,
instead if will only reset on the givn one which is indicated
by @job of amdgpu_sriov_gpu_reset, that way we don't need to
reset and recover each sched/ring if we already know which job
cause GPU hang.

3,unblock sriov_gpu_reset for AI family.

V2:
1:put kickout guilty job after sched parked.
2:since parking scheduler prior to kickout already occupies a
while, we can do last check on the in question job before
doing hw_reset.

TODO:
1:when a job is considered as guilty, we should mark some flag
in its fence status flag, and let UMD side aware that this
fence signaling is not due to job complete but job hang.

2:if gpu reset cause all video memory lost, we need introduce
a new policy to implement TDR, like drop all jobs not yet
signaled, and all IOCTL on this device will return ERROR
DEVICE_LOST.
this will be implemented later.

Signed-off-by: Monk Liu 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher