- 04 Mar, 2011 1 commit
-
-
Ben Skeggs authored
The nv30/nv40 3d driver is about to start using DMA_FENCE from the 3D object which, it turns out, doesn't like its DMA object to not be aligned to a 4KiB boundary. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 25 Jan, 2011 1 commit
-
-
Ben Skeggs authored
Signed-off-by:
-
- 17 Jan, 2011 2 commits
-
-
Ben Skeggs authored
Somehow missed this in the original merge of the nvc0 code. Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
- 05 Jan, 2011 1 commit
-
-
Dave Airlie authored
We need to track the state of the switch in drivers, so that after s/r we don't resume the card we've explicitly switched off before. Also don't allow a userspace open to occur if we've switched the gpu off. Signed-off-by:
-
- 30 Dec, 2010 1 commit
-
-
Ben Skeggs authored
Signed-off-by:
-
- 21 Dec, 2010 4 commits
-
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
- 08 Dec, 2010 12 commits
-
-
Francisco Jerez authored
Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
-
Ben Skeggs authored
NVC0 will be able to share some of nv50's paths this way. This also makes it the card-specific vram code responsible for deciding if a given set of tile_flags is valid, rather than duplicating the allowed types in nv50_vram.c and nouveau_gem.c Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
As of this commit, it's guaranteed that if an object is in VRAM that its GPU virtual address will be constant. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This is required on nv50 as we need to be able to have more precise control over physical VRAM allocations to avoid buffer corruption when using buffers of mixed memory types. This removes some nasty overallocation/alignment that we were previously using to "control" this problem. Signed-off-by: -
Ben Skeggs authored
This will be used later to fixup bo.offset with a buffer's fixed GPU virtual address. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Francisco Jerez authored
There have been reports of PFIFO cache errors during context take down (fdo bug 31637). They are caused by some GPU objects being taken out while the channel is still potentially processing commands. Make sure that all the previous rendering has landed before releasing a GPU object. Reported-by:
Grzesiek Sójka <pld@pfu.pl> Reported-by:
Patrice Mandin <patmandin@gmail.com> Signed-off-by:
-
- 03 Dec, 2010 18 commits
-
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Reviewed-by:
-
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
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Lets start to clean up this mess! Reviewed-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
nv0x-nv4x should be mostly fine, nv50 doesn't work yet. 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
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:
-
