- 05 2月, 2008 1 次提交
-
-
由 Dave Airlie 提交于
This bumps the AGP interface to 0.103. Certain Intel chipsets contains a global write buffer, and this can require flushing from the drm or X.org to make sure all data has hit RAM before initiating a GPU transfer, due to a lack of coherency with the integrated graphics device and this buffer. This just adds generic support to the AGP interfaces, a follow-on patch will add support to the Intel driver to use this interface. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 30 1月, 2008 1 次提交
-
-
由 Ingo Molnar 提交于
Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 15 10月, 2007 1 次提交
-
-
由 Dave Airlie 提交于
With Andi's clflush fixup, we were getting hangs on server exit, flushing the mappings after freeing each page helped. This showed up a race condition where the pages after being freed could be reused before the agp mappings had been flushed. Flushing after each single page is a bad thing for future drm work, so make the page destroy a two pass unmapping all the pages, flushing the mappings, and then destroying the pages. Signed-off-by: NDave Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
- 10 7月, 2007 1 次提交
-
-
由 Dave Jones 提交于
Most of the AGP changes recently have been done in lock-step with DRM updates, so it's probably easier to have airlied pushing AGP changes at the same time he does DRM updates. [Also remove my name from the boot messages. Cautionary tale to others: Never do this, when computers don't boot, people assume you're responsible even if 15 other subsystems initialised after yours. :-) ] Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 04 2月, 2007 1 次提交
-
-
由 Thomas Hellstrom 提交于
This patch allows drm to populate an agpgart structure with pages of its own. It's needed for the new drm memory manager which dynamically flips pages in and out of AGP. The patch modifies the generic functions as well as the intel agp driver. The intel drm driver is currently the only one supporting the new memory manager. Other agp drivers may need some minor fixing up once they have a corresponding memory manager enabled drm driver. AGP memory types >= AGP_USER_TYPES are not populated by the agpgart driver, but the drm is expected to do that, as well as taking care of cache- and tlb flushing when needed. It's not possible to request these types from user space using agpgart ioctls. The Intel driver also gets a new memory type for pages that can be bound cached to the intel GTT. Signed-off-by: NThomas Hellstrom <thomas@tungstengraphics.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 12 8月, 2006 1 次提交
-
-
由 Dave Jones 提交于
Signed-off-by: NDave Jones <davej@redhat.com>
-
- 28 2月, 2006 1 次提交
-
-
由 Dave Jones 提交于
Eliminate trailing whitespace. s/if(/if (/ s/for(/for (/ Signed-off-by: NDave Jones <davej@redhat.com>
-
- 17 11月, 2005 1 次提交
-
-
由 Dave Jones 提交于
It's never written to. Noted by Arjan van de Ven Signed-off-by: NDave Jones <davej@redhat.com>
-
- 10 11月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
AGP shouldn't use "global_flush_tlb()" to flush the AGP mappings, that i spurely an x86'ism. The proper AGP mapping flusher that should be used is "flush_agp_mappings()", which on x86 obviously happens to do a global TLB flush. This makes AGP (or at least the config _I_ happen to use) compile again on ppc64. Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 09 11月, 2005 1 次提交
-
-
由 Alan Hourihane 提交于
AGP allocation/deallocation is suffering major performance issues due to the nature of global_flush_tlb() being called on every change_page_attr() call. For small allocations this isn't really seen, but when you start allocating 50000 pages of AGP space, for say, texture memory, then things can take seconds to complete. In some cases the situation is doubled or even quadrupled in the time due to SMP, or a deallocation, then a new reallocation. I've had a case of upto 20 seconds wait time to deallocate and reallocate AGP space. This patch fixes the problem by making it the caller's responsibility to call global_flush_tlb(), and so removes it from every instance of mapping a page into AGP space until the time that all change_page_attr() changes are done. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NAndrew Morton <akpm@osdl.org>
-
- 21 10月, 2005 1 次提交
-
-
由 Dave Jones 提交于
Signed-off-by: NDave Jones <davej@redhat.com>
-
- 11 9月, 2005 1 次提交
-
-
由 Jesper Juhl 提交于
This patch does a full cleanup of 'NULL checks before vfree', and a partial cleanup of calls to kfree for all of drivers/ - the kfree bit is partial in that I only did the files that also had vfree calls in them. The patch also gets rid of some redundant (void *) casts of pointers being passed to [vk]free, and a some tiny whitespace corrections also crept in. Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 08 6月, 2005 1 次提交
-
-
由 Keir Fraser 提交于
When Linux is running on the Xen virtual machine monitor, physical addresses are virtualised and cannot be directly referenced by the AGP GART. This patch fixes the GART driver for Xen by adding a layer of abstraction between physical addresses and 'GART addresses'. Architecture-specific functions are also defined for allocating and freeing the GATT. Xen requires this to ensure that table really is contiguous from the point of view of the GART. These extra interface functions are defined as 'no-ops' for all existing architectures that use the GART driver. Signed-off-by: NKeir Fraser <keir@xensource.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 01 5月, 2005 1 次提交
-
-
由 Adrian Bunk 提交于
Another large rollup of various patches from Adrian which make things static where they were needlessly exported. Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-