| 330bdf62 | 11-May-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/tmr: avoid processing completed alarms when adding a new one
The idea here was to avoid having to "manually" program the HW if there's
a new earliest alarm. This was lazy and bad, as it
drm/nouveau/tmr: avoid processing completed alarms when adding a new one
The idea here was to avoid having to "manually" program the HW if there's
a new earliest alarm. This was lazy and bad, as it leads to loads of fun
races between inter-related callers (ie. therm).
Turns out, it's not so difficult after all. Go figure ;)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
show more ...
|
| 9fc64667 | 11-May-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm
At least therm/fantog "attempts" to work around this issue, which could
lead to corruption of the pending alarm list.
drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm
At least therm/fantog "attempts" to work around this issue, which could
lead to corruption of the pending alarm list.
Fix it properly by not updating the timestamp without the lock held, or
trying to add an already pending alarm to the pending alarm list....
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
show more ...
|
| 1b0f8438 | 11-May-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/tmr: handle races with hw when updating the next alarm time
If the time to the next alarm is short enough, we could race with HW and
end up with an ~4 second delay until it triggers.
Fi
drm/nouveau/tmr: handle races with hw when updating the next alarm time
If the time to the next alarm is short enough, we could race with HW and
end up with an ~4 second delay until it triggers.
Fix this by checking again after we update HW.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
show more ...
|