- 24 Feb, 2011 35 commits
-
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
'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: Ben Skeggs <bskeggs@redhat.com>
-
Benjamin Franzke authored
Assign correct event when initializing nouveau_page_flip_state. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Marcin Slusarz authored
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Marcin Slusarz authored
The code was supposed to print registers around 0x405018 (which is read earlier), not 0x405818. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> 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
The hw doesn't really appear to be designed to be used the way we have to use it due to DRI2's design. This leads us to having to keep the flipped fb support active at all times. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Also imports a couple of helper functions that'll be used to implement page flipping in the following commits.. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Just a cleanup, to avoid duplicating parts of nv50_crtc.c's code in the page flipping routines. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This should prevent a number of races from occuring, the most obvious of which will be exposed when we start making use of the "display sync" evo channel for page flipping. The DS channel will reject any command stream that doesn't completely agree with the current "master" state. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We need to be able to have the bh run while possibly spinning waiting for the EVO notifier to signal. This apparently happens in some circumstances with preempt disabled, so our workqueue was never being run. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
The nv50 display isr bh needs to be converted to a tasklet, which means we can't sleep anymore. The places we execute vbios init tables are rare, and not in any way performance critical, so this isn't a huge problem. 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
More appropriate, and we're about to be using more than just the master EVO channel. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Tejun Heo authored
With cmwq, there's no reason for nouveau to use a dedicated workqueue. Drop dev_priv->wq and use system_wq instead. Each work item is sync flushed when the containing structure is unregistered/destroyed. Note that this change also makes sure that nv50_gpio_handler is not freed while the contained work item is still running. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Lucas Stach authored
Signed-off-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This gives a small, but noticeable performance gain at lower performance levels, and unchanged at the higher ones. With this commit, we're now using the same timeslice size as the NVIDIA binary driver currently does, and dropping an unknown bit that NVIDIA no longer appear to set. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We may well be making more use of semaphores in the future, having the entire VM available makes requiring DMA objects for each and every semaphore block unnecessary. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Evil, evil chipset. Worst of both worlds. 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
And also, don't disable PFIFO IRQs completely whenever we recieve one, just when we don't know about it already. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
These are the same semaphores nvc0 will use, and they potentially allow us to do much cooler things than our current inter-channel sync impl. Lets switch to them where possible now for some testing. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
v2. moved nv44 pciegart table back to instmem, where it's not accessible by userspace clients. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
In preparation for the addition of a new nv40 backend, we'll need to be able to distinguish between a paged dma object and the on-chip GART. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
In preparation for the addition of a new nv40 pcie backend. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
-
- 23 Feb, 2011 5 commits
-
-
Dave Airlie authored
This reverts commit 5a893fc2. This causes a use after free in the ttm free alloc pages path, when it tries to get the be after the be has been destroyed. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
* drm-mm-cleanup: radeon: move blit functions to radeon_asic.h radeon: kill decls for inline functions radeon: consolidate asic-specific function decls for r600 & later drm/radeon: kill radeon_bo->gobj pointer drm/radeon: introduce gem_to_radeon_bo helper drm/radeon: embed struct drm_gem_object drm: mm: add helper to unwind scan state drm: mm: add api for embedding struct drm_mm_node drm: mm: extract node insert helper functions drm: mm: track free areas implicitly drm/nouveau: don't munge in drm_mm internals
-
Dave Airlie authored
Merge branch 'stable/ttm.pci-api.v5' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into drm-next * 'stable/ttm.pci-api.v5' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: ttm: Include the 'struct dev' when using the DMA API. nouveau/ttm/PCIe: Use dma_addr if TTM has set it. radeon/ttm/PCIe: Use dma_addr if TTM has set it. ttm: Expand (*populate) to support an array of DMA addresses. ttm: Utilize the DMA API for pages that have TTM_PAGE_FLAG_DMA32 set. ttm: Introduce a placeholder for DMA (bus) addresses.
-
Chris Wilson authored
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Chris Wilson authored
Using an order 19 drm_ht for the mmap offsets is a little obscene. That means that will a fully populated GTT with every single object mmaped at least once in its lifetime, there will be exactly one object in each bucket. Typically systems only have at most a few thousand objects, though you may see a KDE desktop hit 50000. And most of those should never be mapped... On my systems, just using an order 10 ht would still have an average occupancy less than 1, so apply a small safety factor and use an order 12 ht, like the other mmap offset ht. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
-