On Sat, 2008-10-18 at 12:31 -0700, Linus Torvalds wrote: > The important thing is that mappings need to be per-CPU, so the above may > work, but only if it's designed so that "io_reserve_pci_resource()" will > actually reserve space for 'nr_possible_cpu' page mappings, and then the > "io_[un]map_atomic()" functions do per-CPU mappings.
Yes, of course. The goal is to make it look exactly like kmap_atomic_pfn, but work on non-memory pages even on non-HIGHMEM configs for x86 (we have to use ioremap on those systems today, which is a fairly significant performance problem). > And quite frankly, even so, we'd possibly still be _better_ off with just > exposing the "kmap_atomic_pfn()" functionality even so. Because quite > frankly, your "io_reserve_pci_resource()" infrastructure is going to > inevitably be more complex and slower than the rather efficient > kmap_atomic_pfn() thing we have. I want it to work just like kmap_atomic_pfn; Venki wanted some way to "know" that no-one else was mapping the pages in non-WC mode. This seemed like a reasonable compromise; the 'mapping' object exists solely to hold the desired prot value to keep all PTEs consistent across the whole system. > One small detail: our we currently have "kmap_atomic_pfn()" and > "kmap_atomic_prot()", and we really should maek the fundamental core > operation be "kmap_atomic_pfn_prot()", and have everything be done in > terms of that. Looking at it, it also looks like kmap_atomic_prot() is > actually incorrect right now, and doesn't do a "prot" thing for > non-highmem pages, but just returns "page_address(page);" Fortunately, we use kmap_atomic_pfn only for our BAR, which is not a non-highmem page. Right now, we're counting on having our BAR covered by an MTRR register so that we get WC access here. I'd like to have the API expose this so that the driver will work on systems which don't have a spare MTRR for the graphics aperture. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel