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: Dave Jones <davej@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
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: Thomas Hellstrom <thomas@tungstengraphics.com>
Signed-off-by: Dave Jones <davej@redhat.com>
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: Linus Torvalds <torvalds@osdl.org>
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: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
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: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Keir Fraser <keir@xensource.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Another large rollup of various patches from Adrian which make things static
where they were needlessly exported.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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!
