I'm writing what should be a trivial device driver (implemented as a
module) for a proprietary card with a lot of memory on it. It's a PCI
card, and I've written drivers for it for 4 other OS's. Porting to
linux should be trivial. And indeed, everything was going really
cleanly, until I got to mmapping -- for some reason that I'm not clear
on (and will probably be obvious to everyone else), when I map the
board's memory into user space, I don't see my reads/writes to that
memory go through to the PCI bus. The mmap succeeds, everything looks
happy, but the memory is either cached, mis-directed, or somehow
otherwise confused. Snippets of my code are included below -- I'd
greatly appreciate someone pointing out the mistake in my code.
int
init_module(void) {
.....
pcibios_read_config_dword(bus,
function,
PCI_BASE_ADDRESS_0,
&base0);
base0 &= PCI_BASE_ADDRESS_MEM_MASK;
mem_size = 0x01000000;
mem_base = ioremap(base0, mem_size);
printk(KERN_INFO "mem_base is %x\n", (unsigned)mxt->mem_base);
...
}
static int
my_mmap(struct file *filp, struct vm_area_struct *vma) {
unsigned long paddr = 0, offset = 0, size = 0;
offset = vma->vm_offset;
if (offset & ~PAGE_MASK)
return(-ENXIO);
paddr = base0 + offset;
size = vma->vm_end - vma->vm_start;
vma->vm_flags |= (VM_SHM | VM_LOCKED | VM_IO);
if (remap_page_range(vma->vm_start, paddr, size, vma->vm_page_prot))
return(-EAGAIN);
return(0);
}
The ioremap of base0 works great, I can read and write the device
memory with no problems from kernel space. It's just the userspace
that's messed. Do I need to futz with the vm_page_prot somehow? I
couldn't find any examples of how to do so. My userspace mmap call
looks has PROT_READ|PROT_WRITE and MAP_SHARED passed in.
This is on a Redhat 6.1 system, kernel version 2.2.12-20,
uniprocessor. Note that I'm not sub'd to the list, so please CC me on
any responses please. TIA!
DaveG o_, o, o_ o_ o'
Programmer )-' /|' ),` ) ' (\ ^o Gymnast
Dancer >\ / > >\ >^' >\ >>' Hiker
daveg@mit.edu www.mit.edu/~daveg/ (617)216-4705
dave.golombek@conexant.com www.conexant.com (508)621-0658
-
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 : Thu Jun 15 2000 - 21:00:34 EST