> ** Reply to message from Jeff Hartmann <firstname.lastname@example.org> on Thu, 25 Jan
> 2001 10:04:47 -0700
>>> The problem with this is that between the ioremap and iounmap, the page is
>>> reserved. What happens if that page belongs to some disk buffer or user
>>> process, and some other process tries to free it. Won't that cause a problem?
>> The page can't belong to some other process/kernel component. You own
>> the page if you allocated it.
> Ok, my mistake. I wasn't paying attention to the "get_free_pages" call. My
> problem is that I'm ioremap'ing someone else's page, but my hardware sits on the
> memory bus disguised as real memory, and so I need to poke around the 4GB space
> trying to find it.
As in an MMIO aperture? If its MMIO on the bus you should be able to
just call ioremap with the bus address. By nature of it being outside
of real ram, it should automatically be uncached (unless you've set an
MTRR over that region saying otherwise).
>> (I was the one who added support to
>> the kernel to ioremap real ram, trust me.)
> I really appreciate that feature, because it helps me a lot. Any
> recommendations on how I can do what I do without causing any problems? Right
> now, my driver never calls iounmap on memory that's in real RAM, even when it
> exits. Fortunately, the driver isn't supposed to exit, so all it does is waste
> a few KB of virtual memory.
Look at the functions agp_generic_free_gatt_table and
agp_generic_create_gatt_table in agpgart_be.c (drivers/char/agp). They
do the ioremap_nocache on real ram for the GATT/GART table. Heres some
quick pseudo code as well.
alloc a page
reserve the page
flush every cpu's cache
ioremap_nocache the page
iounmap the page
unreserve the page
free the page
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/