PCI_IOMAP(9) Public Functions Provided PCI_IOMAP(9)NAME
pci_iomap - create a virtual mapping cookie for a PCI BAR
SYNOPSIS
void __iomem * pci_iomap(struct pci_dev * dev, int bar, unsigned long maxlen);
ARGUMENTS
dev
PCI device that owns the BAR
bar
BAR number
maxlen
length of the memory to map
DESCRIPTION
Using this function you will get a __iomem address to your device BAR. You can access it using ioread*() and iowrite*(). These functions
hide the details if this is a MMIO or PIO address space and will just do what you expect from them in the correct way.
maxlen specifies the maximum length to map. If you want to get access to the complete BAR without checking for its length first, pass 0
here.
AUTHORS
Matthew Wilcox <matthew@wil.cx>
Author.
Alan Cox <alan@lxorguk.ukuu.org.uk>
Author.
COPYRIGHT Kernel Hackers Manual 3.10 June 2014 PCI_IOMAP(9)
Check Out this Related Man Page
PROTO(4) BSD Kernel Interfaces Manual PROTO(4)NAME
proto -- Driver for prototyping and H/W diagnostics
SYNOPSIS
To compile this driver into the kernel, place the following line in your kernel configuration file:
device proto
Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5):
proto_load="YES"
DESCRIPTION
The proto device driver attaches to PCI devices when no other device drivers are present and creates device special files for all resources
associated with the device. The driver itself has no knowledge of the device it attaches to. Programs can open these device special files
and perform register-level reads and writes. As such, the proto device driver is nothing but a conduit or gateway between user space pro-
grams and the hardware device.
Examples for why this is useful include hardware diagnostics and prototyping. In both these use cases, it is far more convenient to develop
and run the logic in user space. Especially hardware diagnostics requires a somewhat user-friendly interface and adequate reporting. Nei-
ther is done easily as kernel code.
FILES
All device special files corresponding to a PCI device are located under /dev/proto/pci<d>:<b>:<s>:<f> with pci<d>:<b>:<s>:<f> representing
the location of the PCI device in the PCI hierarchy. A location includes:
<d> The PCI domain number
<b> The PCI bus number
<s> The PCI slot or device number
<f> The PCI function number
Every PCI device has a device special file called pcicfg. This device special file gives access to the PCI configuration space. For each
valid base address register (BAR), a device special file is created that contains the BAR offset and the resource type. A resource type can
be either io or mem representing I/O port or memory mapped I/O space (resp.)
EXAMPLES
A single function PCI device in domain 0, on bus 1, in slot 2 and having a single memory mapped I/O region will have the following device
special files:
/dev/proto/pci0:1:2:0/10.mem
/dev/proto/pci0:1:2:0/pcicfg
AUTHORS
The proto device driver and this manual page were written by Marcel Moolenaar <marcel@xcllnt.net>.
SECURITY CONSIDERATIONS
Because programs have direct access to the hardware, the proto driver is inherently insecure. It is not advisable to use this driver on a
production machine.
MISSING FUNCTIONALITY
The proto driver does not yet support interrupts. Since interrupts cannot be handled by the driver itself, they must be converted into sig-
nals and delivered to the program that has registered for interrupts.
In order to test the transmission or reception of data, some means of doing direct memory access (DMA) by the device must be possible. This
too must be under the control of the program. The details of how a program can set up and initiate DMA still need to be fleshed out.
Support for non-PCI devices has not been implemented yet.
BSD April 29, 2014 BSD