Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Dec 1998 23:06:23 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        bmcgover@cisco.com
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Aquiring contiguous wired physical memory in the kernel... 
Message-ID:  <199812281506.XAA65889@spinner.netplex.com.au>
In-Reply-To: Your message of "Mon, 28 Dec 1998 09:45:19 EST." <199812281445.JAA04498@bmcgover-pc.cisco.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Brian McGovern wrote:
> I've been looking through the mailing lists for the better part of a half hou
    r
> or so trying to find the answer to this, but it seems that the answers either
> conflict for method, or the answers work for a specific case. So, I'll ask
> the question directly, and hopefully get the "best" answer :)
> 
> I'm about 1/3 of the way through writing a device driver for a high-density
> tty-like device (108 modems in a PCI slot form factor). While the module has
> on-board RAM that I can use for buffering, the device is also capable of usin
    g
> the host's RAM for buffering, which I'd like to take advantage of.
> 
> What I need to be able to do is malloc() a chunk of memory (say 512K-1MB) tha
    t
> is physically contiguous. Then, I need to be able to get the PHYSICAL address
> of this memory chunk, and pass it back off to the board so it can directly
> access the memory.
> 
> Looking through some of the drivers in the pci subdirectory, it appears that
> they use a macro caled vtophys, which calls pmap_kextract, then adds 10737418
    25
> ((1024 * 1024 * 1024) + 1) to the result. Others seem to use kv_top() to get
> the physical address. 
> 
> Anyone care to comment?
> 	-Brian

Well, I'd certainly love to comment on the subject at hand... 108 modem-like
devices on a pci card?  Wow!! :-)  Where do I sign up? :-)

Anyway, what you are looking for is contigmalloc().  It is best to use 
this as early as possible in the system boot before memory gets too 
fragmented.

You can specify an optional upper memory limit (eg: all within bottom 16MB 
for ISA dma), and alignment (ie: start on a 64K boundary), and a sort-of 
region limit (ie: the start and end must be in (say) the same 4MB) chunk.

Cheers,
-Peter




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812281506.XAA65889>