[PATCH 5/5] drm/amd/sched: signal and free remaining fences in amd_sched_entity_fini

Christian König christian.koenig at amd.com
Thu Oct 12 13:50:07 UTC 2017

Am 12.10.2017 um 15:42 schrieb Michel Dänzer:
> On 12/10/17 01:44 PM, Christian König wrote:
>> Am 12.10.2017 um 13:00 schrieb Michel Dänzer:
>>> Anyway, unless anyone knows which commits from amd-staging-drm-next are
>>> needed to make 1d00402b4da2 stable in 4.14, the safe course of action
>>> seems to be reverting it (and ac7afe6b3cf3, which depends on it)?
>> The amdgpu_ttm_bind change should be fixed by "70a9c6b drm/amdgpu: fix
>> placement flags in amdgpu_ttm_bind".
> Indeed, that fixes it for me.
>> But I've assumed they went both into 4.14.
> Unfortunately, it looks like only 1d00402b4da2 made it into 4.14. Alex,
> please send a fixes pull for 4.14 with a backport of 70a9c6b.
> For the other issue, do we want to backport Nicolai's commits
> 6b37d03280a4..318d85de9c20 or revert 6af0883ed977?
> Christian, can you check that there are no other fixes missing from 4.14?

Not that I know of, and manually checking is nearly impossible since I 
don't know what Alex pushed to 4.14 and what not.

Manually checking what went in and what not would take quite some time.

> BTW, this raises an issue: Since we push both fixes and new development
> work to the same internal branch, sometimes it isn't clear which changes
> should go upstream via -fixes or -next. Any ideas for mitigating the
> risk of missing an important fix?
Well we would need to drop that amd-staging-* model and revert back to 
something amd-drm-next-*/amd-drm-fixes-* based.

But that is not something we were able to sell to our internal teams so far.


More information about the amd-gfx mailing list