* Keith Packard <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-10-19 at 19:53 +0200, Ingo Molnar wrote:
>
> > Note how simple and consistent it all gets: IO resources already
> > know their physical location and their size limits. Being able to
> > cache an ioremap in a mapping [and being able to use atomic kmaps on
> > 32-bit] is a relatively simple and natural extension to the concept.
>
> I'm not sure I see any value in caching mappings here; we're mostly
> interested in copying lots of data onto the card and so we use a lot
> of different mappings; atomic mappings are easy to use, and efficient
> enough.
yes but note that by caching the whole mapping on 64-bit we get
everything we want: trivially lockless, works from any CPU, can be
preempted at will, and there are no ugly INVLPG flushes anywhere.
you'll even get 2MB mappings automatically, if the BAR is aligned and
sized correctly.
32-bit we should handle as well but not design for it.
Ingo
-------------------------------------------------------------------------
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
