Re: kmap_atomic_pfn for PCI BAR access?

[Keith Packard <keithp@keithp.com>]

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

On Thu, 2008-06-26 at 15:02 +1000, Dave Airlie wrote:

> Thats why keithp wants something like kmap_atomic but for ioremap
> instead of kmaps.

Right, the usage is precisely the same as kmap_atomic -- reading and
writing from a wide range of physical addresses without needing either
permanent map nor taking the huge cost of TLB flushing.

The existing kmap_atomic_pfn is exactly what I need (modulo the lack of
prot bits), except that it only handles non-memory pages on kernels with
CONFIG_HIGHMEM set.

It seems like making this function work on non-HIGHMEM kernels would
require only the reservation of the same few PTEs that HIGHMEM kernels
use, along with suitable hacking to make them work.

> This would be for short temporary ioremaps like kmap_atomic is.

For an integrated graphics device, this is just an optimization. I take
physical pages, map them to the graphics GTT which makes them visible to
the CPU up in I/O space. Then, I map address in the GTT back to the CPU
with kmap_atomic_pfn and viola -- WC mapped access to regular pages, all
without touching the low memory mappings.

Before trying this, we just mapped the 'real' address of the page and
then used clflush to get the contents out to memory where the graphics
device could pick it up. However, the clflush is fairly expensive,
enough so that using the WC mapping turns out to be faster in practice.

Beyond simple integrated graphics performance benefits, we're looking
towards discrete graphics cards where we need to write to VRAM which can
only be made visible through the aperture; in that environment, we're
stuck choosing between ioremap (urf) or the same kmap_atomic_pfn as
above. In this case, there's no question that kmap_atomic_pfn will be a
huge performance benefit.

-- 
keith.packard@intel.com

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