On Mon, 17 Jun 2002, Benjamin Herrenschmidt wrote:
>
> > mmap() and AGP driver gives access to IOMEM/AGP
>
> That one is problematic. I don't support the mmap interface properly
> on Apple chipsets for example, because they don't support the AGP
> aperture beeing accessed by the CPU.
I assume you mean that the CPU doesn't honour the AGP mappings, but the
CPU _can_ access the physical pages themselves. How do you do it right
now, since we seem to be doing "ioremap_nocache()" all over the place with
the AGP aperture?
But fundamentally that should not be a problem: we can map the (unmapped)
AGP pages one page at a time (rather than as one contiguous block of
remapped pages) into user mode.
I thought AGP already supported a mmap() interface, and if it really
doesn't, it should be trivial to do...
[ Time passes, Linus looks at the sources ]
Ok, there does seem to be mmap() support in the AGP module, but it seems
to use that stupid "remap_page_range()" and the AGP base (similar to
ioremap() inside the kernel), so it does seem to mmap the _mapped_ AGP
area.
It would be possible to just install a "nopage" handler, and map one page
at a time on demand from the pool of (non-GART-mapped) pages that we keep
in the gatt_table[] or whatever.
Maybe there is some reason for doing it that way that I don't understand.
More likely, it's just done that way because it was the simple and stupid
approach.
However, you seem to prefer a different approach, which would certainly
work:
> I would much prefer the agpgart interface to be redisigned around
> different semantics, mostly vmalloc() some space to use as AGP memory,
> then bind that to the GART, but don't rely on direct AGP aperture
> access.
>
> There are also some slight speed improvements to win using this
> sheme as I could map the AGP memory as cacheable (which would give a
> significant boost on PPC) provided buffers & ring get properly flushed
> before beeing "passed" to the chip.
Hmm.. It would be fairly simple to do all page allocation in user space,
and have an interface that says "put the physical page corresponding to my
virtual address xxxx into the AGP aperture at offset yyyy".
This would effectively disallow the above "map by unmapped page" approach,
because it's too damn expensive to find and flush any existing mappings
when somebody maps in a new page. And if not all systems support the
GART-assisted CPU mapping that we do now, that means that nobody can mmap
the AGP area into memory.
The expensive part would be the "mark this page uncacheable" when moving
it to the AGP buffer, which implies a cross-CPU TLB flush for each such
page. So moving a page into the AGP aperture is fundamentally a fairly
expensive operation: wbinvd itself takes a _loong_ time, but if you have
to do it on all CPU's along with the TLB flush, it gets _really_
expensive.
So moving pages that way is definitely not cheap either. Hmm.
Linus
----------------------------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
