- 15 Sep, 2014 40 commits
-
-
Emil Velikov authored
nv92 hardware has only 16 interrupt lines, while nv94 and later has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect PDISP setup. This is a regression introduced with commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3 Author: Ben Skeggs <bskeggs@redhat.com> Date: Mon May 12 15:22:42 2014 +1000 gpio: split g92 class from nv50 Reported-by: estece on #nouveau Cc: stable@vger.kernel.org # 3.16+ Signed-off-by:Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
*when* this is done is only a rough approximation of what the binary driver does.. need to investigate more to see if it matters Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Awful, awful. But, on the GK106 I have, some upcoming patches show that this is actually necessary after all. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
All the other chipsets should be moved over to this too. It's not needed yet for the upcoming commits, so left this step as it'll conflict badly with Roy's GT21x reclocking work. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Fixes type/mask calculation being based on uninitialised data for VGA outputs. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
NVIDIA binary driver appears to, not sure if it's for a good reason, but grasping at straws for some GDDR5 reclocking issues here. Signed-off-by: -
Roy Spliet authored
V2: Always disable DLL reset Signed-off-by:
Roy Spliet <rspliet@eclipso.eu> Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Time measured from disabling FB to re-enabling, PPWR_IN reveals status of heads at the end of script. Helps debug various issues (like flicker). Signed-off-by:
-
Roy Spliet authored
Needs to be done after wait-for-VBLANK, and NVA3 requires register writes in between. Rather than hard-coding register writes, just split out fb_disable and fb_enable. v2. Squashed "fb/ramnve0: disable fb before reclocking" Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Martin Peres authored
Signed-off-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Martin Peres authored
One of my nv92 has a calibrated internal sensor but it displays 0°C as the default values use sw calibration values to force the temperature to 0. Since we cannot read the temperature from the adt7473 present on this board, let's re-enable the internal reading! Signed-off-by:
-
Martin Peres authored
We will use this subdev to disable temperature reading on cards that did not get a sensor calibration in the factory. v2: - rename "nouveau_fuse_rd32" to "gxXXX_fuse_rd32" as adviced by Christian Costa - fold the code a little as adviced by Emil Velikov Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Pierre Moreau authored
Signed-off-by:
Pierre Moreau <pierre.morrow@free.fr> Signed-off-by:
-
Pierre Moreau authored
It can help to remove any ambiguity about which options were passed to Nouveau, especially in case the user had some options set in /etc/modprobe.d/*.conf that he forgot about, as they won't appear in a dmesg. Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Martin Peres authored
Signed-off-by: -
Martin Peres authored
Signed-off-by:
-
Martin Peres authored
Signed-off-by:
-
Martin Peres authored
Signed-off-by:
-
Martin Peres authored
The problem with the current implementation is that adding a timer improperly checked which process would time up first by not taking into account how much time elapsed since their timer got scheduled. Rework the re-scheduling decision t fix this. The catch with this fix is that we are limited to scheduling timers of up to 2^31 ticks to avoid any potential overflow. Since we are unlikely to need to wait for more than a second, this won't be a problem :) Another possible fix would be to decrement the timeouts of all processes but it would duplicate a lot of code and dealing with edge cases wasn't pretty last time I checked. Signed-off-by:
-
Martin Peres authored
For some reason, it is now required to wait a 20 µs after the 0x200 reset of the engine. Signed-off-by:
-
Martin Peres authored
v2: change the copyright ownership from "Nouveau Community" to myself, as per Illia's recommendation. Signed-off-by:
-
