Re: mmap cdev function in device drivers
Poul-Henning Kamp had the audacity to say:
A good example to look at is the pci/xrpu.c file, that driver
barely does anything but a mmap.
Poul-Henning
Hey, thanks. That's a great idea. I'll check that out. I've been leafing through
the rather monolithic meteor, brooktree, and even the PCI pcm code.
In message [EMAIL PROTECTED], Peter Edwards writes:
Hi,
Just trying to take some of the aforementioned "magic" out of i386_btop
/ vtop :-)
return( atop(vtophys(bktr-bigbuf) + offset) );
atop (I assume) stands for "address to page" (given a pointer, give the
number of the page it is in)
vtophys is "virtual to physical". (given a pointer in a virtual address
space, find out the physical address of the backing memory.)
My understanding is that mmap(2) will allocate a portion of the calling
process's address space, and for each page it needs to map, will call
the device's mmap function, giving it the calculated offset (and the
protection attributes).
The device's mmap returns the index of the physical page of the memory
to be inserted under the virtual addresses the process sees.
simplified_mmap_syscall_for_device(dev_t device, size_t len, off_t
offset)
{
caddr_t ptr = alloc_address_space(len);
assert(ptr % PAGESIZE == 0);
while (len) {
pageno = device-mmap(offset); /* Call device's mmap */
map_address_to_page(ptr, pageno);
len -= PAGESIZE;
offset += PAGESIZE;
ptr += PAGESIZE;
}
}
So, the call above is returning the page number (of the physical address
(of bktr-bigbuf)).
Of course, My ignorance will probably be corrected in due course!
--
Peter.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
--
Coleman Kane
President,
UC Free O.S. Users Group - http://pohl.ececs.uc.edu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap cdev function in device drivers
I just want to inform you before doing a huge amount of work on this that over a year ago, Stepehen Hocking started work on a 3dfx driver. His work seems to have disappeared from the planet, but you can try to contact him, and you'll probably get some old code to work with maybe :) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: mmap cdev function in device drivers
On 08-May-00 Coleman Kane wrote: the memory region mapped by the PCI BIOS (in this case the 0x100 region between 0xec00 and 0xecff), or an address of a mapped region within kernel memory area? I had it return the former and it crashed the machine, trying to use bus_alloc_resource(...) with the SYS_RES_MEMORY parameter just won't map any memory The return type is the errno for the mmap() call.. You need to inform the VM systems about it. The meat of your mmap call should be - return(i386_btop(vtophys(rman_get_virtual(sc-g_membase.reshandle)) + offset)); rman_get_virtual() gets the kernel virtual address out of the memeory handle, vtophys turns it into a physical address (hmm.. come to think of it I could probably replace those two with rman_get_start), and i386_btop does, err, magic :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap cdev function in device drivers
Daniel O'Connor had the audacity to say: The return type is the errno for the mmap() call.. You need to inform the VM systems about it. The meat of your mmap call should be - return(i386_btop(vtophys(rman_get_virtual(sc-g_membase.reshandle)) + offset)); This is probably what I am missing, is there any documentation on this? I see a number of ways this is done in the source... (from /sys/dev/bktr/bktr_os.c): return( atop(vtophys(bktr-bigbuf) + offset) ); I think I am rather misunderstanding what exactly atop and 1386_btop do... rman_get_virtual() gets the kernel virtual address out of the memeory handle, vtophys turns it into a physical address (hmm.. come to think of it I could probably replace those two with rman_get_start), and i386_btop does, err, magic :) Of course, and I like an idiot am sending it the return of the resource alloc call... it is lsited as type struct resource * in the headers... now, my question is that do I need to alloc vm space for this? The mmap call keeps returning ENOMEM whenever I call it, from userspace. I have it do a bus_alloc_resource on the sysmem, now it returns the right pointer and everything, but is just seems to exhaust the maximum page maps by mapping every 0x1000 region between 0xec00 and 0xed00. I see some drivers using vm_page_alloc_contig to get a large area, but it seems like it's for allocating a local buffer, I am looking at the code for the meteor and bktr devices... --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mmap cdev function in device drivers
Hello, I have taken it upon myself to write a device driver to access the 3dfx voodoo cards, just like the 3dfx linux driver that is available. I am using the linux code as a reference and have come to a brick wall while writing the cdev mmap function. What exactly is the return value of the device_mmap(...) function supposed to be? What the linux driver basically does is it maps the device's memory directly into userland memory, that part of the mmap functionality in FreeBSD 4.0 seems to be handled by the vm, all it seem to want is an address returned, type int, from looking at the other drivers. Is this the address of the memory region mapped by the PCI BIOS (in this case the 0x100 region between 0xec00 and 0xecff), or an address of a mapped region within the kernel memory area? I had it return the former and it crashed the machine, and trying to use bus_alloc_resource(...) with the SYS_RES_MEMORY parameter just won't map any memory -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
