LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [RFC] iomap_atomic_prot_pfn()
@ 2008-03-10 16:08 Thomas Hellström
0 siblings, 0 replies; only message in thread
From: Thomas Hellström @ 2008-03-10 16:08 UTC (permalink / raw)
To: Linux Kernel list
For the new DRM graphics memory manager, there is a need to map and
patch graphics command buffers from within the kernel. When the memory
manager has sorted out where the buffers are located, the command stream
and state buffers need to be patched up with references to the new
locations. At this point, the buffers are usually located in graphics
memory or bound to the AGP aperture.
So there is a need to do quick map - write - unmap of a single or
possibly a pair of these pages, and it seems something like
kmap_atomic() would be the best thing, in order to avoid IPI tlb flushing.
It seems like ioremap_nocache() is too slow, and it's not really an
option to permanently map a large area of graphics memory or AGP
So I've considered implementing something like the following:
void *iomap_atomic_prot_pfn(unsigned long pfn, enum km_type type,
Initially at least on some architectures: x86 and ppc.
But there are some options:
1) Reuse the fixmap kmap_atomic KM_USER? and KM_IRQ? slots on
architectures that support them, and add them to the fixmap of the other.
2) Add completely new fixmap slots on all architectures, starting with
the ones listed above.
3) Don't do any of this, but allocate some permanent ptes using vmap()
and hack those ptes within the driver when needed.
So basically I'm asking for some guidance on which is the preferred
method to do this. Any comments appreciated.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2008-03-10 16:25 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-10 16:08 [RFC] iomap_atomic_prot_pfn() Thomas Hellström
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).