Hi all,
Could the resident wizard of memory-management take a couple of minutes
and help me figure out where to go with this?
I have a piece of code that was originally written for a 2.0 series
kernel. The particular function I'm having difficulty porting is
intended to grab a chunk of memory off the top at boot & make it
uncacheable. A'la the "playing dirty" paragraph in Rubini's book. As I
understand from others who have worked with this longer than me, due to
the particular device, it is important that the memory not be cached.
Here is the function, followed by my observations:
static unsigned long mapit(struct thread_struct *tss,
unsigned long va,
unsigned long pa,
int page_count)
{
int i;
unsigned long va_in = va;
/* _printk("mapit: va=%08X pa=%08X pages=%d\n", va, pa, page_count); */
for (i = 0; i < page_count; i++, va += MMU_PAGE_SIZE, pa +=
MMU_PAGE_SIZE)
{
int prot;
/* Set to PAGE_KERNEL */
prot = _PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY |
_PAGE_ACCESSED; MMU_map_page(tss, va, pa, prot);
MMU_disable_cache_for_page(tss, va);
} /* for i */
return(va_in);
} /* END of mapit() */
(This is on a ppc...so I guess if Cort is reading this, maybe he can
comment)
We call it as follows:
/* Map the device into the virual address space */
my_device_base = mapit(tss,
va_my_iobase = end_of_DRAM - MY_MEMORY_SIZE,
pa_my_iobase = MY_PHYSICAL_IOBASE,
MY_MEMORY_SIZE / MMU_PAGE_SIZE);
The first thing I did was s/MMU_PAGE_SIZE/PAGE_SIZE as MMU_PAGE_SIZE
disappeared and both equate to 4096 on this platform anyway.
It appears that MMU_map_page is now replaced by map_page, which doesn't
require the thread_struct. Can someone briefly explain anything I might
want to watch out for when using this? Is it as simple as changing it
to map_page(va, pa, prot)?
Also, it appears that MMU_disable_cache_for_page is gone as well (this
looks to have been a purely ppc-thing). So, how would I go about
disabling caching for a page or range of pages? As far as I can tell,
aside from the use of this call in the code I'm now trying to port, it
appears that the attempt at a BeBox port was the only thing that used
it.
Comments, anyone? (Besides "you're an idiot, go away"?)
Perhaps a better question is...what is "the right way" to grab a large
chunk of RAM from the top of the available pool and make sure that it is
non-cacheable? Obviously, if I wanted to modularize this driver, I
can't really do this...I certainly can't do it as it's being done now.
-- Regards,Darin W. Smith
You know it's a great show when it has dialogue and plotlines like this *every week*: Jordi: "Captain, it's a cloud of quantum humpback lepton micro-silly-string bacteria that could eat through the hull in 5 milliseconds." Picard: "Noted." "Helm, take us directly into the cloud at warp factor 4!" "Engage!" Jordi: "Captain, the cloud is eating through the hull. We have to destroy them." Picard: "We can't do anything about that. This may be a sentient lifeform. We can't violate the Prime Directive."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:18 EST