- 11 Jun, 2014 24 commits
-
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This will, at some point, be used to replace various bits and pieces of code doing direct bios parsing. For now, it'll just be used for some DP improvements. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
There's also provisions to allow a pad to be locked with a specific routing, for an indefinite period of time. This will be used in future patches. The G94+ pad driver will now also power-down pads when not required. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This was a half-finished hack before, just enough to handle the shared aux/i2c pad thing on G94 and up. We got lucky with locking etc up until now, as this was (generally) all protected by the DRM mode_config lock. It's about to become a lot more likely to hit the races. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Re-uses the implementation's accessor functions rather than requiring and init/fini implementation for each chipset. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We really want this for, at least, MST devices. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Not enabled at the backends yet, but will read status and send back max reached at level 0. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- 10 Jun, 2014 16 commits
-
-
Ilia Mirkin authored
This fixes hangs on GK208 which happen instantaneously on trying to use a geometry shader. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org # v3.14+
-
Mario Kleiner authored
Cards with nv04 display engine can't reliably use vblank counts and timestamps computed via drm_handle_vblank(), as the function gets invoked after sending the pageflip events. Fix this by defaulting to the old crtcid = -1 fallback path on <= NV-50 cards, and only using the precise path on NV-50 and later. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 3.13+
-
Mario Kleiner authored
Whenever a single nouveau_mc_intr() main gpu irq-handler invocation was responsible for calling both, the vblank-irq handler (display engine irq) and kms-pageflip completion handler (from fifo irq), the order of invocation was wrong. nouveau_finish_flip() was called before drm_handle_vblank() for the vblank of pageflip completion, so the emitted pageflip event contained stale vblank count and timestamp from previous vblank. This caused failure in userspace to timestamp properly. Reorder order of invocation of engine irq handlers: Put NVDEV_ENGINE_DISP always on top, and thereby before NVDEV_ENGINE_FIFO, so that drm_handle_vblank() gets called to update vblank timestamps and count before potential pageflip events make use of that information. This works on nv-50 and later, where kms-pageflip completion triggers an irq either after a separate vblank irq, or both pageflip and vblank trigger one common irq invocation, but never before vblank irqs. v2 (Ben): - removed mods for nv04-nv40, it doesn't help there anyway - this is considered a hack, and a better solution should be found Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 3.13+
-
Mario Kleiner authored
nv04_disp_scanoutpos() must abort to trigger simple timestamping fallback if vtotal/htotal regs return zero. This happens if the output isn't a digital output, but a vga analog output, as the regs don't get initialized in that case. Fixes timestamping failure on nv-40 and earlier with vga output. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 3.14+
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Leave debug for the more interesting bits of info. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Use with caution. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
Some adt7473 can't manage the 20µs delay we use for the bitbanging, bumping it to 40µs seem to do the trick. Signed-off-by: Martin Peres <martin.peres@free.fr> Tested-by: Marcel Dopita <mdop@seznam.cz>
-
Martin Peres authored
I spent some time this weekend trying to find in the vbios the number of pulses per revolutions in the vbios but couldn't find it. It would seem all my cards have 2 pulses per revolution so let's stick to that until further notice. Thermal table's id 0x48 may indicate this information but it would seem that changing the value results in the blob power or clock gating the RPM counter... We should ask NVIDIA about that, should be trivial-enough for them to answer. Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
John Rowley authored
Only tested on nvf1, was advised to enable on all. Signed-off-by: John Rowley <john.rowley08@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
John Rowley authored
Signed-off-by: John Rowley <john.rowley08@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-