Done. There was a bit of fuzz when applying it. Please double check it:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next&id=a7fbb630c5485f5095146df46f04c2ca1a24c299
Thanks,
Alex
Alex
On Fri, Mar 13, 2020 at 10:51 AM Lucas Stach wrote:
>
> Hi Alex,
>
> since you seem to be pickin
Hi Alex,
since you seem to be picking up scheduler patches, can I ask you to
take this one through your tree?
Regards,
Lucas
On Mo, 2020-01-20 at 11:59 +0100, Christian König wrote:
> Am 20.01.20 um 11:51 schrieb Lucas Stach:
> > 1db8c142b6c5 (drm/scheduler: Add drm_sched_suspend/resume_timeout(
On Mo, 2020-01-20 at 11:59 +0100, Christian König wrote:
> Am 20.01.20 um 11:51 schrieb Lucas Stach:
> > 1db8c142b6c5 (drm/scheduler: Add drm_sched_suspend/resume_timeout()) made
> > the job_list_lock IRQ safe in as the suspend/resume calls were expected to
> > be called from IRQ context. This usag
Am 20.01.20 um 11:51 schrieb Lucas Stach:
1db8c142b6c5 (drm/scheduler: Add drm_sched_suspend/resume_timeout()) made
the job_list_lock IRQ safe in as the suspend/resume calls were expected to
be called from IRQ context. This usage never materialized in upstream.
Instead amdgpu started locking the
1db8c142b6c5 (drm/scheduler: Add drm_sched_suspend/resume_timeout()) made
the job_list_lock IRQ safe in as the suspend/resume calls were expected to
be called from IRQ context. This usage never materialized in upstream.
Instead amdgpu started locking the job_list_lock in an IRQ unsafe way in
amdgpu
