Re: ioremap_nocache problem?

[Jeff Hartmann <jhartmann@valinux.com>]

Timur Tabi wrote:

> ** Reply to message from Jeff Hartmann <jhartmann@valinux.com> on Thu, 25 Jan
> 2001 10:47:13 -0700
> 
> 
> 
>> 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).
> 
> 
> It's not outside of real RAM.  The device is inside real RAM (it sits on the
> DIMM itself), but I need to poke through the entire 4GB range to see how it
> responds.
> 
> 
>> 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.
> 
> 
> Unfortunately, the memory they remap is allocated:
> 
> table = (char *) __get_free_pages(GFP_KERNEL, page_order);
> 
> ...
> 
> CACHE_FLUSH();
> agp_bridge.gatt_table = ioremap_nocache(virt_to_phys(table), (PAGE_SIZE * (1 <<
> page_order)));
> CACHE_FLUSH();
> 
> I've searched high and low for examples of code that does what I do, and I
> can't find any.

You need to have your driver in the early bootup process then.  When 
memory is being detected (but before the free lists are created.), you 
can set your page as being reserved.  Then the kernel will leave it 
alone when it creates its free lists.  This does mean that this driver 
can not be a module and that it must run at least part of itself in the 
early bootup process.  I don't remember exactly where you need to do 
this, you might try looking at arch/i386/mm/init.c (Just an educated guess.)

-Jeff

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/