kernel/linux.git/drivers/gpu/drm/amd/scheduler, branch v4.4.171

drm/amdgpu: fix race condition in amd_sched_entity_push_job

2015-12-02T20:04:04+00:00

As soon as we leave the spinlock after the job has been added to the job queue, we can no longer rely on the job's data to be available. I have seen a null-pointer dereference due to sched == NULL in amd_sched_wakeup via amd_sched_entity_push_job and amd_sched_ib_submit_kernel_helper. Since the latter initializes sched_job->sched with the address of the ring scheduler, which is guaranteed to be non-NULL, this race appears to be a likely culprit. Signed-off-by: Nicolai Hähnle Bugzilla: https://bugs.freedesktop.org/attachment.cgi?bugid=93079 Reviewed-by: Christian König

drm/amdgpu: move dependency handling out of atomic section v2

2015-11-23T17:20:15+00:00

This way the driver isn't limited in the dependency handling callback. v2: remove extra check in amd_sched_entity_pop_job() Signed-off-by: Christian König Reviewed-by: Chunming Zhou

drm/amdgpu: optimize scheduler fence handling

2015-11-23T17:19:58+00:00

We only need to wait for jobs to be scheduled when the dependency is from the same scheduler. Signed-off-by: Christian König Reviewed-by: Chunming Zhou

drm/amdgpu: fix incorrect mutex usage v3

2015-11-16T16:05:58+00:00

Before this patch the scheduler fence was created when we push the job into the queue, so we could only get the fence after pushing it. The mutex now was necessary to prevent the thread pushing the jobs to the hardware from running faster than the thread pushing the jobs into the queue. Otherwise the thread pushing jobs into the queue would have accessed possible freed up memory when it tries to get a reference to the fence. So what you get in the end is thread A: mutex_lock(&job->lock); ... Kick of thread B. ... mutex_unlock(&job->lock); And thread B: mutex_lock(&job->lock); .... mutex_unlock(&job->lock); kfree(job); I'm actually not sure if I'm still up to date on this, but this usage pattern used to be not allowed with mutexes. See here as well https://lwn.net/Articles/575460/. v2: remove unrelated changes, fix missing owner v3: rebased, add more commit message Signed-off-by: Christian König Reviewed-by: Alex Deucher

drm/amdgpu: cleanup scheduler fence get/put dance

2015-11-16T16:05:58+00:00

The code was correct, but getting two references when the ownership is linearly moved on is a bit awkward and just overhead. Signed: Christian König Reviewed-by: Alex Deucher

drm/amdgpu: add command submission workflow tracepoint

2015-11-16T16:05:57+00:00

OGL needs these tracepoints to investigate performance issue. Change-Id: I5e58187d061253f7d665dfce8e4e163ba91d3e2b Signed-off-by: Chunming Zhou

drm/amd: add kmem cache for sched fence

2015-11-16T16:05:51+00:00

Change-Id: I45bb8ff10ef05dc3b15e31a77fbcf31117705f11 Signed-off-by: Chunming Zhou Reviewed-by: Christian König

drm/amdgpu: fix stoping the scheduler timeout

2015-11-04T17:29:21+00:00

cancel_delayed_work_sync is forbidden in interrupt context. Signed-off-by: Christian König Reviewed-by: Chunming Zhou Reviewed-by: Alex Deucher

drm/amd/scheduler: don't oops on failure to load

2015-11-03T16:15:29+00:00

In two places amdgpu tries to tear down something it hasn't initalised when failing. This is what happens when you enable experimental support on topaz which then fails in ring init. This patch allows it to fail cleanly. agd: Split out from from the original patch since the scheduler is a driver independent. Reviewed-by: Chunming Zhou Reviewed-by: Christian König Signed-off-by: Dave Airlie Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/amdgpu: ignore scheduler fences from the same entity

2015-10-28T21:04:18+00:00

We are going to submit them before the job anyway. Signed-off-by: Christian König Reviewed-by: Chunming Zhou