Re: [git pull] drm patches for 2.6.27-rc1

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

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.

-- 
keith.packard@intel.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]