ioremap, virt_to_phys and pcidev->base_address consistency issues
loic at myri.com
loic at myri.com
Thu Jun 17 10:23:58 EST 1999
[ I am not currently subscribed to all the mailing-lists, sorry
if this issue has been brought recently]
Hello,
I am looking for a simple way to map PCI memory space to both kernel
and user-space, and to map kernel memory to user-space.
ioremap, virt_to_phys and the base_address field of the pci_dev
structure have different meaning across architectures which makes it
more difficult that needed, to support all the linux archs.
Here is the status of things as I understand it:
ioremap function:
x86:
take a physical==bus address (note there is both ioremap and
ioremap_nocache. On >= P6 processors, if the kernel is not compiled
with mtrr support, the "cacheability" behaviour of plain ioremap may
depend on the BIOS, so you may want to use ioremap_nocache instead)
Alpha:
take a virtual kernel address
sparc64:
powerpc:
take a physical address
pcidev->base_address:
x86:
base_adress register === bus address + type bits
alpha:
gives a "special address" that code the bus number + bus base
address" meant to be used with the alpha specific dense_mem function.
sparc64:
gives the kernel virtual address to access the device from kernel
powerpc:
has some hacks so that it gives the physical address for some devices,
gives the bus address the rest of the time
virt_to_phys:
x86, Alpha, powerpc:
same than __pa() => give physical address
sparc64:
same than virt_to_bus => gives DMAable PCI bus address
(so I just use __pa now instead of virt_to_phys).
So what would be the right person to contact to try to make things
more consistent? Is there currently a standard way to map PCI memory
space both in the kernel and in user-space aside from using some
#ifdefs?
Loic PRYLLI
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
More information about the Linuxppc-dev
mailing list