|
devLib2
2.11
|
The PCI bus implementation for Linux uses the Userspace IO kernel API to access the bus. Devices needing only memory mapped I/O access do not require a kernel driver. To support PCI style interrupts a minimal kernel module using the Linux UIO framework is required. Devices which implement generic interrupt enable/disable via the PCI control register may user the generic 'uio_pci_generic' kernel module. Otherwise this must either be written for each device to be supported.
It is important to consider writing a full kernel module. The advantage of the UIO interface is simpler development with access to userspace tools and safeguards. Also compatibility with RTEMS and vxWorks. The disadvantage is increased latency, being forced to be compatible with RTEMS and vxWorks, and being restricted in use to EPICS code.
It is likely that devices needing low latency, high throughput, or access to features like DMA would be better served by writing a full kernel module.
When servicing interrupts from a userspace process it is not possible to globally disable interrupts. Thus it is not possible to rely on epicsInterruptLock() when accessing resources which must be shared between kernel and user-space.
This makes it difficult to perform read-modify-write operations on shared registers. This can be an intractable problem for a device which implements its interrupt enable register as a bit mask.
When evaluating hardware for the suitability look for an interrupt mask register and status register.
This should not be an issue for devices having a single interrupt condition. Devices using PCI to local bus bridges like the PLX PCI9030 should be usable. Also, devices supporting version 2.3 or greater of PCI standard can make use of the standard master interrupt enable/status bits in the control and status registers.
To allow IOCs to run with minimal privlages it is advisable to change the permissions of the special files use by devlib2. This can be done either manually, or by configuring the UDEV daemon.
When attempting to make use of a PCI devices, devlib2 will attempt to access several files.
The "resource*" files exist one for each BAR. devPCIToLocalAddr() will first attempt to open the corresponding file.
These are possible locations of symlinks to "/dev/uio#". devPCIToLocalAddr() will next attempt to open each in turn, then map the a region corresponding to the BAR number, or the number of mappings when the DEVLIB_MAP_UIOCOMPACT flag is given.
In this example, the permissions of /resource0 are changed.
And for a UIO device
To discover possible attributes for matching use "udevadm info" and look for the first SUBSYSTEM=="pci" paragraph.
If not device file exists, then the PCI geographic address can be used
The effects of a new rules file can be tested with "udevadm -a add test".
More information on writing UIO kernel modules can be found:
The kernel source tree contains several example drivers.
1.8.13