Re: ioremap_nocache problem?

Jeff Hartmann (jhartmann@valinux.com)
Thu, 25 Jan 2001 11:13:35 -0700


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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/