- 23 6月, 2011 3 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
gpuobj really needs splitting into channel/gpuobj code instead... Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Removes the need to disable IRQs to lookup channel struct on every pushbuf ioctl, among others. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 16 5月, 2011 4 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
The nouveau_wait_for_idle() call should hopefully not have been actually necessary, we *do* wait for the channel to go idle already. If it's an issue somehow, the chipset-specific hooks can wait for idle themselves before taking the lock. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
This needs a massive cleanup, but to catch bugs from the interface changes vs the engine code cleanup, this will be done later. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
There's lots of more-or-less independant engines present on NVIDIA GPUs these days, and we generally want to perform the same operations on them. Implementing new ones requires hooking into lots of different places, the aim of this work is to make this simpler and cleaner. NV84:NV98 PCRYPT moved over as a test. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 31 3月, 2011 1 次提交
-
-
由 Lucas De Marchi 提交于
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
-
- 25 2月, 2011 2 次提交
-
-
由 Ben Skeggs 提交于
'mappable' isn't really used at all, nor is it necessary anymore as the bo code is capable of moving buffers to mappable vram as required. 'no_vm' isn't necessary anymore either, any places that don't want to be mapped into a GPU address space should allocate the VRAM directly instead. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 07 1月, 2011 1 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 30 12月, 2010 1 次提交
-
-
由 Ben Skeggs 提交于
Current 3D driver expects this behaviour. While this could be changed, there's no compelling reason to reserve more than one subchannel for the DRM. If we ever need to use an object other then M2MF, we can just re-bind subchannel 0 as required. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 27 12月, 2010 1 次提交
-
-
由 Michel Hermier 提交于
When hacking the libdrm for improvements, I triggered a kernel crash related to the fact that the NOUVEAU_NOTIFIEROBJ_ALLOC ioctl calls nouveau_channel_get with an unchecked channel index. The patch ensures that the channel index is an unsigned and validates its value in nouveau_channel_get. Signed-off-by: NMichel Hermier <hermier@frugalware.org> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 21 12月, 2010 1 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 08 12月, 2010 3 次提交
-
-
由 Ben Skeggs 提交于
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: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
The regs belong to PFIFO, they're different for pretty much the same generations we need different PFIFO control for, and NVC0 is going to be even more different than the rest. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
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: NGrzesiek Sójka <pld@pfu.pl> Reported-by: NPatrice Mandin <patmandin@gmail.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Acked-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 03 12月, 2010 12 次提交
-
-
由 Ben Skeggs 提交于
Reviewed-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
nv0x-nv4x should be mostly fine, nv50 doesn't work yet. Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
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: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
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: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
nouveau_channel_ref() takes a "weak" channel reference that doesn't prevent the hardware channel resources from being released, it just keeps the channel data structure alive. Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
nouveau_channel_put() can be executed after the 'refcount == 0' check in nouveau_channel_get() and before the channel reference count is incremented. In that case CPU0 will take the context down while CPU1 thinks it owns the channel and 'refcount == 1'. Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
The destroy_context() engine hooks call gpuobj management functions to release the channel resources, these functions use HARDIRQ-unsafe locks whereas destroy_context() is called with the HARDIRQ-safe context_switch_lock held, that's a lock ordering violation. Push the engine-specific channel destruction logic into destroy_context() and let the hardware-specific code lock and unlock when it's actually needed. Change the engine destruction order to avoid a race in the small gap between pgraph and pfifo context uninitialization. Reported-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
This fixes a race condition between fbcon acceleration and TTM buffer moves. To reproduce: - start X - switch to vt and "while (true); do dmesg; done" - switch to another vt and "sleep 2 && cat /path/to/debugfs/dri/0/evict_vram" - switch back to vt running dmesg We don't make use of this on any other channel yet, they're currently protected by drm_global_mutex. This will change in the near future. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 05 10月, 2010 2 次提交
-
-
由 Ben Skeggs 提交于
Nouveau will need this on GeForce 8 and up to account for the GPU reordering physical VRAM for some memory types. Reviewed-by: NJerome Glisse <jglisse@redhat.com> Acked-by: NThomas Hellström <thellstrom@vmware.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Mainly to make room for inter-channel sync. Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 24 9月, 2010 2 次提交
-
-
由 Ben Skeggs 提交于
Reviewed-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 17 8月, 2010 1 次提交
-
-
由 Dave Airlie 提交于
With the current screwed but its ABI, ioctls for the drm, Linus pointed out that we could allow userspace to specify the allocation size, but we pass it to the driver which then uses it blindly to store a struct. Now if userspace specifies the allocation size as smaller than the driver needs, the driver can possibly overwrite memory. This patch restructures the driver ioctls so we store the structure size we are expecting, and make sure we allocate at least that size. The copy from/to userspace are still restricted to the size the user specifies, this allows ioctl structs to grow on both sides of the equation. Up until now we didn't really use the DRM_IOCTL defines in the kernel, so this cleans them up and adds them for nouveau. v2: fix nouveau pushbuf arg (thanks to Ben for pointing it out) Reported-by: NLinus Torvalds <torvalds@linuxfoundation.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 7月, 2010 2 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Nouveau will no longer load at all if card initialisation fails, so all these checks are unnecessary. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 01 6月, 2010 1 次提交
-
-
由 Jordan Crouse 提交于
Remove the drm_resource wrappers and directly use the actual PCI and/or platform functions in their place. [airlied: fixup nouveau properly to build] Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Reviewed-by: NMatt Turner <mattst88@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 09 4月, 2010 1 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 25 2月, 2010 2 次提交
-
-
由 Ben Skeggs 提交于
This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
-
由 Ben Skeggs 提交于
This allows us to submit push buffers from any memtype to the hardware. We'll need this ability for VRAM index buffers at some point. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-