Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!bbn!bbn.com!ajc
From: ajc@bbn.com (Anthony J. Courtemanche)
Newsgroups: comp.sys.mips
Subject: Wiring down physical pages
Keywords: DMA, device drivers
Message-ID: <48553@bbn.COM>
Date: 20 Nov 89 20:12:46 GMT
Sender: news@bbn.COM
Lines: 47


I am trying to write a device driver for a MIPS M2000 and am having
trouble understanding the virtual memory system.  I have 3 simple
questions that unfortunately I couldn't get answered from the MIPS
software support phoneline.  They suggested I try here (which sounded
to me like a big cop-out by the software support people, but maybe
I'll get lucky) so here goes.  I also tried looking at some device
drivers supplied by MIPS, but they all were super complicated and I
couldn't seem to find the answers to my 3 simple questions there
either.

I have a device to plug into the M2000 (running RISC/os 4.20) that
wants to do DMA.  I have three problems that I must solve:

	1) The device needs some contiguous memory to write into.
	   This memory is larger than a physical page (4K). How
	   do I allocate this memory in the device driver?  My current
	   solution is to declare a large global static array in the
	   device driver code.  Either by chance or by design, upon
	   checking, this array IS physically contigous, which is
	   good.  Should I be allocating this memory by another means?

	2) In order to not have any surprises, the virtual memory
	   system better not use these physical pages to map random
	   virtual addresses later on.  These physical pages need to
	   be "wired down" and reserved for this kernel resource.
	   How do I do this?  Upon checking, the static array is in
	   the "kseg0" segment of the kernel, but I do not know
	   whether or not this has any bearing on whether this memory
	   can be swapped or not.  Also, for ease of use, I would like
	   these physical pages to bypass the cache, so that when the
	   device writes into this memory, the cpu won't see stale
	   data still in the cache.  I know there exists the cachectl
	   call to modify the cacheability of specific pages.  Is this
	   the proper call to make in the device driver?

	3) User applications programs will need to access this kernel
	   reserved memory that the device is writing into.  These
	   applications programs just want to map in these physical
	   pages into their own address space and access them as if
	   they were normal addresses in their address space.  How do
	   I do this?

If anyone out there in net-land knows any answers to these, please let
me know.
--Anthony Courtemanche
  ajc@bbn.com