path: root/drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c
AgeCommit message (Collapse)Author
2017-06-06drm/nouveau/tmr: fully separate alarm execution/pending listsBen Skeggs
Reusing the list_head for both is a bad idea. Callback execution is done with the lock dropped so that alarms can be rescheduled from the callback, which means that with some unfortunate timing, lists can get corrupted. The execution list should not require its own locking, the single function that uses it can only be called from a single context. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2017-05-12drm/nouveau/tmr: avoid processing completed alarms when adding a new oneBen Skeggs
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
2017-05-12drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarmBen Skeggs
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
2017-05-12drm/nouveau/tmr: handle races with hw when updating the next alarm timeBen Skeggs
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
2016-05-20drm/nouveau/core: remove pmc_enable argument from subdev ctorBen Skeggs
These are now specified directly in the MC subdev. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/tmr: convert to new-style nvkm_subdevBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/tmr: type-safe PTIMER-based delay/wait macrosBen Skeggs
These require an explicit struct nvkm_device pointer, unlike the previous macros which take a void *, and work for (almost) anything derived from nvkm_object by using some heuristics. These macros are more general than the previous ones, and can be used to handle PTIMER-based busy-waits (will be used in later devinit fixes) as well as more complicated wait conditions. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/tmr: switch to device pri macrosBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/tmr: cosmetic changesBen Skeggs
This is purely preparation for upcoming commits, there should be no code changes here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-22drm/nouveau/timer: namespace + nvidia gpu names (no binary change)Ben Skeggs
The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-22drm/nouveau: remove symlinks, move core/ to nvkm/ (no code changes)Ben Skeggs
The symlinks were annoying some people, and they're not used anywhere else in the kernel tree. The include directory structure has been changed so that symlinks aren't needed anymore. NVKM has been moved from core/ to nvkm/ to make it more obvious as to what the directory is for, and as some minor prep for when NVKM gets split out into its own module (virt) at a later date. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>