[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1224376691.4384.105.camel@koto.keithp.com>
Date: Sat, 18 Oct 2008 17:38:11 -0700
From: Keith Packard <keithp@...thp.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: keithp@...thp.com, Linus Torvalds <torvalds@...ux-foundation.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Dave Airlie <airlied@...ux.ie>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
dri-devel@...ts.sf.net, Andrew Morton <akpm@...ux-foundation.org>,
Yinghai Lu <yinghai@...nel.org>
Subject: Re: [git pull] drm patches for 2.6.27-rc1
On Sun, 2008-10-19 at 00:32 +0200, Ingo Molnar wrote:
> the _real_ remapping in a graphics aperture happens on the GPU level
> anyway, you manage an in-RAM GPU pagetable that just works like an
> IOMMU, correct?
Yes, a one-level linear MMU which uses BIOS-reserved memory.
So, at least for a prototype, on 64-bit we can just use ioremap_wc and
hold the mapping while the driver is open? Is there any huge benefit to
using the kernel mapping?
> so on 32-bit we have the INVLPG TLB overhead and preemption restrictions
> - but we knew that. We'd have to allow atomic_kmap() on non-highmem as
> well but that's fair.
Yes, the non-highmem case is currently in fairly bad shape.
> Mind sending patches for this? :-)
I've got Venki lined up to do this work for me; once we're happy enough
with the API. In particular, the non-highmem 32-bit case seems a bit
tricky.
Also, does anyone have a better set of names for this stuff?
io_reserve_pci_mapping seems fairly ugly to me.
--
keith.packard@...el.com
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists