- 03 Dec, 2010 40 commits
-
-
Ben Skeggs authored
Reviewed-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Allows callers to install their own handlers for when a GPIO line changes state (such as for hotplug detect). This also fixes a bug where we weren't acknowledging the GPIO IRQ until after the bottom half had run, causing a severe IRQ storm in some cases. Reviewed-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Lets start to clean up this mess! Reviewed-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Francisco Jerez authored
Reported-by:
Pekka Paalanen <pq@iki.fi> Signed-off-by:
-
Francisco Jerez authored
Signed-off-by:
Xavier Chantry <chantry.xavier@gmail.com> Signed-off-by:
-
Francisco Jerez authored
The point is to share more code between the PFB/PGRAPH tile region hooks, and give the hardware specific functions a chance to allocate per-region resources. Signed-off-by:
-
Francisco Jerez authored
nouveau_bo_move_m2mf() needs to lock the kernel channel, and it may be called from the pushbuf IOCTL with an user channel already locked. Use a separate subclass for the kernel channel mutex because this is legitimate mutex nesting. Signed-off-by:
-
Francisco Jerez authored
In a multihead setup vblank interrupts may end up enabled in both heads. In that case we want to ignore the vblank interrupts coming from the wrong CRTC to avoid tearing and unbalanced calls to drm_vblank_get/put (fdo bug 31074). Reported-by:
Felix Leimbach <felix.leimbach@gmx.net> Signed-off-by:
-
Francisco Jerez authored
Signed-off-by:
-
Francisco Jerez authored
nv0x-nv4x should be mostly fine, nv50 doesn't work yet. Signed-off-by:
-
Francisco Jerez authored
Signed-off-by:
-
Francisco Jerez authored
Signed-off-by:
-
Marcin Slusarz authored
nouveau_fence_* functions are not type safe, which could lead to bugs. Additionally every use of nouveau_fence_unref had to cast struct nouveau_fence to void **. Fix it by renaming old functions and creating static inline functions with new prototypes. We still need old functions, because we pass function pointers to ttm. As we are wrapping functions, drop unused "void *arg" parameter where possible. Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Only supported on NV50+ so far, and disabled by default currently. The module parameter "msi=1" will enable it. There's a kernel bug which will cause this to fail if the module (or the NVIDIA binary driver) has ever been loaded before loading nouveau with MSI enabled. As such, this is only safe to enable if you have nouveau load on boot, and don't wish to ever reload it. The workaround is to "echo 0 > /sys/bus/pci/devices/<device>/enable" until the enable count reads 0. Then you should be able to load nouveau with MSI enabled. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Not an issue right now, we're forced to 64k size/alignment by the BO allocator anyway. This won't be the case soon. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This doesn't work yet for unknown reasons. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This really needs cleaning up somehow, and probably investigate what's needed to do this on earlier generations. NVIDIA do something similar there too. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We previously added all the available classes for the entire generation, even though the objects wouldn't work on the hardware. Signed-off-by: -
Ben Skeggs authored
The structs themselves, as well as the non-sw object creation function are probably very misnamed now. That's a problem for later :) Signed-off-by: -
Ben Skeggs authored
We will eventually want to address hw engines other than PGRAPH. Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
